H.265 (HEVC) — The 4K Codec
H.265 — 4K 시대를 연 코덱
H.264 대비 같은 화질에 절반 비트레이트. 4K·HDR·아이폰 비디오의 표준. 그러나 라이센스 지옥과 인코딩 비용 폭증이 도입의 큰 장벽.
Overview
H.265 (HEVC)는 2013년 표준화. H.264와 같은 JCT 팀이 만들었지만 "같은 화질에 또 절반 비트레이트"라는 도약을 이뤘다. 4K·8K·HDR 시대를 가능하게 한 결정적 기술.
이번 장은 H.265가 H.264 대비 어떻게 두 배 효율을 냈는지, 그 대가가 무엇이었는지, 그리고 라이센스라는 비기술적 문제가 도입을 어떻게 지연시켰는지 본다.
- H.265의 핵심 혁신(CTU·35방향·향상된 인터)을 설명할 수 있다
- CTU의 quad-tree 분할이 왜 압축률을 폭증시키는지 안다
- H.265 인코딩이 왜 5~10배 느린지 근거와 함께 설명 가능
- Tile·WPP가 어떻게 병렬 인코딩을 가능하게 하는지 안다
- H.265 도입이 느렸던 라이센스 사정을 알고 의사결정에 반영할 수 있다
Sections
8.1 H.265가 H.264 대비 두 배 효율인 이유
한 줄: 모든 단계에서 더 정교하게. 세 가지가 결정적이다.
(1) 더 큰 블록과 가변 분할: H.264의 16×16 매크로블록 대신 CTU(Coding Tree Unit) 64×64. 그 안에서 quad-tree로 64→32→16→8까지 잘게 분할.
(2) 더 많은 인트라 예측 방향: 9방향 → 35방향. 더 정확한 추측 → 더 작은 잔차.
(3) 더 정교한 모션 보상: AMVP(Advanced MV Prediction), 머지 모드, 더 정밀한 보간 필터.
이 셋의 누적 결과가 "같은 화질에 절반 비트레이트". 4K 영상을 1080p 수준의 비트레이트로 보낼 수 있게 됨 → 4K 스트리밍·BD가 현실이 됨.
다만 인코딩이 5~10배 느려진다. CTU 분할의 탐색 공간이 폭증하기 때문. 디코딩은 비슷한 수준(약간 더 무거움)이라 디바이스 디코딩에는 큰 부담 없음.
8.2 CTU와 Quad-Tree 분할 — 핵심 혁신
CTU는 H.265의 가장 큰 발상 전환. "고정 크기 블록"이라는 가정을 버린다.
한 64×64 CTU 안에서 인코더가 결정: - 이 CTU는 단조 영역(하늘)이면 → 64×64 한 덩어리 - 디테일이 있는 영역이면 → 4분할 32×32 - 그 32×32 중 일부가 더 디테일하면 → 다시 4분할 16×16 - 끝까지 → 8×8
이 분할이 quad-tree 구조. 디테일 양에 맞춰 블록 크기가 자동 적응.
왜 큰가? 푸른 하늘 64×64 한 덩어리로 처리하면 시그널링 오버헤드가 압도적으로 작다. H.264는 같은 영역을 16×16 매크로블록 16개로 처리 → 시그널링이 16배.
비용: 인코더가 "어떻게 분할할까"를 탐색해야 함. CTU 하나당 가능한 분할 조합이 수십 가지. 이게 H.265 인코딩 비용 폭증의 주범.
x265는 빠른 RDO(Rate-Distortion Optimization) 알고리즘으로 이 탐색을 줄이지만, x264 대비 5~10배 느린 게 현실. preset slow에서는 30~50배까지.
8.3 35방향 인트라 예측 + Planar·DC
인트라 예측이 9 → 35 방향. 정확히는: - DC (블록 평균) 1개 - Planar (선형 그라데이션) 1개 - 방향성 33개 (수직·수평·대각선·그 사이의 각 단계)
총 35 모드. H.264 대비 거의 4배. 더 정확한 추측 → 더 작은 잔차 → 더 좋은 압축.
특히 Planar 모드가 흥미롭다. "이 블록은 네 모서리로부터 부드러운 그라데이션"이라고 예측. 자연 이미지의 부드러운 영역(피부·하늘)에서 매우 효과적.
비용: 인코더가 35방향을 다 시도하면 H.264 대비 4배 인트라 비용. 빠른 알고리즘(코스트 기반 가지치기)으로 줄이지만 여전히 큰 비용.
AV1은 이걸 56방향 + 다양한 변형으로 확장. 더 좋지만 더 무거움. 이게 코덱 진화의 정직한 룰.
8.4 Tile·WPP — 병렬 처리의 첫 도입
H.265의 또 다른 큰 발전: 병렬 인코딩·디코딩 지원. H.264는 매크로블록 사이 의존성이 강해 병렬화가 어려웠음.
Tile: 프레임을 직사각형 타일로 나눠 각 타일을 독립적으로 처리. 멀티코어 CPU·GPU 가속에 유리. 4K 영상을 4타일로 나누면 4코어가 동시에 처리.
WPP (Wavefront Parallel Processing): 한 행씩 시작 시점을 살짝 늦춰 "파도"처럼 병렬 처리. 의존성 유지하면서 병렬화.
Slice: 한 프레임을 여러 슬라이스로 나눠 독립 처리. 에러 복구에도 유리.
이 셋이 4K·8K 시대를 가능하게 한 또 다른 축. 실시간 4K 인코딩이 가능해진 게 이 병렬화 덕분.
ffmpeg에선 -x265-params "tiles=4:wpp=1" 같이 사용.
8.5 라이센스 지옥 — 기술 외의 거대한 장벽
H.265의 기술은 훌륭했지만 라이센스 정리가 재앙이었다.
H.264는 MPEG LA라는 단일 패텐트 풀에서 라이센스 관리. 명확하고 비교적 합리적. 그래서 빠르게 보급.
H.265는 세 개의 패텐트 풀 + 수많은 독립 권리자가 각자 라이센스 요구. MPEG LA, HEVC Advance, Velos Media, 그리고 별도 권리 주장자들.
결과: - 제조사가 어디서·얼마를 내야 할지 모름 - 인터넷 회사(브라우저)가 H.265 지원을 미룸 — Chrome·Firefox가 오래 거부 - 운영체제·디바이스마다 다른 지원 — 아이폰은 빠르게, 안드로이드는 늦게, 데스크톱 브라우저는 더 늦게
이 라이센스 분쟁이 결국 Alliance for Open Media(AOMedia) 결성을 촉발 — Google·Mozilla·Cisco·Netflix·Microsoft·Amazon·Intel·Apple이 모여 "우리가 로열티 무료 코덱 만들자". 결과물이 AV1.
교훈: 기술적 우수성이 도입을 보장하지 않는다. 비기술적 요인(라이센스·정책·표준화 과정)이 시장을 좌우. 이게 9장에서 다룰 AV1·VVC 전쟁의 배경.
한국 지도를 행정 구역으로 나눈다고 치자. H.264는 "모든 영역을 가로세로 같은 크기로 자른다". 부산 같은 도시도, 강원도 같은 산악 지역도 동일 격자. 도시 내부는 격자가 너무 커서 상세 정보가 안 들어가고, 산악은 격자가 너무 작아 빈 격자가 잔뜩.
H.265의 CTU는 "인구 밀도에 따라 격자 크기 가변". 서울 시내는 작은 격자(8×8), 강원도 산악은 큰 격자(64×64) 한 덩어리. 각 영역의 디테일에 맞춤 → 같은 정보를 더 적은 격자로 표현.
그리고 35방향 인트라 예측은 "옆 영역을 보고 이 영역 추측"이 9방향에서 35방향으로 정교화. 부산 옆 동래의 인구 밀도를 알면, 동래 옆 해운대도 비슷할 거다. 9가지 방향(동·서·남·북·…)으로 추측하던 걸 35가지 세분된 방향(북북동·동북동·…)으로.
결과: 같은 지도 정보를 절반의 용량으로 표현. 그러나 "어떻게 가변 격자를 그릴까"를 결정하는 데 5배 시간이 든다. 압축률과 인코딩 비용의 정직한 트레이드오프.
같은 영상을 x264와 x265로 인코딩해 R-D 비교. 파일 크기·VMAF·인코딩 시간을 측정.
import subprocess, os, time, json
INPUT = 'sample.mp4'
configs = [
('x264 fast', ['libx264', '-preset', 'fast', '-crf', '23']),
('x264 medium', ['libx264', '-preset', 'medium', '-crf', '23']),
('x264 slow', ['libx264', '-preset', 'slow', '-crf', '23']),
('x265 fast', ['libx265', '-preset', 'fast', '-crf', '28']),
('x265 medium', ['libx265', '-preset', 'medium', '-crf', '28']),
('x265 slow', ['libx265', '-preset', 'slow', '-crf', '28']),
]
results = []
for name, opts in configs:
output = f'{name.replace(" ", "_")}.mp4'
t0 = time.time()
subprocess.run([
'ffmpeg', '-y', '-i', INPUT,
'-c:v', *opts, '-an', output
], check=True, capture_output=True)
dt = time.time() - t0
size = os.path.getsize(output) / 1e6
# VMAF
subprocess.run([
'ffmpeg', '-y', '-i', output, '-i', INPUT,
'-lavfi', 'libvmaf=log_path=v.json:log_fmt=json',
'-f', 'null', '-'
], check=True, capture_output=True)
vmaf = json.load(open('v.json'))['pooled_metrics']['vmaf']['mean']
results.append((name, dt, size, vmaf))
print(f'{name:<14} {dt:>6.1f}s {size:>6.2f} MB VMAF={vmaf:5.1f}')
# 결과 예시 (1080p 30fps 10s):
# x264 fast 0.8s 3.45 MB VMAF=94.2
# x264 medium 1.5s 3.12 MB VMAF=95.0
# x264 slow 4.8s 2.98 MB VMAF=95.5
# x265 fast 4.2s 1.82 MB VMAF=93.8 ← 같은 화질, 절반 크기
# x265 medium 12.5s 1.65 MB VMAF=94.6
# x265 slow 42.1s 1.55 MB VMAF=95.0 ← x264 medium과 같은 화질, 50% 크기
직접 비교가 명확하다. x265 medium은 x264 medium 대비 인코딩 시간 8배, 파일 크기 절반. R-D 곡선이 압도적으로 위. 그러나 "8배 느린 인코딩"의 비용이 라이브·실시간엔 받아들이기 어려움. 그래서 VOD·다운로드용엔 x265, 라이브엔 여전히 x264.
✅ 시니어가 보는 것
- CTU·quad-tree 분할의 직관과 비용 효과를 안다
- x264 대비 x265의 인코딩 시간이 왜 5~10배인지 설명 가능
- Tile·WPP의 의미와 4K 실시간 인코딩에서의 가치 안다
- 라이센스 사정을 알고 도입 결정에 반영
⚠️ 레드 플래그
- 'H.265는 무조건 좋다'며 라이브에 사용 시도
- x265 preset veryslow를 일상에 씀
- 라이센스 이슈 모른 채 제품 출시
- Profile·Level 차이가 H.264와 같다고 가정
🎤 예상 인터뷰 질문
- H.265가 H.264 대비 압축률 두 배인 이유를 세 가지로 설명해 주세요
- x265 인코딩이 x264보다 느린 본질적 이유는?
- H.265의 라이센스 문제가 AV1 등장에 어떻게 영향을 주었나요?
Key Takeaways
H.265 = HEVC
2013년. H.264 대비 같은 화질에 절반 비트레이트.
CTU 64×64 가변
Quad-tree 분할. 단조 영역은 크게, 디테일은 작게.
35방향 인트라
9 → 35. Planar 모드 추가.
병렬 처리
Tile·WPP·Slice. 4K 실시간 가능.
인코딩 5~10배 느림
CTU 탐색 비용이 주범.
라이센스 지옥
3개 풀 + 별도 권리자. 도입 큰 장벽.
4K·HDR의 표준
BD 4K, 아이폰 비디오, Netflix 4K.
AV1을 촉발
라이센스 불만이 AOMedia 결성으로.