09 · HEVC / H.265 — 좋은 기술, 나쁜 라이선스
이 문서가 답하는 질문: HEVC는 왜 채택이 늦었고, 누가 쓰는가? 선행:
08-codec-h264.md
한 줄 답
HEVC는 H.264 대비 같은 품질에서 약 50% 비트 절감을 이루지만, 라이선스 풀이 셋으로 분열되며 채택이 지연됐다. 결국 Apple 생태계(iOS·Apple TV)와 Smart TV·Blu-ray UHD에 정착하고, 웹은 AV1로 넘어가는 전환기 코덱이 됐다.
Why — 왜 HEVC가 만들어졌고, 왜 늦었나
만들어진 이유 (2013)
- 4K UHD 시대 도래 → H.264로는 비트레이트 너무 높음
- HDR·10bit·BT.2020 표준화와 동시 진행
- 모바일 디바이스 디코더 chip이 HEVC 가속 가능해지는 시점
채택이 늦은 이유
H.264는 MPEG LA 단일 패턴트 풀 — 한 번 라이선싱하면 끝. HEVC는 3개 풀로 분열:
| 풀 | 멤버 | 정책 |
|---|---|---|
| MPEG LA | 25개사 | 디바이스 라이선스 + 콘텐츠 무료 |
| HEVC Advance (2015 분리) | Sony·Dolby·Philips·Mitsubishi 등 | 디바이스 + 콘텐츠 라이선스 ← 충격 |
| Velos Media (2017 분리) | Ericsson·Panasonic·Qualcomm 등 | 미공개 |
→ OTT 서비스 입장에서 콘텐츠 라이선스 비용이 얼마인지 알 수 없음. 누구도 모험을 안 함. → Apple은 patent 보유자라 직접 채택, 그 외 빅테크는 AV1으로 회피.
How — H.264와의 차별점
1) CTU (Coding Tree Unit) — 매크로블록의 진화
H.264 매크로블록은 16×16 고정. HEVC는 64×64 CTU가 기본.
H.264: 16×16 매크로블록 (1 size)
→ 더 잘게 8×8, 4×4까지 분할
HEVC: 64×64 CTU
→ 32×32 / 16×16 / 8×8 까지 quad-tree 분할→ 4K·8K처럼 큰 평면 영역(하늘·벽)은 64×64 한 블록으로 효율적 압축. → 디테일 영역만 잘게 쪼갬 — 더 적응적.
2) Intra Prediction 모드 35개
H.264는 9개 방향, HEVC는 35개 방향 (수평·수직·대각선·planar·DC 포함). 대각선 디테일이 많은 콘텐츠(텍스처·천)에서 특히 효율 향상.
3) Motion Compensation 정밀도
- H.264: 1/4 pixel
- HEVC: 1/4 luma + 1/8 chroma
- 7-tap / 8-tap interpolation filter (H.264는 6-tap)
4) SAO (Sample Adaptive Offset)
디블록킹 필터 후 추가 노이즈 보정 단계. 링잉 아티팩트(ringing) 를 줄인다 (날카로운 경계 주변의 파동).
5) Tile / Slice / Wavefront
병렬 디코딩을 위한 분할:
- Tile: 화면을 격자로 나눠 독립 디코드 (멀티코어 친화)
- Wavefront Parallel Processing (WPP): CTU 줄을 비스듬히 병렬
→ 4K·8K 디코딩 시 멀티코어 활용 효율 ↑.
압축 효율 비교 (BD-rate, lower=better)
| 콘텐츠 | H.264 → HEVC 절감 |
|---|---|
| 1080p 영화 | 35~40% |
| 4K HDR | 45~55% |
| 게임/스포츠(고모션) | 30% |
| 애니메이션 | 50% |
What — 사양 표
Profile
| Profile | 비트심도 | 서브샘플 | 사용처 |
|---|---|---|---|
| Main | 8 | 4:2:0 | 표준 SDR |
| Main 10 | 10 | 4:2:0 | HDR10·HDR10+·Dolby Vision Profile 5 |
| Main 4:2:2 10 | 10 | 4:2:2 | 방송 마스터링 |
| Main 4:4:4 | 8 | 4:4:4 | 그래픽 |
| Main 4:4:4 10 | 10 | 4:4:4 | VFX |
| Main 4:4:4 16 Intra | 16 | 4:4:4 | 디지털 시네마 |
| Monochrome | 8/10 | 4:0:0 | 흑백 (의료·감시) |
Level (해상도·프레임레이트 제한)
| Level | 최대 해상도@fps | 최대 비트레이트 (Main Tier) |
|---|---|---|
| 3.0 | 720p@30 | 6 Mbps |
| 4.0 | 1080p@30 | 12 Mbps |
| 4.1 | 1080p@60 | 20 Mbps |
| 5.0 | 4K@30 | 25 Mbps |
| 5.1 | 4K@60 | 40 Mbps |
| 5.2 | 4K@120 | 60 Mbps |
| 6.0 | 8K@30 | 60 Mbps |
| 6.1 | 8K@60 | 120 Mbps |
| 6.2 | 8K@120 | 240 Mbps |
→ Main Tier vs High Tier — High Tier는 비트레이트 상한이 ~3× (Blu-ray UHD에 사용).
MIME / codecs 파라미터
video/mp4; codecs="hvc1.1.6.L120.90" ← Main Profile 4.0
video/mp4; codecs="hvc1.2.4.L150.B0" ← Main 10 Profile 5.0
video/mp4; codecs="hev1.1.6.L120.90" ← unparsed (NAL inline)hvc1 vs hev1:
hvc1: SPS/VPS/PPS inhvcCconfig (sample entry box) — Apple 표준hev1: SPS/VPS/PPS inline in NAL — 일부 안드로이드 디코더 친화
→ 같은 비트스트림이지만 컨테이너 packaging이 다름. iOS Safari는 hvc1만 안정.
ffmpeg 인코딩
# HEVC 1080p (HW 가속 없이, x265)
ffmpeg -i in.mov \
-c:v libx265 -preset slow -crf 22 \
-tag:v hvc1 \
-pix_fmt yuv420p \
-c:a aac -b:a 128k \
-movflags +faststart \
out.mp4
# HDR10 Main 10
ffmpeg -i hdr_master.mov \
-c:v libx265 -preset slow -crf 20 \
-pix_fmt yuv420p10le \
-x265-params "colorprim=bt2020:transfer=smpte2084:colormatrix=bt2020nc:\
master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1):\
max-cll=1000,400" \
-tag:v hvc1 hdr10.mp4
# Apple VideoToolbox HW 가속 (macOS, iOS)
ffmpeg -i in.mov -c:v hevc_videotoolbox -b:v 5M -tag:v hvc1 out.mp4
# NVIDIA NVENC (Windows/Linux)
ffmpeg -i in.mov -c:v hevc_nvenc -preset p7 -cq 22 -tag:v hvc1 out.mp4
# Intel QSV
ffmpeg -i in.mov -c:v hevc_qsv -global_quality 22 -tag:v hvc1 out.mp4x265 preset
ultrafast superfast veryfast faster fast medium slow slower veryslow placebo
← 빠름 · 낮은 효율 느림 · 높은 효율 →x264와 동일한 이름이지만 속도 차이가 더 큼 — slower는 medium 대비 5~10× 시간.
What-if — 잘못 다루면 어떻게 깨지는가
❌ 함정 1 — hvc1 vs hev1 혼용
iOS Safari는 hvc1만, 일부 Android 디코더는 hev1만 받음. 호환성 보장하려면 -tag:v hvc1으로 명시.
# ffmpeg는 default로 hev1 출력
# iOS 호환 hvc1로 강제
-tag:v hvc1❌ 함정 2 — Chrome HEVC 미지원 가정
Chrome 11+ (2022)부터 OS HW HEVC 디코더가 있으면 재생 가능 (그러나 enabled by default 아님). 현실적으로 Chrome에는 VP9 또는 AV1 폴백 권장.
❌ 함정 3 — Smart TV 일부 모델은 Main 10만 지원
10bit 디코더는 있는데 8bit Main이 거부되는 케이스. 보통 Main 10이 superset 으로 작동하지만 일부 Sony·Samsung 펌웨어 버그.
❌ 함정 4 — 라이선스 비용 미산정
OTT 콘텐츠 송출에 HEVC를 쓰면 HEVC Advance 풀이 content royalty를 청구할 수 있음. 규모가 크면 수년 뒤 collection notice 가능 — Netflix·Amazon이 AV1로 가는 진짜 이유.
❌ 함정 5 — Apple ProRes 마스터를 HEVC로 직접 인코딩
ProRes (10bit 4:2:2)를 HEVC Main(8bit 4:2:0)으로 가면 색·계조 정보 대폭 손실. Main 10 4:2:0 또는 Main 4:2:2 10 으로 가서 색 보존 후 4:2:0 8bit로 다운그레이드.
❌ 함정 6 — Dolby Vision Profile 5를 HDR10 호환으로 가정
Profile 5는 base layer 단독 (DV-only) — HDR10/SDR 폴백 불가. 디바이스가 DV를 못 받으면 깨진 영상. Profile 8.1 이 single-layer + HDR10 폴백 가능.
Insight — 흥미로운 이야기
“HEVC Advance가 모든 걸 망쳤다”
2015년 HEVC Advance가 분리되면서 발표한 라이선스 모델: 콘텐츠당 0.5% royalty. Netflix·Amazon·YouTube에게 수억 달러 단위 비용. 표준화 직후 그들이 등을 돌렸고, 그 자리에 AV1 합의가 시작됐다. “나쁜 라이선스는 좋은 기술을 죽인다” 의 교과서 사례.
“Apple이 HEVC를 사랑하는 이유”
Apple은 HEVC patent의 주요 소유자 중 하나 (HEVC Advance 멤버). iPhone 7(2016) 부터 HW 인코더/디코더 탑재, iOS 11(2017) 부터 사진 라이브러리 default가 HEIF (HEVC 정지영상). “카메라 → 저장 → 클라우드 → 재생” 모든 단계를 HEVC로 통일 — Apple의 닫힌 생태계가 HEVC 채택 가속.
“Blu-ray UHD가 HEVC의 마지막 보루”
4K UHD Blu-ray (2016~) 는 표준이 HEVC Main 10 only. AV1로 갈 수 없음. 디스크 인프라 + 디코더 칩이 이미 박혀있어 AV1 폴백 없음. → “HEVC는 영원히 안 사라진다 — 디스크가 살아있는 한”. 그러나 디스크 시장은 축소 중.
“HEVC 인코더 x265가 GPL이 된 이유”
x265는 처음부터 GPL 라이선스 — 상업적 사용에 상업 라이선스 별도 구매 필요. x264 (GPL이지만 상업 라이선스 거의 무료) 와는 다른 모델. 이 비대칭이 오픈소스 인코딩 도구의 보급을 늦췄고, AV1 SVT-AV1 (BSD) 가 매력적인 이유.
“VVC가 와도 HEVC는 안 죽는다”
2020년 VVC 발표 후에도 HEVC는 5G·8K 방송에서 여전히 mainstream. 디바이스가 VVC HW 디코더를 갖추는 데 5년 이상. 그 사이에 HEVC가 legacy mature codec으로 자리. → 마치 H.264가 HEVC 시대에도 폴백으로 살아있듯, HEVC도 VVC 시대에 폴백으로 남는다.
요약 + Mermaid
HEVC는 H.264 대비 50% 절감의 좋은 기술이지만, 라이선스 분열로 웹 채택이 지연됐다. CTU·35-mode intra prediction·SAO·1/8 chroma motion이 효율의 출처. Main 10이 HDR의 표준. Apple/Smart TV/Blu-ray UHD에 정착, 웹은 AV1로 우회 — 전환기 코덱.