# FFmpeg 8.0 릴리즈 > Clean Markdown view of GeekNews topic #22671. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=22671](https://news.hada.io/topic?id=22671) - GeekNews Markdown: [https://news.hada.io/topic/22671.md](https://news.hada.io/topic/22671.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-08-23T09:53:50+09:00 - Updated: 2025-08-23T09:53:50+09:00 - Original source: [ffmpeg.org](https://ffmpeg.org/index.html#pr8.0) - Points: 2 - Comments: 1 ## Topic Body - **FFmpeg 8.0 "Huffman"** 은 **Vulkan 연산 기반 코덱**과 하드웨어 가속 디코딩·인코딩, 여러 *신형 파일 포맷과 필터*가 추가됨 - 인프라를 전면 **현대화**하였고, *기여 프로세스와 코드 품질*도 강화함 - **VVC 디코더 안정화**, xHE-AAC 디코더, *MV-HEVC 및 LC-EVC 지원* 등 주요 오디오 및 비디오 코덱 영역도 진보하였음 - 오픈 소스 **멀티미디어 기술 발전**의 중심 역할을 수행하며, 지속적 기능 개선과 보안성 향상을 이어가고 있음 --- ### FFmpeg 소개 - FFmpeg은 **완전한 범용 멀티미디어 처리 툴킷**으로, 음성 및 영상을 **녹화, 변환, 스트리밍**하는 데 유연하고 강력한 솔루션 - `ffmpeg -i input.mp4 output.avi`와 같이 간단한 명령어만으로 영상 및 음성 처리가 가능함 #### 2025년 8월 23일, FFmpeg 8.0 "Huffman" 출시 - **FFmpeg 8.0 "Huffman"** 이 공개됨. 수차례 지연과 인프라 최신화 과정을 거치면서, 지금까지 가장 방대한 규모의 릴리스가 이루어졌음 - 새로운 기능에는 **APV, ProRes RAW, RealVideo 6.0, Sanyo LD-ADPCM, G.728** 등 *네이티브 디코더* 추가, **VVC 디코더**의 IBC, ACT, Palette Mode 지원 강화, Vulkan 연산 기반 **FFv1 (인코드·디코드), ProRes RAW (디코드 한정)** 등의 *코덱*이 포함됨 - **Vulkan** 기반 *하드웨어 가속* 디코딩(예: VP9, VVC, H264/5)과 인코딩(AV1, H264/5), 다양한 새로운 *포맷(MCC, G.728, Whip, APV)*과 *필터(colordetect, pad_cuda, scale_d3d11, Whisper 등)*이 도입됨 - **Vulkan 1.3**에서 동작하는 연산 셰이더 기반 *디코더 및 인코더 계열*이 새롭게 추가됨. 별도의 특수 하드웨어 가속기가 필요 없는 구조로, hwaccel API와 동일하게 동작함. 인코더 사용 시 새로운 인코더를 지정해야 하며, FFv1(인코드·디코드)와 ProRes RAW(디코드)만 현재 지원됨. ProRes(양방향)와 VC-2(양방향)는 준비 중임 - 이 구조는 **병렬 디코딩 최적화 코덱**에만 적용될 수 있으며, 향후 더 다양한 분야에서 **높은 성능 개선**과 **비선형 영상 편집·무손실 녹화 등 새로운 활용**이 기대됨 - 프로젝트 인프라도 대폭 최신화됨. 메일링 리스트 서버를 완전히 교체하였고, 이제 [code.ffmpeg.org](https://code.ffmpeg.org/)에서 **Forgejo 기반 코드 협업**을 지원함 - 사용자는 최신 버전 업그레이드를 권장함 ## Comments ### Comment 42796 - Author: neo - Created: 2025-08-23T09:53:51+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=44985730) * FFmpeg 개발자들과 기여자들에게 감사를 전함 - 오디오/비디오 자동화가 필요할 때마다 FFmpeg을 항상 사용해왔음, 온라인 비디오 툴들도 대부분 이 툴을 핵심 엔진으로 사용하거나 UI 래퍼로 활용하고 있음 - 오늘 FFmpeg.Wasm 프로젝트([https://github.com/ffmpegwasm/ffmpeg.wasm](https://github.com/ffmpegwasm/ffmpeg.wasm))가 있다는 것도 알게 됨 - 2024년 1월에 1993년 애니 영화의 프레임을 15분 단위로 추출한 뒤, Real-ESRGAN-ncnn-vulkan([https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan](https://github.com/xinntao/Real-ESRGAN-ncnn-vulkan))을 사용하여 업스케일링하고, 결과 프레임을 4K로 다시 조합했던 경험 공유 - 만약 이 작업 흐름에 UI를 추가했다면, 요즘 인기 있는 Topaz AI 같은 툴이 될 수 있었을 것이라는 생각을 해봄 - 업스케일된 샘플 이미지도 공유함([샘플 이미지](https://files.horizon.pics/3f6a47d0-429f-4024-a5e0-e85ceb0f6ea9?a=1672&mime1=image&mime2=jpeg)) * 직접 ffmpeg를 쓰지 않을 때조차 이를 내장한 도구들을 자주 사용함 - 최근 오래된 DVD에서 추출한 저화질 애니를 k4yt3x/video2x를 통해 업스케일함, 설치가 쉬웠고 libffmpeg가 내장돼 있었음 - 인코딩 시 FFmpeg와 동일한 인자를 쓸 수 있었음 - 최적 인자 선택을 위해 ffmpeg로 짧은 장면을 여러 파라미터 세트로 인코딩, 다시 ffmpeg로 스틸 이미지를 추출해 비교함 * FFmpeg가 컴퓨트 셰이더 기반 비디오 엔코더와 디코더를 도입한 점을 기쁘게 생각함 - 하드웨어에서 널리 지원되는 코덱은 H.264, H.265, AV1 정도라서, 다른 코덱도 플랫폼 가속이 가능하면 좋을 것임 (효율이 좀 떨어지더라도 의미 있음) - 새로운 ProRes 인코더가 현재 진행 중인 프로젝트에 유용하게 느껴짐 - 널리 사용되는 일반적인 코덱들은 병렬 디코딩에 적합하지 않아 지원이 어렵다는 설명이 이해감 - 수만 개의 스레드를 사용해야 하는데, 프레임 간, 타일 간 데이터 의존성 때문에 병렬화가 쉽지 않음 - 인코더는 디코더보다 융통성이 좀 더 있을 것 같은데, VP9([https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-vp9-video-codec/](https://blogs.gnome.org/rbultje/2016/12/13/overview-of-the-v...)) 같은 걸 컴퓨트 셰이더로 인코딩하는 건 도전적인 과제일 것 같음 * 비디오 인코더/디코더를 컴퓨트 셰이더로 구현한 것에 대한 기쁜 소식을 다시 한 번 공유함 - 과거에는 표준화된 인실리콘 하드웨어 인터페이스만 있었기 때문에 Vulkan 기반 인코더/디코더가 범용적인지 물었다가 웃음샀던 경험 있음 - 이러한 개선이 구형 하드웨어에서도 제공되는 점이 정말 멋짐, 이런 식으로 새로운 코덱 및 전체 품질 향상 루트를 열 수 있기 바람 * 디코더 최신 동향을 10년 넘게 살펴보지 않았지만, 직관적으로는 GPU 가속이 픽셀 데이터로 바뀌는 후반 처리에 큰 도움이 될 거라 예상함 - 초기 디컴프레션은 CPU에서, 이후 디컴프레션된 데이터를 GPU로 전송해 최종 변환 작업(모션 벡터 적용, iDCT 등)을 하면 될 것 같음 - 완성 프레임이 이미 GPU 텍스처로 있으면 디스플레이 오버헤드도 적음 - 내 직감이 어느 정도 맞았는지 궁금함 * FFmpeg 메인테이너들의 재능에 매번 놀라움을 느낌, 이런 고난이도 작업을 무료로 해주는 점이 대단함 * 이 릴리즈 노트가 매우 흥미로움 - 최근 몇 주 동안 WebGPU 컴퓨트 셰이더로 ProRes 디코더를 제작했는데, 충분히 빠르게 동작함 (Apple은 아마도 자체 하드웨어 가속을 쓸 것이라 생각함) - 이 경로가 Android의 새로운 APV 코덱에도 잘 맞을 것 같음 - ProRes 비트스트림 스펙은 SMPTE에 제출되어 있지만, ProRes RAW에 관한 정보는 찾기 힘들었음 - 소프트웨어 및 컴퓨트 기반 구현이 등장해 매우 흥미롭다고 느낌, 아마 ffmpeg 개발자들이 리버스 엔지니어링한 듯함 - 코드 대강 보니 일반 ProRes와 크게 다르지 않아 보임 - [ProRes 스펙 문서](https://pub.smpte.org/doc/rdd36/20220909-pub/rdd36-2022.pdf) * FFmpeg를 사용할 때마다 감탄하게 됨 (매뉴얼을 다시 찾아보거나 LLM의 도움을 받을 필요가 있긴 하지만, 시각적 옵션에서 명령을 만들어주는 GUI를 사용할 때조차도 느낌) - 이제는 필수적인 트랜스코딩 멀티툴이 된 듯함 - Vulkan 1.3 기반 프로세싱을 도입한 건 좋은 결정으로 생각함 - 어제 보니 Asahi Linux on Mac도 같은 표준을 지원한다는 것도 알게 됨 * FFmpeg 인자는 ‘원조 프롬프트 엔지니어링’에 해당한다는 재치 있는 표현을 남김 * LLM과 FFmpeg, ImageMagick 같은 복잡한 커맨드라인 툴은 환상적인 조합임 - 원하는 작업을 자연어로 설명만 하면 바로 실현되는 완벽한 미래형 UI/UX라고 느낄 정도임 - 예시로 폴더의 모든 이미지를 특정 크기로 크롭, 채도 조정, TIFF로 저장, 영상 루프로 조립해 웹용 인코딩까지 한 번에 처리하는 시나리오를 상상해봄 * LLMs는 FFmpeg용 인터페이스로 훌륭하게 작동함 - 자연어로 사용할 수 있게 도와주는 도구들이 많이 있고, 본인의 스크립트도 공유함([https://github.com/jjcm/llmpeg](https://github.com/jjcm/llmpeg)) * ffmpeg로 복잡한 CLI 명령을 만드느라 노력의 50%를 허비하고, 나머지 50%는 셸 이스케이프와 싸우느라 쓴다는 농담 섞인 현실을 공유함 - 특히 텍스트를 영상에 입힐 때 텍스트 이스케이프가 매우 어렵게 다가옴 - 파이썬에서 많은 인자(필터 등)와 함께 ffmpeg를 부를 때 완벽한 방법을 찾은 사람이 있는지 궁금함 (r-strings? heredocs? 등) * FFmpeg 다양한 기능을 쉽게 다룰 수 있는 좋은 GUI 프론트엔드가 있는지 궁금해함 - 때로는 그냥 리멕스(remux)만 필요하거나, 동일 코덱의 영상/오디오 스트림을 결합만 하고 싶을 때가 있음 * 영상 결합은 쉽게 들리지만 생각보다 변수와 이슈가 많다는 점을 강조함 - 타임베이스, 시작 오프셋, 프레임 크롭, FPS 차이, B 프레임, 오픈 GOP 등의 변수로 인해 특정 재생 환경에서 문제 생길 수 있음 - 오디오 역시 샘플레이트 차이 등 다양한 변수가 존재함 - Lossless-Cut 프로그램이 언급되었는데, 호환성 검사 기능이 유용함 - 하지만 영상을 MPEG-TS로 변환한 뒤 합치는 게 여러 문제를 우회하는데 좋음, 램디스크에서 빠르게 처리 가능함 - 예시로 사용할 수 있는 ffmpeg 명령줄 시퀀스도 공유함 * Handbrake가 그 역할을 잘 수행해줌 - 기능 면에서 충분하며, 약간 올드하긴 하지만 여전히 유용하게 사용 가능함 * 맥 사용자라면 ffWorks([https://www.ffworks.net/index.html](https://www.ffworks.net/index.html))를 추천함 - 대부분의 기능을 쉽게 접근할 수 있고, 배치 처리 및 프리셋 설정도 지원함 - 개발자가 매우 적극적으로 지원해줘서 가장 좋아하는 앱 중 하나이며, 가치가 높아 도네이션도 하고 있음 - Handbrake와 Losslesscut도 훌륭하지만, ffWorks의 완성도를 경쟁할 앱이 다른 플랫폼엔 없는 듯함 * 본인에게 가장 좋은 프론트엔드는 ChatGPT라고 생각함 - 자연어로 원하는 작업을 설명하면 굉장히 정확한 ffmpeg 명령어를 생성해줌 * [Lossless-cut](https://github.com/mifi/lossless-cut) 프로그램 확인을 권장함 * FFmpeg의 변경내역(Changelog)을 확인할 수 있는 링크([https://github.com/FFmpeg/FFmpeg/blob/master/Changelog](https://github.com/FFmpeg/FFmpeg/blob/master/Changelog))를 공유함 * 흥미로운 소식임을 짧게 표현함 - 관련 동영상([https://youtu.be/9kaIXkImCAM?si=b_vzB4o87ArcYNfq](https://youtu.be/9kaIXkImCAM?si=b_vzB4o87ArcYNfq))도 함께 공유함 * 이 동영상이 풍자인지, 진지한지 궁금해함 * ffmpeg가 ssl, zlib, sqlite 다음으로 가장 많이 쓰이는 라이브러리 4위가 아닐까 하는 개인적 의견을 제시함 (비디오가 2025년에는 정말 어디에나 존재한다는 전제에서) * 동의는 어렵다고 봄, 비디오 처리는 주로 미디어를 받는 서버에서 필요하기 때문임 - 대부분의 휴대폰이 ffmpeg로 영상 처리하지 않는다는 점을 언급함 * curl이 더 상위권일 수도 있고, "SSL"은 구현체가 다양해서 수치가 분산될 것임 * NixOS 인프라의 fastly 메트릭 로그([https://github.com/NixOS/infra/blob/main/metrics/fastly/README.md](https://github.com/NixOS/infra/blob/main/metrics/fastly/READ...))를 데이터 소스로 제안함 * Qt, libpng, libusb 등 ffmpeg보다 더 많이 쓰이는 라이브러리들이 꽤 된다고 생각함 * Arch Linux의 패키지 통계([https://pkgstats.archlinux.de/packages](https://pkgstats.archlinux.de/packages))도 확인해볼 만함 * Vulkan 컴퓨트 셰이더 구현이 특히 FFv1과 ProRes RAW에서 멋지다고 생각함 - 고정 기능 하드웨어 디코더를 완전히 우회하므로 메모리 대역폭 영향이 어떻게 되는지 궁금함 - FFv1의 컨텍스트 적응형 산술 부호화는 본질적으로 연속적이라 속도 낼 수 없을 것 같지만, 매우 큰 속도 향상을 얻고 있다는 점에 놀람 - 여러 심볼을 동시에 병렬화하거나 슬라이스 단위로 병렬화하는 방식인지, 전통적으로 GPU로 산술 부호화 가속이 힘든 이유가 있었는데 ffmpeg 팀이 어떤 트레이드오프를 했는지 궁금함 - 해당 구현의 프로파일링 경험이 있는 사람이 있다면, 엔트로피 디코딩 단계에서의 점유율과 대역폭 선택에 대해 듣고 싶음 * ffmpeg는 너무나도 많은 도구의 기반을 이루고 있음 - 대중은 미디어 업계에 ffmpeg가 얼마나 기여했는지 잘 모르는 경우가 많음 - 오디오/비디오 자동화가 필요할 때마다 항상 찾게 되는 툴임