Meta의 FFmpeg 활용: 대규모 미디어 처리의 비밀

 (engineering.fb.com)
12P by GN⁺ | ★ favorite | 댓글 1개
  • 메타는 하루 수백억 회 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·업계·사용자 모두에게 혜택 제공

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 내부 포크가 점점 구식이 되어가자, 우리는 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의 지원은 감사하지만 지속 가능한 수준은 아니다”라고 언급했음
      관련 트윗 보기
    • Meta가 실제로 얼마를 기부했는지 궁금함
      독일 STF는 2024/2025년에 €157,580을 지원했다고 함
    • Meta가 수십억 달러를 벌면서도 국가 기금보다 적게 기부한다는 건 좀 아이러니함
    • [삭제된 댓글]

  • FFmpeg 서버들이 다행히 가벼운 콘텐츠만 처리해서 버티는 중임
    무거운 영상이었다면 과부하가 났을 것임

  • 동일한 HN 게시물이 6일 전에도 올라왔음
    왜 이 링크를 달았다고 다운보트하는지 모르겠음

    • 내 이해로는, 동일 사용자가 반복 등록하지 않는 한 재게시는 괜찮은 것으로 알고 있음
    • [삭제된 댓글]
답변달기