한 고객이 버그에 대한 짧은 화면 기록을 요청한 적이 있습니다. 캡처는 4분 동안 212MB였습니다. 이는 60프레임의 초당 60프레임의 Retina 디스플레이 비용이 드는 비용이며, 오류 메시지의 25MB 제한이 내가 이길 수 있는 숫자가 아니라는 것을 확인하기 전에 메일 서버가 두 번 튕겨 나왔습니다. 첨부 파일은 Base64로 인코딩되어 있으므로 파일이 남은 것보다 약 1/3 더 크게 도착합니다. 25가 아닌 18MB 이하로 했어야 했는데 녹음은 6MB, 720p, 오디오가 없었고 완벽하게 선명해 보였습니다. 버그의 화면 녹화는 대부분 커서가 움직이는 정적 페이지이고 아름답게 압축되기 때문입니다. 유용한 교훈은 설정이 아니었습니다. 이 작업은 모두 동일한 3줄 계산이며, 일단 할 수 있으면 추측을 중단합니다.
TL;DR: 일정 비율 요소는 품질 대상이고 결과 크기는 푸티지가 전달하는 모션의 양에 따라 달라지기 때문에 품질 수준에서는 파일 크기를 지정하지 않습니다. 하드한도에 도달하려면 거꾸로 작업하십시오. 대상 비트 전송률은 초당 킬로비트 단위의 크기를 바이트 시간 8로 나누고 지속 시간(초)을 1000으로 나눈 값입니다. 그런 다음 해당 숫자 아래에 있는 일반 비트 전송률의 해상도를 선택합니다. 1080p를 720p로 떨어뜨리면 어떤 품질의 슬라이더보다 더 많은 것을 절약할 수 있으며, 오디오를 삭제하는 것은 사람들이 예상하는 것보다 더 많이 절약할 수 있습니다. 그만큼 비디오 압축기 on Toolz.dev는 자신의 브라우저 탭에서 WebAssembly로 컴파일된 FFmpeg를 통해 인코딩을 실행하고, 시작하기 전에 추정치를 표시하고, 파일을 업로드하지 않습니다.
품질 설정이 크기를 약속하지 않는 이유는 무엇입니까?
비디오를 압축하는 가장 일반적인 두 가지 방법은 다른 질문에 답하고 더 나은 결과를 제공하는 방법은 미리 크기를 말할 수 없는 방법이기 때문입니다.
타겟 비트 전송률 모드는 다음과 같이 말합니다. 그러면 크기가 산술적이고 정확히 예측 가능하며 품질이 크게 흔들립니다. 스틸 타이틀 카드와 핸드헬드 비의 샷은 모두 2Mbps를 얻으므로 타이틀 카드는 대부분을 낭비하고 비는 젖은 자갈처럼 보입니다.
일정한 비율 계수 모드는 다음과 같이 말합니다. 이 품질을 유지하고 필요한 모든 비트를 사용하십시오. 쉬운 프레임은 약간의 비트를 얻고, 하드 프레임은 많은 것을 얻고, 사진은 처음부터 끝까지 시각적으로 유지됩니다. 크기는 무엇이든지.
모든 최신 인코더는 라이브 스트리밍되지 않은 모든 것에 대해 두 번째 엔코더를 권장하며 여기에서 압축기가 사용하는 것입니다. 비용은 버튼을 누르기 전 페이지의 숫자가 해당 해상도와 품질에 대한 일반적인 비트 전송률에서 파생된 추정치이며 실제 그림이 영상과 함께 이동한다는 것입니다. 정적 화면 기록은 일상적으로 추정치의 절반에 도달합니다. 움직이는 물의 휴대용 영상이 그 위에 착륙할 수 있습니다. 색종이, 눈, 바람의 잎사귀와 카메라 그레인은 모든 추정치를 뛰어넘는 네 가지입니다. 모두 무작위 소음에 가깝고 소음은 압축으로 할 수 없는 한 가지이기 때문입니다.
레벨을 선택할 때 CRF는 무엇을 선택합니까?
8비트 H.264에 대해 0에서 51까지의 스케일을 실행합니다. 여기서 0은 무손실이고 51은 볼 수 없으며, FFMPEG H.264 인코딩 가이드 기본값은 23, 제정한 작업 범위는 대략 17에서 28입니다. 기억할 가치가 있는 속성은 저울이 로그라는 것입니다. 6의 변화는 비트 전송률의 대략 절반 또는 두 배입니다. 그 단일 사실은 각 레벨이 시도하기 전에 무엇을 하는지 알려줍니다.
컴프레서는 CRF 26과 27의 차이가 보이지 않는 반면 23과 33의 차이가 전체 포인트이기 때문에 슬라이더가 아닌 3개를 제공합니다.
| 레벨 | H.264 CRF | VP9 CRF | 오디오 | 그것은 무엇을 위해 |
|---|---|---|---|---|
| 라이트 | 23 | 31 | 160kbps | 다시 편집할 사본과 영상을 보관합니다. 거의 시각적으로 무손실합니다. |
| 균형 잡힌 | 28 | 36 | 128kbps | 평범한 대답. 빛의 비트 전송률의 약 절반이며 노트북 화면에서 차이를 찾아야 합니다. |
| 강한 | 33 | 42 | 96kbps | 하드한도에 도달합니다. 유물은 상세한 영상에 표시되기 시작하며 채팅 업로드에는 아무도 신경 쓰지 않습니다. |
VP9 숫자는 별도의 척도이므로 관련이 없는 것처럼 보입니다. 라이트 레벨 31은 바로 Google의 것입니다. 주문형 비디오에 대한 VP9 인코딩 권장 사항 1080p의 목표 품질로 나열하고 나머지 테이블은 720p의 경우 32, 480p의 경우 33 또는 34, 4k의 경우 15를 책갈피에 보관할 가치가 있습니다.
어느 것이 더 많은 공간을 절약하고 품질이 낮거나 픽셀을 더 적게 절약합니까?
픽셀 수가 적고 넓은 여백으로 가깝지 않습니다.
해상도는 2차원 수량입니다. 1080p에서 720p로 가는 것은 3분의 1이 아니며 207만 픽셀은 092만 픽셀이므로 인코더는 단일 품질 결정을 내리기 전에 설명할 수 있는 픽셀 수가 56% 적습니다. 파일은 대략 다음과 같습니다. 4K에서 1080P로 이동하면 4분의 3이 제거됩니다.
다음은 도구가 추정하는 일반적인 비트 전송률을 사용하여 소스 높이 및 수준별로 1분 클립이 도달하는 것입니다. 오디오가 포함되어 있습니다.
| 소스 | 라이트 | 균형 잡힌 | 강한 |
|---|---|---|---|
| 4K (2160p) | 106MB | 61MB | 35MB |
| 1080p | 35MB | 20 메가바이트 | 11MB |
| 720p | 20 메가바이트 | 12MB | 7MB |
| 480p | 10MB | 6MB | 4MB |
그것을 가로질러 읽으십시오. 품질 열을 한 단계 아래로 이동하면 약 43%를 절약할 수 있습니다. 해상도 열을 한 단계 아래로 이동하면 약 42%가 절약됩니다. 품질 단계가 3개 후에 떨어지고 가시적인 인공물이 발생한다는 것을 알 수 있을 때까지 동점처럼 보이지만, 해상도 단계는 대부분의 사람들이 시청할 화면에서 비용이 전혀 들지 않습니다. 느슨한 메시지에 표시된 1080p 클립이 약 400픽셀 너비의 상자에 표시됩니다.
시도한 순서는 다음과 같습니다. 시청자가 현실적으로 사용할 수 있는 모든 항목으로 해상도를 삭제하고 품질을 균형 있게 유지하며 아직 완료하지 않은 경우에만 강력하게 도달합니다.
8MB와 같은 하드 한계에 어떻게 착륙합니까?
거꾸로 작업하십시오. 전체 계산은 한 줄이며 배울 가치가 있는 비디오 산술의 유일한 부분입니다.
# total bitrate (kbps) = target size (bytes) x 8 / duration (s) / 1000
#
# 8 MB, 45-second clip:
# 8,000,000 x 8 / 45 / 1000 = 1,422 kbps total
# minus 96 kbps of audio = 1,326 kbps for video
#
# 1080p strong is ~1,400 kbps video -> about 8.4 MB. Just over.
# 720p strong is ~800 kbps video -> about 5.0 MB. Comfortable.
#
# the equivalent single pass, if you have ffmpeg installed:
ffmpeg -i input.mp4 -c:v libx264 -crf 33 -preset fast \
-vf scale=-2:720 -c:a aac -b:a 96k \
-movflags +faststart -pix_fmt yuv420p output.mp4
세 가지가 실제로 이것을 신뢰할 수 있습니다.
- 헤드룸을 떠나십시오. 한도의 80%를 목표로 한다. CRF는 크기 대상에 도달하지 않으며, 한 번 오버슈트는 파일을 보내는 시간입니다.
- 이메일로 진행되는 경우 인코딩 오버헤드를 계산합니다. base64는 24비트의 입력마다 4자로 표시됩니다. RFC 2045, 따라서 부착물은 와이어에서 3분의 1만큼 팽창합니다. 25MB 사서함 한도는 실제 파일의 약 18MB입니다.
- 당신이 기억하는 숫자를 믿지 마십시오. Discord의 무료 업로드 제한은 8MB, 25MB, 10MB, 2026년 8월 현재 20MB입니다. Gmail은 수년 동안 25MB로 유지되었습니다. WhatsApp은 귀하가 보내는 모든 것을 다시 압축합니다. 필요한 날의 제한을 확인한 다음 산술을 수행하십시오.
클립이 보여주고 싶은 것보다 길면 클립을 짜는 것보다 잘라내는 것이 좋습니다. 지속 시간을 절반으로 줄이면 전체 품질에서 크기가 절반으로 줄어듭니다. 그만큼 비디오 트리머 절단이 키프레임 근처에 도착할 때 전혀 다시 인코딩하지 않고 범위를 가져오고 결과는 크기의 절반에서 바이트 동일 영상이 됩니다.
프레임 속도를 낮추는 것이 도움이 됩니까?
생각보다 적고 목록에 있는 다른 어떤 것보다 나빠 보입니다.
그 이유는 연속 프레임이 이미 서로 압축되기 때문입니다. 비디오 코덱은 하나의 풀 프레임을 저장한 다음 차이점을 설명하므로 60fps 클립의 프레임 31은 프레임 30과 거의 동일하기 때문에 거의 무료입니다. 그것을 버리는 것은 당신이 저장한다고 상상하는 비트를 저장하지 않습니다. 일반적인 속도로 절약은 무료보다 선형에 더 가깝기 때문에 60fps에서 30fps는 절반이 아닌 3분의 1이 될 것이며 30fps에서 15fps는 모든 카메라 움직임에서 가시적인 저더를 제공합니다.
올바른 호출인 경우 두 가지가 있습니다. 대부분 정적 콘텐츠의 화면 녹화는 15fps에서 읽을 수 있는 것이 전혀 없으며, 이는 일반적으로 한도 아래로 최선을 다하는 경우입니다. 그리고 시청자가 모션을 눈치채지 못하고 12~15fps의 fps에서 살아남는 페이지의 애니메이션으로 변환 중인 영상을 만듭니다.
사람이나 카메라가 있는 모든 것에 대해 프레임 속도를 그대로 두고 대신 해상도를 낮추십시오.
오디오가 살아남아야 합니까?
오디오가 무료가 아니기 때문에 오디오가 무엇을 위한 것인지 물어보십시오.
128kbps의 오디오로 10분 동안 녹음하면 9.6MB의 사운드가 전송되며, 이는 사진이 한 비트가 되기 전에. 해당 오디오가 룸 윙윙거리는 소리가 있는 무성 화면 캡처 또는 교체할 음악 또는 이미 전사된 음성 트랙인 경우 사용 가능한 가장 쉬운 절약이 될 수 있으며 시청자에게 비용이 들지 않습니다. 압축기에는 정확히 그것을 위한 스위치가 있습니다. -an 오디오 스트림을 완전히 생략합니다.
소리가 중요할 때 레벨은 기존 포인트인 160에서 128kbps로 떨어집니다. 96kbps AAC는 말하기에 적합하고 음악에 대해 가청합니다. 파일이 필사하거나 편집할 수 있도록 오디오만 사용하려면 오디오 추출기 영상을 건드리지 않고 트랙을 빼내고, 오디오 변환기 자체 조건으로 다시 인코딩합니다.
한 가지 세부 사항이 사람들을 사로잡습니다. 오디오 트랙이 없는 비디오는 대부분의 플레이어에서 자동으로 재생되며 트랙이 음소거될 것으로 예상되는 몇 가지 오래된 모바일 브라우저에서 자동 재생되지 않습니다. 클립이 웹 페이지로 이동하는 경우 오늘날 모든 브라우저 배송이 비디오 전용 MP4를 올바르게 처리하지만 자동 8kbps 트랙이 없는 것보다 안전합니다.
WebM은 추가로 기다릴 가치가 있습니까?
파일을 여는 사람에 따라 다릅니다.
WebM 컨테이너의 VP9는 비슷한 가시적 품질로 H.264보다 약 4분의 1 작은 착륙합니다. 그것은 진정한 이득이며, 브라우저가 그것을 재생할 수 있다는 유일한 요구 사항인 자신의 사이트에서 WebM이 일반적으로 더 나은 파일입니다. Chrome, Firefox 및 Edge는 10년 동안 VP9를 지원했으며 Safari는 버전 14부터 사용했습니다.
비용은 두 번 나타납니다. VP9 인코딩은 x264보다 느리며, 브라우저에서 거의 그렇지 않으며, 하나의 세부 정보는 명령을 직접 실행하는 모든 사람을 넘어뜨립니다. VP9는 비트 전송률이 명시적으로 0일 때만 품질 목표를 존중합니다. 통용하다 -crf 36 자체적으로 그리고 인코더는 대신 기본 비트 전송률을 대신 사용하고 당신을 무시합니다. 필요하다 -crf 36 -b:v 0, 도구가 보내는 것입니다.
두 번째 비용은 브라우저가 아닌 모든 것입니다. 채팅 앱, CMS 업로드 필드, 비디오 편집기, PowerPoint, 파일 관리자의 미리보기 창, 고객의 전화: 이들 중 다수가 MP4를 허용하고 WebM에서 어깨를 으쓱합니다. 파일이 사람에게 전달되는 경우 H.264로 MP4를 보내십시오. 만약 당신이 통제하는 페이지에 들어가는 경우, WebM. 그 동일한 분할은 전체 형식 질문을 통해 실행됩니다. 리뮤스 가이드 전환 측면에서 커버합니다.
압축된 MP4가 때때로 재생을 거부하는 이유는 무엇입니까?
인덱스가 끝난 위치와 그만두면 안되는 플래그입니다.
MP4는 모든 프레임이 시작되는 위치를 설명하는 목차를 유지합니다. 일반적으로 기록된 인코더는 모든 것이 진행되는 동안 모든 것을 발견하고 파일의 끝에 테이블을 작성합니다. 디스크에서 재생을 위해 괜찮습니다. http를 통해 제공되는 것은 플레이어가 전체 파일을 가질 때까지 시작할 수 없다는 것을 의미하므로 채팅 앱이나 CMS의 40MB 비디오는 다운로드하는 동안 아무 것도 하지 않고 앉아서 시작합니다.
-movflags +faststart 완성된 파일을 두 번째 전달하고 해당 테이블을 앞으로 이동합니다. 인코딩은 잠시 더 오래 걸리고 1초 후에 비디오가 재생되기 시작합니다. 컴프레서가 생산하는 모든 MP4에는 그것을 가지고 있습니다.
이 명령에는 크기가 아닌 호환성을 위해 두 개의 플래그가 더 있습니다. -pix_fmt yuv420p 4:2:2 또는 4:4:4 MP4가 유효하고 긴 하드웨어 디코더 목록에서 재생을 거부하기 때문에 4:2:0 크로마 서브샘플링을 수행합니다. 그리고 스케일 필터가 기록됩니다. scale=-2:720 보다는 scale=-1:720, H.264는 짝수의 픽셀 크기와 -2 계산된 너비를 짝수로 반올림합니다. 홀수 너비를 요구하면 인코딩이 "2로 나눌 수 없는 너비"로 실패합니다.
두 번 압축이 훨씬 더 나빠 보이는 이유는 무엇입니까?
손실 압축이 능숙하지 않기 때문에 세대 손실이며 사람들이 예상하는 것보다 가파르게 발생합니다.
첫 번째 인코딩은 눈이 놓치지 않을 것이라고 판단하는 세부 사항을 버리고 자신의 인공물을 남깁니다. 가장자리에서 약간의 차단, 부드러운 그라디언트, 고대비 주위에서 울리는 것입니다. 두 번째 인코딩은 이러한 인공물이 그림이 아님을 알 수 있는 방법이 없습니다. 보존할 가치가 있는 콘텐츠로 취급하고, 설명하는 데 사용하는 비트를 사용하고, 위에 자신을 추가합니다. 동일한 클립에 대한 3 라운드의 균형 압축은 더 큰 파일 크기에서 1 라운드의 강력한 라운드보다 나빠 보입니다.
따라서 실제 규칙은 짧습니다. 이미 만든 사본에서 절대 원본에서 압축하지 마십시오. Light Archive 버전과 작은 버전을 모두 보내야 하는 경우 소스에서 둘 다 만드십시오. 그리고 파일이 업로드 시 다시 압축되는 플랫폼을 이미 통과했다면 대부분이 파일을 이미 2세대로 처리합니다.
이것은 동일한 산술입니다. 이미지 압축 그리고 JPEG가 반복해서 저장한 이유는 진흙으로 변하는 이유와 같은 이유입니다. PDF 압축기 문서 전체가 아닌 문서 내부의 이미지에 대해 작업합니다.
파일이 컴퓨터를 떠나나요?
아니요, 도구를 사용할 수 있는 용도를 변경하는 비디오의 경우입니다.
인코딩이 실행됩니다. WebAssembly로 컴파일된 FFmpeg, 브라우저 탭에서 실행. 파일은 디스크에서 페이지 메모리로 읽고 거기에 인코딩되어 다운로드로 다시 전달됩니다. DevTools를 열고 네트워크 패널로 전환하고 무언가를 압축하고 시청하십시오. 요청 없음 비디오가 전달됩니다.
세 가지 결과가 따릅니다.
아무것도 업로드되지 않았으므로 아무것도 유지되지 않습니다. 복사본이 생성되지 않았기 때문에 보존 정책이 삭제되기를 기다리는 서버에 복사본이 없습니다. 미공개 제품 데모, NDA 아래의 영상 또는 제3자 업로드에 동의하지 않은 사람이 있는 모든 사람이 사용 가능한 것과 그렇지 않은 것의 차이입니다.
제한은 계획이 아니라 브라우저입니다. 전체 파일이 탭 메모리에 들어가므로 페이지는 최대 500MB를 허용하고 30분에 단일 패스를 제한하며 4MB 엔진 다운로드 후 2분 인코딩이 아닌 파일을 선택할 때 둘 다 확인합니다. 대기열도, 워터마크도, 계정도 없고 구매할 크기 계층도 없습니다.
첫 번째 실행은 느립니다. FFMPEG WebAssembly 번들은 한 번 다운로드되며 몇 초가 걸리고 이후에 캐시됩니다. 이 도구는 페이지가 열릴 때가 아니라 첫 번째 압축에 로드되므로 페이지 자체가 빠르게 유지됩니다.
데스크탑 인코더는 언제 올바른 도구입니까?
위의 숫자가 제약 조건이 되지 않을 때. 브라우저 탭은 합리적인 인코더이자 잘못된 비디오 파이프라인이며 라인이 어디에 속하는지 명확히 할 가치가 있습니다.
500MB 이상의 파일에 대해 기본으로 이동하거나 30분 동안 클립을 사용하면 탭 메모리가 실제 한계입니다. 쉘의 루프를 통해 40개의 클립이 모든 인터페이스를 통해 40번의 트립을 능가하기 때문에 배치에 대해 기본으로 이동합니다. 단일 CRF 패스로 약속할 수 없는 정확한 크기에 도달하기 위해 2-패스 인코딩이 필요할 때 네이티브로 이동합니다. 그리고 GPU가 20초 안에 WebAssembly를 4분 이상 걸리는 하드웨어 인코딩을 위해 네이티브로 이동합니다.
6. 15분 안에 랩톱에서 아무 것도 설치하지 않고 낯선 사람에게 영상을 건네지 않고 5분 안에 제한을 받아야 하는 클립의 경우 브라우저는 거리만큼 빠른 경로입니다. 그것이 직업이다. 압축기 를 위해 지어졌습니다. 변환기 포맷을 변경하고 이미지 압축기 같은 문제에 대해 1차원 아래로.
