동영상을 제작하거나 기존 파일을 변환하고 웹사이트에 올릴 영상을 준비할 때 가장 중요한 결정 중 하나는 적절한 형식과 압축 설정을 선택하는 것입니다. 파일이 무조건 작다고 좋은 것은 아닙니다. 브라우저에서 안정적으로 재생되고, 스마트폰에서 작동하며, 효율적으로 디코딩되고, 용도에 필요한 화질을 충분히 유지해야 합니다.
저는 MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, x264 인코더 프리셋, 브라우저 호환성, 모바일 하드웨어 디코딩, 영상 화질 측정 방법을 조사했습니다. 동일한 원본 영상을 여러 CRF 값으로 인코딩한 뒤 눈으로 확인하고 객관적인 지표로 비교하는 압축 실험도 진행했습니다.
최종적으로, 동영상 파일 하나만으로 가능한 한 폭넓은 브라우저, 스마트폰, 외부 애플리케이션을 지원해야 한다면 H.264 코덱을 사용하는 MP4를 우선하기로 했습니다.
주로 스마트폰에서 시청하는 짧은 동영상은 미세한 디테일을 모두 보존하는 것보다 빠른 로딩과 작은 파일 크기가 중요했습니다. 큰 데스크톱 모니터에서도 일반적인 재생 중에는 CRF 22와 30의 유의미한 차이를 느끼지 못했기에 x264 CRF 30을 선택했습니다.
다만 이 결정에는 중요한 단서가 있습니다. CRF 30은 영화나 고급 영상 제작물, 최대한의 시각적 충실도가 중요한 영상에 권장하는 설정이 아닙니다. 그런 용도에서는 CRF 20 정도처럼 훨씬 보수적인 값을 출발점으로 삼는 편이 나을 수 있습니다. 장편영화나 고화질 영화 영상에 대해 동일한 수준의 실험을 수행하지 않았으므로 이러한 설정은 별도로 시험해 볼 초기값에 불과합니다.
이 글에서는 이러한 기술적 판단의 근거, 실제 압축 결과와 그 한계, 그리고 프로젝트에 맞는 동영상 형식과 화질 설정을 선택하는 방법을 설명합니다.
1. 동영상 컨테이너와 코덱은 서로 다릅니다
MP4와 WebM을 비교하기 전에 컨테이너와 코덱의 차이를 이해해야 합니다.
컨테이너는 영상, 오디오, 타임스탬프, 메타데이터를 하나의 파일에 담는 형식입니다. 비디오 코덱은 영상 프레임을 압축하고 디코딩하는 방식을 결정합니다.
예를 들어 MP4에는 H.264, HEVC, AV1 영상을 담을 수 있습니다. 확장자는 같아도 이러한 조합은 압축 특성과 기기 요구 사항이 서로 다릅니다.
| 구성요소 | 예시 | 역할 |
|---|---|---|
| 동영상 컨테이너 | MP4, WebM, MOV, MKV | 영상과 오디오, 시간 정보를 하나로 묶음 |
| 비디오 코덱 | H.264, HEVC, VP9, AV1 | 영상 프레임을 압축하고 디코딩함 |
| 오디오 코덱 | AAC, Opus, MP3 | 오디오를 압축하고 디코딩함 |
| 비디오 인코더 | x264, x265, SVT-AV1, libvpx-vp9 | 비디오 압축을 구현함 |
파일 이름의 확장자를 .webm에서 .mp4로 바꾼다고 비디오 코덱이 변환되지는 않습니다. 마찬가지로 AV1 영상을 MP4에 담아도 AV1 디코딩을 지원하지 않는 기기에서는 재생할 수 없습니다.
동영상 호환성을 논할 때는 컨테이너, 비디오 코덱, 오디오 코덱, 코덱 프로파일, 비트 심도, 재생 환경을 함께 고려해야 합니다.
2. MP4와 WebM: 웹 동영상에는 무엇이 더 좋을까?
MP4와 WebM 모두 현재 널리 쓰이는 정식 동영상 컨테이너입니다. 실제 특성은 내부 코덱에 따라 달라지므로 어느 한쪽이 언제나 우월하다고 할 수 없습니다.
H.264를 담은 MP4: 매우 폭넓은 실용적 호환성
H.264 영상과 AAC 오디오를 담은 MP4는 오랫동안 매우 폭넓은 호환성을 확보해 왔습니다. 주요 데스크톱 브라우저와 모바일 브라우저, 운영체제의 동영상 플레이어, 다양한 외부 애플리케이션에서 지원합니다.
스마트폰과 컴퓨터의 하드웨어 비디오 디코더도 널리 지원합니다. 하드웨어 디코딩은 소프트웨어 디코딩보다 CPU 사용량을 줄이고 재생 효율을 높이며 전력 소모를 낮출 수 있습니다.
주요 단점은 압축 효율입니다. 최신 코덱은 체감 화질이 비슷할 때 더 낮은 비트레이트를 달성하는 경우가 많습니다.
그렇더라도 파일 크기를 극한까지 줄이는 것보다 안정적인 재생이 중요하다면 H.264는 여전히 훌륭한 선택입니다.
VP9을 담은 WebM: 효율적인 압축과 브라우저 친화성
WebM에는 일반적으로 VP8, VP9 또는 AV1 영상이 들어가고, 오디오는 보통 Opus나 Vorbis로 인코딩됩니다.
VP9은 비슷한 시각적 품질에서 H.264보다 압축 효율이 좋은 경우가 많습니다. 최신 Safari를 포함한 현재의 브라우저에서 폭넓게 지원합니다.
Safari가 WebM이나 VP9을 전혀 지원하지 않는다고 말하는 것은 정확하지 않습니다. 브라우저 호환성은 시간이 지나며 크게 향상됐습니다.
더 중요한 제약은 브라우저 바깥에서의 호환성입니다. 운영체제 기본 앱, 오래된 기기, 타사 소프트웨어에서는 기존 H.264 MP4만큼 WebM을 일관되게 처리하지 못할 수 있습니다.
재생 기능을 관리할 수 있는 브라우저 전용 서비스라면 WebM은 좋은 선택입니다. 하지만 방문자가 파일을 내려받아 다양한 프로그램으로 열 가능성이 있다면 MP4/H.264 쪽이 결과를 예측하기 쉽습니다.
실제 사용에서 나타나는 차이
| 요구 사항 | MP4 + H.264 | WebM + VP9 |
|---|---|---|
| 최신 브라우저 재생 | 매우 우수 | 우수 |
| 오래된 브라우저와 기기 지원 | 일반적으로 더 좋음 | 환경 의존도가 더 높음 |
| 다운로드 파일 호환성 | 일반적으로 더 좋음 | 기본 앱마다 결과를 예측하기 어려움 |
| 압축 효율 | 양호 | 더 좋은 경우가 많음 |
| 하드웨어 디코딩 | 매우 널리 보급됨 | 흔하지만 기기에 따라 다름 |
| 적합한 용도 | 폭넓게 호환되는 파일 하나 | 클라이언트 환경을 아는 웹 서비스의 효율적 전송 |
핵심은 WebM이 좋은 형식인지가 아닙니다. 자신의 환경에서 압축 효율의 이점이 호환성 측면의 절충을 감수할 만큼 큰지가 중요합니다.
3. H.264, H.265, VP9, AV1: 어떤 코덱을 선택해야 할까?
주요 비디오 코덱마다 압축 효율, 인코딩 비용, 하드웨어 지원, 소프트웨어 호환성, 라이선스 조건 사이의 균형이 다릅니다.
| 코덱 | 압축 효율 | 실제 호환성 | 일반적인 용도 |
|---|---|---|---|
| H.264 / AVC | 양호 | 매우 우수 | 일반 웹 동영상, 모바일 재생, 다운로드 |
| H.265 / HEVC | 대체로 H.264보다 좋음 | 환경에 따라 다름 | 호환되는 Apple 기기, 통제된 환경, 고해상도 영상 |
| VP9 | 대체로 H.264보다 좋음 | 최신 브라우저에서 매우 좋음 | 브라우저 기반 동영상 전송 |
| AV1 | 압축 효율 잠재력이 매우 높음 | 지원이 확대되지만 오래된 기기는 제한적 | 최신 스트리밍과 호환 기기 |
이 표는 정성적인 비교이며 모든 영상에 적용되는 비트레이트 순위가 아닙니다. 실제 효율은 영상 내용, 인코더 구현, 목표 화질, 인코딩 프리셋, 측정 방식에 따라 달라집니다.
H.264: 성숙한 기술, 빠른 디코딩, 넓은 지원 범위
H.264는 높은 수준으로 최적화되어 있으며 방대한 하드웨어와 소프트웨어에서 지원합니다. 별도의 전용 재생 앱 없이 안정적인 동영상 재생이 필요할 때 이런 성숙도가 강점입니다.
약점은 최신 코덱이 영상을 더 효율적으로 압축할 수 있는 경우가 많다는 점입니다. H.264에는 특허 및 라이선스 문제도 있으므로 해당하는 상업적 배포 환경에서는 이를 검토해야 합니다.
H.265 / HEVC: 높은 압축 효율과 호환성의 절충
HEVC는 비슷한 화질에서 H.264보다 비트레이트를 크게 줄일 수 있습니다. 고해상도 콘텐츠나 기기 호환성을 통제할 수 있는 환경에서 특히 매력적입니다.
많은 Apple 기기가 HEVC를 잘 지원합니다. 하지만 브라우저와 외부 애플리케이션 지원은 운영체제 및 설치된 디코딩 구성요소에 따라 다릅니다. 라이선스 역시 고려해야 합니다.
HEVC가 좋은 선택일 수는 있지만, 일반 웹사이트에서 다운로드 가능한 동영상을 HEVC 형식 하나로만 제공하도록 무조건 선택하지는 않겠습니다.
VP9: 실용적인 개방형 대안
VP9은 좋은 압축 성능과 최신 브라우저에서의 폭넓은 호환성을 갖췄습니다. 영상을 브라우저 안에서 재생하며 재생 환경을 예측할 수 있다면 충분히 매력적입니다.
제 용도에서 가장 큰 단점은 사용자가 파일을 다운로드하거나 WebM·VP9 지원이 일정하지 않은 네이티브 애플리케이션으로 열 때 발생하는 불확실성이었습니다.
AV1: 뛰어난 압축 효율, 하지만 하드웨어 지원은 아직 보편적이지 않음
AV1은 가장 유망한 현대적 비디오 코덱 중 하나입니다. 기존 코덱보다 비트레이트를 상당히 낮출 수 있으며 하드웨어 디코딩 지원도 계속 확대되고 있습니다.
하지만 오래된 기기에는 AV1 디코더가 없거나 소프트웨어 디코딩이 필요할 수 있습니다. 고해상도 영상을 소프트웨어로 디코딩하면 CPU와 배터리를 더 많이 소모하고 성능이 낮은 기기에서는 재생 문제가 생길 수 있습니다.
재생 환경을 통제할 수 있다면 AV1을 진지하게 검토할 가치가 있습니다. 반대로 오래된 기기와 최신 기기, 일반 외부 동영상 플레이어까지 파일 하나로 지원해야 한다면 H.264가 더 안전한 기본 선택입니다.
MDN 비디오 코덱 가이드에서 각 코덱과 브라우저 요구 사항에 관한 유용한 정보를 확인할 수 있습니다.
4. 하나의 동영상 형식만 쓸까, 여러 버전을 제공할까?
이는 동영상 전송 구조에서 가장 중요한 결정 중 하나입니다.
여러 버전을 제공할 수 있다면 호환되는 기기에는 AV1 또는 VP9을 제공하고, 다른 환경에서는 H.264로 대체할 수 있습니다. 이렇게 하면 폭넓은 재생 호환성을 유지하면서 압축 효율을 개선할 수 있습니다.
다만 여러 버전을 유지하면 인코딩, 저장 공간, 캐싱, 검증, 재생 형식 선택이 모두 복잡해집니다.
원본 동영상마다 완성 파일이 정확히 하나만 필요하다면 대체로 호환성을 우선하는 전략이 적합합니다.
저는 별도 대체 형식 없이도 주요 브라우저, 스마트폰, 일반적인 다운로드 후 재생 환경에서 작동하는 파일 하나를 원했기 때문에 MP4/H.264를 선택했습니다.
MP4/H.264의 압축 효율이 최고라는 뜻은 아닙니다. 최신 코덱으로 파일을 더 작게 만들 가능성보다 재생 결과의 예측 가능성을 우선한 것입니다.
5. 모바일 동영상에서는 우선순위가 다른 이유
동영상 압축 방식은 콘텐츠가 실제로 어떻게 소비되는지에 맞춰야 합니다.
주로 스마트폰에서 보는 짧은 영상과 대형 TV에서 보는 장편영화는 요구 조건이 다릅니다. 전자에서는 미세한 디테일 보존보다 빠른 로딩과 적은 모바일 데이터 사용량이 더 중요할 수 있습니다. 후자에서는 화질이 최우선일 수 있습니다.
모바일용 짧은 영상에서 파일이 작으면 여러 이점이 있습니다.
- 재생을 시작하기 전 전송할 데이터가 줄어듭니다.
- 연결 속도가 제한된 환경에서 다운로드가 더 빨리 끝날 수 있습니다.
- 기기에 필요한 저장 공간이 줄어듭니다.
- 사용자의 모바일 데이터 소비가 감소합니다.
- 인코딩 비트레이트가 낮으면 낮은 전송 속도에서도 재생이 더 안정적일 수 있습니다.
하지만 파일 크기가 작다고 영상이 절대로 버퍼링되거나 멈추지 않는 것은 아닙니다. 네트워크 변동, 최대 비트레이트, 서버 동작, 재생 버퍼링, 기기의 디코딩 성능도 영향을 미칩니다.
모바일 호환성은 확장자 외에도 여러 조건에 좌우됩니다. 하드웨어 디코딩, 코덱 프로파일과 레벨, 비트 심도, 크로마 서브샘플링, 해상도, 프레임 레이트, 최대 비트레이트가 모두 중요합니다. CSS 기준 너비 390픽셀로 표시되는 영상도 픽셀 밀도가 높은 스마트폰 화면에서는 훨씬 많은 실제 픽셀을 사용할 수 있습니다. 따라서 프레임을 너비 390픽셀로 축소해 확인하는 작업이 해당 스마트폰에서 원본 영상을 시청하는 것과 같다고 볼 수는 없습니다. 실제 기기와 재생 조건으로 시험하세요.
CRF는 화질을 조절할 뿐 정확한 최대 비트레이트를 강제하지 않습니다. 전체 파일이 비교적 작아도 복잡한 영상에는 높은 비트레이트 구간이 존재할 수 있습니다. 특히 느린 연결에서도 안정적으로 재생해야 한다면 명시적 비트레이트 또는 VBV 제한, 적절한 해상도 상한, 현실적인 네트워크 조건에서의 시험을 고려하세요.
핵심 원칙은 간단합니다. 추상적인 최고 화질이 아니라 실제로 원하는 시청 경험에 맞춰 최적화해야 합니다.
6. x264 CRF 이해하기: 낮을수록 고화질, 높을수록 작은 파일
H.264를 선택했다면 다음 과제는 얼마나 강하게 압축할지 결정하는 것입니다.
x264의 CRF(Constant Rate Factor, 고정 품질 계수)는 영상의 디테일 보존과 파일 크기 사이의 절충을 조절합니다.
일반적으로 CRF가 낮으면 화질이 높고 파일이 커집니다. CRF가 높으면 압축 손실이 늘지만 파일이 작아집니다.
CRF는 정확한 비트레이트나 출력 파일 크기를 지정하지 않습니다. 인코더가 원본 영상에 맞춰 비트를 배분하므로 단순한 장면과 디테일이 풍부한 장면은 CRF가 같아도 파일 크기가 크게 다를 수 있습니다.
CRF 자체가 디코더의 기본 호환성을 결정하는 것도 아닙니다. CRF 22와 CRF 30으로 적절하게 인코딩한 두 H.264 영상은 코덱, 프로파일, 레벨, 픽셀 형식, 해상도, 프레임 레이트가 같을 수 있습니다.
주된 차이는 압축 화질과 비트레이트 특성입니다.
특히 서로 다른 코덱 구현의 CRF 수치는 직접 비교할 수 없습니다. x264의 CRF 30이 AV1 인코더의 CRF 30과 같은 시각적 품질을 뜻하지는 않습니다.
7. 실제 압축 실험: CRF 22부터 32까지
일반적인 재생 중에 차이가 중요해질 때까지 영상을 얼마나 강하게 압축할 수 있는지 확인하고 싶었습니다.
이미 한 차례 압축된 짧은 동영상 하나를 사용해 CRF 22, 24, 26, 28, 29, 30, 31, 32로 H.264 비교 파일을 만들었습니다.
해상도, 프레임 레이트, 길이, 프레임 수 등 영상의 주요 속성은 유지했습니다. CRF 변화의 효과를 평가할 수 있도록 인코더 설정도 통일했습니다.
결과에서는 파일 크기가 크게 달라졌습니다.
| CRF | 원본 대비 대략적인 크기 | 의미 |
|---|---|---|
| 22 | 63% | 보수적인 압축으로 디테일을 더 잘 보존 |
| 24 | 49% | 화질 손실을 조금 더 감수하며 파일 크기 감소 |
| 26 | 38% | 상당한 디테일을 보존하면서 추가 절감 |
| 28 | 30% | 원본과 비교적 높은 유사도를 유지하는 작은 출력 |
| 29 | 26% | 더 강한 압축 |
| 30 | 23% | 시험한 영상에서 제가 선호한 절충안 |
| 31 | 21% | 원본 충실도를 더 낮추고 파일 크기를 절감 |
| 32 | 19% | 시험 중 가장 작은 파일이자 측정 화질 손실이 가장 큼 |
이 비율은 시험한 원본에만 해당하며 다른 모든 영상에서 얻을 수 있는 일반적인 절감률로 해석하면 안 됩니다. 표의 백분율은 각각 독립적으로 반올림했습니다. 정확한 상대 절감률을 구하려면 반올림한 값을 나누지 말고 실제 파일 크기로 계산해야 합니다.
가장 놀라웠던 점은 대형 데스크톱 모니터에서도 일반적인 재생 중에는 CRF 22와 CRF 30 사이에 유의미한 시각적 차이를 느끼지 못했다는 것입니다.
CRF 32를 포함해 더 강하게 압축한 버전도 살펴봤지만, 해당 영상의 일반 재생에서는 큰 차이를 발견하지 못했습니다.
이 결과가 중요했던 이유는 원래 영상의 주요 시청 대상이 더 작은 모바일 화면이었기 때문입니다. 데스크톱 모니터에서도 화질 저하가 거슬리지 않았다면, 실제 시청 경험을 개선하지 않는 디테일을 위해 훨씬 큰 파일을 유지할 이유가 거의 없었습니다.
물론 이 관찰은 특정 유형의 원본에 대한 주관적인 평가입니다. 모든 사용자와 스마트폰, 모든 동영상에서 결과가 같다는 증거는 아닙니다. 픽셀 밀도가 높은 화면을 가까이에서 보면 특히 미세한 디테일이나 그라데이션에서 압축 흔적이 보일 수 있습니다.
8. 객관적인 측정에서는 실제 화질 손실이 확인됐습니다
재생할 때 차이가 눈에 띄지 않는다고 해서 두 영상이 수학적으로 동일하다는 뜻은 아닙니다.
저는 객관적인 영상 품질 지표로 인코딩 결과도 비교했습니다. CRF가 높아질수록 원본과의 유사도는 낮아졌습니다.
픽셀 밀도가 높은 모바일 화면을 근사하려고 동일한 조건으로 축소한 비교에서 대표적인 SSIM 측정값은 다음과 같았습니다.
| CRF | 대략적인 SSIM | CRF 28 대비 출력 크기 |
|---|---|---|
| 22 | 0.9934 | 2.13× |
| 28 | 0.9869 | 1.00× |
| 30 | 0.9837 | 0.79× |
| 32 | 0.9795 | 0.63× |
경향은 분명합니다. 압축을 강하게 할수록 측정한 원본 충실도가 낮아졌습니다. 자세히 살펴보면 가는 선과 질감에서도 미묘한 차이가 나타났습니다.
하지만 시험한 영상의 일반적인 시청 경험은 여전히 매우 비슷했습니다. 그래서 객관적 지표와 주관적 평가를 함께 사용하는 것이 중요합니다.
SSIM은 이미지의 유사성을 측정할 뿐, 사람이 느끼는 시청 경험 전체를 나타내지 않습니다. 시간에 따른 압축 흔적, 체감 선명도, 움직임의 특성, 개별 시각적 디테일의 주관적 중요성을 완전히 반영하지 못합니다.
VMAF도 유용한 지각 화질 지표입니다. Netflix는 2026년 6월에 휴대전화 시청 조건을 고려한 모델을 포함해 VMAF v1 모델을 공개했습니다. 이 모델은 체감 화질이 화면 크기와 상대적인 시청 거리에 부분적으로 영향을 받는다는 점을 명시적으로 반영합니다.
이번 조사에서 보수적으로 인코딩한 샘플의 평균 VMAF는 약 95로 보고됐지만, 공격적인 모든 CRF 설정에 대해 일관된 VMAF 측정값을 얻지는 못했습니다. 따라서 VMAF를 근거로 CRF 30이나 32가 어떤 보편적인 화질 기준을 충족했다고 주장하지 않았습니다.
실제 결론은 더 제한적입니다. 시험에 사용한 짧은 영상은 일반적인 재생에서 강한 H.264 압축을 매우 잘 견뎠다는 것입니다.
9. 모바일용 짧은 영상에 CRF 30을 선택한 이유
파일을 비교한 뒤 주로 모바일 기기에서 시청하는 비슷한 유형의 짧은 영상에는 CRF 30을 쓰기로 했습니다.
그 이유는 다음과 같습니다.
- 영상이 짧고 영화 수준의 화질을 제공할 목적이 아니었습니다.
- 빠른 로딩과 작은 다운로드 파일이 중요했습니다.
- 대형 데스크톱 모니터에서도 CRF 22와 30의 유의미한 차이를 느끼지 못했습니다.
- CRF 30은 보수적인 설정보다 훨씬 작은 파일을 만들었습니다.
- 시험한 샘플에서는 CRF 32도 시각적으로 괜찮았지만 더 복잡한 영상에는 확신이 적었습니다.
시험한 출력 파일에서 CRF 30은 CRF 28보다 약 21%, CRF 22보다 60% 넘게 크기가 작았습니다.
보기 좋은 화질, 빠른 로딩, 합리적인 데이터 사용량이 목표인 모바일용 짧은 영상이라면 충분히 감수할 만한 절충이었습니다.
하지만 조건이 무엇보다 중요합니다. CRF 30을 선택한 것은 실제 시청 목적과 시험한 영상의 결과 때문이지, 30이 스마트폰에 본질적으로 가장 적합한 CRF 값이기 때문이 아닙니다.
모바일 기기에 CRF 30이 필요한 것은 아닙니다. 훨씬 충실도 높게 인코딩된 영상도 문제없이 표시할 수 있습니다. CRF 30은 이런 절충을 받아들일 수 있을 때 원본에 대한 충실도 일부를 작은 파일과 맞바꾸는 의도적인 결정입니다.
내용이 크게 다른 여러 영상에 적용하기 전에는 복잡한 움직임, 어두운 장면, 그라데이션, 문자, 미세한 질감을 포함한 대표 영상을 여러 개 시험하겠습니다.
10. 영화나 고화질 영상에 CRF 30을 권하지 않는 이유
이 부분이 이번 실험의 가장 중요한 한계입니다.
제가 얻은 CRF 30 결과를 장편영화, 고급 영상 콘텐츠, 전문 촬영 영상, 대형 화면용 영상에 무조건 적용하지 마세요.
그런 영상에는 미묘한 그라데이션, 필름 그레인, 어두운 장면, 복잡한 움직임, 섬세한 표면 질감, 정교하게 보정한 색상이 포함될 수 있습니다. 약간의 대역폭을 아끼는 것보다 이런 디테일을 지키는 편이 중요할 수 있습니다.
일반적인 고화질 1080p 영상이라면 저는 CRF 20 정도처럼 훨씬 보수적인 x264 설정부터 시작해 원본에 따라 높고 낮은 값을 평가하겠습니다.
시각적 충실도가 중요할 때 CRF 18~22는 실용적인 시작 범위가 될 수 있습니다. 다만 적절한 값은 해상도, 콘텐츠, 요구 조건에 따라 이 범위를 벗어날 수도 있습니다.
이 제안은 널리 공개된 인코딩 지침과도 일치합니다. 예를 들어 HandBrake 화질 설정 문서에서는 여러 1080p x264 용도에 대해 RF 20~24 정도를 권장합니다.
장편영화나 고급 영화 영상에서 동일한 통제 실험을 진행하지는 않았습니다. 따라서 CRF 20이 언제나 최적이라거나, CRF 22가 항상 충분하다거나, 특정 영화가 CRF 30에서는 받아들이기 어려운 화질이 된다고 주장할 수 없습니다.
올바른 방법은 대표 장면을 고르고 여러 화질 단계로 인코딩한 후 실제 시청할 화면에서 비교해, 추가 압축이 눈에 띄는 손상을 일으키기 시작하는 지점을 찾는 것입니다.
영상을 보관하거나 다시 편집하거나 향후 재인코딩의 소스로 사용할 예정이라면 압축된 배포용 파일과 별도로 고품질 마스터를 보관해야 합니다.
11. x264의 veryslow 프리셋을 사용한 이유
CRF가 압축 화질의 한 측면을 제어한다면, x264 프리셋은 효율적인 인코딩 결정을 찾기 위해 인코더가 얼마나 많은 작업을 수행할지 제어합니다.
x264에는 매우 빠른 것부터 매우 느린 것까지 다양한 프리셋이 있습니다. 일반적으로 느린 프리셋은 CPU 시간을 더 사용하지만 비슷한 체감 화질에서 압축 효율을 높일 수 있습니다.
동일한 원본에서 medium과 veryslow를 비교했더니, 시험한 화질 설정에서는 veryslow가 더 작은 파일을 만들었습니다.
오프라인에서 한 번 인코딩한 뒤 여러 번 재사용한다면 추가 처리 시간을 들일 가치가 있습니다.
그래서 -preset veryslow를 선택했습니다.
그러나 이 선택이 언제나 최적인 것은 아닙니다. 즉시 처리해야 하거나 CPU 비용이 크거나 처리 대기 영상이 아주 많다면 slow 또는 medium이 운영상 더 나은 균형을 제공할 수 있습니다.
프리셋은 주로 인코딩 복잡도와 압축 효율을 바꿉니다. H.264를 다른 코덱으로 바꾸거나 결과 파일을 모바일 기기에서 본질적으로 재생 불가능하게 만들지는 않습니다.
12. 애니메이션 영상에는 x264의 animation 튜닝을 사용합니다
손으로 그린 애니메이션이나 애니메이션풍 원본에는 x264의 -tune animation을 사용합니다.
이 설정은 CRF와 다릅니다. 튜닝은 특정 영상 특성에 맞게 인코더의 일부 결정을 바꿉니다. animation 튜닝은 그림의 윤곽선, 단색 영역, 양식화된 움직임이 있는 자료를 위해 고안됐습니다.
따라서 저는 다음과 같이 구분합니다.
- 애니메이션 또는 그린 영상:
-preset veryslow -tune animation을 사용합니다. - 일반 실사 영상: animation 튜닝을 자동으로 켜지 말고 기본 인코더 설정부터 시작하거나 다른 적합한 튜닝을 따로 평가합니다.
튜닝의 역할을 오해해서는 안 됩니다. -tune animation이 눈에 띄게 나은 화질이나 더 작은 파일을 보장하지는 않습니다. 인코더의 동작을 바꿀 뿐이며 결과는 원본에 따라 달라집니다.
별도로 CRF를 고정하고 animation 튜닝 여부를 비교했습니다. 그 비교에서는 튜닝을 켜자 파일이 약 6% 커졌고, 측정한 이미지 유사도는 약간 좋아졌습니다. 눈으로 본 차이는 작았습니다.
CRF 22~32의 주요 파일 크기 비교에서는 animation 튜닝을 사용하지 않았습니다. 따라서 해당 실험의 정확한 파일 크기와 압축 비율이 -tune animation을 활성화해도 똑같을 것이라고 가정하면 안 됩니다.
그럼에도 애니메이션 영상에는 해당 소재에 맞는 튜닝을 선호하며, 그 인코딩 프로파일의 일부로 파일 크기와 화질을 평가합니다.
인코더 튜닝은 보편적인 화질 향상 기능이 아니라 콘텐츠에 따른 조정으로 이해해야 합니다.
13. 모바일용 짧은 애니메이션 영상에 권장하는 FFmpeg 설정
실제로 트랜스코딩이 필요한 일반적인 SDR 애니메이션 영상이라면 다음 명령을 시작 프로파일로 사용하겠습니다.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset veryslow \
-tune animation \
-crf 30 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
output.mp4이 명령에는 주요 선택 사항이 명확히 드러납니다.
-c:v libx264: 소프트웨어 H.264 인코더를 사용합니다.-preset veryslow: 인코딩 속도보다 압축 효율을 우선합니다.-tune animation: 애니메이션에 맞춘 인코더 조정을 활성화합니다.-crf 30: 이런 짧은 영상에 선택한 강한 고정 품질 목표를 적용합니다.-profile:v high: 최신 기기에서 폭넓게 지원되는 H.264 프로파일을 선택합니다.-pix_fmt yuv420p: 8비트 4:2:0 영상을 출력합니다.-map 0:v:0: 첫 번째 비디오 스트림을 선택합니다.-map '0:a:0?': 첫 번째 오디오 스트림이 있다면 선택합니다.-c:a aac -b:a 128k: 오디오가 있으면 일반 AAC 오디오로 인코딩합니다.-movflags +faststart: MP4 초기화 메타데이터를 파일 앞부분으로 이동합니다.
이는 예시일 뿐 모든 입력 파일에 적용되는 범용 명령이 아닙니다. 원본 동영상의 특성에 따라 추가 처리가 필요할 수 있습니다.
특히 HDR 또는 10비트 영상을 적절한 색상 관리 없이 8비트 SDR로 무작정 변환하면 안 됩니다. 색이 틀어지거나 밝은 영역의 디테일이 사라지고 밴딩이 눈에 띌 수 있습니다. 회전 메타데이터, 가변 프레임 레이트, 샘플 종횡비, 인터레이스 영상, 특이한 오디오 채널 구성, 해상도 호환성 제한도 주의해야 합니다.
원본 프레임 레이트와 영상 크기가 이미 적절하다면 그대로 유지하는 편이 일반적으로 비교하기 쉽고 불필요한 리사이징이나 움직임 변화를 막을 수 있습니다. 필요하지 않은데 가변 프레임 레이트 영상을 고정 프레임 레이트로 강제 변환하면 프레임이 복제되거나 삭제될 수 있습니다. 크기를 조정할 때는 표시 종횡비를 유지하고 선택한 4:2:0 픽셀 형식에서 사용할 수 있는 크기인지 확인하세요. 매우 높은 해상도, 프레임 레이트 또는 H.264 레벨은 오래된 기기의 디코딩 한계를 넘을 수 있으므로 호환성을 위해 의도적으로 해상도나 프레임 레이트를 낮춰야 할 때도 있습니다.
14. 고화질 영상을 위한 좀 더 보수적인 FFmpeg 시작 설정
파일 크기보다 원본에 대한 충실도가 훨씬 중요하다면 CRF를 낮게 설정하고 결과를 평가하세요.
예를 들어 일반적인 SDR 실사 영상에는 다음 구성이 시험해 볼 만한 합리적인 시작점입니다.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c:v libx264 \
-preset slow \
-crf 20 \
-profile:v high \
-pix_fmt yuv420p \
-c:a aac -b:a 192k \
-movflags +faststart \
output.mp4이 예시의 slow 프리셋은 범용적으로 시작하기 좋은 값일 뿐, veryslow보다 성능이 좋다는 주장이 아닙니다. 추가 인코딩 시간이 허용된다면 veryslow도 합리적입니다.
이 고화질 프로파일은 시험을 권하는 설정이지, 제가 진행한 짧은 영상 실험에서 효과가 입증된 구성은 아닙니다.
고급 영상이라면 CRF 18, 20, 22 부근을 시험한 다음 시각적 결과에 따라 선택하세요. 다루기 어려운 그레인이나 움직임에는 다른 설정이 필요할 수 있고, 보관용 마스터에는 훨씬 약한 압축이 필요할 수 있습니다.
15. 이유 없이 영상을 다시 인코딩하지 마세요
손실 압축에는 대가가 따릅니다. 이미 압축된 파일을 다시 인코딩하면 출력이 원본과 비슷해 보여도 압축 흔적이 추가될 수 있습니다.
트랜스코딩하기 전에 원본 파일이 이미 호환성, 크기, 화질 요구 조건을 충족하는지 확인하세요.
영상에 호환되는 H.264 비디오와 AAC 오디오가 들어 있고 시각적 변환이 필요 없다면 손실 인코딩을 다시 하는 것보다 스트림 복사가 나을 수 있습니다.
ffmpeg -i input.mp4 \
-map 0:v:0 -map '0:a:0?' \
-c copy \
-movflags +faststart \
output.mp4이 작업은 압축된 스트림을 다시 인코딩하지 않고 그대로 복사합니다. 컨테이너 내부 구성을 변경하면서 추가 세대의 압축 손실을 피할 수 있습니다.
일반적으로 화질을 낮춰 재인코딩할 때만큼 파일 크기를 줄이지는 못합니다.
기존 영상이 이미 충분히 작고 호환성이 좋으며 시각적으로 만족스럽다면 그대로 두는 것이 최고의 최적화일 수 있습니다.
16. 파일 크기만 믿지 말고 인코딩 결과를 검증하세요
FFmpeg가 성공 코드로 종료됐다고 해서 동영상이 모든 조건을 충족한다는 뜻은 아닙니다.
먼저 FFprobe로 출력 스트림을 확인합니다.
ffprobe -v error \
-show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
-of json output.mp4코덱, 픽셀 형식, 영상 크기, 프레임 레이트, 재생 시간, 오디오 스트림을 검증하세요.
그다음 출력 영상 전체를 디코딩해 일부 손상이나 디코딩 오류가 있는지 확인합니다.
ffmpeg -v error -xerror -i output.mp4 -f null -압축 실험에서는 같은 원본에서 생성한 결과를 비교해야 합니다. 중요한 변수는 일정하게 유지하고 한 번에 하나의 주요 설정만 바꾸세요.
실제로 영상을 재생하면서 미세한 디테일을 확인하고 그라데이션, 어두운 부분, 움직이는 물체, 문자에 주의하세요.
가능하면 SSIM, PSNR, VMAF 같은 객관적 지표를 육안 비교에 더해 활용하세요. 점수 하나가 높다고 모든 압축 흔적이 보이지 않는다고 판단해서는 안 됩니다.
마지막으로 대표적인 기기와 다운로드 후 재생 환경에서 직접 시험하세요. 브라우저 지원 정보도 유용하지만 호환성이 최우선이라면 실제 재생 테스트가 특히 중요합니다.
17. MP4 파일을 올바르게 전송하기
인코딩 설정이 좋아도 웹 전송 설정이 나쁘면 해결되지 않습니다.
일반적인 점진적 MP4 재생에서는 올바른 Content-Type: video/mp4 헤더를 설정하고, 부분 다운로드나 탐색이 필요할 경우 HTTP 바이트 범위 요청을 지원해야 합니다.
FFmpeg의 +faststart 옵션은 일반 MP4 파일의 초기화 정보를 파일 앞부분으로 이동합니다. 점진적인 로딩에는 도움이 되지만 화질을 개선하거나 비트레이트를 줄이지는 않습니다.
기본 HTML video 요소로 H.264 MP4 파일 하나를 전송할 수 있습니다.
<video controls playsinline preload="metadata">
<source src="/media/video.mp4" type="video/mp4">
</video>preload 속성은 브라우저에 제공하는 힌트일 뿐 다운로드 양을 엄격하게 제한하지는 않습니다. 브라우저 자동 재생 정책에 따라 동영상을 음소거하거나 오디오가 없어야 할 수도 있습니다.
페이지에 영상이 여러 개 있다면 처음부터 모두 다운로드하지 마세요. 필요할 때만 불러오면 모바일 데이터 사용량을 줄이고 체감 응답성을 개선할 수 있습니다.
모바일용 짧은 영상에서는 다운로드 시작 시점을 최적화하는 일이 인코딩 파일의 크기를 줄이는 것만큼 중요할 수 있습니다.
18. 어떤 동영상 형식과 화질을 선택해야 할까?
무엇을 최적화하려는지에 따라 정답이 달라집니다.
| 목표 | 권장 시작점 |
|---|---|
| 웹 재생과 다운로드 모두에서 폭넓게 호환되는 파일 하나 | MP4 + H.264 + AAC(오디오가 있는 경우) |
| 여러 형식을 제공할 수 있는 최신 브라우저 환경 | AV1 또는 VP9, H.264 대체 형식 제공 |
| 지원 기기에서 압축 극대화 | AV1 평가 |
| HEVC 호환성을 관리할 수 있는 환경 | MP4 + HEVC 고려 |
| 파일 크기가 가장 중요한 모바일용 짧은 영상 | 대표 영상으로 시험한 뒤 x264 CRF 30 검토 |
| 애니메이션 또는 그린 영상 | -tune animation을 적용한 x264 평가 |
| 고화질 영화 또는 고급 영상 | CRF 20 부근의 더 보수적인 값에서 시험 시작 |
| CPU 시간이 덜 중요한 오프라인 인코딩 | x264 slow 또는 veryslow 고려 |
| 빠른 처리와 제한된 CPU 자원 | x264 medium 또는 slow 고려 |
| 기존 영상이 이미 요구 조건을 만족함 | 그대로 두거나 재인코딩 없이 컨테이너만 변경 |
| 보관 또는 향후 편집 | 배포용 파일과 별도로 고품질 마스터 보존 |
19. 최종 선택과 실험이 실제로 증명한 것
동영상 형식, 호환성, 인코딩 효율, 실제 압축 결과를 조사한 뒤 모바일용 짧은 영상을 위한 실용적인 전송 프로파일을 선택했습니다.
선택한 형식은 H.264를 사용한 MP4입니다. 최신 코덱으로 가장 작은 파일을 만드는 것보다 브라우저, 스마트폰, 다운로드한 파일, 외부 애플리케이션에서 예측 가능하게 재생되는 것이 중요했기 때문입니다.
인코더는 libx264와 veryslow 프리셋을 선택했습니다. 오프라인으로 인코딩할 수 있고 추가 처리 시간을 감수할 수 있었기 때문입니다.
애니메이션 영상에는 animation 튜닝을 사용하지만, 이 설정이 인코더 동작을 바꿀 뿐 파일 크기 감소나 모든 영상에서의 화질 향상을 보장하지는 않는다는 점을 알고 있습니다.
모바일용 짧은 영상에는 CRF 30을 선택했습니다. 큰 데스크톱 모니터로 비교해도 일반 재생에서 유의미한 화질 차이를 느끼지 못하면서 파일 크기는 상당히 줄었기 때문입니다.
그렇다고 CRF 30이 영화나 고화질 영상의 이상적인 설정이라는 뜻은 아닙니다. 미세한 디테일, 그라데이션, 그레인, 전반적인 충실도가 중요하다면 CRF 20 부근이나 그에 준하는 보수적인 값부터 시험하겠습니다. 영화 영상에 대해서는 이에 대응하는 통제 실험을 수행하지 않았으므로 그 값을 실험으로 입증된 최적값이라고 주장하지 않습니다.
가장 중요한 결론은 모든 영상에 보편적으로 가장 좋은 코덱, 형식, CRF 값은 존재하지 않는다는 것입니다.
호환성을 최우선으로 하고 파일 하나만 원한다면 MP4/H.264가 좋은 기본 선택입니다. 대체 형식을 제공하면서 압축 효율을 높이고 싶다면 VP9과 AV1을 조사해 보세요. 주로 휴대전화에서 보는 짧은 영상을 인코딩한다면 CRF를 높여도 원하는 시청 경험을 해치지 않으면서 파일을 충분히 작게 만들 수 있는지 확인하세요. 영화나 고급 영상은 더 보수적인 화질 설정을 사용하고 신중하게 검증해야 합니다.
먼저 재생 요구 조건을 정하고, 다음으로 코덱을 선택한 뒤, 마지막에 압축 화질을 결정하세요. 그런 다음 실제로 중요한 기기와 조건에서 결과를 시험하세요. 새롭거나 효율적이거나 흔히 권장된다는 이유만으로 코덱이나 CRF 값을 무작정 채택하는 것보다 훨씬 믿을 만한 접근법입니다.