FFmpeg、WebRTC（WHIP）の超低遅延ストリーミング対応をマージ

• FFmpeg に WHIP（WebRTC-HTTP Ingestion Protocol）muxer が正式に追加され、1秒未満の超低遅延ストリーミングを直接サポート
• 今回のコミットでは WHIP muxer の命名と構造が再編され、SSL/DTLS/RTC のエラーメッセージとログが改善
• DTLS の曲線/プロファイル、RTP payload、ICE STUN など主要なプロトコルパラメータが Chrome の定義に合わせて更新され、マジックナンバーがマクロおよび関数として切り出された
• DTLS ハンドシェイクと ICE 処理が1つの関数に統合・最適化され、性能と安定性が大きく向上
• 音声・映像のトランスコード（h264_mp4toannexb、OPUS timestamp、マーカー設定など）のバグが修正され、標準的な WebRTC 環境との互換性が向上
• OpenSSL 依存関係が明確化され、DTLS 対応時にのみ WHIP がビルドされるようになった
• FFmpeg だけで WebRTC ベースの配信・リアルタイムストリーム環境を構築しやすくなり、既存の RTMP などのレガシープロトコルに比べて超低遅延の特性を活用できるようになった

---

avformat/whip: FFmpeg WHIP muxer 対応を追加

主な変更点の要約

• WHIP Version 3 ベースの muxer を正式導入し、内部名称と構造を整理
• SSL、DTLS、RTC の ログコンテキストとエラーメッセージがより明確に
• ハードコードされた マジックナンバーをマクロと別関数に切り出し、保守性を強化
• DTLS の曲線リスト、SRTP プロファイル名などを FFmpeg と OpenSSL の標準に合わせて修正
• ICE STUN マジックナンバー、RTP ペイロードタイプを Chrome ブラウザ標準と一致するよう更新
• 音声フレームサイズ、H.264 MP4→AnnexB 変換、OPUS タイムスタンプなど メディア処理の課題を解決
• DTLS ハンドシェイクと ICE 処理ロジックを 単一関数に統合し、管理しやすくした
• OpenSSL ベースの DTLS 対応条件が明確になり、ビルドエラーと互換性を改善
• SRTP、BIO コールバック、CA キー/証明書初期化など TLS/DTLS 内部構造を統合
• whip.c ファイル新設など 全13ファイルを変更・追加

背景と意味

• WHIP は WebRTC ベースのストリーム送出のための HTTP ベース標準プロトコルであり、超低遅延のライブ配信に不可欠
• これまで FFmpeg での WebRTC エンコード・送出には別ツールや複雑な中継が必要だったが、今回のマージにより FFmpeg 単一コマンドでの WHIP 送出が可能になった
• リアルタイム配信、ライブコマース、ビデオ会議などさまざまな分野で、最新の WebRTC エコシステムと直接連携できる技術的な転換点

[GN⁺]

Hacker Newsの意見

• WebRTC配信にものすごく興奮している。Broadcast BoxのREADMEとOBSのPRリンクで自分なりに理由をまとめているが、これでGStreamer、OBS、FFmpegのすべてがWHIPをサポートすることになり、あらゆるプラットフォームに適用できる汎用的な動画配信プロトコルに到達した。長年にわたるオープンソース+WebRTC配信の経験から見ても、今回の成果は大きなマイルストーンだと思う
  • 以前はリモートのdosboxゲームをスマホからVNCで遊んでいたが、今ならinput handlerのWebアプリを自作して、この技術+OBSの組み合わせで無限に時間を溶かせそうな新しい挑戦意欲が湧く
  • モバイル配信ユニットで複数の5Gモデムを接続し、multipath/failover-bonding機能（例: SRTを改造してH.265を複数リンクで送信）を追加する予定があるのかという質問
  • 人気の配信ソフトウェア、モバイル、Web、組み込みなど多様なプラットフォームで直接活用された経験を経て、broadcast-boxと開発への貢献に驚いている
  • 自分のwebrtcライブラリが複数のプロジェクトで有用に使われ、幅広い技術領域に影響を与えたことを見てうれしいと表明
• WebRTC-HTTP Ingestion Protocol（WHIP）の実装を告知。SCTP自体を扱うのではなく、WebRTCを使うピアとHTTP経由でゲートウェイの役割を果たす。WHIP IETF文書（リンク）を参照。いつかSCTPの代わりにQUICやWebTransportベースのp2pプロトコルへ移行してほしいと期待している。Media-over-Quic（MoQ）にも関心はあるが、ブラウザ対応や発展がここ数年鈍い点を共有。関連リンクはquic.videoとMoQ IETF introduction
  • SCTPの部分をどのように活用・公開したいのかを尋ねる質問。WHIP IETF草案には関連する言及や提案がなく曖昧で、ほとんどの「WHIP Provider」はDataChannelをサポートしているが標準化はされていない状況
• FFmpegとWebサイトを直接つないで、そのままオーディオ/ビデオストリームを受信できるのかという質問。詳しくはPhoronixのページ（リンク）で確認可能
  • FFmpegライブラリ、特にlibavformatを使うプログラムなら、WebRTCストリームを直接受け取って活用できるという要約説明
• 今回の変更でセルフホストのストリーム/ストリーミングCDN構築がはるかに簡単になるだろうという期待。ffmpegの独立性とプラグアンドプレイ性能を強調
  • Simulcastと組み合わせればコストや参入障壁が劇的に下がる見込みで、broadcast-boxを作ったきっかけも、セルフホスティング+WebRTCの参入障壁を下げるためだった
  • LLM活用によりffmpeg関連のあらゆる動画作業でone-linerコマンドまで導き出せるとして、AI利用体験を絶賛
  • ffmpegの万能さを一目で示す漫画xkcd 2347をいつも思い出す
• Anubisのグラフィックをffmpegやgnuなどで予想外に見かけた経験が印象的だった
• WHIP機能の追加によって、システムにffmpegを維持することがさらに危険にならないかという懸念。WebRTCのセキュリティ脆弱性が実際に多くの侵害原因だと感じており、過去にもブラウザをインストールしたあと常に無効化していた経験
  • どんなセキュリティ脆弱性があるのかという質問。今回の実装は非常に小さく、ユーザーに最高の成果物を提供するという強い確信に言及
  • --without-whipのように不要ならビルドから完全に外せるオプションを選べるのかという質問。そうできれば最良だという意見
  • ffmpegは過去にセキュリティ問題を多く経験しているので、ユーザー入力を処理する際は常に隔離環境を使うのが最善。たとえばffmpegと依存関係だけを含むDockerイメージをジョブごとに新しく起動して使う、あるいはサムネイルや文書処理が必要ならClamAV、OpenOffice、ImageMagickなどを追加するのを推奨。また、ユーザー生成ファイルを扱うサーバーはできるだけ分離されたVLAN、またはAWSならセキュリティグループ内だけで運用する方式を勧める。各プロジェクトを批判したいわけではなく、バイナリ形式そのものの難しさと先回りした安全対策の重要性を強調。4chanの事例も参照。ffmpegのセキュリティページはこちら
• ffmpegのセキュリティ監査活動がどのようになっているのかという質問。公式サイトではやや事後対応的に見えるという印象を共有
• ffmpegで今後Jitsiビデオ会議の音声ストリーム録音が可能になるのか確認する質問
• FFmpegのソースビルドでwhipサポートをうまく適用した経験があるか、正しい./configureオプションを見つけにくいという嘆き
  • 必要なオプションは--enable-muxer=whipと--enable-opensslだという案内
• Jellyfinでこの機能が適用される日を心待ちにしている
  • これについて、Jellyfinにどんな機能的な助けがあるのかを尋ねる質問