FFmpegがWebRTCサポートを統合

355日前原文(git.ffmpeg.org)

概要

Anubis は、ウェブサイトを AI企業のスクレイピング から保護するために導入された仕組み。 Proof-of-Work 方式を採用し、悪質な大量アクセスを抑制。正当なユーザーにも一時的に チャレンジページ が表示される場合あり。 JShelter などのプラグインが有効だと正常動作しないことも。今後はより精密な 判別方法 導入予定。

Anubisによる保護の仕組み

ウェブサイトの 管理者 がAI企業による 過剰なスクレイピング 対策として導入
Anubis はProof-of-Work型のチャレンジページを表示
- Hashcash に着想を得た仕組み
- 個人利用レベルでは負担が少ない
- 大量アクセス時にはコストが大きくなり、スクレイピング抑止
サイト全体の ダウンタイム防止 を目的
一時的に 正規ユーザー にもチャレンジが表示される場合あり

Proof-of-Work方式の詳細

Proof-of-Work は、リクエストごとに一定の計算処理を要求
スパムメール対策 で提案されたHashcashと同様の考え方
通常利用者には負担が少なく、 自動化ツール やボットには大きな負荷
サイト資源の 公平な利用 を促進

今後の改善方針

Anubisは 暫定的な対策 として運用
将来的には、 ヘッドレスブラウザ の識別精度向上を目指す
- 例： フォントレンダリング の挙動などで判別
正規ユーザーへの影響を最小限に抑える方針

プラグインとの互換性注意

Anubisは 最新のJavaScript機能 を利用
JShelter などのプラグインが有効だと正常動作しない場合あり
該当ドメインでは プラグインの無効化 を推奨

Hackerたちの意見

これはどういう意味なの？ウェブサイトがFFmpegのインスタンスに直接接続して、音声や動画のストリームを受け取れるってこと？Phoronixにはもう少し詳しいページがあるよ。

└

つまり、FFmpegのライブラリ（特にlibavformatを使ってるみたいだけど）を使ってるプログラムがWebRTCのストリームを受け取れるってことだね。

面白いな、iOSのSafariでボット検出にブロックされ続けてる。仕事のWiFiでも、携帯データでも。アヌビス、助けてくれよ。

└

「アクセス拒否」のページが出るの？それとも無限のチャレンジループにハマってるの？

└

デュアルスタックネットワーク持ってる？

FFmpegのセキュリティ監査ってどうなってるの？サイトを見る限り、反応的な感じだね。

これでFFmpegをシステムに置いておくのがもっと危険にならないといいけど。WebRTCのセキュリティの欠陥が多くの妥協を引き起こしてるから、ブラウザをインストールした後にまず無効にすることの一つなんだ。

└

どんなセキュリティの欠陥があるの？この実装はすごく小さいから、ユーザーに最高のものを提供できてるって100%自信があるよ。

└

これがffmpegをシステムに残すのをより危険にしないことを願ってる。ffmpegは過去にたくさんの問題があったから、ユーザー入力を扱うときはしっかり管理するのがベストプラクティスだよ。ffmpegとその依存関係だけをインストールしたDockerイメージを作って、トランスコードのジョブごとに「docker run」を実行するのがいいかも。画像やドキュメントのサムネイルを作る必要があるなら、ClamAVやOpenOffice、ImageMagickもイメージに追加してもいいかもね。個人的には、ユーザー生成ファイルを扱うサーバーは、受け入れと提供だけでなく、厳重にロックダウンされたVLAN（AWSならセキュリティグループ）で管理するのがいいと思う。ちなみに、これらのプロジェクトに対するバカな批判じゃないからね。セキュリティは難しいし、時には疑わしいリバースエンジニアリングのゴミが含まれているバイナリフォーマットを扱うときは特にそう。4chanみたいにやられないように、これを認識しておくのは賢明だよね。

└

もし必要ないなら、--without-whipみたいな引数でコンパイルできるのかな？それが理想的だね。

SCTPの部分じゃないよ！これはWebRTC-HTTPインジェクションプロトコル（WHIP）を実装してるんだ。これは、実際にWebRTCをピアとやり取りするゲートウェイと話すための一般的な低遅延HTTPプロトコルだよ。将来的には、SCTPを使うのではなく、QUICやWebTransportに基づいたp2pプロトコルに切り替えられるといいな。QUICは既存のUDPの上でSCTPの役割をうまく果たしてくれるから、そんなに複雑で変動のあるものを追加する必要がないんだ。候補としてはMedia-over-Quic（MoQ）があるけど、ブラウザにはp2pのQUICがなくて、その進展は数年前に止まっちゃった。

└

SCTPの部分をどう使いたい？WHIPのIETFドラフトにはそれについての言及がないから、どうやって公開すればいいかわからないんだ。ほとんどの「WHIPプロバイダー」もDataChannelをサポートしてるけど、まだ標準化されてないんだよね。

これで自己ホスティングのストリームやストリーミングCDNがずっと簡単になるはずだよ。使い方がわかれば、FFmpegは本当に素晴らしいスタンドアロンのメディアソフトウェアなんだ。

└

ほんとワクワクする！特にSimulcastがあれば、みんなにとってすごく安くて簡単になるよね。自ホスティングとWebRTCをもっと簡単にするために、https://github.com/Glimesh/broadcast-box を作ったんだ :)

└

LLMはそれをすごく上手に使えるよね。動画関連のタスクを頼むと、ffmpegのワンライナーを教えてくれる。

└

本当にそうだね、この漫画がいつも思い浮かぶよ。https://xkcd.com/2347/

WebRTCの放送がめっちゃ楽しみ！Broadcast BoxのREADMEやOBSのPRに理由を書いたよ。GStreamer、OBS、FFmpegが全部WHIPに対応したから、これでモバイル、ウェブ、組み込み、放送ソフトなど、どのプラットフォームでも使える動画放送の共通プロトコルがやっとできたね。オープンソースとWebRTCの放送に何年も取り組んできたから、これは大きなマイルストーンだよ :)

└

すごく頑張ってくれてありがとう、Sean！君のWebRTCライブラリを使えて、幅広い技術的な取り組みでの影響を見られて嬉しいよ。

└

webrtcストリームを再生できる動画プレーヤーってある？前にチェックした時、VLCとか他の人気ツールはまだ対応してなかった気がする。

Jellyfinでこれが実装されるのが待ちきれない！

└

これって何を提供するの？

チャット機能もあったらいいな。

これって、ffmpegがJitsiのビデオ会議の音声ストリームを録音できるようになったってこと？

ハクソク