영상과 코덱
영상 파일을 둘러싼 헷갈리는 것들은 거의 다 하나의 구분에서 비롯됩니다 — 상자와 그 안에 든 것의 구분이죠. 여기 나오는 용어들은 이 둘을 가리키는 말이거나, 그 사이에서 내용물을 옮기는 작업을 가리키는 말입니다.
-
컨테이너
래퍼, 포맷 -
영상, 오디오, 자막 트랙을 함께 담고 각각이 어디에 있는지 기술하는 파일 구조입니다. MP4, MKV, AVI, WebM이 컨테이너입니다. 컨테이너는 그 무엇도 압축하지 않습니다.
내용물이 적힌 라벨이 붙은 보관 상자라고 생각하면 됩니다. 상자에는 이렇게 적혀 있습니다 — 이런 방식으로 인코딩된 영상 트랙이 하나 있음, 이런 언어들로 된 오디오 트랙이 둘 있음, 이 시점부터 시작하는 자막이 있음. 그중 무엇이 어떻게 압축되었는지에 대해서는 아무 의견도 담고 있지 않습니다.
이것이 바로 완전히 같은 화질, 완전히 같은 파일 크기의 영상이 MP4와 MKV 양쪽에 존재할 수 있고, 그중 하나는 iPhone에서 열리는데 다른 하나는 열리지 않는 이유입니다. 다른 건 내용물이 아니라 상자입니다.
-
코덱
코더-디코더 -
영상이나 오디오 스트림을 압축하고, 재생을 위해 다시 압축을 푸는 데 쓰이는 방식입니다. H.264, HEVC, AV1, AAC, MP3이 코덱입니다. 코덱은 파일 형식이 아닙니다.
이름 자체가 coder-decoder(부호화기-복호화기)의 줄임말입니다. 인코딩은 눈에 잘 띄지 않도록 계산된 방식으로 세부 정보를 버리고, 디코딩은 남겨둔 정보로 원본에 가까운 근사치를 다시 만들어냅니다. 코덱이 좋을수록 같은 크기에서 그 손실이 덜 눈에 띕니다.
기기는 컨테이너를 읽을 수 *있고* 그 안의 모든 코덱을 디코딩할 수 있을 때 비로소 파일을 재생합니다. 둘 다 필요한 조건이라서, 파일은 열리는데 아무것도 나오지 않는다면 실패한 건 두 번째 조건 쪽입니다.
-
H.264
AVC, MPEG-4 Part 10 -
무엇이든 디코딩할 수 있는 영상 코덱입니다. 2003년에 발표됐고, 지금도 호환성 면에서 가장 안전한 선택이며, 지난 15년 사이 만들어진 모든 휴대폰·컴퓨터·TV가 하드웨어로 가속합니다.
H.264가 워낙 압도적으로 자리를 잡아서 "이게 어디서나 재생될까"와 "이게 H.264일까"는 거의 같은 질문이 되어버렸습니다. 가장 효율적인 코덱은 아닙니다 — HEVC와 AV1 둘 다 더 적은 비트로 더 많은 일을 해냅니다 — 하지만 지원 범위에서는 그 무엇도 근처에도 못 갑니다.
여기엔 프로필이 있고, 그중 하나가 Apple 기기에서 말썽을 일으킵니다. 흔히 Hi10P로 표기되는 High 10은 색상 채널당 8비트가 아니라 10비트를 인코딩합니다. 하드웨어 디코더는 8비트 전용이라서, 소프트웨어 대체 경로가 없는 기기에서 Hi10P 파일은 소리만 나오고 화면은 나오지 않습니다.
-
HEVC
H.265 -
H.264의 후속 코덱으로, 같은 화질을 대략 절반 크기로 담아냅니다. 2015년 이후 모든 Apple 기기가 하드웨어로 디코딩하며, iPhone이 영상을 촬영할 때 쓰는 코덱이기도 합니다.
HEVC 덕분에 휴대폰에서 4K가 실용적인 선택이 되었습니다 — 같은 화면을 대략 절반의 비트레이트로 담을 수 있으니까요. Apple이 일찍부터 적극적으로 채택해서, Apple 하드웨어에서는 H.264만큼 안전한 선택입니다.
다른 곳에서는 사정이 더 복잡합니다. HEVC를 둘러싼 특허 라이선스 문제가 상당히 첨예해서 웹 브라우저들의 지원이 더뎠고, 바로 그 빈틈을 메우기 위해 만들어진 것이 AV1입니다.
-
AV1
-
2018년에 발표된 로열티 프리 코덱으로, HEVC보다 효율적이고 HEVC와 달리 라이선스 분쟁도 없습니다. 하드웨어 디코딩은 Apple 기기 중에서는 iPhone 15 Pro에 와서야 처음 지원됐습니다.
AV1이 존재하는 이유는 HEVC의 라이선스 구조 때문에 대형 스트리밍 업체와 웹 브라우저 회사들이 누구에게도 비용을 내지 않고 배포할 수 있는 대안을 원했기 때문입니다. 지금은 상당한 양의 웹 영상이 이 코덱으로 전달되고 있습니다.
문제는 디코딩 비용입니다. 하드웨어 지원이 없으면 AV1은 소프트웨어로 디코딩되는데, 가능은 하지만 배터리를 눈에 띄게 소모하고 고해상도에서는 끊길 수 있습니다. 오래된 기기라면 같은 영상의 H.264 버전이 더 나은 선택입니다.
-
비트레이트
-
영상이나 오디오의 1초 분량이 차지하는 데이터 양으로, 보통 초당 메가비트로 나타냅니다. 파일 크기와 기기가 처리해야 할 부담을 결정하는 가장 중요한 요소입니다.
해상도가 주목을 받지만, 실제로 화면이 어떻게 보이는지를 결정하는 건 비트레이트입니다. 비트레이트가 낮은 4K 파일은 비트레이트가 높은 1080p 파일보다 더 나빠 보일 수 있는데, 인코더가 목표 크기에 맞추려고 더 많은 것을 버려야 했기 때문입니다.
버벅이는 파일의 원인도 대개 이것입니다. 영상이 컴퓨터에서는 잘 재생되는데 휴대폰에서 버벅인다면 파일에는 아무 문제가 없습니다 — 그저 그 칩이 감당하고 싶은 것보다 초당 더 많은 디코딩 작업을 요구하는 것뿐입니다.
-
재다중화
리먹스, 다시 포장 -
기존 영상·오디오 스트림을 재인코딩하지 않고 한 컨테이너에서 다른 컨테이너로 옮기는 작업입니다. 무손실이고, 프로세서가 아니라 디스크 속도로 제한될 만큼 빠릅니다.
재다중화는 스트림을 그대로 복사할 뿐, 프레임 하나 건드리지 않습니다. H.264와 AAC를 담은 한 시간짜리 MKV는 몇 초 만에 MP4가 되고, 화면과 소리는 비트 단위로 완전히 동일합니다.
이건 목적지 컨테이너가 원본이 담고 있는 것을 받아줄 때만 가능합니다 — MP4는 H.264와 AAC는 받아주지만 VP9나 Vorbis는 받아주지 않습니다. 변환이 "순식간이었다"는 말은 사실 재다중화가 일어났다는 뜻입니다. 한 시간이 걸렸다면 뭔가는 재인코딩된 것입니다.
-
트랜스코드
재인코딩, 변환 -
스트림을 디코딩한 다음 다시 인코딩하는 작업으로, 보통 다른 코덱으로 바꾸거나 더 낮은 비트레이트로 바꿉니다. 매번 느리고 손실이 생기며, 한 번 떨어진 화질은 다시 돌아오지 않습니다.
흔히 "영상 변환"이라고 부르는 게 바로 이것이고, 실제로 비용이 상당한 작업입니다 — 프레임 하나하나가 디코딩되고, 처리되고, 다시 압축됩니다. 정말로 코덱이 지원되지 않거나 파일을 더 작게 만들어야 할 때는 이게 맞는 답입니다.
"내 휴대폰에서 이게 안 열려요"라는 문제에 대해서는 재다중화로 충분했을 상황에서 잘못된 답이 되는 경우가 많고, 문제의 원인이 오직 DTS 오디오 트랙 하나뿐인 파일에도 좋지 않은 답입니다 — 트랙 하나만 교체하면 화면은 손대지 않고 그대로 남습니다.
-
하드웨어 디코딩
-
메인 프로세서가 아니라 전용 칩에서 영상을 디코딩하는 방식입니다. 훨씬 빠르고, 발열도 훨씬 적고, 배터리에도 훨씬 유리합니다 — 다만 애초에 그 용도로 설계된 코덱만 처리할 수 있습니다.
모든 휴대폰에는 H.264와 HEVC를 아주 효율적으로 처리하는 고정 기능 영상 디코더가 들어 있습니다. 그게 지원하지 않는 코덱은 소프트웨어가 떠맡게 되는데, 작동은 하지만 배터리와 발열 부담이 크고 고해상도에서는 따라가지 못할 수도 있습니다.
이게 바로 휴대폰의 형식 지원이 단순히 된다·안 된다로 나뉘지 않는 이유입니다. 같은 기기가 1080p에서는 소프트웨어로 어떤 코덱을 완벽하게 재생하면서 4K에서는 같은 코덱을 재생하지 못할 수 있는데, 두 결과 모두 파일이 잘못됐다는 뜻은 아닙니다.
-
10비트
Hi10P, High 10 -
더 부드러운 그러데이션을 위해 색상 채널당 8비트 대신 10비트를 저장하는 영상입니다. HEVC에서는 흔하고 잘 지원되지만, H.264에서는 iPhone에서 소리는 나오는데 화면이 안 나오는 가장 흔한 원인입니다.
채널당 비트 수가 많을수록 색조 사이의 단계가 더 촘촘해지고, 이는 어두운 하늘이나 느린 페이드에서 보이던 색 밴딩을 없애줍니다. HDR에서는 이게 개선 사항이 아니라 필수 조건입니다.
문제는 구체적으로 H.264입니다. 10비트 H.264는 하드웨어 디코더가 구현하는 범위 밖에 있고, Apple의 시스템 플레이어에는 이를 처리할 소프트웨어 경로가 없어서 오디오는 재생되는데 화면은 끝내 나오지 않습니다. 애니메이션 릴리스에서 이 방식을 많이 쓰기 때문에, 전체 형식 점유율이 시사하는 것보다 훨씬 자주 이 문제와 마주치게 됩니다.
-
키프레임
I-프레임 -
이전 프레임과의 차이가 아니라 화면 전체가 통째로 저장된 프레임입니다. 탐색은 이 프레임에만 정확히 도달할 수 있어서, 요청한 것과 살짝 다른 순간으로 이동하는 경우가 생깁니다.
영상 압축은 대부분의 프레임을 이웃 프레임과의 차이로 기술하는 방식으로 이뤄집니다. 오직 키프레임만 독립적으로 존재하고, 보통 2~10초마다 한 번씩 나타납니다.
탐색 바를 드래그하면 플레이어는 가장 가까운 키프레임을 찾아 그 지점부터 재생을 시작합니다. 키프레임 간격이 넓을수록 파일은 작아지지만 탐색은 그만큼 거칠어집니다. 이 절충은 인코딩 시점에 이미 결정되며, 나중에 재인코딩하지 않고서는 바꿀 수 없습니다.