클라이언트를 위해 처음으로 화면 녹화를 변환했을 때 모든 사람이 하는 방식으로 수행했습니다. MOV를 변환기에 떨어뜨리고 11분을 기다렸다가 MP4를 보냈습니다. 파일은 40% 더 작고 눈에 띄게 부드러웠고 클라이언트는 데모의 텍스트가 왜 흐릿해 보였는지 물었습니다. 대답은 애초에 변환이 필요하지 않다는 것이었습니다. 그 MOV 내부의 비디오는 이미 H.264였습니다. 이것이 바로 MP4가 보유하고 있는 것입니다. 11분의 재인코딩은 약 2초 만에 바이트와 동일할 수 있는 파일을 생성하기 위해 품질을 버렸습니다. 그것이 바로 이면의 전체 아이디어다. 비디오 변환기 에 Toolz.dev, 그리고 어떤 도구를 사용하든 이해하는 것이 좋습니다.
TL;DR: 대부분의 MOV 파일에는 이미 H.264 비디오와 AAC 오디오가 포함되어 있습니다. 이는 MP4에 포함된 것과 동일한 것이므로 변환할 때 다시 인코딩할 필요가 없습니다. 스트림은 새 컨테이너로 복사되며, 이 프로세스는 Remuxing입니다. 몇 분이 아닌 몇 초가 걸리고 픽셀이 디코딩되거나 다시 압축되지 않기 때문에 아무 것도 잃지 않습니다. 더 툴즈 비디오 변환기 기본적으로 복사하고 형식에 진정으로 필요한 경우에만 다시 인코딩하며 브라우저 탭 내에서 WebAssembly로 컴파일된 FFmpeg를 통해 실행되므로 비디오가 업로드되지 않습니다.
컨테이너란 무엇이며, 왜 중요한가?
비디오 파일에는 두 개의 레이어가 있으며 비디오 변환에 대한 거의 모든 혼란스러운 점은 혼합하여 발생합니다.
X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 10 컨테이너 래퍼입니다. 스트림을 보유하고, 각 프레임이 시작되는 시간, 각 프레임이 시작되는 위치, 오디오 트랙이 어떤 언어에 있는지, 어떤 썸네일을 표시할지 기록합니다. MP4, MOV, WebM, AVI 및 MKV는 컨테이너입니다. 파일의 확장명은 비디오가 아닌 컨테이너의 이름을 지정합니다.
X-1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 1000 X 10 성직복 내부의 압축입니다. H.264, H.265, VP9 및 AV1 그림을 압축합니다. AAC, Opus, MP3 및 FLAC은 사운드를 압축합니다. 코덱은 파일이 주어진 장치에서 재생되는지 여부를 결정하는 것이며 변경하는 데 시간이 걸립니다.
이 두 가지 아이디어를 분리하면 유용한 질문이 "이게 무슨 형식입니까?"가 아닌 "어떤 레이어를 변경하고 있습니까?"가됩니다. 컨테이너를 교체하는 것은 저렴합니다. 코덱을 변경하는 것은 비용이 많이 들고 손실이 많습니다. 그것들을 구별하지 않는 도구는 매번 값싼 작업에 대해 값비싼 작업을 청구합니다.
MOV에서 MP4로 거의 순간적인 이유는 무엇입니까?
MOV와 MP4는 가까운 친척이기 때문입니다. 파일 형식은 MP4가 구축된 ISO 기본 미디어 파일 형식의 기초가 되었기 때문에 두 컨테이너는 거의 같은 방식으로 데이터를 구성합니다. 그리고 그 안에 있는 스트림은 일반적으로 동일한 스트림입니다. iPhone 녹화, Mac 화면 캡처, DSLR 클립 및 Premiere 내보내기 모두 일반적으로 .mov 또는 .mp4로 래핑하든 상관없이 AAC 오디오가 포함된 H.264 비디오를 생성합니다.
그래서 변환은 ...의 부러 하다: 각 스트림이 시작되고 끝나는 위치를 읽고, 해당 바이트를 새 컨테이너에 쓰고, 새 인덱스를 작성하십시오. 프레임이 디코딩되지 않습니다. 픽셀이 검사되지 않습니다. 출력은 다른 래퍼의 동일한 비디오 데이터이며, 디코딩된 프레임이 비트 단위 비트 동일하다는 엄격한 의미에서 무손실입니다.
실제로 2분짜리 클립이 1분 이상이 아닌 약 1초 만에 끝나고 비디오 데이터가 변경되지 않았기 때문에 파일 크기가 거의 움직이지 않는다는 것을 의미합니다. 이 작업에 몇 분이 걸리고 더 작은 파일을 다시 인코딩하는 변환기가 다시 인코딩되었으며 크기 드롭은 더 이상 사용할 수 없는 품질입니다.
각 경로가 적용되는 시점입니다.
| 소스 | 타겟 | 무슨 일이 일어나는지 | 속도 | 품질 비용 |
|---|---|---|---|---|
| MOV (H.264/AAC) | MP4 | 리뮤지, 스트림 복사 | 초 | 없음 |
| MP4 (H.264/AAC) | 정기권 | 리뮤지, 스트림 복사 | 초 | 없음 |
| MOV 또는 MP4 | 웨브엠 | 다시 등의 뜻 -VP9/Opus로 인코딩 | 분 | 일부는 설정에 따라 다릅니다. |
| 모든 비디오 | GIF | 다시 등의 뜻 -인코딩, 팔레트가 256색으로 축소 | 분 | 심한, 설계상 |
| GIF | MP4 | 다시 등의 뜻 - H.264로 인코딩 | 초에서 1분으로 | 미성년자, 일반적으로 보이지 않음 |
언제 다시 인코딩해야 합니까?
3가지 경우, 그리고 3건만.
대상 컨테이너는 코덱을 보유할 수 없습니다. WebM은 비디오의 경우 VP8, VP9 및 AV1을, 오디오에는 Vorbis 또는 Opus를 허용합니다. H.264를 허용하지 않습니다. 따라서 MP4에서 WebM으로의 MP4는 항상 실제 변환이며 실시간으로 소요됩니다.
소스 코덱은 H.264 래퍼의 H.264가 아닙니다. 카메라의 ProRes MOV, DV 캡처, 오래된 DivX AVI: MP4가 기술적으로 어떤 경우에는 기술적으로 휴대할 수 있지만 대부분의 플레이어가 거부하는 코덱을 보유하고 있습니다. 변환은 디코딩 및 재 압축을 의미합니다.
당신은 의도적으로 그림을 변경하고 있습니다. 해상도를 낮추고, 비트 전송률을 줄이고, 프레임 속도를 변경합니다. 다시 압축하지 않고 비디오를 작게 만들 수있는 방법이 없습니다. 그래서 파일을 축소하는 것은 형식을 변경하는 것과 다른 작업입니다. 이를 위해, 비디오 압축기, 압축과 변환은 사람들이 합리적으로 혼동하는 다른 작업이기 때문에 정확히 존재합니다.
GIF로 변환하는 것이 소리보다 훨씬 더 나빠진 이유는 무엇입니까?
GIF는 전체 이미지에 대해 최대 256가지 색상을 보유합니다. 이것이 형식의 정의 한계이며, GIF89A 사양 1989년에는 인코더가 해결할 수 없습니다. 따라서 비디오에서 GIF로의 모든 변환은 소스에 포함될 수 있는 1,670만 가지 색상 중 256가지 색상을 선택해야 합니다.
순진하게 수행되며 각 프레임은 자체적으로 최고의 256을 선택합니다. 그 결과 동일한 셔츠가 연속 프레임에서 약간 다른 색상을 사용하고 전체 사진이 크롤링되고 반짝이는 것처럼 보입니다. 이것은 비디오-GIF 출력에 대한 가장 일반적인 단일 불만이며 전적으로 프레임별 팔레트의 인공물입니다.
수정은 2-패스 인코딩입니다. 먼저 전체 클립을 스캔하고 모든 것을 제공하는 하나의 팔레트를 만든 다음 공유 팔레트에 대해 모든 프레임을 인코딩합니다. 색상이 움직이지 않기 때문에 크롤링이 사라집니다. Toolz 변환기는 두 패스를 모두 실행하므로 GIF는 단일 패스 도구보다 잠시 시간이 걸리고 상당히 안정적으로 보입니다.
두 번째 놀라움은 크기입니다. GIF는 현대 비디오 코덱을 효율적으로 만드는 모션 보정이 없는 프레임 간의 차이점이 아닌 전체 프레임을 저장합니다. MP4로 400KB인 5초 클립은 일상적으로 GIF로 4MB가 됩니다. 사람들이 생각하는 것보다 더 자주 할 가치가 있는 개종으로 이어집니다.
대신 GIF를 MP4로 변환해야 합니까?
거의 항상 그렇습니다. H.264와 동일한 애니메이션은 일반적으로 크기의 10분의 1이며, 큰 GIF가 정지되거나 스로틀되는 모바일 브라우저에서 인라인으로 재생되며, 전화기를 가열하지 않도록 하드웨어 디코딩을 지원합니다. 모든 주요 소셜 플랫폼은 이러한 이유로 업로드한 GIF를 비디오로 조용히 변환합니다. 이는 작업에 적합한 형식에 대한 합리적인 신호입니다.
한 가지 세부 사항은 변환이 전혀 작동하는지 여부를 결정합니다. H.264는 픽셀 크기가 필요하기 때문에 표준 크로마 샘플링을 조직하고 GIF에는 종종 홀수 GIF가 있습니다. 601픽셀 너비의 GIF는 지극히 정상입니다. 인코더가 홀수 치수를 전달한 경우 비밀 메시지로 완전히 실패하거나 자동으로 프레임을 패딩합니다. 여기서 변환기는 인코딩하기 전에 크기를 가장 가까운 짝수로 반올림합니다. 이는 아무도 볼 수 없는 1픽셀 자르기이며 파일과 오류의 차이입니다.
동영상이 아무데나 업로드되나요?
아니요, 이것은 사용 방법을 변경하는 부분입니다. 전환이 진행됩니다 WebAssembly로 컴파일된 FFmpeg, 브라우저 탭에서 실행 중입니다. 파일은 디스크에서 페이지 메모리로 읽고 그곳에서 변환되고 다운로드로 다시 전달됩니다.
여기에는 세 가지 실용적인 결과가 있습니다.
- 아무것도 당신의 기계를 떠나지 않습니다. DevTools를 열고 네트워크 패널로 전환하고 파일을 변환하고 시청: No Request에서 비디오를 전달합니다. NDA의 영상, 미공개 제품 데모, 제3자 업로드에 동의하지 않은 사람이 있는 모든 것, 이것이 사용 가능한 것과 그렇지 않은 것의 차이입니다.
- 대기열과 크기 상한선이 없습니다. 당신은 다른 사람들의 직업 뒤에 기다리지 않으며 계획이 당신을 100MB로 제한하지 않습니다. 진정한 한계는 브라우저 탭의 메모리로, 일반 노트북에서 수백 메가바이트의 파일을 편안하게 처리합니다.
- 첫 번째 실행은 나머지보다 느립니다. FFmpeg WebAssembly 번들은 한 번 다운로드해야 하며 이는 몇 초입니다. 그 후 캐시되고 후속 변환이 즉시 시작됩니다.
거래는 정직합니다. 전용 인코더가 있는 서버는 매우 큰 파일에서 더 빠릅니다. 대부분의 사람들이 변환하는 클립의 경우 업로드 및 다운로드의 왕복 비용은 인코딩이 저장하는 것보다 더 많은 시간이 소요됩니다.
어떤 설정이 차이를 만드는가?
리뮤직의 경우, 없음. 아무것도 다시 결정되지 않기 때문에 구성할 것이 없습니다.
재인코딩의 경우 2.
결의안 다른 설정보다 더 많은 작업을 수행합니다. 너비와 높이의 4분의 1을 픽셀 수로 절반으로 줄이고 파일은 대략 다음과 같습니다. 1080p에서 720p로 이동하는 것이 가장 효과적인 단일 변경이며 전화 화면에서는 그 차이를 보기 어렵습니다.
비트 전송률 또는 품질 목표 다른 것입니다. 대부분의 도구는 이것을 숫자가 아닌 품질 슬라이더로 노출합니다. 이는 올바른 호출입니다. 고정 비트 전송률은 간단한 장면에서 비트를 낭비하고 복잡한 장면을 굶주리는 반면 품질 대상은 각 장면에 필요한 것을 소비합니다.
프레임 속도는 사람들이 도달하는 세 번째 레버이며 일반적으로 해서는 안 됩니다. 30fps를 15fps로 떨어뜨리면 프레임이 절반으로 줄어들지만 모션이 눈에 띄게 더듬거리며 연속 프레임이 서로 잘 압축되기 때문에 해상도 변경보다 덜 절약됩니다.
# What a remux looks like at the command line. -c copy is the whole trick:
# copy the streams, do not decode them.
ffmpeg -i input.mov -c copy output.mp4
# Compare to a real conversion, which decodes and re-compresses every frame.
ffmpeg -i input.mov -c:v libx264 -crf 23 -c:a aac output.mp4
첫 번째 명령은 파일을 읽는 데 걸리는 시간에 완료됩니다. 두 번째는 비디오가 복잡하기 때문에 시간이 걸립니다. 사용 가치가있는 모든 브라우저 기반 변환기는 내부적으로 동일한 구분을합니다. 비디오 변환기 해요.
컨테이너가 변경되면 오디오는 어떻게 됩니까?
리뮤즈에서는 전혀 없습니다. AAC 트랙은 비디오와 함께 바이트에 대해 바이트에 걸쳐 복사되므로 MOV에서 MP4로의 변환이 사운드를 저하시킬 수 없는 이유입니다. 동일한 압축된 오디오 데이터가 새 래퍼에 있습니다.
재인코딩할 때 대상에 따라 다릅니다. WebM은 AAC를 휴대할 수 없으므로 오디오가 Opus로 다시 압축되며 이는 이미 손실된 오디오에 적용되는 손실 단계입니다. 말로는 거의 듣지 않고 심벌즈와 같이 고주파수 디테일이 있는 음악에서 가끔 들을 수 있습니다.
때로는 오디오가 당신이 원하는 유일한 것입니다. 촬영되었지만 팟캐스트로 게시될 녹음된 인터뷰, 휴대전화로 원하는 강의, 필사 중인 사운드트랙. 전체 비디오를 변환한 다음 사진을 삭제하는 것은 느린 방법입니다. 그만큼 오디오 추출기 사운드를 직접 뽑아내고 MP4 및 MOV 소스의 경우 Re-Exux와 똑같은 트릭인 재인코딩 없이 기존 AAC 트랙을 M4A에 복사할 수 있습니다. 가지고 있는 파일이 이미 오디오이고 형식만 잘못된 경우 오디오 변환기 그 쪽을 처리합니다.
한 가지 알아야 할 점은 비디오 파일에 여러 오디오 트랙이 있으며 다른 언어 또는 별도의 설명에 대해 사용할 수 있습니다. 이 도구를 포함한 대부분의 브라우저 기반 도구는 첫 번째 트랙에서 작동합니다. 소스에 둘 이상의 것이 있고 특정 소스가 필요한 경우, 이는 명시적 스트림 선택기가 있는 명령줄에서 FFMPEG에 대한 작업입니다.
어떤 형식으로 누구에게 보내야 합니까?
대부분의 개종 작업은 실제로 변장을 한 이 질문입니다. 정직한 대답은 H.264 비디오 및 AAC 오디오가 포함된 MP4가 다른 어떤 조합보다 훨씬 더 자주 올바른 선택이라는 것입니다. 왜냐하면 생각 없이 본질적으로 모든 곳에서 재생되는 유일한 조합이기 때문입니다.
| 어디로 가는지 | 송전하다 | 왜 |
|---|---|---|
| 고객, 동료, 이메일 | MP4 (H.264/AAC) | 10년 동안 만든 모든 전화, 노트북 및 브라우저에서 재생 |
| 당신이 통제하는 웹사이트 | MP4, WebM을 두 번째 소스로 사용 | WebM은 동일한 품질에서 더 작고 MP4는 대체 |
| 소셜 플랫폼 | MP4 | 그들은 당신이 보내는 모든 것을 다시 인코딩하므로 가장 깨끗한 입력을 제공하십시오. |
| 편집 타임라인 | 원본 파일 | 비용 품질을 편집하기 전에 모든 전환을 되돌릴 수 없음 |
| 크기 상한이 있는 채팅 앱 | MP4, 압축 | 형식이 아닌 크기를 변경 |
| 이메일 서명 또는 README의 인라인 | mp4 허용되는 경우, gif가 허용되지 않는 경우에만 | GIF는 선택이 아닌 비디오를 거부하는 장소에 대한 대체입니다. |
가장 큰 슬픔을 덜어주는 행은 편집입니다. 사람들은 가져오기 전에 영상을 변환하고 품질을 잃은 다음 편집 및 내보내기, 더 많은 손실을 입습니다. 타임라인이 원본을 수락하면 원본을 제공하고 끝에 한 번 변환합니다.
또 다른 일반적인 실수는 압축을 시도했을 때 변환하는 것입니다. "업로드 한도에 비해 너무 큰 파일입니다.”는 형식 문제가 아닙니다. MOV를 MP4로 변경해도 비디오 데이터가 동일하기 때문에 도움이 되지 않습니다. 작게 만든다는 것은 의도적으로 다시 인코딩하는 것을 의미합니다. 비디오 압축기 필요하지 않은 부품을 위해 또는 트리밍합니다. 비디오 트리머 먼저. 30초는 아무도 인코딩하지 않아도 되는 30초이며 모든 품질 설정을 능가합니다.
이미지 변환과 비교하면 어떻습니까?
이미지에 대해 동일한 컨테이너 대 코덱 분할이 존재하며 동일한 결과를 초래합니다. 일부 변환은 저렴하고 무손실이며 다른 변환은 정보를 버립니다. PNG를 BMP로 변환하면 모든 픽셀이 유지되고 JPEG로 변환하는 것은 그렇지 않습니다. 그만큼 이미지 포맷 변환기 가이드 그 쪽을 덮고, 이미지 압축 가이드 여기에 적합보다 더 깊이 있는 손실 대 무손실 구분을 다룹니다.
실용적인 차이는 규모입니다. 잘못된 이미지 변환은 한 장의 사진을 요합니다. 잘못된 비디오 변환은 11분의 비용이 들며 클라이언트가 텍스트가 왜 흐릿하게 보이는지 묻는 질문입니다.
일반적인 질문
MOV 또는 MP4가 더 나은가요? 대부분의 목적에서 일반적으로 동일한 비디오가 포함되어 있기 때문입니다. MP4는 더 넓은 장치 지원을 가지고 있으므로 공유를 위한 더 안전한 기본값입니다. MOV는 Apple Tools가 생산하는 것이며 MP4가 제공하지 않는 일부 전문 코덱을 제공합니다.
변환된 파일이 커진 이유는 무엇입니까? 덜 효율적인 코덱이나 컨테이너 또는 GIF로 변환했습니다. 리뮤직은 크기를 의미 있게 바꾸지 않으며, 이전 코덱으로 인코딩하면 쉽게 확장할 수 있습니다.
내 mp4가 이전 장치에서 재생되지 않는 이유는 무엇입니까? 컨테이너는 정상이지만 코덱은 그렇지 않습니다. MP4 래퍼의 H.265 스트림은 확장이 친숙해 보이지만 H.264만 디코딩하는 하드웨어에서는 재생되지 않습니다. 이것은 중요한 레이어의 가장 명확한 경우입니다.
