Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
본 기사는 H.264와 같은 코덱의 저수준 인코딩 기술(움직임 추정, 양자화)을 깊이 있게 분석하며 압축 기술의 복잡성과 중요성을 다룹니다. 또한 무손실 영상 지원 기능과 WebP 등 최신 포맷과의 비교를 통해 데이터 효율성 측면에서 코덱 기술의 진화를 조명합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 RSS: GeekNews (한국어)의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기2011년쯤 Jason Garrett-Glaser, 일명 DarkShikari와 함께 x264가 더 많은 코어를 활용하도록 슬라이스 단위 멀티스레드 룩어헤드 패치를 작업한 적이 있음. 당시 그는 Sony의 PlayStation 게임 스트리밍 서비스를 최적화하고 있었고, 프레임 작업을 여러 코어로 분산한 뒤 재결합과 스케줄링을 개선하면 같은 코어 수로도 게임 스트리밍에 중요한 인코딩 지연을 줄일 수 있었음.
우리는 당시 단일 NUMA 영역에서는 드물었던 물리 코어 48개짜리 서버로 트랜스코딩을 하고 있었음. 그가 테스트할 환경이 없어, 직접 빌드한 계측용 버전으로 스레드 수를 크게 늘려 인코딩하고 플레임 그래프와 프로파일을 보내줌. 이를 바탕으로 움직임 추정 코드를 최적화하자 첫 시도부터 CPU 사용량이 고르게 분산되고 약 24개 코어까지 인코딩 속도가 향상됨. 기억으로는 이전에는 약 8개 코어에서 확장이 멈추고 코어 하나에 부하가 몰렸음.
이 과정에서 움직임 추정, 양자화, 지각 기반 압축이 얼마나 저수준이면서도 고도화된 기술인지 엿볼 수 있었음. 평소 별생각 없이 쓰는 기술에 이렇게 많은 기법이 들어 있다는 건 지금도 마법처럼 느껴짐. 그때 이미 x265도 작업 중이었음.
그의 블로그인 Diary of an x264 developer도 이 코드베이스의 복잡성을 들여다보기 좋은 읽을거리임. https://github.com/mstorsjo/x264/blob/master/doc/threads.txt.
H.264에는 잘 쓰이지 않는 무손실 영상 지원 기능이 있음. 도구에서 기능을 발견하거나 선택하기 어렵고 웹 브라우저와 호환되지 않을 때도 있지만, 널리 쓰이는 코덱으로 진짜 무손실 영상을 만들 수 있음. 중간에 8비트 YUV로 양자화하는 변환 단계 없이 실제로 무손실인지 검증도 가능함. x264vfw는 AVI 파일 안에서도 이 형식을 지원하므로, Video For Windows를 사용하는 오래된 소프트웨어로도 이런 파일을 만들 수 있음.
OBS로 무손실 H.264를 쉽게 녹화할 수 있고, FFmpeg 기반 플레이어라면 문제없이 재생 가능함. 영상 재생에서 운영체제가 중요하던 시절은 이미 오래전에 지났음.
무손실 H.264는 ProRes 같은 형식과 비교해 어떤 용도로 쓰는 건가요? 무손실 오디오처럼 최적화할 여지가 그리 많지 않은 건가요?
VP9과 AV1은 기본 프로파일에 무손실 지원이 포함되어 있으므로, 적어도 이론상으로는 모든 구현체가 해당 코덱의 무손실 파일과 호환되어야 함.
압축이 곧 지능이라는 생각이 정말 마음에 듦. 관련된 기법과 흥미로운 아이디어가 무척 많고, 글에서 다룬 것 외에도 이해하기 어려운 수많은 기법을 이어 붙여 데이터를 놀라울 정도로 줄일 수 있을 것 같음. Hutter Prize가 좋은 예임. 이 스레드의 다른 곳에 나온 3Blue1Brown 영상에서도 소개됐던 것 같음. 이 글은 LLM 등장 전에 쓰였으니, 비슷한 문제에 OpenAI나 Anthropic 수준의 연산 자원을 투입하면 어떤 결과를 만들어낼지 보고 싶음. https://arxiv.org/html/2404.09937v1.
최근 Hutter Prize 출품작들은 LSTM을 트랜스포머로 교체하고 학습시키는 것만으로도 엄청난 도약을 이뤄냄. 프롬프트와 약간의 학습으로 3만 5,000달러를 받는다면 꽤 쏠쏠함.
다음 단계는 인코더를 비롯해 사람의 선입견이 반영된 압축 요소를 원시 데이터와 학습으로 대체하는 것임. 아마 20~30%는 더 개선할 여지가 있을 듯함.
MPEG 창립자 중 한 명이 수십 년 만에 MPEG를 떠나는 이유를 쓴 글을 여기서 읽은 기억이 남. 이유 중 하나는 현대 AI와 압축은 구분하기 어렵다는 것이었고, 최근 폭발적으로 늘어난 지식을 활용해 새로운 압축 알고리즘을 탐구하려 했음.
PNG도 정말 비효율적이라 BMP처럼 퇴장해야 할 듯함. 이 글이 쓰일 때 이미 WebP를 쓸 수 있었음.
원본 PNG는 1,039,993바이트, 최적화한 PNG는 541,539바이트, 무손실 WebP는 398,974바이트임. JPEG XL은 무손실로 310,778바이트이며 빠르고 간편함.
PNG 최적화에는 엄청난 연산을 쏟아부었음. 더 줄일 여지가 있겠지만 필요한 노력은 터무니없는 수준임.
WebP 호환성은 여전히 짜증스러움. 형식 자체의 장점과 별개로, Pop OS 22.04에서도 Eye of Gnome 대신 Firefox로 열어야 함. 이런 호환성 문제가 곳곳에 남아 있고, 지원을 게을리하는 것이 PNG가 계속 쓰이는 큰 이유임.
JPEG XL이 마침내 주요 웹 브라우저에 도입되기 시작했으니, 플랫폼 차원의 기본 지원도 늘어나고 오래된 코덱들을 서서히 퇴출할 수 있기를 바람. 영상 코덱과 비교했을 때 애니메이션이 약한 점을 빼면, 거의 모든 용도에서 뛰어난 형식임.
덧붙이자면, 가능한 최고 수준의 PNG 압축을 백그라운드로 돌린 결과 528,313바이트까지 줄어듦. 겨우 몇 분 걸렸을 뿐임.