HEVC(H.265) 비디오 코덱 실전 활용 | 4K·8K·x265·FFmpeg 튜닝

작성 0xmote · 2026년 5월 18일 · 18분 읽기 · 수정 2026년 9월 30일 중급 가이드

이 글의 핵심

4K·HDR 영상을 H.264로 보내면 비트레이트 부담이 커지는데, HEVC는 같은 화질을 더 적은 비트로 담는 대신 인코딩이 느리고 웹 브라우저 지원이 고르지 않습니다. 품질 우선 소프트웨어 인코딩과 속도 우선 하드웨어 인코딩 사이의 선택, 품질을 지키면서 파일 크기를 줄이는 옵션, 배치 처리 자동화를 예제와 함께 정리했습니다.

들어가며

HEVC(H.265)는 같은 화질에서 H.264보다 비트레이트를 대략 25~50% 줄이는 것을 목표로 설계된 범용 코덱입니다. 실제 절감 폭은 콘텐츠, 인코더 설정, 측정 방법에 따라 크게 달라집니다. 4K·8K UHD 방송, HDR10·HLG, 모바일 기기의 저장 공간 절약에서 특히 자주 검토됩니다.

반면 특허 라이선스 문제와 구형 단말·웹 브라우저 호환성은 H.264보다 까다롭습니다. 이 글은 압축 효율은 챙기면서 배포 위험은 통제한다는 관점에서 인코딩 방법과 판단 기준을 정리합니다.

HEVC를 도입할지 판단할 때 가장 먼저 따질 것은 압축률이 아니라 디코더가 누구 손에 있느냐입니다. 셋톱박스, 사내 단말, 최신 스마트폰처럼 재생 환경을 통제할 수 있다면 HEVC의 비트레이트 절감은 곧바로 저장·전송 비용 절감으로 이어집니다. 반면 불특정 다수의 웹 브라우저가 대상이라면 재생 실패율이 비용 절감을 상쇄할 수 있습니다. 아래 내용은 이 판단에 필요한 구조적 배경과, 실제로 인코딩 명령을 짤 때 자주 틀리는 옵션을 중심으로 정리했습니다.

코덱 개요

역사 및 개발 배경

HEVC는 ITU-T VCEG와 ISO/IEC MPEG의 공동 팀인 JCT-VC(Joint Collaborative Team on Video Coding)가 표준화했고, 2013년에 ITU-T H.265와 ISO/IEC 23008-2(MPEG-H Part 2)로 발행되었습니다. 설계 목표는 UHD, 높은 프레임레이트, 높은 비트 심도에서 H.264보다 효율을 높이는 것과, 타일(tile)과 WPP(Wavefront Parallel Processing)처럼 멀티코어에서 병렬로 인코딩·디코딩하기 쉬운 구조를 갖추는 것이었습니다.

기술적 특징

CTU(Coding Tree Unit): H.264의 16×16 매크로블록 대신 최대 64×64 크기의 블록에서 시작해 쿼드트리로 재귀 분할합니다.
CU / PU / TU: 코딩 단위, 예측 단위, 변환 단위를 분리해서 복잡한 텍스처나 경계에 맞춰 각각 다른 크기로 나눌 수 있습니다.
예측 개선: 인트라 예측 방향이 H.264의 최대 9개에서 35개(방향 33개 + Planar + DC)로 늘었고, 인터 예측은 Merge 모드로 주변 블록의 움직임 정보를 재사용해 모션 벡터에 드는 비트를 줄입니다.
인루프 필터: 디블로킹 필터에 SAO(Sample Adaptive Offset)가 추가되어 링잉과 밴딩 같은 아티팩트를 줄입니다. ALF(Adaptive Loop Filter)는 HEVC 표준화 과정에서 제외되었고, 후속 코덱인 VVC(H.266)에 들어갔습니다.

CTU가 64×64까지 커질 수 있다는 점이 4K에서 특히 중요합니다. H.264의 16×16 매크로블록은 4K 화면을 약 3만 개 조각으로 나누지만, 하늘이나 벽처럼 평평한 영역도 16×16마다 헤더와 모드 정보를 따로 써야 했습니다. HEVC는 평평한 영역을 큰 블록 하나로, 경계가 복잡한 영역만 8×8까지 잘게 쪼개므로 해상도가 높을수록 절감 효과가 커집니다. 반대로 저해상도(480p 이하)에서는 큰 블록의 이점이 작아 H.264 대비 차이도 줄어드는 경향이 있습니다. 인코더가 느린 이유도 이 구조에서 나오는데, 각 CTU를 어떻게 쪼갤지 가능한 분할 조합을 탐색하는 비용이 크기 때문이며, preset이 느릴수록 더 많은 조합을 시도합니다.

주요 프로파일 및 레벨

프로파일	요지	실무 메모
Main	8비트 4:2:0	일반 VOD·방송에 널리 사용
Main 10	10비트 4:2:0	HDR 필수, 그레이딩·밴딩 완화에 유리
Main Still Picture	정지 영상 한 장	HEIF(HEIC) 사진 포맷의 기반

티어(Tier)와 레벨(Level)은 디코더가 처리해야 하는 해상도, 초당 샘플 수, 비트레이트의 상한을 정합니다. 예를 들어 레벨 5.0은 4K 30fps, 5.1은 4K 60fps 수준이고, High 티어는 같은 레벨에서 더 높은 비트레이트를 허용합니다. 4K 60fps HDR처럼 요구가 높은 콘텐츠를 만들 때는 대상 기기의 디코더가 어느 프로파일·티어·레벨까지 지원하는지 먼저 확인해야 합니다.

압축 원리

Intra / Inter 예측

Intra: 방향 예측 모드가 35개로 세분화되어, 비스듬한 직선 경계나 완만한 그라데이션을 H.264보다 정확하게 예측합니다.
Inter: Merge 모드에서는 모션 벡터를 직접 쓰지 않고 “이웃 후보 목록의 몇 번째와 같다”는 인덱스만 보냅니다. 같은 방향으로 움직이는 넓은 영역에서 모션 정보 비트가 크게 줄어듭니다.

Transform & Quantization

변환 블록(TU)은 4×4부터 32×32까지 쓸 수 있고, 정수 근사 DCT를 기본으로 4×4 인트라 휘도 블록에만 DST를 씁니다. 큰 변환은 평평한 영역의 에너지를 소수의 계수로 모아 줍니다. 양자화 강도는 x265의 CRF나 AQ(Adaptive Quantization) 같은 레이트 제어와 맞물려, 사람 눈이 민감한 영역에 비트를 더 배분하도록 조절됩니다.

Entropy Coding

HEVC는 엔트로피 코딩으로 CABAC만 씁니다. H.264에 있던 CAVLC 선택지는 없어졌습니다. CABAC 자체는 H.264와 같은 원리지만, 컨텍스트 수를 줄이고 컨텍스트 없이 처리하는 bypass 빈을 늘려서 고해상도에서 디코더 처리량이 병목이 되지 않도록 설계되었습니다.

압축 파이프라인 다이어그램

flowchart TB
  subgraph frame [프레임 입력]
    F[YUV / RGB 변환]
  end
  subgraph tree [공간 분할]
    CTU[CTU 64x64]
    SPLIT[재귀적 CU 분할]
  end
  subgraph predict [예측]
    PRED[Intra / Inter + Merge]
  end
  subgraph coeff [계수]
    TQ[Transform & Quantize]
  end
  subgraph stream [비트스트림]
    CABAC[CABAC]
    NAL[HEVC NAL Units]
  end
  F --> CTU
  CTU --> SPLIT
  SPLIT --> PRED
  PRED --> TQ
  TQ --> CABAC
  CABAC --> NAL

실전 인코딩

품질 우선: libx265 + CRF (8비트 420)

ffmpeg -i input.mov -c:v libx265 -crf 24 -preset slow -tag:v hvc1 \
  -pix_fmt yuv420p -c:a aac -b:a 192k output.mp4

CRF: x265에서는 흔히 24~28 범위가 실용적입니다. H.264의 CRF와 숫자 의미가 같지 않으니 직접 시각 비교가 중요합니다. x265의 기본값은 28이며, x264 CRF 23과 비슷한 체감 품질을 내도록 맞춰져 있다고 x265 문서가 설명합니다. 즉 x264에서 쓰던 숫자를 그대로 가져오면 x265에서는 필요 이상으로 큰 파일이 나옵니다.
-tag:v hvc1: MP4 안의 HEVC 트랙에는 코덱 태그가 hev1과 hvc1 두 가지가 있는데, FFmpeg 기본값은 hev1입니다. Apple의 QuickTime·Safari·iOS는 hvc1 태그만 재생하므로, 이 옵션을 빼면 “다른 플레이어에서는 재생되는데 맥과 아이폰에서만 안 열린다”는 증상이 생깁니다. 화질과는 무관하고 호환성을 위한 옵션입니다.

Main 10 (10비트): HDR·그레이딩 파이프라인

ffmpeg -i input.mov -c:v libx265 -crf 22 -preset slow -pix_fmt yuv420p10le \
  -tag:v hvc1 -c:a aac -b:a 192k output.mp4

소스가 8비트라면 비트 심도만 올린다고 원본에 없던 정보가 생기지는 않습니다. 원본과 마스터링 단계에 맞춰 결정하세요. 다만 8비트 SDR 소스라도 10비트로 인코딩하면 하늘 같은 완만한 그라데이션에서 인코더가 만드는 밴딩이 줄어드는 효과가 있어, 호환성이 허락되면 Main 10을 쓰는 서비스도 있습니다.

위 명령은 10비트로 인코딩할 뿐 HDR 메타데이터를 싣지는 않습니다. HDR10 소스를 이 명령으로 변환하면 PQ 전달 함수로 만들어진 픽셀 값이 SDR(BT.709)로 표시되어 색이 바래고 어둡게 보입니다. HDR을 유지하려면 색 공간과 마스터링 정보를 명시해야 합니다.

ffmpeg -i input_hdr10.mov -c:v libx265 -crf 20 -preset slow -pix_fmt yuv420p10le \
  -x265-params "hdr10=1:repeat-headers=1: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 -c:a copy output_hdr10.mp4

master-display와 max-cll 값은 예시이며, 실제로는 원본 파일의 값을 ffprobe -show_frames -read_intervals "%+#1" input_hdr10.mov로 읽어 그대로 옮겨야 합니다. 값이 틀리면 TV의 톤 매핑이 잘못되어 밝은 부분이 날아가거나 전체가 어둡게 표시됩니다. repeat-headers=1은 스트리밍 중간부터 재생해도 디코더가 HDR 정보를 받을 수 있도록 키프레임마다 헤더를 반복하는 옵션입니다.

목표 비트레이트(4K VOD 예시)

ffmpeg -i input_4k.mov -c:v libx265 -b:v 15M -maxrate 20M -bufsize 40M \
  -preset medium -pix_fmt yuv420p -tag:v hvc1 -c:a aac -b:a 192k output.mp4

NVIDIA NVENC (속도)

ffmpeg -hwaccel cuda -i input.mov -c:v hevc_nvenc -rc vbr -cq 26 -b:v 0 -preset p5 \
  -pix_fmt yuv420p -tag:v hvc1 -c:a aac -b:a 192k output.mp4

-cq와 -preset의 의미와 허용 값은 드라이버와 FFmpeg 버전에 따라 달라질 수 있으므로 ffmpeg -h encoder=hevc_nvenc로 확인합니다. p1(가장 빠름)~p7(가장 느림, 고품질) 형식의 preset은 비교적 최근 SDK에서 도입된 체계입니다.

-b:v 0을 함께 준 데는 이유가 있습니다. NVENC의 VBR 모드는 목표 비트레이트가 지정되지 않으면 FFmpeg의 기본 비트레이트를 상한처럼 쓰는 경우가 있어서, -cq만 주면 복잡한 장면에서 품질 목표를 채우지 못하고 비트레이트가 눌려 화질이 기대보다 낮게 나옵니다. -b:v 0으로 상한을 풀어야 -cq 값이 주로 품질을 결정합니다. 또 -hwaccel cuda는 디코딩만 GPU로 할 뿐, 디코딩된 프레임은 기본적으로 시스템 메모리로 내려왔다가 다시 GPU로 올라갑니다. 필터 없이 인코딩만 한다면 -hwaccel_output_format cuda를 추가해 프레임을 GPU 메모리에 둔 채 인코더로 넘기면 복사 비용을 줄일 수 있습니다(이때 -pix_fmt yuv420p 같은 CPU 쪽 픽셀 형식 지정은 빼야 합니다).

파라미터 튜닝 가이드

상황	방향
세밀한 텍스처(잔디, 물결)	CRF를 약간 낮추거나 AQ 관련 옵션(`aq-mode`, `aq-strength`) 검토
저지연(라이브, 화상회의)	`-tune zerolatency`로 B-프레임과 lookahead 제거, 빠른 preset, 작은 VBV 버퍼
아카이브	느린 preset, 목표 파일 크기가 정해져 있으면 2-pass

품질 vs 속도 트레이드오프

HEVC 소프트웨어 인코딩은 같은 preset 이름이라도 x264보다 훨씬 느립니다. 오프라인 VOD는 느린 preset으로 시간을 들이고, 실시간 인코딩은 GPU 하드웨어 인코더를 쓰는 것이 현실적입니다.
같은 파일 크기로 맞춰 비교하면 HEVC가 PSNR, SSIM, VMAF에서 유리한 경우가 많지만, 지표는 특정 아티팩트를 놓치기도 하므로 최종 판단은 실제 시청으로 합니다.

성능 비교

다른 코덱과의 압축률

실무에서는 같은 VMAF나 SSIM 목표에 도달하는 데 필요한 비트레이트로 비교하는 방식이 흔합니다(BD-rate). 압축 효율은 대체로 H.264 < HEVC ≤ AV1 순으로 이해하면 되지만, 콘텐츠와 인코더 구현, 설정에 따라 순서가 바뀌기도 합니다. 하드웨어 인코더끼리 비교하면 소프트웨어 인코더끼리 비교할 때보다 차이가 작게 나오는 경우가 많습니다.

인코딩·디코딩 속도

인코딩: libx265는 고해상도와 느린 preset에서 매우 느립니다. 대량 변환 파이프라인이라면 파일 단위로 여러 프로세스나 여러 서버에 나눠 처리하는 구성을 고려합니다.
디코딩: 최근 몇 년 사이 나온 스마트폰 SoC와 GPU는 대부분 HEVC 4K·10비트 하드웨어 디코딩을 지원합니다. 하드웨어 디코더가 없는 구형 PC는 CPU로 디코딩해야 해서 4K에서는 프레임이 끊기거나 발열과 팬 소음이 커질 수 있습니다.

하드웨어 가속 지원

Intel: Quick Sync에서 HEVC 디코딩과 인코딩을 지원합니다. 10비트 지원 여부는 세대별로 다릅니다.
NVIDIA: NVENC(인코딩)와 NVDEC(디코딩)으로 지원하며, FFmpeg에서는 hevc_nvenc, hevc_cuvid 등으로 씁니다.
Apple: VideoToolbox로 지원하며, FFmpeg에서는 hevc_videotoolbox로 씁니다.
모바일 SoC: 사실상 표준으로 탑재되어 있지만, 10비트와 HDR 메타데이터 처리는 모델마다 차이가 있습니다.

실무 활용 사례

스트리밍 서비스 (YouTube, Netflix 등)

넷플릭스처럼 TV와 셋톱박스 비중이 큰 서비스는 4K HDR에 HEVC를 쓰면서 AV1을 함께 배포하고, 구형 단말을 위해 H.264 비트레이트 사다리(ladder)를 유지합니다. 반면 유튜브는 로열티 문제 때문에 HEVC 대신 VP9과 AV1을 씁니다.
DASH/HLS로 패키징할 때는 코덱 태그, 세그먼트 길이, 키프레임 간격이 재생 안정성에 큰 영향을 줍니다. 세그먼트 경계마다 키프레임이 오도록 GOP 길이를 세그먼트 길이에 맞춰 고정해야 화질 전환이 매끄럽습니다.

모바일 앱

아이폰은 iOS 11부터 지원 기기에서 카메라 기본 녹화 형식이 HEVC이고, 최신 안드로이드 기기도 대부분 HEVC 녹화와 재생을 지원합니다. 다만 사용자가 올린 영상을 다른 사용자에게 보여 주는 앱이라면, 구형 기기 비율에 따라 서버에서 H.264 버전을 함께 만들어 두는 설계가 안전합니다.

웹 브라우저 지원

MP4 안의 HEVC는 OS, GPU, 브라우저 빌드에 따라 재생 여부가 갈립니다. 불특정 다수의 웹 사용자가 대상이라면 H.264나 AV1(폴백 포함)으로 가는 편이 단순한 경우가 많습니다.

브라우저 쪽 상황은 몇 년 사이 많이 바뀌었습니다. Safari는 오래전부터 HEVC를 재생했고, Chrome은 107 버전부터 하드웨어 디코더가 있는 기기에서 HEVC 재생을 지원합니다. 즉 같은 Chrome이라도 GPU·OS에 따라 재생 여부가 갈리고, 소프트웨어 디코딩 폴백은 없습니다. 그래서 웹에서 HEVC를 쓴다면 <video>에 <source>를 여러 개 두거나 MediaSource.isTypeSupported('video/mp4; codecs="hvc1.1.6.L120.90"')로 확인한 뒤 H.264로 대체하는 구조가 필수입니다. codecs 문자열도 hvc1로 시작해야 하며, 여기서도 앞의 -tag:v hvc1이 영향을 줍니다.

최적화 팁

품질 유지하며 파일 크기 줄이기

해상도와 fps를 먼저 확정한 뒤 CRF나 비트레이트를 조정합니다. 작은 화면에서 볼 영상이라면 4K를 낮은 비트레이트로 보내는 것보다 1080p를 넉넉한 비트레이트로 보내는 편이 더 좋아 보이는 경우가 많습니다.
HDR은 마스터링에 쓰인 전달 함수(PQ/HLG)와 메타데이터를 파이프라인 전체에서 보존해야 합니다. 중간 단계에서 한 번이라도 메타데이터가 빠지면 최종 결과물이 SDR로 표시됩니다.

인코딩 속도 개선

preset을 빠른 쪽으로 옮깁니다(slow → medium → fast). 한 단계마다 속도와 압축률이 함께 바뀌므로 VMAF로 품질 변화를 확인합니다.
GPU 인코더로 전환하고, 같은 VMAF를 내는 데 비트레이트가 얼마나 더 드는지 확인합니다.
코어가 많은 서버에서는 x265의 pools(스레드 풀), frame-threads 옵션을 -x265-params로 조정할 수 있습니다. 다만 영상 한 개를 많은 코어로 나누기보다 여러 파일을 동시에 인코딩하는 편이 전체 처리량이 더 높은 경우가 많습니다.

배치 처리 자동화

#!/usr/bin/env bash
set -euo pipefail
mkdir -p hevc_out
for f in *.mkv; do
  ffmpeg -y -i "$f" -c:v libx265 -crf 26 -preset medium -pix_fmt yuv420p \
    -tag:v hvc1 -c:a copy "hevc_out/${f%.mkv}.mp4"
done

-c:a copy는 오디오 재인코딩을 피해 시간을 줄이지만, MKV에 흔한 FLAC이나 DTS 같은 오디오는 MP4에 넣을 수 없거나 재생기가 지원하지 않을 수 있으므로 컨테이너 호환성을 확인해야 합니다. 원본 오디오가 AAC가 아니라면 -c:a aac로 바꾸는 편이 안전합니다.

흔한 문제와 해결

호환성 이슈

재생은 되는데 색이 이상하다: 색 범위(tv/limited와 pc/full), 색 메타데이터(BT.709/BT.2020), 플레이어의 톤 매핑 문제일 수 있습니다. 인코딩할 때 마스터 파일과 같은 색 태그를 명시적으로 지정합니다.
웹에서 안 열린다: 브라우저와 OS 조합 문제일 수 있으니 H.264나 AV1을 함께 제공하는 방법을 검토합니다. 맥과 iOS에서만 안 열린다면 hvc1 태그부터 확인합니다.

품질 저하 문제

저비트레이트 4K: 잔디나 물결처럼 세밀하고 움직이는 텍스처에서 아티팩트가 쉽게 드러납니다. 비트레이트, 해상도, CRF를 함께 조정합니다.
x265 vs NVENC: 같은 숫자 설정이라도 품질 곡선이 다릅니다. CRF 26과 CQ 26이 같은 화질이라는 보장은 없으니 같은 VMAF에 맞춰 비교하세요.

라이선스 고려사항

HEVC는 특허 라이선스 문제가 오래 논란이 되었고, 상용 소프트웨어 배포나 하드웨어 제품에는 법무 검토가 필요할 수 있습니다. 오픈소스 인코더를 쓴다고 특허 사용료 문제가 사라지는 것은 아닙니다.

HEVC 특허가 까다로운 이유는 풀이 하나가 아니기 때문입니다. H.264는 사실상 MPEG LA 한 곳과 계약하면 됐지만, HEVC는 Access Advance와 Via LA(옛 MPEG LA의 HEVC 프로그램을 이어받음) 같은 여러 풀과, 어느 풀에도 속하지 않은 개별 특허권자가 따로 있습니다. x265 같은 소프트웨어는 소스 코드 라이선스(GPL/상용)만 정할 뿐 특허 라이선스를 대신해 주지 않습니다. 이 불확실성이 대형 기업들이 로열티 없는 AV1을 만든 직접적인 계기였고, 웹 브라우저가 HEVC 지원을 하드웨어 디코더(기기 제조사가 이미 라이선스를 낸 경로)에 맡기는 이유이기도 합니다.

HEVC가 잘 맞는 경우

4K 영상 보관, 모바일 앱의 다운로드 용량 절감, 사내 UHD 스트리밍처럼 디코더가 통제된 환경에서 HEVC는 매우 실용적입니다. 불특정 다수의 웹 사용자에게 배포하는 것이 목표라면 H.264와 AV1을 포함한 멀티 코덱 전략과 비교해 보세요.

공식 스펙 및 표준 문서

ITU-T H.265 | ISO/IEC 23008-2 (HEVC)

공식 스펙:

ITU-T: https://www.itu.int/rec/T-REC-H.265
ISO: https://www.iso.org/standard/83528.html

핵심 섹션:

Annex A: 프로파일(Main, Main 10), 티어와 레벨(5 ≈ 4K@30fps, 5.1 ≈ 4K@60fps)
Annex D: SEI 메시지 (HDR 메타데이터)
Annex E: VUI (색 공간, 전달 함수)

HDR 표준:

SMPTE ST 2086 - HDR Static Metadata
ITU-R BT.2100 - HDR TV 표준 (PQ, HLG)

참고 자료:

자주 묻는 질문 (FAQ)

Q. HEVC로 인코딩한 영상이 재생은 되는데 색이 이상하게 보이면 무엇을 확인하나요?

A. 대개 색 범위(tv/limited와 pc/full)가 어긋났거나, BT.709와 BT.2020 같은 색 메타데이터가 빠지거나 잘못 붙은 경우, 또는 플레이어의 톤 매핑 문제입니다. 인코딩할 때 색 관련 태그를 마스터 파일과 일관되게 지정하고, 10비트 HDR 소스라면 플레이어와 기기가 해당 메타데이터를 해석하는지 실기기에서 확인해야 합니다. 브라우저·OS 조합에 따라 아예 재생되지 않는 경우도 있으므로 웹 배포에는 H.264나 AV1 폴백을 함께 준비하는 편이 안전합니다.