あのFFmpegがWebRTC対応！これで動画配信はこうなる

WebRTCそのものの複雑さはすごく高いんだ。WHIPは多くのアプリが連携するための標準的な道筋みたいだけど、結局何かをするには外部サービスに依存するね。理論的には、ffmpegがICEサーバーになってピア接続したり、SDPでストリーム交渉したり、ついでにWHEP（egress protocol）も使って、実際のストリーム転送はSCTPでやったりできるかも。そうなれば、ゲートウェイサービスに任せるんじゃなくて、スタンドアロンのピアみたいに振る舞えるかもしれないね。GstreamerやOBSもWHIPベースで、WebRTCサポートのために外部ゲートウェイに依存してるのは注目すべき点だよ。WebRTCのレイヤーケーキ全体をやる明確な方法は一つじゃないから（WHEPは結構人気だと思うけど）、WHIPは動画送信をサポートする良い方法なんだ。これで、誰かがシステムでWebRTCをどう実装したいかに合うか合わないか、たくさんの決定をしなくて済むんだ。そういった決定は全部WHIPゲートウェイの中にあるからね。全部やろうとするより、切り離した方が良いのかもしれない。そうしないと、特定の意見に基づいたアプローチが必要になるからね。

これってどういう意味？ウェブサイトがFFmpegインスタンスに直接接続して、音声や動画のストリームを受け取れるってこと？Phoronixにもっと分かりやすいページがあったよ。
https://www.phoronix.com/news/FFmpeg-Lands-WHIP-Muxer

それはね、FFmpegライブラリ（libavformatらしいよ）を使うプログラムがwebrtcストリームを消費できるって意味だよ。

まだ実際の使い道が全然分からないんだ。いくつか例を教えてくれないかな？（変な意味じゃなくて、純粋にこれで何ができるようになるのか知りたいんだよ。）

WebRTCは1秒以下の遅延でピアツーピア通信が得意だから、ほぼリアルタイムの動画が役立つ場所ならどこでも使えるよ。例えば、2つの違う都市の景色をライブ音声付きでつなぐバーチャルポータルを作りたいとするじゃない？FFmpegにプロ仕様のシネマカメラやDSLRカメラから綺麗な音声映像フィードを入れて、WebRTCでウェブページベースのライブビューアーにストリームできるんだ。あるいは、ウェブページでドローンや探査ロボットを遠隔操作したい場合なんかにもすごく良いと思うよ。

皮肉なことに、1秒以下の遅延って実はWebRTCが_本当に_必要なんじゃないんだよね。普通のTCPストリームでも、ネットワーク遅延に加えて100～200msくらいは結構信頼性高く得られるんだ。[1] でもブラウザはHLSに事実上標準化しちゃったせいで、その設計が低遅延には全く向いてないんだ（低遅延HLSもできるけど、ものすごい努力が必要）。だから、低遅延のストリーミング動画は、ブラウザの得意技になったことがないんだよね。その代わりに、ずっと複雑なプロトコル（WebRTC）を、低遅延のビデオ会議向けルートとして悪用してるんだ。（昔、VLCでガラスtoガラスで100ms以下のストリーミングをやったことがあるよ。だからそれは十分に可能なんだ。でもブラウザが邪魔をしてるんだ。）[1] それよりずっと遅延を減らすのは、完璧じゃないネットワーク条件下では難しくなるだろうね。だって、少しでもパケットロスが始まったら、TCPの再送メカニズムから切り替えて、パケットを捨てて、少しの間アーティファクトを受け入れて、そして先に進みたいから。

node1# nc -u node2 12345 ＜ /dev/fb0
node2# nc -lu 12345 ＞ /dev/fb0

「1秒以下の遅延」っていうのはWebRTC関係の人がよく言う決まり文句だけど、そうだよね、分かりにくいよね。これ↑（ncコマンドの例）より動画の流れを速くすることはできないんだ。新しい標準を発明することでできる唯一のことは、目的のために加えなきゃいけないオーバーヘッドを最小限にすることだけだよ。

WebRTCが一番手軽で広まってるね。TCPで動画配信のいい標準作ろうとしても、普及しないだろうし大変だ。だから、WebRTCをみんなが使いやすくする挑戦を受け入れたよ。「WebRTC for the Curious」みたいな本で、複雑さを少しでも楽にできたらいいなって思ってる :)

「TCPでよりシンプルな標準を」ってどういう意味？HTTPでvideoタグとストリーム使えばできるじゃん、新しい標準はいらないよ。でもそれだと低遅延じゃないんだ（バッファ制御できないから）。

HLSは動画を分割して、いくつかダウンロードしてから再生開始するから、30～60秒遅延するんだ（これはテレビ向きで、インタラクティブな用途にはダメ）。AppleのLL-HLSで細かくして、受信中にデコードすれば2～5秒くらいになるけど、CDNとか色々な工夫が必要で「英雄的」って言われるくらい難しい。SafariはHLSそのまま再生できるけど、他のブラウザはhls.jsが必要。DASH、RTMP、SRTはもっとコードが必要だから、HLSがVODとかの「無難な選択肢」になったんだよ、低遅延じゃないのに。

実際（携帯回線とかね）パケットロスがあるでしょ。だからTCPは、品質の高いリアルタイム配信には向かないんだよ。

まず思ったのは、ストリームを好きな形式で保存するのに超便利ってこと。例えば通勤中に古いスマホで見る用に変換したりね。ffmpeg -i ＜stream＞ってやって、いつものオプション使うだけ。ダウンロードして変換する手間が省ける。ffmpegは処理もできるから、ストリームからクロマキー合成とかも。ffmpegは低レベルな構成要素で、ライブラリとして使われることが多いけど、プレイヤーとか処理ツールがストリーム入力を簡単に追加できるようになるのが一番大きい影響だろうね。

Unreal Engineから動画ストリームを出せるのはWebRTCだけなんだ。だからこれで、クライアントはlibdatachannelみたいな変なのじゃなくて、ffmpeg/avconvを使えるようになるね。

俺のデスクトップアプリ ossia.io はffmpeg使ってて、これでネット経由で別のPCと動画送受信したいんだ。ルーターのポート開けるとか面倒なことなしにね。これがvdo.ninjaみたいなサーバーと組み合わせれば解決しそう。https://ossia.io

多分、WebRTC使ってるビデオ会議システム（Teams、Discord、Zoomとか）のオープンソースクライアントが作りやすくなるんじゃないかな。これらのサービスはブラウザ用にはWebRTCをフォールバックで使ってるか、全部に使ってるみたいだし。（非公式クライアントをブロックする対策はあるかもだけどね。）

人気のある/有名なWebRTCの送信側（サーバー）ってあるの？ YouTubeとかじゃないんでしょ？ じゃあWebRTCで何を見るの？

Twitchは今WHIPをサポートしてるよ。WebRTCサービスの中にはWHIPをサポートしてるところが多いんだ（Cloudflare、LiveKit、Dolbyとか）。webrtcHacksに記事があるよ[0]。ちょっと古いけど、雰囲気は掴める！[0] https://webrtchacks.com/tag/simulcast/

え、これってWebRTCの受信側だけってこと？WHIPを使ってサーバーにストリーム要求できるようになったってことかな？

いや、今は送信側だけだってば！WHIPはWebRTCでプッシュ（送り出す）するためのもの→https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html
WHEPはプル（受け取る）するためのものだよ→https://github.com/wish-wg/webrtc-http-egress-protocol/blob/…
WHEPはまだ固まってないから、標準化されたらOBSとかFFmpegとかにも対応させようと思ってるよ。

うーん、これってgstreamerのwhepsrc使ってる人にはどう影響するんだろ？今のWHEPサーバーが来年のWebRTCと互換性無くなるリスクってあるのかな？

これで自分でストリーム配信したり、CDN作るのがマジで簡単になるはずだね。FFmpegは使い方分かれば、それだけで何でもできちゃうすごいソフトだからさ。

これ超興奮するわ。特にSimulcastがあれば、マジで安く簡単にできるようになるね。自分でホストしてWebRTC使うのを簡単にしたくて、このリポジトリ作ったんだよね。見てみて→https://github.com/Glimesh/broadcast-box

LLMってマジでFFmpegの使い方が神がかってんのな。どんな動画のこと聞いても、コマンド一行で解決する方法教えてくれるんだぜ。

うわ、マジか。俺もさっきGeminiに「ffmpegでテロップ画像入れるには？」って聞いたら、overlayフィルター使う方法を詳しく教えてくれたんだよ。まだ試してないけど、見た感じはイケてそう。

まあ、もっともらしいかもしれないけど、「まだ試してない」なら、もっともらしい答えを出すのが上手いってだけじゃん。LLMの一番よくある失敗って、もっともらしいけど間違ったこと言っちゃうことなんだからさ。

俺が最近使ってる感じだと、間違えるのなんて10%くらいだよ。大体ちゃんと根拠があること言うし、問題なく動くことが多いよ。

もし他のソフトが黙って、もっともらしく10%の確率でエラー吐くって想像できる？そんなの絶対使われないって。VCマネーってマジすごい薬だよな（※VCはベンチャーキャピタルのこと）。

素晴らしいね—15年前にffmpeg関連の仕事でソフトエンジニアの基礎を築いたんだ。LLMがフィルターとかCLIコマンドを生成してくれるのは、「理論上可能だけど、金もらわないと無理」だったBashスクリプトみたいな作業を、楽しくて簡単で日常的なものに変えてくれた。昨日、14分の動画を最初の10秒はリアルタイムで、残りは10倍速で再生するコマンドを聞いてみたんだけど、ffmpegのCLI構文って全部頭に入れれば何でもできる気がしてたけど、一つのコマンドで全部できるって知ってやっぱり驚いたよ。

僕はBashスクリプトを不愉快に思ったことはないな。仕事でも普段のコンピューターでも何千ものスクリプトを使ってるよ。~/binフォルダーに自作した便利なスクリプトを置いてるんだ。真面目なプログラミングにはPythonとかRubyを使うけど、これをBashでやり続ける理由の一つは、手で組んでテストしたコマンドライン呼び出しを、変更なしでスクリプトに入れられることなんだ。

僕も！データエンジニアだから、パイプラインジョブが動いてる時はそれを監視するスクリプトがあるんだ。ジョブが終わったら、完了したこととステータスを音声で教えてくれる。これは何十もある便利なスクリプトの一つにすぎないけどね。
これのおかげで、20分おきにステータスを確認しなくても、ビデオゲームしたり本読んだりして人生がずっと楽になったよ。
あなたほどたくさん作ってはないけどね。いくつか共有してもらえない？

何千ってのは多分誇張だけど、でも本当にたくさんあるよ！
端末エミュレーションやVMとかに接続しててコピペが効かない時に、いつも使ってるのがtypeitforme。テキストファイルの内容を、数秒の遅延（目的のウィンドウにフォーカスを移す時間）の後、キーボードバッファを通して送るんだ。
今は~/.bash_aliasasファイルにエントリーとして入れてるよ。
alias typeitforme=’sleep 3 \u0026\u0026 xdotool type –file ’
これは標準のUbuntu Linuxで動くよ。xdotoolのドキュメントをチェックすれば、もっと色々なアイデアが得られるかもね。

「答えはまだテストしてないけど、見た目はちゃんとしてそう。」
それがLLMだよね。

まあ、それはそうだけど、Hacker Newsにコメントする時間は限られてたんだ。動画をセットアップしてこのアイデアをテストするまではできなかった。ffmpegの公式ドキュメントでオーバーレイ機能が存在することは確認したよ。

Hacker Newsのスレッドは、たとえ完全に無関係でも、少なくとも一度はLLMに言及しないとね。

本当にそうだよね。このコミックいつも思い出すよ。
https://xkcd.com/2347/

XMPPクライアントのGajimは、これを長い間待ってたんだ！彼らのオーディオ＼ビデオ通話機能は非推奨になってて、FFmpegがもっと簡単にオーディオ＼ビデオ通話機能を追加できるようになるのを我慢強く待ってたみたい。

GajimとかXMPPってまだ使われてるの？Pidginでチャットアプリを使えてた頃が懐かしいな。
今は全部walled gardenで、サービスごとにアプリが必要だもんね。

これでffmpegをシステムに入れるのがもっと危険にならないといいな。WebRTCのセキュリティ上の欠陥はたくさんの侵害の原因になってるんだ。
ブラウザをインストールした後に最初に無効にするものの一つだよ。

どんなセキュリティ上の欠陥？
この実装はすごく小さいんだ。ユーザーに可能な限り最高のものを届けられてると100％確信してるよ。

一番最近だとこれ: https://cyberpress.org/critical-libvpx-vulnerability-in-fire…、でも毎年ここから選べるよhttps://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=webrtc
WebRTCを無効にするって人が多い最大の理由は、VPN使ってる時のIP漏洩を防ぐためって言うのは君の言う通りだよhttps://www.techradar.com/vpn/webrtc-leaks
でもRCEやDoSを心配しなくていいのは嬉しいボーナスだね。
これがffmpegユーザーにどれだけ影響するかは分からないけど、WebRTCがセキュリティに関して悪い実績があることを考えると、システムにもう一つ含まれることで攻撃対象が増えるのは少し心配だよ。

それって複数の実装での問題だよ！
その多くはJavascript周りのChromiumの問題で（WebRTCのコードなんてまだ始まってもなかった）、
それってこのリンクを貼って「WebRTCはHTTPより安全だ」って言うようなものだよhttps://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=http
IP漏洩は2019年以降修正されてる[0]。ICE/P2Pはまだ大きな攻撃対象だけどね。他のたくさんのトリックが試されてるのを見てるよ。
[0] https://www.youtube.com/watch?v=SqcW8kJAMJg

autoexecは、WebRTCをクライアントとして実装しているブラウザやメッセンジャー、その他のソフトウェアに影響を与えているWebRTCの膨大な脆弱性のこと言ってるんだろうね。その完全な実装を正しくやるのは難しいみたいだ。
もちろん、この実装がすごく小さいって言うのは君の言う通りだ。普通のクライアント実装とは全然違うから、同じ心配はしてないよ。
それと、WebRTCのWHIP部分だけだし、ffmpegを通してユーザー入力を処理する人は、願わくば使う機能だけ有効にしてコンパイルしてるか、少なくとも設定時に”–disable-muxer=whip”とかを無効にしてるんじゃないかな。
もしくは、実行時に全部明示的に指定すれば、ffmpegが可変のユーザー入力に基づいて機能を読み込むことはないだろうね。

＞autoexecは、WebRTCの脆弱性がブラウザとか他のソフトにたくさん影響してるって言いたいんだろうね。その完全な実装を正しくやるのは難しいみたいだ。
どんなの？ ちょっと検索してみたけど、ほとんどがIP漏洩とかフィンガープリンティングみたいなものみたいで、それはffmpegには関係ないよ。

WebRTC関連のヤバいCVEをいくつか見つけたんだ。FFmpegに直接関係ないのはわかってるけど、WebRTCって聞くとセキュリティが気になるんだよね。だから、ブラウザとかとは違うFFmpegの実装について指摘するのに良い機会だと思ったんだよ。

WebRTCって検索しただけで、実際にはCVE読んでないんじゃない？しかもそれを論点の根拠にするなんてすごいね。あれってブラウザの実装の問題でしょ？NodeとかLinuxの例と同じで、自分の意見に合う証拠を探してるだけじゃん。質が低いよ。

そんな煽るようなこと書く前に、このスレッドの論点忘れてない？WebRTCを実装したときにセキュリティを再確認すべきかって話をしてるんだよ。FFmpegの実装はブラウザとは違うけど、ブラウザのWebRTCにはたくさん脆弱性があったから、再確認は原則として正しいんだ。
俺がCVE読んでないってどこでそう思ったんだ？ちゃんと読んでるよ。ランダムに選んだけど、Use-after-freeだって書いてあったし。実装バグかどうかなんてどうでもいいんだよ、WebRTCの実装で入った脆弱性なんだから。

＞「IP漏洩やフィンガープリンティングはFFmpegには関係ない」って話だけど、もしFFmpegが将来WHEPを実装したら、ストリームを視聴する時にはその辺が心配になるね。ストリームを配信する時、特にゲートウェイ経由なら、そこまで心配ないだろうけど。

これ、まさに俺も疑問だったんだよ。ブラウザでWebRTCを使うとフィンガープリンティングのリスクがあるけど、それってFFmpegを実行することとは関係ないんじゃないの？

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

そうだよ、FFmpegの機能はほとんど全部、コンパイルする時に有効にしたり無効にしたりできるんだ。

FFmpegは、よく分からないコーデックとかバイナリ形式をC言語で扱う高性能なコードなんだから、そんなに心配することないよ。

FFmpegには過去にたくさんの問題があったから、ユーザー入力を扱うときはコンテナとかでしっかり隔離するのが一番だよ。Dockerでffmpegだけ入れたイメージ作って、それを使うとかね。ClamAVとかも同じ。ユーザー生成ファイルを扱うサーバーは、ネットワークも厳重に隔離すべきだね。
これはプロジェクトへの批判じゃなくて、セキュリティは難しいってことを認識しようって話。4chanみたいにならないためにもね。詳しくはここ見てね： https://ffmpeg.org/security.html