# Meta의 FFmpeg 활용: 대규모 미디어 처리의 비밀 > Clean Markdown view of GeekNews topic #27387. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27387](https://news.hada.io/topic?id=27387) - GeekNews Markdown: [https://news.hada.io/topic/27387.md](https://news.hada.io/topic/27387.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-11T06:33:10+09:00 - Updated: 2026-03-11T06:33:10+09:00 - Original source: [engineering.fb.com](https://engineering.fb.com/2026/03/02/video-engineering/ffmpeg-at-meta-media-processing-at-scale/) - Points: 12 - Comments: 1 ## Summary 메타는 하루 **수백억 회 실행되는 FFmpeg 파이프라인**을 내부 포크에서 완전히 벗어나 업스트림 버전으로 전환했습니다. FFlabs·VideoLAN과 협력해 **멀티레인 병렬 인코딩**과 실시간 품질 메트릭 기능을 FFmpeg 6.0~8.0에 반영하며, 대규모 미디어 처리 효율을 근본적으로 개선했습니다. 또한 자체 ASIC인 MSVP를 FFmpeg의 표준 하드웨어 API로 통합해 소프트웨어와 하드웨어 인코딩 환경을 일관되게 유지합니다. ## Topic Body - 메타는 하루 **수백억 회 FFmpeg을 실행**하며, 내부 포크 버전 대신 **업스트림 FFmpeg**으로 전면 전환하는 데 성공 - 내부 포크와 오픈소스 버전의 기능 격차를 해소하기 위해 FFlabs, VideoLAN과 협력하여 **멀티레인 병렬 인코딩**과 실시간 품질 메트릭 기능을 업스트림에 구현 - 하루 **10억 건 이상의 동영상 업로드**를 처리하며 DASH 재생을 위한 다중 해상도·코덱 인코딩을 단일 FFmpeg 명령줄로 수행 - FFmpeg 6.0~8.0 버전에서 구현된 **효율적 스레딩 구조**는 메타의 설계를 기반으로 하며, 모든 사용자에게 인코딩 효율 향상을 제공함 - 자체 설계 ASIC인 **MSVP(Meta Scalable Video Processor)** 를 FFmpeg의 표준 하드웨어 API를 통해 통합하여 소프트웨어·하드웨어 파이프라인 간 일관성 확보 - 25년 이상 개발된 FFmpeg에 대한 **지속적 투자**를 통해 Meta 플랫폼의 새로운 동영상 경험과 안정성을 동시에 강화 --- ### FFmpeg의 역할과 Meta의 과제 - FFmpeg은 다양한 오디오·비디오 코덱과 컨테이너 포맷을 지원하는 **업계 표준 미디어 처리 도구**로, 복잡한 필터 체인을 통한 미디어 편집·변환이 가능 - Meta는 ffmpeg(메인 CLI)과 ffprobe(미디어 파일 속성 조회 유틸리티) 바이너리를 하루 **수백억 회** 실행하며, 개별 파일 처리를 넘어서는 추가 요구사항 존재 - 오랫동안 내부 포크에 의존해 **스레드 기반 멀티레인 인코딩**과 실시간 품질 메트릭 계산 등 당시 업스트림에 없던 기능을 자체 구현 ### 내부 포크의 분기와 업스트림 복귀 필요성 - 내부 포크가 업스트림 FFmpeg과 **상당히 분기**되면서 기능 세트의 격차가 점차 확대 - 동시에 FFmpeg 새 버전이 새로운 코덱·파일 포맷 지원과 **안정성 개선**을 제공해, 사용자들이 올리는 다양한 동영상 콘텐츠를 중단 없이 수용하기 위해 오픈소스 최신 버전도 병행 지원 필요 - 내부 변경 사항을 리베이스할 때 **리그레션 방지**가 어려워지면서, FFmpeg 개발자·FFlabs·VideoLAN과 협력하여 내부 포크를 완전히 폐기하고 업스트림 버전만 사용하는 방향으로 전환 ### 효율적인 멀티레인 트랜스코딩 구축 (VOD 및 라이브스트리밍) - 사용자가 동영상을 업로드하면 **DASH(Dynamic Adaptive Streaming over HTTP)** 재생을 위한 다중 인코딩 세트를 생성하며, 해상도·코덱·프레임레이트·화질 수준이 각각 다른 인코딩을 제공 - 앱의 동영상 플레이어가 네트워크 상태 등 신호에 따라 인코딩을 **실시간으로 전환** 가능 - 가장 단순한 방식은 각 레인을 개별 FFmpeg 명령줄로 순차 처리하는 것이지만, 병렬 실행 시에도 각 프로세스가 **중복 작업**(디코딩 반복, 프로세스 시작 오버헤드)을 수행하여 비효율적 - 단일 FFmpeg 명령줄에서 프레임을 한 번만 디코딩한 뒤 각 출력 인코더로 전송하면 **디코딩 중복 제거**와 프로세스 시작 오버헤드 절감 가능 - 하루 **10억 건 이상**의 동영상 업로드를 처리하므로 프로세스당 연산 절감이 전체적으로 큰 효율 향상 - Meta 내부 포크는 **병렬 비디오 인코딩** 최적화를 추가로 제공: 기존 FFmpeg은 여러 인코더 사용 시 프레임별로 직렬 실행했으나, 모든 인코더 인스턴스를 병렬 실행하여 더 높은 병렬성 확보 - FFmpeg 개발자(FFlabs, VideoLAN 포함)의 기여로 FFmpeg 6.0부터 더 효율적인 스레딩이 구현되기 시작해 **8.0에서 완성** - Meta 내부 포크의 설계에 직접적인 영향을 받았으며, **수십 년 만에 가장 복잡한 FFmpeg 리팩토링**으로 기록 - 모든 FFmpeg 사용자에게 더 효율적인 인코딩 혜택 제공 ### 실시간 품질 메트릭 (라이브스트리밍) - 시각적 품질 메트릭은 미디어의 **지각적 화질을 수치로 표현**하여 압축으로 인한 품질 손실을 정량화하는 데 사용 - **참조(reference) 메트릭**: 원본 인코딩과 왜곡된 인코딩을 비교 - **비참조(no-reference) 메트릭**: 원본 없이 화질 평가 - FFmpeg은 PSNR, SSIM, VMAF 등의 품질 메트릭을 두 개의 기존 인코딩을 사용해 인코딩 완료 후 별도 명령줄로 계산 가능하지만, **라이브스트리밍에서는 실시간 계산 필요** - 각 출력 레인의 비디오 인코더 뒤에 **비디오 디코더를 삽입**하여, 압축 적용 후의 프레임 비트맵을 얻고 압축 전 프레임과 비교함으로써 단일 FFmpeg 명령줄에서 각 인코딩 레인의 품질 메트릭을 실시간 산출 - **FFmpeg 7.0**부터 FFlabs와 VideoLAN 개발자의 기여로 "인루프(in-loop)" 디코딩이 활성화되어, 이 기능에 대한 내부 포크 의존 완전 해소 ### 업스트림 기여 기준과 내부 전용 패치 - 실시간 품질 메트릭과 효율적 스레딩 같은 기능은 Meta 내외부 다양한 FFmpeg 기반 파이프라인에 효율 향상을 제공하므로 **업스트림에 기여** - 반면 Meta 인프라에 고도로 특화되어 일반화가 어려운 패치는 내부에만 유지 - FFmpeg은 NVIDIA NVDEC/NVENC, AMD UVD, Intel QSV 등의 **하드웨어 가속 디코딩·인코딩·필터링**을 표준 API로 지원 - Meta의 자체 비디오 트랜스코딩 ASIC인 **MSVP(Meta Scalable Video Processor)** 도 동일한 표준 API를 통해 지원 추가, 다양한 하드웨어 플랫폼에서 공통 도구 사용 가능 - MSVP는 Meta 내부 인프라에서만 사용되어 외부 FFmpeg 개발자가 테스트·검증할 하드웨어 접근이 불가하므로 내부 패치로 유지 - 최신 FFmpeg 버전으로 리베이스 시 **광범위한 검증**을 통해 견고성과 정확성 확보 ### FFmpeg에 대한 지속적 투자 - 멀티레인 인코딩과 실시간 품질 메트릭 기능으로 모든 VOD 및 라이브스트리밍 파이프라인에서 **내부 포크를 완전 폐기** - FFmpeg의 표준 하드웨어 API 덕분에 MSVP ASIC과 소프트웨어 기반 파이프라인을 **최소한의 마찰**로 병행 지원 - 25년 이상 활발히 개발된 FFmpeg에 대해 오픈소스 개발자와의 파트너십을 통해 **지속 투자** 계획, Meta·업계·사용자 모두에게 혜택 제공 ## Comments ### Comment 52790 - Author: neo - Created: 2026-03-11T06:33:10+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=47305236) - 내부 포크가 점점 **구식**이 되어가자, 우리는 FFmpeg 개발자들과 협력해 필요한 기능을 공식 FFmpeg에 통합했음 덕분에 내부 버전을 완전히 폐기하고 업스트림 버전만으로 운영할 수 있게 되었음 일부는 “더 기여할 수 있지 않았냐”고 하지만, 오픈소스의 본질은 **모두가 이익을 공유**한다는 점임 - Meta가 커뮤니티에 **기여**한다는 점은 부정할 수 없다고 생각함 React, React Native 등 수많은 프로젝트를 통해 우리는 이미 혜택을 받고 있음 - 하지만 이런 기능들이 **초대형 기업**의 요구에서 비롯된 것이라면, 대부분의 사용자는 그 혜택을 체감하지 못함 결국 이런 구조는 권력을 가진 쪽에만 유리하다는 생각임 - 긍정적인 변화임은 분명하지만, 그 배경에는 내부 이익을 우선시한 시기가 있었음 그래도 Meta가 오픈소스 생태계에 많은 것을 공개한 점은 업계 차별화 요소로 작용함 - 모든 빅테크 기업은 **오픈소스 기반** 없이는 존재할 수 없었음을 잊지 말아야 함 - 오픈소스 기여 자체는 좋지만, 블로그 글의 **톤**이 마음에 들지 않았음 “이제야 업스트림에 통합했다”는 식의 표현은 마치 과거의 미흡함을 포장하려는 느낌이었음 기술 블로그에 마케팅 문구를 섞는 건 독자 입장에서 거슬림 - Fabrice Bellard가 은퇴할 때 **충분히 보상받길** 바람 그의 소프트웨어 덕분에 수많은 기업이 돈을 벌었음 - FFmpeg의 새 버전이 다양한 코덱과 포맷을 지원하게 된 건 좋지만, Meta가 매일 수십억 번 실행하는 규모라면 이런 개선에 **지속적으로 참여했는지** 궁금함 - [삭제된 댓글] - 하루 수백억 번 실행된다는 건 정말 **어마어마한 규모**임 나는 자동화된 영상 조립 작업으로 하루 수천 번만 돌려도 오버헤드가 느껴짐 `single-decode multi-output` 기능 덕분에 처리 시간이 40% 줄었음 - 이 정도 규모면 **RAM 사용량**도 상상 초월일 것임 다행히 최근 메모리 가격 하락 덕분에 오픈소스 개선의 **비용 대비 효과**가 더 커졌음 - 인코더 인스턴스를 병렬로 돌려 **병렬성**을 높이는 접근은 합리적임 하지만 나는 **시간축 병렬화(time-axis parallelization)** 기능을 보고 싶음 입력 영상을 키프레임 단위로 나눠 병렬 인코딩하면 품질 저하 없이 속도를 높일 수 있음 - 그런데 키프레임 위치를 **미리 예측**할 수 있을까? 보통 인코더가 효율을 위해 동적으로 배치하기 때문에 사전 분할이 어려울 수도 있음 - 인코더가 P/B 프레임 분석 시 수행하는 **모션 분석**을 한 번만 계산해 여러 인코딩에 재활용할 수 있지 않을까 궁금함 - Meta 팀이 `ffmpeg`와 `ffprobe`에 기여한 점에 감사함 앞으로 **코드 품질, 문서화, 커뮤니티 행사** 등에 대한 재정 지원도 고려해주길 바람 - “내부 포크가 점점 낡아갔다”는 표현이 너무 **공감됨** 참고로 FFmpeg 8에서는 HDR과 SDR 색상 매핑이 완벽하게 처리됨 - 예전엔 메타데이터 자동 복사 문제로 고생했는데, 이제 해결돼서 정말 반가움 - 오랜만에 소식 들으니 반갑고, 발전이 인상적임 - 독일의 **Sovereign Tech Fund**가 FFmpeg에 기부했다는 소식이 흥미로움 - 독일 STF는 약 **15만 달러**를 기부했지만, Meta 엔지니어 1년 인건비만 해도 그 두 배 이상일 것임 아마 Meta는 미디어 인코딩 전담팀을 두고 연간 **100만 달러 이상 가치**의 기여를 하고 있을 듯함 - 하지만 FFmpeg 공식 계정은 “Meta의 지원은 감사하지만 **지속 가능한 수준은 아니다**”라고 언급했음 [관련 트윗 보기](https://x.com/FFmpeg/status/2029053011314786701) - Meta가 실제로 얼마를 기부했는지 궁금함 독일 STF는 2024/2025년에 €157,580을 지원했다고 함 - Meta가 수십억 달러를 벌면서도 **국가 기금보다 적게 기부**한다는 건 좀 아이러니함 - [삭제된 댓글] - FFmpeg 서버들이 다행히 **가벼운 콘텐츠**만 처리해서 버티는 중임 무거운 영상이었다면 과부하가 났을 것임 - 동일한 HN 게시물이 [6일 전에도 올라왔음](https://news.ycombinator.com/item?id=47224355) 왜 이 링크를 달았다고 다운보트하는지 모르겠음 - 내 이해로는, 동일 사용자가 반복 등록하지 않는 한 **재게시**는 괜찮은 것으로 알고 있음 - [삭제된 댓글]