FFmpeg、WebRTC（WHIP）による超低遅延ストリーミング対応を統合
(git.ffmpeg.org)- FFmpeg
avformat/whipに WHIP muxer が追加され、WebRTC ベースの 1秒未満の低遅延ストリーミング を FFmpeg 内で扱えるようになった - 変更の基準は WHIP Version 3 で、muxer 名と実装だけでなく、SSL・DTLS・RTC のログコンテキストとエラーメッセージもあわせて整理された
- 実装内部のマジックナンバーは マクロと関数 に置き換えられ、DTLS curve list・SRTP profile・ICE STUN マジックナンバー・RTP payload type の処理も改善された
- メディア経路では固定フレームサイズの代わりに
rtc->audio_par->frame_sizeを使い、MP4/ISOM 入力の Annex B 変換には h264_mp4toannexb を使用する - ビルド設定は
whipが DTLS 有効時のみ 有効になるよう変更され、現在の対応対象は OpenSSL に限定される
WHIP muxer の追加とビルド連携
avformat/whipに WHIP muxer が追加され、1秒未満の低遅延ストリーミングに対応した- 実装の基準は WHIP Version 3
- 新しい実装ファイルとして libavformat/whip.c が追加された
- ドキュメントとビルド構成もあわせて変更された
DTLS・ICE・RTP 処理の整理
- WHIP muxer は名称変更とあわせて実装が洗練され、SSL・DTLS・RTC のエラーメッセージとログコンテキストが改善された
- マジックナンバーは マクロ に置き換えられ、一部ロジックは関数として分離された
- ログレベルもより明確に調整された
- DTLS 経路では、複数の互換性・性能関連の変更が入った
- DTLS curve list が更新された
- FFmpeg と OpenSSL 向けの SRTP profile 名が整理された
- DTLS handshake と ICE 処理が性能改善のため最適化された
- 単一の handshake timeout と server role を使い、ARQ を回避する
- ICE 処理は request/response と DTLS handshake を単一関数へ統合する方向で整理された
- ICE STUN マジックナンバーが見直された
- RTP payload type は Chrome の定義を基準に更新された
メディア処理と OpenSSL の制約
- 音声側の固定フレームサイズは
rtc->audio_par->frame_sizeを使う方式に変更された - MP4/ISOM 入力を Annex B に変換するため
h264_mp4toannexbが使用される - OPUS timestamp の問題と、BSF 使用後の marker 設定もあわせて修正された
- TLS と DTLS の実装は共通構造に統合された
- BIO callback、read、write、
print_ssl_error、openssl_init_ca_key_cert、init_bio_methodが共有される - 同一のデータ構造を使用する
- BIO callback、read、write、
- OpenSSL のビルドエラーが修正され、Pion と動作するよう調整された
configureはdtlsが有効な場合にのみwhipを有効にするよう変更された- 現在の対応対象は OpenSSL
1件のコメント
Hacker News のコメント
WebRTC 配信には本当に期待している。理由は Broadcast Box の README と OBS の PR にまとめてある
これで GStreamer、OBS、FFmpeg がすべて WHIP をサポートするようになり、モバイル、Web、組み込み、配信ソフトウェアなど、あらゆるプラットフォームで使える普遍的な映像配信プロトコルができたことになる
オープンソースと WebRTC 配信の分野で数年にわたって取り組んできたが、大きなマイルストーンだと思う
[0] https://github.com/Glimesh/broadcast-box?tab=readme-ov-file#...
[1] https://github.com/obsproject/obs-studio/pull/7926
SCTP の部分ではない。実際には、ピアと WebRTC の SCTP ベースのプロトコルで通信するゲートウェイに接続するための低遅延 HTTP プロトコルである WebRTC-HTTP Ingestion Protocol、つまり WHIP を実装したもの
https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
いつかは SCTP の代わりに QUIC や WebTransport ベースの P2P プロトコルへ移行できるといい。QUIC は既存の UDP 上で SCTP が担っていたことをうまく処理し、複雑さや実装差を大きく増やさない
候補の一つは Media-over-QUIC（MoQ）だが、ブラウザには P2P QUIC がなく、そちらの進展も数年前から止まった状態
https://quic.video/ https://datatracker.ietf.org/group/moq/about/
ほとんどの WHIP プロバイダーは DataChannel もサポートしているが、まだ標準化されたものではない
これがどういう意味なのか気になる。Web サイトが FFmpeg インスタンスに直接接続して、音声や映像ストリームを受け取れるということなのか？
Phoronix の説明のほうが少し詳しい: https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer
これなら セルフホストのストリームやストリーミング CDN をずっと簡単に作れるようになりそう
FFmpeg は使い方さえ分かれば、本当に驚くほど優れたスタンドアロンかつプラグアンドプレイのメディアソフトウェア
セルフホストと WebRTC をもっと簡単にしたくて https://github.com/Glimesh/broadcast-box を作った
XMPP クライアントの Gajim はこれを長い間待っていた。音声・ビデオ通話機能は事実上放置された状態で、FFmpeg のおかげで再び追加しやすくなるのを辛抱強く待っていた形だ
今では全部、閉じた庭やアプリごとのサービスになってしまった
Anubis のグラフィックを予想外に見るとうれしい。これまで ffmpeg や gnu などで見かけた
このせいでシステムに ffmpeg を置いておくのがさらに危険にならないことを願う。WebRTC のセキュリティ脆弱性は多くの侵害事故の原因で、ブラウザをインストールしたら最初に無効化する機能の一つ
今回の実装は非常に小さく、ユーザーに可能な限り最善のものを提供していると 100% 確信している
--without-whipのような引数でビルドから外せるのか気になる。それが理想的だと思うffmpeg と依存関係だけを入れた Docker イメージを作り、変換作業ごとに
docker runを実行するような形がよい。画像やドキュメントのサムネイルも作る必要があるなら、ClamAV、OpenOffice、ImageMagick も一緒に入れられる個人的には、ユーザー生成ファイルを単に受け取って配信する以上の処理をするサーバーは、別の強くロックダウンした VLAN、AWS なら Security Group の中に置くほうがよいと思う
これは言及されたプロジェクトへの無知な非難ではない。セキュリティは難しく、特に長年積み重なっていて、時には怪しい方法でリバースエンジニアリングされたバイナリ形式を扱う場合はなおさらだ。4chan のようにやられる前に、それを認めるのが賢明
[1] https://ffmpeg.org/security.html
本当に良い。Web ベースのリモート制御を作っているところで、これで
ffmpeg gdigrabを WebRTC ストリームにして、今やっている ExpressJS の回避策なしにクライアントが直接消費できるなら、とても満足できそうiOS Safari でボット検出に何度も弾かれるのが興味深い。会社の WiFi とセルラーデータの両方でそうなる
Anubis に通してほしい
"access denied"ページが表示されるのか、それともチャレンジが無限に繰り返されるのか気になるAnubis が通してくれない ;(