いいアイデアですね。IOについて詳しく教えてもらえますか？ffmpegサーバーがクライアントからブロックを読み取る方法はどうなってるんでしょう？それが大きな障害になりそうです。

ffmpeg.orgにパッチを提出してみたらどう？

ここにいるのを見れて嬉しい！Pundleでの君の仕事には本当に感心したよ。（あれは驚くほど速いHMR開発環境だったね - 今のViteみたいに。）自分だけが使ってる気がしてたけど、瞬時の更新から離れるのは難しかった。

これの意味は何なの？9500TやRyzen V1500Bの単一CPUコアで、60mbpsの4K H264を1080p 5mbpsのh264にリアルタイムで再エンコードできるよ。つまり、Jellyfinのためにモバイルでトランスコーディングするというコアユースケースには、PCでハードウェアビデオエンジンは9年間も必要なかったんだ。なんでみんなハードウェアビデオエンコーディングにこだわるのか全くわからない。完全に間違ってる。品質も悪いし、効率は赤いニシンだよ。ffmpegのIOスレッドには、設定を変えない限り、すべてのCPUコアを使うことになるし、設定を変えないよね。それに、Plexみたいなものでは面倒なセットアップやプレミアム機能が必要になる。全く意味がない！もしレイテンシが重要なら、ハードウェアエンジンは意味があるけど、ネットワーク経由で送ることでレイテンシを捨ててる。基本的に唯一のユースケースはゲームストリーミングで、その場合はローカルGPUがある。これらのffmpegネットワークハードウェアエンコードの革新が、実際のベンチマーク比較を持っているのを見たことがない。君は良かれと思って言ってるんだろうけど、本当に意味がないよ。

これ、かなり面白いね。ローカルマシン（とリモート）に接続して、任意のエンコードジョブを実行するために、ffmpegのフロントエンドで似たような実験をしてたんだ。そうすることで、エンコードタスクを別のマシンにオフロードしつつ、ローカルでキューイングメカニズムを保ってた。プロジェクトは https://ffmpeg-commander.com で、ffmpegコマンドを生成するためのものだけど、タスクをオフロードするための実験的なバックエンドもある。複数のサーバーでチャンクエンコーディングをサポートしてる？ 大きな動画ファイルをサポートするための素晴らしい機能になると思う。

ffmpegは素晴らしいHTTPの入力と出力サポートがあるよ。最近、結構使ってる。node.jsでffmpegをラッピングして、内蔵のHTTPサーバーとクライアントを使ってやり取りしてる。ほとんどの場合、ディスクに触れる必要がないから、負荷もかなり減ったよ。

一部の処理（最新の圧縮技術を使ってすでに圧縮された動画をさらにダウンサイジングすること）はCPUやGPUに依存するけど、他の処理、例えば何千もの高解像度JPEGを軽く圧縮したタイムラプスにまとめるのは、IOに依存することが多いよね。このツールはどうやってそのトレードオフを実現してるんだろう？ローカルで処理した方がいいものもあれば、外部GPUにオフロードした方がいいものもあると思う。あと、帯域幅がメガビットかギガビットかでも大きな違いが出るよね。

約1年半前に答えたことがあって、その答えは今でもほぼ正しいです： https://news.ycombinator.com/item?id=41743932 オペレーティングシステムを混ぜて使えるし、macOS、Windows、Linux、sudo権限は必要ありません。rffmpegは共有ファイルシステムが必要で、それを設定するのは大変かもしれません： https://github.com/joshuaboniface/rffmpeg/blob/master/docs/S... ffmpeg-over-ipはffmpegにパッチを当てて、サーバー用に1つのポートを開けるだけで、バイナリを実行すればOK。マウントは全く必要ありません。

Plan 9の素晴らしいところは、他の分散システムをすごく複雑に見せるところだね。Plan 9の最悪なところも、他の分散システムをすごく複雑に見せるところだ！

これは人間のエラーだと思ってもらうしかないですね。投稿する興奮のあまり、Show HNを省いちゃいました。

Show HN？それって何？ :-) ハッカーニュースはずっと読んでるけど、ハッカーニュースで技術を見せることに関する何かの慣習を見逃してたみたい。

ああ、今見えた。メニューオプションなんだね。全然気づかなかったよ :-)

コメントありがとう！こういうのは、サーバーとクライアントの両方をコントロールできるときに使うケースだね。各リクエストには基本的なHMAC認証が組み込まれてるよ。> できればサンドボックス化することをおすすめする。サーバーは特別な権限が必要ない標準的なバイナリだから、アクセスできるファイルやGPUの制限されたセットだけにアクセスできる、最も厳重にロックされたユーザーを作れば、うまくいくよ。これが推奨されてる。

ffmpegがsftpをサポートしてるから、sftpを探ってみたんだけど（-i sftp://...）、コードがかなりバグってて、これを変更できるようにパッチを上流に提出したいと思ってる。対照的にFTPは、少なくともコードを見た感じではかなり安定してた。FTPには他にも使いづらい欠点があったから、私のユースケースには向いてなかった。それが一つの動機で、もう一つはサーバーに入る引数を書き直す必要があるから。君が説明してるのは、基本的にffmpeg-over-ip v4（その前のバージョンも！）のことだったし、常に聞いてたフィードバックはファイルシステムを共有するのは手間がかかりすぎるってこと。WindowsやmacOSのsshサーバーは使いづらいし、みんなバンドルされたソリューションを使いたがってる。ffmpegをフォークするのは簡単じゃなかった！ビルドプロセスを理解するのに時間がかかって、最終的にはjellyfinのビルドスクリプトを使うことにしたけど、上流のHEADから数バージョン遅れてるのが難点だね。

要約すると： - クライアントがサーバーにリクエストを送る（それが双方向のネットワークソケットを開く） - サーバーはその双方向ソケットを使って、vfsのような特性を持つローカルのパッチを当てたffmpegを起動する - ffmpeg（クライアント-サーバーの双方向ソケットを使って）は、クライアントのファイルシステムをローカルのように扱いながら入出力操作を行う だから、クライアントはポートを開いたり、従来のマウント方式でファイルシステムを公開する必要がなくて、1つのサーバーが複数のクライアントのファイルシステムやリクエストを処理できるんだ。

メディアサーバーのユースケースで、ffmpegのネイティブなネットワーク機能を使って、入力をストリーミングして、そこから複数の出力（HLSを考えてみて）をストリーミングバックするのは、現時点では不可能なんだ。HTTP、FTP、SFTPにはそれぞれ制限があって、HLSのユースケースには明らかに壊れているものもあるし、他はシークストリーミングができない。vfsレイヤーを追加するためにffmpegをパッチ当てたり、コーデックやhwaccelを追加した後のビルドパイプラインを理解するのにたくさんの時間を費やす代わりに、内蔵機能を使いたかったな。将来的にはこれを変えられることを願ってる。いくつかのバグを特定したから、パッチを提出するつもりだよ。

そうだね、どんなバイナリにもパッチを適用してビルドして、ffmpegって名前にすれば、サーバーとクライアントを含めてネットワーク越しに動くよ。