12 ポイント 投稿者 GN⁺ 2026-03-11 | 1件のコメント | WhatsAppで共有
  • Metaは1日に数百億回FFmpegを実行しており、内部フォーク版ではなくアップストリームFFmpegへの全面移行に成功
  • 内部フォークとオープンソース版の機能差を解消するため、FFlabs、VideoLANと協力してマルチレーン並列エンコードとリアルタイム品質メトリクス機能をアップストリームに実装
  • 1日10億件以上の動画アップロードを処理し、DASH再生向けの多解像度・多コーデックエンコードを単一のFFmpegコマンドラインで実行
  • FFmpeg 6.0〜8.0で実装された効率的なスレッディング構造はMetaの設計に基づいており、すべてのユーザーにエンコード効率の向上を提供
  • 独自設計のASICであるMSVP(Meta Scalable Video Processor) をFFmpegの標準ハードウェアAPIを通じて統合し、ソフトウェア・ハードウェアパイプライン間の一貫性を確保
  • 25年以上開発されてきたFFmpegへの継続的な投資を通じて、Metaプラットフォームの新しい動画体験と安定性を同時に強化

FFmpegの役割とMetaの課題

  • FFmpegは多様な音声・映像コーデックとコンテナフォーマットをサポートする業界標準のメディア処理ツールで、複雑なフィルタチェーンによるメディア編集・変換が可能
  • Metaはffmpeg(メインCLI)とffprobe(メディアファイルの属性を調べるユーティリティ)バイナリを1日に数百億回実行しており、個別ファイル処理を超える追加要件が存在
  • 長年にわたり内部フォークに依存し、スレッドベースのマルチレーンエンコードやリアルタイム品質メトリクス計算など、当時のアップストリームになかった機能を独自実装

内部フォークの分岐とアップストリーム復帰の必要性

  • 内部フォークがアップストリームFFmpegと大きく乖離するにつれて、機能セットの差が徐々に拡大
  • 同時にFFmpegの新バージョンは新しいコーデック・ファイルフォーマット対応と安定性向上をもたらし、ユーザーが投稿する多様な動画コンテンツを途切れなく受け入れるため、オープンソース最新版の並行サポートも必要に
  • 内部変更をリベースする際にリグレッション防止が難しくなったため、FFmpeg開発者・FFlabs・VideoLANと協力し、内部フォークを完全に廃止してアップストリーム版のみを使う方向へ転換

効率的なマルチレーントランスコーディングの構築(VODおよびライブストリーミング)

  • ユーザーが動画をアップロードすると、DASH(Dynamic Adaptive Streaming over HTTP) 再生向けに複数のエンコードセットを生成し、解像度・コーデック・フレームレート・画質レベルがそれぞれ異なるエンコードを提供
    • アプリの動画プレーヤーはネットワーク状態などのシグナルに応じてエンコードをリアルタイムに切り替え可能
  • 最も単純な方法は各レーンを個別のFFmpegコマンドラインで順次処理することだが、並列実行しても各プロセスが重複作業(デコードの繰り返し、プロセス起動オーバーヘッド)を行うため非効率
  • 単一のFFmpegコマンドラインでフレームを一度だけデコードしてから各出力エンコーダへ送れば、デコード重複の排除とプロセス起動オーバーヘッド削減が可能
    • 1日10億件超の動画アップロードを処理するため、プロセスごとの計算削減が全体として大きな効率向上につながる
  • Metaの内部フォークはさらに並列動画エンコード最適化を提供: 従来のFFmpegは複数エンコーダ利用時にフレームごとに直列実行していたが、すべてのエンコーダインスタンスを並列実行してより高い並列性を確保
  • FFmpeg開発者(FFlabs、VideoLANを含む)の貢献により、FFmpeg 6.0からより効率的なスレッディングが実装され始め、8.0で完成
    • Meta内部フォークの設計から直接的な影響を受けており、数十年ぶりで最も複雑なFFmpegリファクタリングとして記録
    • すべてのFFmpegユーザーに、より効率的なエンコードの恩恵を提供

リアルタイム品質メトリクス(ライブストリーミング)

  • 視覚品質メトリクスはメディアの知覚上の画質を数値化し、圧縮による品質低下を定量化するために使われる
    • 参照(reference)メトリクス: 元のエンコードと劣化したエンコードを比較
    • ノーリファレンス(no-reference)メトリクス: 原本なしで画質を評価
  • FFmpegはPSNR、SSIM、VMAFなどの品質メトリクスを、既存の2つのエンコードを使ってエンコード完了後に別コマンドラインで計算できるが、ライブストリーミングではリアルタイム計算が必要
  • 各出力レーンの動画エンコーダの後ろに動画デコーダを挿入し、圧縮適用後のフレームビットマップを取得して圧縮前フレームと比較することで、単一の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・業界・ユーザーのすべてに利益をもたらす

1件のコメント

 
GN⁺ 2026-03-11
Hacker Newsの意見
  • 内部フォークが次第に古くなっていく中で、私たちはFFmpegの開発者たちと協力し、必要な機能を公式FFmpegに統合した
    そのおかげで内部版を完全に廃止し、アップストリーム版だけで運用できるようになった
    「もっと貢献できたのでは」という声もあるが、オープンソースの本質は皆で利益を分かち合うことにある

    • Metaがコミュニティに貢献していることは否定できないと思う
      React、React Nativeなど数多くのプロジェクトを通じて、私たちはすでに恩恵を受けている
    • しかし、こうした機能が超巨大企業の要求から生まれたものなら、ほとんどのユーザーはその恩恵を実感できない
      結局こうした構造は、権力を持つ側にだけ有利なのだと思う
    • 前向きな変化であることは確かだが、その背景には内部の利益を優先していた時期があった
      それでもMetaがオープンソースのエコシステムに多くを公開してきた点は、業界での差別化要因として機能している
    • すべてのビッグテック企業は、オープンソース基盤なしには存在できなかったことを忘れるべきではない
    • オープンソースへの貢献自体は良いが、ブログ記事のトーンが気に入らなかった
      「ようやくアップストリームに統合した」というような表現は、まるで過去の不十分さを取り繕おうとしているように感じた
      技術ブログにマーケティング文句を混ぜるのは、読者としては鼻につく
  • Fabrice Bellardが引退するときには、十分な報酬を受けてほしい
    彼のソフトウェアのおかげで数多くの企業が利益を上げてきた

  • FFmpegの新バージョンが多様なコーデックやフォーマットをサポートするようになったのは良いことだが、
    Metaが毎日数十億回実行する規模なら、こうした改善に継続的に関わってきたのかが気になる

    • [削除されたコメント]
  • 1日に数百億回実行されるというのは本当にとてつもない規模
    自分は自動化された動画組み立て処理で1日数千回回すだけでもオーバーヘッドを感じる
    single-decode multi-output機能のおかげで処理時間が40%短縮された

    • この規模だとRAM使用量も想像を絶するはずだ
      幸い最近のメモリ価格下落のおかげで、オープンソース改善の費用対効果はさらに高まった
  • エンコーダーインスタンスを並列に回して並列性を高めるアプローチは合理的だ
    ただ、自分は**時間軸並列化(time-axis parallelization)**機能を見てみたい
    入力動画をキーフレーム単位で分割して並列エンコードすれば、品質低下なしに速度を上げられる

    • ただ、キーフレーム位置を事前に予測できるだろうか?
      通常はエンコーダーが効率のために動的に配置するので、事前分割は難しいかもしれない
    • エンコーダーがP/Bフレーム解析時に行うモーション解析を一度だけ計算し、複数のエンコードで再利用できないだろうかと気になる
  • Metaチームがffmpegffprobeに貢献してくれたことに感謝する
    今後はコード品質、ドキュメント、コミュニティイベントなどへの資金支援も検討してほしい

  • 「内部フォークが次第に古びていった」という表現にはとても共感する
    ちなみにFFmpeg 8ではHDRとSDRのカラーマッピングが完璧に処理される

    • 以前はメタデータ自動コピーの問題で苦労したが、今は解決されて本当にうれしい
    • 久しぶりに話を聞けてうれしいし、進歩が印象的だ
  • ドイツのSovereign Tech FundがFFmpegに寄付したという話は興味深い

    • ドイツのSTFは約15万ドルを寄付したが、Metaのエンジニア1人の年間人件費だけでもその2倍以上にはなるだろう
      おそらくMetaはメディアエンコーディング専任チームを持ち、年間100万ドル以上相当の貢献をしているはずだ
    • しかしFFmpeg公式アカウントは「Metaの支援には感謝するが、持続可能な水準ではない」と述べていた
      関連ツイートを見る
    • Metaが実際にいくら寄付したのか気になる
      ドイツのSTFは2024/2025年に€157,580を支援したという
    • Metaが数十億ドルを稼ぎながら、国家基金より少ない寄付しかしていないというのは少し皮肉だ
    • [削除されたコメント]
  • FFmpegサーバーは幸い軽いコンテンツばかり処理しているので持ちこたえている
    重い動画だったら過負荷になっていただろう

  • 同じHN投稿は6日前にも上がっていた
    なぜこのリンクを貼っただけでダウンボートされるのかわからない

    • 私の理解では、同じユーザーが繰り返し投稿していない限り、再投稿は問題ないはずだ
    • [削除されたコメント]