H.264 vs HEVC vs AV1 비디오 코덱 비교: 압축, 호환성, 인코딩 선택

비디오 코덱 선택은 화질, 파일 크기, 재생 가능한 기기를 한꺼번에 결정합니다. H.264는 지금도 가장 넓게 재생되는 기본값이고, HEVC는 같은 화질을 더 적은 비트로 담는 대신 라이선스와 기기 지원을 따져야 하며, AV1은 로열티 부담이 없는 대신 인코딩이 무겁습니다. 이 글은 세 코덱을 같은 기준으로 놓고, 압축 효율 차이가 내부 구조의 어디에서 오는지, 인코더가 무엇을 최적화하는지, 서비스에서 어떻게 섞어 쓰는지를 차례로 봅니다.

---

한눈에 비교

특성	H.264 (AVC)	HEVC (H.265)	AV1
표준	ITU-T H.264 / ISO MPEG-4 Part 10	ITU-T H.265 / ISO MPEG-H Part 2	AOMedia Video 1
최대 블록	16×16 매크로블록	64×64 CTU	128×128 슈퍼블록
압축 효율	기준	설계 목표는 H.264 대비 같은 화질에서 약 절반의 비트	HEVC 대비 추가 절감이 흔히 보고되나 설정 의존적
소프트웨어 인코딩 부담	가장 가벼움	더 무거움	대체로 가장 무거움
디코딩 지원	사실상 모든 기기	최신 TV·모바일·GPU, 브라우저는 하드웨어 디코더 유무에 좌우	최신 브라우저·칩셋, 구형 기기는 소프트웨어 디코딩
로열티	특허 풀	복수의 특허 풀	AOMedia 로열티 프리 라이선스
대표 프로파일	Baseline, Main, High	Main, Main 10	Main(8·10비트 4:2:0), High, Professional

압축 효율 칸에 구체적인 퍼센트를 적지 않은 이유가 있습니다. 코덱 비교 결과는 어떤 인코더(x264, x265, SVT-AV1, libaom, 하드웨어 인코더)를 어떤 프리셋으로 돌렸는지, 품질을 PSNR로 쟀는지 VMAF로 쟀는지, 소스가 애니메이션인지 필름 그레인이 많은 실사인지에 따라 크게 달라집니다. 코덱 자체보다 인코더 구현의 차이가 더 큰 경우도 흔합니다.

---

코덱 내부 구조: 매크로블록, CTU, 슈퍼블록

세 코덱은 모두 예측 → 잔차 변환·양자화 → 엔트로피 부호화라는 같은 골격을 공유합니다. 효율 차이는 블록을 얼마나 크고 유연하게 나눌 수 있는지, 예측 모드가 얼마나 다양한지, 루프 안에서 어떤 필터를 쓰는지에서 나옵니다. 그리고 선택지가 늘어날수록 인코더가 탐색해야 할 공간도 커져 인코딩이 느려집니다.

H.264: 매크로블록, 1/4 화소 모션 보상, 정수 변환

H.264의 기본 단위는 휘도 16×16 화소의 매크로블록입니다. 흔히 쓰는 4:2:0 샘플링에서 색차는 가로·세로가 절반이라 매크로블록당 8×8 색차 블록 두 개가 대응합니다. 인터 예측에서는 매크로블록을 16×16, 16×8, 8×16, 8×8로 나눌 수 있고, 8×8은 다시 8×4, 4×8, 4×4로 나뉘어 블록마다 별도의 모션 벡터를 가질 수 있습니다.

모션 보상은 1/4 화소 정밀도로 이뤄집니다. 참조 프레임에서 정수 격자 사이의 값을 보간해 예측을 만들고, 원본과의 차이인 잔차만 부호화합니다. 모션 벡터 자체도 주변 블록으로부터 예측한 값과의 차이만 보냅니다.

잔차 변환은 DCT를 정수 연산으로 근사한 4×4 변환이 기본이고, High 프로파일에서 8×8 변환이 추가됩니다. 인트라 16×16 모드의 휘도 DC 계수와 색차 DC 계수에는 Hadamard 변환을 한 번 더 적용합니다. 양자화된 계수는 CAVLC 또는 CABAC으로 부호화하는데, CABAC은 Main 프로파일 이상에서만 쓸 수 있고 같은 화질에서 비트를 더 줄이는 대신 디코딩이 무겁습니다.

블록 경계의 계단 현상을 줄이는 디블로킹 필터는 인코딩 루프 안에 있습니다. 필터를 거친 프레임이 다음 프레임의 참조가 되므로, 인코더와 디코더가 똑같이 적용해야 합니다.

HEVC: CTU와 쿼드트리 분할

HEVC는 고정된 매크로블록 대신 CTU(Coding Tree Unit)를 최상위 블록으로 둡니다. CTU 크기는 16×16, 32×32, 64×64 중에서 고르고, 쿼드트리로 재귀 분할해 CU(Coding Unit)를 만듭니다. 평탄한 배경은 64×64 한 덩어리로 부호화하고, 물체 경계처럼 복잡한 부분만 8×8까지 잘게 나눌 수 있어서, 4K처럼 넓고 평탄한 영역이 많은 영상에서 이득이 큽니다.

CU 안에서 예측 단위(PU)는 예측 방식과 파티션 모양을, 변환 단위(TU)는 변환·양자화 블록 크기를 정합니다. TU는 4×4부터 32×32까지 쓸 수 있습니다. 인트라 예측은 평면(planar), DC, 33개 방향 모드를 합쳐 35개 모드로 늘어나, H.264의 최대 9개 모드보다 에지 방향을 더 정밀하게 따라갑니다.

루프 필터에는 디블로킹 외에 SAO(Sample Adaptive Offset)가 추가됐습니다. SAO는 화소를 밝기 구간이나 에지 모양에 따라 분류한 뒤 분류별 오프셋을 더해, 양자화로 생긴 링잉과 밴드 형태의 왜곡을 줄입니다. 대신 CU 분할, 예측 모드, TU 크기의 조합이 폭발적으로 늘어나 인코더가 좋은 조합을 찾는 비용이 H.264보다 훨씬 큽니다.

AV1: 슈퍼블록, 유연한 파티션, 필름 그레인 합성

AV1은 128×128 또는 64×64 슈퍼블록에서 시작해 10가지 파티션 유형으로 분할합니다. 4분할뿐 아니라 가로·세로 2분할, 한쪽만 다시 나누는 T자형 분할, 4개의 가늘고 긴 띠로 나누는 분할이 있어서, 쿼드트리만 쓰는 HEVC보다 얇은 선이나 경계를 더 적은 블록으로 표현할 수 있습니다. 변환도 DCT 외에 ADST, 뒤집은 ADST, 항등 변환을 가로·세로 방향별로 조합할 수 있어, 잔차의 방향성에 맞는 변환을 고를 수 있습니다.

실무에서 특히 의미 있는 기능은 필름 그레인 합성입니다. 필름이나 고감도 촬영의 입자 노이즈는 무작위라 예측이 거의 불가능하므로, 그대로 부호화하면 비트를 많이 먹고 낮은 비트레이트에서는 뭉개져 보기 싫게 변합니다. AV1 인코더는 노이즈를 제거한 영상을 부호화하고, 노이즈의 통계적 특성만 파라미터로 보냅니다. 디코더는 이 파라미터와 규정된 의사 난수 생성기로 비슷한 질감의 그레인을 만들어 출력 직전에 더합니다. 합성된 그레인은 참조 프레임에 들어가지 않으므로 예측 품질에는 영향을 주지 않습니다. 원래 입자 하나하나를 복원하는 것이 아니라 “비슷해 보이는” 질감을 다시 만드는 것이라, 그레인이 거의 없는 소스에 켜면 원본에 없던 질감을 덧칠하게 됩니다.

엔트로피 부호화는 H.264·HEVC의 CABAC처럼 이진 심볼을 다루는 대신, 여러 값을 가진 심볼을 적응형 확률 분포로 직접 부호화하는 방식입니다. 이런 도구들이 모두 디코더 쪽 연산을 늘리기 때문에, 하드웨어 디코더가 없는 구형 기기에서는 AV1 소프트웨어 디코딩이 CPU와 배터리를 많이 씁니다.

---

레이트-디스토션 최적화(RDO)

인코더는 블록마다 “어떤 분할, 어떤 예측 모드, 어떤 모션 벡터, 어떤 양자화”를 쓸지 골라야 합니다. 표준은 비트스트림 문법과 디코딩 방법만 정하고 이 선택 방법은 정하지 않으므로, 같은 코덱이라도 인코더에 따라 결과가 크게 달라집니다.

대부분의 인코더는 라그랑주 비용 J = D + λR을 최소화하는 후보를 고릅니다. D는 왜곡(SSE나, 빠른 근사로 SATD를 씀), R은 그 선택에 필요한 비트 수, λ는 둘 사이의 교환 비율입니다. λ는 양자화 파라미터(QP)에 연동되어, QP가 클수록 λ가 커지고 비트를 아끼는 거친 선택이 유리해집니다.

이 관점에서 보면 인코더 프리셋의 의미가 분명해집니다. 느린 프리셋은 더 많은 분할과 모드 후보를 실제로 부호화해 보고 J를 비교하므로, 같은 품질 목표에서 더 적은 비트를 쓰는 경향이 있습니다. 빠른 프리셋은 후보를 휴리스틱으로 미리 걸러내 속도를 얻는 대신 최적 선택을 놓칩니다. 세 코덱 중 선택지가 가장 많은 AV1에서 이 차이가 가장 크게 나타나므로, AV1 인코딩 시간이 긴 것은 상당 부분 탐색 공간이 넓기 때문입니다. CRF 같은 품질 기반 모드도 내부적으로는 목표 품질을 맞추려고 프레임마다 QP와 λ를 조정합니다.

---

서비스 인코딩 파이프라인

실제 서비스에서는 FFmpeg 한 줄로 끝나는 경우가 드물고, 보통 다음 요소가 함께 움직입니다.

첫째, 적응 스트리밍용 비트레이트 래더입니다. 같은 소스에서 360p부터 4K까지 여러 렌디션을 만들 때, 모든 콘텐츠에 같은 비트레이트 표를 쓰면 단순한 애니메이션에는 비트가 남고 복잡한 스포츠에는 모자랍니다. 콘텐츠별로 해상도·비트레이트 조합을 여러 개 인코딩해 품질-비트레이트 곡선의 볼록 껍질(convex hull)을 구하고, 그 위의 점을 래더로 고르는 per-title 인코딩이 이 문제를 다룹니다. 품질 하한은 VMAF 같은 지표로 둡니다.

둘째, 버퍼 제약입니다. 방송이나 OTT는 순간 비트레이트가 일정 수준을 넘으면 안 되므로, x264·x265의 VBV(Video Buffering Verifier) 설정으로 최대 비트레이트와 버퍼 크기를 제한합니다. 2-pass 인코딩은 첫 패스에서 장면 복잡도를 파악해 둘째 패스에서 비트를 더 잘 배분합니다. 실시간 방송은 2-pass를 쓸 수 없으므로 저지연 튜닝과 하드웨어 인코더가 중심이 됩니다.

셋째, 역할 분리입니다. 원본은 ProRes나 FFV1 같은 편집·보관용 포맷으로 두고, 배포용만 H.264·HEVC·AV1로 트랜스코딩합니다. 나중에 더 나은 인코더나 코덱이 나오면 원본에서 다시 만들 수 있기 때문입니다. 손실 압축된 배포본을 다시 다른 코덱으로 변환하면 두 번의 손실이 누적됩니다.

넷째, HDR과 색 공간입니다. PQ·HLG 전달 특성과 마스터링 디스플레이 메타데이터는 플랫폼마다 요구하는 형태가 다르고, -color_primaries, -color_trc, -colorspace를 빠뜨리면 플레이어가 SDR로 오인해 색이 바랜 것처럼 재생됩니다. 저는 HDR 인코딩 결과를 실제 기기에서 재생해 보기 전에는 배포하지 않는 쪽을 택하는데, 메타데이터 문제는 파일 분석 도구로는 멀쩡해 보이다가 특정 TV에서만 드러나는 경우가 많기 때문입니다.

아래는 보관용 원본에서 SVT-AV1로 배포본을 만드는 예입니다.

ffmpeg -i master.mov -c:v libsvtav1 -preset 6 -crf 32 \
  -svtav1-params tune=0:keyint=240:film-grain=8 \
  -pix_fmt yuv420p10le -c:a libopus -b:a 160k \
  -movflags +faststart distribution_av1.mp4

SVT-AV1의 preset은 숫자가 작을수록 느리고 효율이 좋습니다. film-grain=8은 그레인 노이즈 제거와 합성 강도를 정하는데, 앞에서 설명했듯 그레인이 강한 실사 소스에서만 켜고 애니메이션이나 화면 녹화에서는 끄는 편이 맞습니다. 10비트 출력(yuv420p10le)은 8비트 소스라도 그라데이션의 밴딩을 줄이는 데 도움이 되지만, 대상 기기의 디코더가 10비트를 지원하는지 먼저 확인해야 합니다. +faststart는 MP4의 moov 박스를 파일 앞으로 옮겨 다운로드 도중에도 재생을 시작할 수 있게 합니다.

---

코덱별 특징과 FFmpeg 예제

H.264

하드웨어 디코더 보급률이 가장 높아, 스마트 TV, 구형 모바일, 임베디드 기기, 웹뷰까지 거의 어디서나 재생됩니다. 인코더도 성숙해서 x264는 빠른 프리셋에서도 품질이 좋고, 실시간 인코딩 부담이 가장 적습니다. 반면 같은 화질에서 비트레이트가 가장 크고, 4K·HDR처럼 해상도가 커질수록 16×16 매크로블록의 한계가 두드러집니다.

ffmpeg -i input.mp4 -c:v libx264 -preset medium -crf 23 \
  -pix_fmt yuv420p -c:a aac -b:a 128k output.mp4

-pix_fmt yuv420p는 소스가 4:4:4나 4:2:2일 때 x264가 High 4:4:4 같은 프로파일로 인코딩해 대부분의 하드웨어 디코더에서 재생이 안 되는 사고를 막아 줍니다.

HEVC

같은 화질에서 비트레이트를 크게 줄일 수 있어 4K·HDR 콘텐츠와 방송에서 널리 쓰입니다. 최신 기기에는 하드웨어 인코더·디코더가 대부분 들어 있습니다. 약점은 라이선스 구조가 복잡하다는 점과 웹 지원입니다. 브라우저의 HEVC 재생은 대체로 운영체제와 하드웨어 디코더에 의존하므로, 같은 브라우저라도 기기에 따라 재생 여부가 갈립니다.

ffmpeg -i input.mp4 -c:v libx265 -preset medium -crf 28 \
  -tag:v hvc1 -c:a aac -b:a 128k output.mp4

-tag:v hvc1이 빠지면 FFmpeg은 MP4에 hev1 태그를 쓰는데, Apple 플레이어는 hvc1 태그만 재생하므로 macOS·iOS에서 영상이 나오지 않습니다. x264의 CRF 23과 x265의 CRF 28이 비슷한 화질이라는 것은 각 인코더의 기본값 기준으로 널리 쓰이는 출발점일 뿐, 코덱 간에 CRF 숫자를 그대로 옮길 수는 없습니다.

AV1

Alliance for Open Media가 로열티 프리 라이선스로 공개한 코덱으로, YouTube와 Netflix 같은 대형 서비스가 배포에 쓰고 있습니다. 대역폭 비용이 큰 서비스일수록 인코딩 비용을 들여 비트레이트를 줄이는 이득이 커집니다. 단점은 소프트웨어 인코딩 부하와 구형 단말 지원이며, 하드웨어 AV1 디코더가 없는 기기를 위한 폴백이 사실상 필요합니다.

ffmpeg -i input.mp4 -c:v libsvtav1 -preset 6 -crf 30 \
  -c:a libopus -b:a 128k output.mkv

SVT-AV1은 멀티코어 확장성이 좋아 서버 배치 인코딩에 많이 쓰이고, libaom은 참조 구현으로 느린 설정에서 효율을 끌어올릴 여지가 있지만 속도가 크게 느립니다.

---

용도별 선택

시나리오	추천	이유
광범위 호환 (웹·임베디드)	H.264	디코더 보급률
4K/HDR VOD, 최신 TV	HEVC 또는 AV1	대역폭·저장 효율
저지연 라이브	H.264 또는 하드웨어 HEVC	인코딩 지연과 안정성
대역폭 비용이 큰 VOD	AV1 + H.264 폴백	한 번 인코딩, 여러 번 전송
게임 녹화·편집	H.264	편집 도구·공유 호환

flowchart TD
  A[코덱 선택] --> B{최우선은?}
  B -->|모든 기기 재생| C[H.264]
  B -->|대역폭 절감 + 최신 기기| D[HEVC 또는 AV1]
  B -->|로열티 최소화| E[AV1 + H.264 폴백]
  C --> F[호환성 최대]
  D --> G[디코더 지원 매트릭스 확인]
  E --> H[멀티 코덱 파이프라인]

결정 순서는 먼저 반드시 재생되어야 하는 기기 목록을 확정하고, 그다음 인코딩에 쓸 수 있는 시간과 연산 예산, 마지막으로 CDN 전송 비용을 따지는 편이 단순합니다. 재생되지 않는 코덱은 효율이 아무리 좋아도 의미가 없기 때문입니다. 비교할 때는 코덱마다 CRF 스케일이 다르므로 같은 CRF 숫자를 쓰지 말고, 자기 콘텐츠 샘플로 VMAF 같은 품질 지표와 파일 크기, 인코딩 시간을 함께 기록한 뒤 실제 기기에서 재생해 보는 것이 가장 확실합니다. 빠른 움직임, 자막·텍스트, 어두운 그라데이션, 그레인이 많은 장면을 샘플에 꼭 넣어야 코덱 간 차이가 드러납니다.

---

H.264에서 HEVC·AV1로 옮기기

HEVC를 추가할 때는 먼저 대상 플랫폼의 HEVC 디코딩 지원을 확인합니다. 웹은 특히 기기별 차이가 크므로 H.264 렌디션을 유지한 채 HEVC를 추가 렌디션으로 얹는 방식이 안전합니다. MP4에서는 앞서 말한 hvc1 태그를 맞춥니다.

AV1을 추가할 때는 소프트웨어 인코딩 시간을 먼저 측정해 프리셋을 정하고, HLS·DASH 매니페스트에 AV1과 H.264(또는 HEVC) 렌디션을 함께 넣어 클라이언트가 재생 가능한 쪽을 고르게 합니다. Apple 기기에서는 하드웨어 AV1 디코더가 있는 비교적 최신 기기에서만 AV1이 재생되므로, 폴백이 빠지면 상당수 iOS 사용자가 재생하지 못합니다. 원본은 보관용 포맷으로 남겨 두어, 나중에 인코더가 개선되면 다시 인코딩할 수 있게 합니다.

특허·배포 정책은 제품 형태와 지역마다 다르므로, 상용 제품이라면 법무·벤더 검토를 거쳐야 합니다.

---

폴백 구성

가장 단순한 폴백은 <video> 요소에 여러 <source>를 넣는 것입니다. 브라우저는 위에서부터 type의 코덱 문자열을 보고 재생 가능한 첫 번째 소스를 고릅니다.

<video controls>
  <source src="trailer.av1.mp4" type='video/mp4; codecs="av01.0.08M.08"'>
  <source src="trailer.hevc.mp4" type='video/mp4; codecs="hvc1.1.6.L93.B0"'>
  <source src="trailer.h264.mp4" type='video/mp4; codecs="avc1.640028"'>
</video>

코덱 문자열은 실제 파일과 맞아야 합니다. av01.0.08M.08은 Main 프로파일, 레벨 4.0, Main 티어, 8비트를 뜻하고, hvc1.1.6.L93.B0은 Main 프로파일 레벨 3.1, avc1.640028은 High 프로파일 레벨 4.0입니다. 앞의 FFmpeg 예제처럼 hvc1 태그로 만든 파일에 hev1 코덱 문자열을 적으면 Safari가 소스를 건너뛸 수 있습니다. 긴 영상이나 네트워크 변동이 큰 환경이라면 HLS·DASH로 코덱별 렌디션을 나눠 적응 스트리밍을 구성하는 편이 낫습니다.

---

같이 보면 좋은 글

• H.264(AVC) 실무
• HEVC(H.265) 실전 가이드
• AV1 차세대 코덱 가이드