direcf / 비디오 코덱 — H.264·H.265·AV1과 그 너머 / Ch01
GitHub ↗
CHAPTER 01 OF 10
📐

Why Video Compression

비디오 압축이 필요한 이유

비디오 데이터는 비현실적으로 거대하다. 압축이 없으면 '비디오'라는 미디어 자체가 성립하지 않는다 — 이 한 줄이 모든 코덱의 출발점이다.

Why Video Compression cheatsheet
🍌 NANO BANANA CHEATSHEET · CH 01

Overview

개관

비디오 코덱을 공부하기 전에 단 한 가지 사실만 머리에 박으면 된다 — 비디오 데이터는 비현실적으로 거대하다. 그래서 압축이 필요하다. 이 한 줄이 우리가 앞으로 9개 챕터에 걸쳐 다룰 모든 기술(DCT·모션 추정·CABAC·CTU 등)의 출발점이다.

이번 장은 짧지만 중요하다. 실제 숫자로 'raw 비디오가 얼마나 거대한가'를 체감하고, 그래서 코덱이 어떤 '게임'을 하고 있는지를 직관적으로 그려본다. 압축률 100배·200배는 마법이 아니라, 비디오 데이터에 숨어 있는 거대한 중복을 영리하게 활용하는 정보이론적 게임의 결과다.

🎯 Learning Goals
  • Raw 비디오 데이터의 실제 크기를 직접 계산할 수 있다
  • 'Codec'이라는 단어의 어원과 정확한 의미를 안다
  • 압축이 단순 트릭이 아니라 수학·정보이론에 뿌리를 둔다는 사실을 이해한다
  • 손실(Lossy)과 무손실(Lossless) 압축의 본질적 차이를 구분한다
  • 코덱이 풀어야 할 '근본 문제'가 무엇인지 한 문장으로 설명할 수 있다

Sections

본문

1.1 Raw 비디오의 절망적인 크기

1080p 30fps 비디오의 raw 데이터량을 계산해 보자. 1920×1080 픽셀, 한 픽셀당 RGB 3채널 × 8비트 = 24비트, 초당 30프레임.

1920 × 1080 × 24 × 30 ≈ 1,492 Mbps ≈ 1.5 Gbps.

초당 1.5 기가비트다. 너의 인터넷이 100Mbps라면, 1초 분량을 받는 데 15초가 걸린다. 즉 압축 없이는 실시간 재생이 불가능하다.

4K(3840×2160) 60fps이면 12Gbps, 8K 60fps이면 약 50Gbps. 디스크에 저장한다고 해도 1시간짜리 1080p 영상이 약 650GB다. 우리가 일상에서 보는 1080p 영화 파일이 보통 2~4GB임을 생각하면 150~300배 정도 압축이 일어나고 있다는 의미다.

이 게임의 본질: 이 150배 압축을 화질 손실 없이 가까이, 또는 사람 눈에 거의 안 보이는 손실로 달성해야 한다.

1.2 코덱(Codec)의 정확한 정의

Codec = Coder + Decoder의 합성어. 인코더는 압축하고, 디코더는 복원한다.

둘은 짝이다. H.264로 인코딩된 영상은 H.264 디코더로만 복원할 수 있고, AV1로 인코딩된 영상은 AV1 디코더로만 복원할 수 있다. 이게 디바이스 호환성의 본질이다 — 아이폰이 H.265로 찍은 영상을 옛 안드로이드가 못 보는 이유는, 그 안드로이드에 H.265 디코더가 없거나(또는 HW 가속 없이 SW로만 가능해 배터리 폭주) 하기 때문이다.

또 하나 중요한 구분: '코덱'과 '컨테이너'는 다르다. .mp4라는 확장자는 컨테이너고, 그 안에 H.264·H.265·AV1 어떤 비디오 코덱이든 들어 있을 수 있다. 우체국 박스(컨테이너) vs 그 안의 내용물(코덱). 자세한 건 챕터 10에서 다룬다.

1.3 압축은 정보이론적 게임

코덱은 트릭의 모음이 아니다. Shannon의 정보이론에 뿌리를 둔 수학이다.

Shannon이 1948년에 정립한 것: 어떤 데이터든 그 데이터의 '엔트로피(entropy)' 한계까지만 무손실 압축 가능하다. 엔트로피는 데이터의 '무질서도' 또는 '예측 불가능성'의 양. 완전 무작위 데이터는 엔트로피가 최대라 압축이 안 된다.

다행히 비디오 데이터는 엔트로피가 매우 낮다. 인접 픽셀은 거의 같고, 인접 프레임도 거의 같고, 인간 눈은 디테일을 다 못 본다. 이런 '예측 가능성'이 클수록 압축률이 폭증한다.

그래서 비디오 코덱이 하는 일을 한 문장으로 요약하면: '데이터 안의 예측 가능한 부분을 최대한 찾아내 제거하는 것'. 이 한 문장이 H.264·H.265·AV1을 모두 관통하는 정신이다.

1.4 손실(Lossy) vs 무손실(Lossless)

압축에는 두 종류가 있다.

무손실(Lossless): 압축 후 복원하면 원본과 비트 단위로 동일. 보통 2~4배 압축. 의료·아카이브·전문 후반작업에 쓰임. 예: FFV1, H.264 Lossless 모드.

손실(Lossy): 사람이 인지 못 하는 정보를 일부러 버리고 압축. 100~300배 압축 가능. 우리가 일상에서 보는 모든 비디오. 예: 일반 H.264/H.265/AV1.

무손실 압축은 정보이론 한계에 의해 압축률이 강하게 제한된다. 그래서 일상 비디오는 거의 다 Lossy다. 손실의 핵심은 '무엇을 버려도 사람이 못 알아차리느냐' — 이게 챕터 2의 '시각적 중복'과 챕터 4의 '양자화'로 이어진다.

엔지니어가 기억할 것: 같은 비트레이트에서 더 잘 보이게 = 같은 화질에 더 작은 파일 = 더 영리하게 손실을 분배. 이게 H.264 → H.265 → AV1의 발전 방향이다.

1.5 이 코스의 지도

앞으로 9개 챕터에서 다룰 흐름:

- 2장: 비디오에 숨어 있는 세 가지 중복(공간·시간·시각)을 본다. - 3장: 모든 현대 코덱이 공유하는 4단계 파이프라인(예측 → 변환 → 양자화 → 엔트로피)을 소개한다. - 4–5장: 파이프라인의 핵심 두 부품 — DCT/양자화, 모션 추정 — 을 깊게 본다. - 6장: I/P/B 프레임과 GOP 구조. - 7–8장: 두 거인 H.264와 H.265를 디테일하게 비교한다. - 9장: AV1 + 로열티 무료 운동, 차세대 표준 경쟁. - 10장: ffmpeg로 실전 — 컨테이너, CRF, 스트리밍 ABR, 하드웨어 인코더.

각 장 끝의 코드는 Python(numpy + subprocess로 ffmpeg 호출) 위주. 직접 돌려보면서 따라가면 가장 빠르다.

💡 Analogy · 비유
책 한 권을 한 단락으로

톨스토이의 『전쟁과 평화』는 약 50만 단어다. 그 책을 누구에게 "한 단락으로 요약해 줘" 하면, 사람마다 결과가 다르다. 어떤 사람은 "러시아 귀족 가족들의 나폴레옹 전쟁 전후 이야기"라고 말하고, 어떤 사람은 "역사 속 개인의 무력함과 사랑"이라고 말한다.

둘 다 손실이 있다. 디테일은 다 사라졌다. 하지만 핵심 정보는 살아 있고, 책을 안 읽은 사람도 '대략 어떤 책'인지 안다. 이게 손실 압축이다. 원본의 99.99%를 버렸지만 핵심은 보존됐다.

비디오 코덱이 하는 일도 똑같다. 한 프레임 안의 픽셀 200만 개를 '무엇을 버려도 사람이 못 알아차리느냐'의 기준으로 잘라낸다. 압축률이 100배, 200배인 이유는 비디오 데이터가 톨스토이 소설보다 훨씬 더 중복이 많기 때문이다 — 옆 픽셀은 거의 같고, 옆 프레임도 거의 같고, 사람 눈은 둔감하다.

Raw 비디오의 실제 크기를 계산해 보고, 일반적인 압축 파일과 비교해 보자. 숫자가 직접 보이면 코덱이 풀고 있는 문제의 규모가 체감된다.

python
def raw_video_size(width, height, fps, bit_depth=24, duration_sec=1):
    """Return raw video data size in bits and bytes."""
    bits = width * height * bit_depth * fps * duration_sec
    return bits, bits / 8

configs = [
    ("480p 30fps",  720,  480, 30),
    ("1080p 30fps", 1920, 1080, 30),
    ("1080p 60fps", 1920, 1080, 60),
    ("4K 60fps",    3840, 2160, 60),
    ("8K 60fps",    7680, 4320, 60),
]

print(f"{'name':<14} {'1초':>14} {'1시간':>14}")
print("-" * 46)
for name, w, h, fps in configs:
    bits_per_sec, _ = raw_video_size(w, h, fps)
    mbps = bits_per_sec / 1e6
    gb_per_hour = bits_per_sec * 3600 / 8 / 1e9
    print(f"{name:<14} {mbps:>10.0f} Mbps  {gb_per_hour:>10.1f} GB")

# 결과 (실행해 보면 충격적):
# 1080p 30fps   →  1,493 Mbps,    672 GB/시간
# 4K 60fps      → 11,944 Mbps,  5,374 GB/시간
# 8K 60fps      → 47,776 Mbps, 21,499 GB/시간

# 일반 1080p 영화 파일(2GB/2시간 ≈ 2.2Mbps)과 비교하면
# 1,493 / 2.2 ≈ 680배 압축. 이게 코덱이 하는 일.

raw_video_size는 단순한 곱셈이지만 숫자가 직관에 충격을 준다. 1080p 30fps 영화 1시간이 672GB. 우리가 보는 압축된 1080p 영화 파일이 ~2GB라는 걸 생각하면, 코덱이 약 300~700배의 압축을 해주고 있다. 이 압축률을 가능하게 하는 건 다음 챕터에서 다룰 '세 가지 중복'의 활용이다.

🏭 현업에서의 평가
비디오 엔지니어 면접에서 '비디오 데이터의 raw 크기를 즉석에서 계산할 수 있느냐'는 기본 중의 기본. 이걸 못 하면 비트레이트 설정·스토리지 견적 같은 실무 결정을 못 한다.

✅ 시니어가 보는 것

  • Raw 크기를 즉석에서 계산할 수 있는 감각 (해상도·fps·bit depth 조합)
  • Lossy/Lossless 트레이드오프를 도메인별로 판단 가능 (의료 vs 스트리밍)
  • '코덱'과 '컨테이너'의 구분을 명확히 인지
  • 압축률 100배가 정보이론에 기반한 것임을 이해

⚠️ 레드 플래그

  • '코덱이 영상을 작게 만들어준다' 수준에서 멈춤
  • Mbps와 MB/s를 혼동
  • MP4를 코덱이라고 부름 (실제로는 컨테이너)
  • Lossless가 항상 더 좋다고 생각

🎤 예상 인터뷰 질문

  1. 1080p 60fps 영상을 raw로 1시간 저장하면 디스크가 얼마나 필요한가?
  2. Lossless 압축이 어떤 도메인에선 필수이고 어떤 도메인에선 낭비인지 예시로 설명해 주세요
  3. MP4와 H.264의 관계를 설명해 주세요
숙달 vs 익숙함: Familiar는 '코덱은 비디오를 작게 만들어준다'를 안다. Mastery는 raw 데이터 크기를 즉석에서 계산하고, lossy/lossless 선택을 도메인별로 정당화하며, 압축률이 정보이론적 한계에 묶여 있다는 점까지 이해한다.

Key Takeaways

핵심 정리

Raw는 비현실적

1080p 30fps = 1.5Gbps. 압축 없이 비디오는 존재 불가.

Codec = Coder + Decoder

둘은 짝. 호환성 문제의 본질.

코덱 ≠ 컨테이너

MP4(컨테이너) 안에 H.264·H.265·AV1 다 가능.

Shannon의 한계

무손실 압축은 엔트로피까지만. 무한 압축은 불가능.

비디오는 중복이 많다

그래서 100~300배 압축이 현실적.

Lossy의 본질

사람이 못 인지하는 정보를 일부러 버린다.

코덱의 핵심 게임

데이터 안의 예측 가능성을 최대한 찾아 제거.

이 코스의 지도

중복 → 파이프라인 → 부품 → 코덱 진화 → 실전.

← 목차 Ch02 · The Three Redundancies →