私はここにすでに持っているRPIとカメラモジュールを使って、私のニーズに合った完璧なモバイルウェブカメラを作成しようとしています。私はRPIと「クライアント」として使用するノートブックでArchを実行しています。カメラが実行中で、raspividデータをどこかでパイプでき、前後にSSH経由で接続できます。
これで、ローカルネットワークを介して転送しようとしています。理想的には、RPIで「サーバー」スクリプトを起動し、サーバーを再びシャットダウンすることを決定するまで、必要なだけ多くのクライアントを接続できます。そして理想的には、別々のデバイスを持ち、ワイヤレスで送信するのにかかる待ち時間はほとんど検出できないので、ビデオとオーディオを補償して同期しようとする必要はありません。だから私が理解したのはVLCを使うことは不可能です。また、理想的には、「クライアント」がストリームを使用可能にするか、/dev/video1別の方法で提供することをお勧めします。しかし、現在はOBSに入れたいです。何とか。
これまでにいくつかのチュートリアル、特に関連チュートリアルを試してみましたnetcatが、クライアントでストリームを再生できない場合は、プロセスがすぐに停止または切断されました。
どこを見なければならないのか、どのように計画すべきかについてのアドバイスはありますか？動的クライアントの切断を実装するためにメディアサーバーなどを使用しようとしましたが、非常に軽くなければなりません。
ベストアンサー1
ビデオをストリーミングするには、ビデオストリーミング用に設計されたプロトコルを使用します。これはUDPとマルチキャストを意味するので、必要なだけ多くのクライアントを接続できます。 TCPとユニキャストを使用すると、接続が切断されると停止します。
これらのプロトコルが存在します。RTTP、次のサーバー実装が存在します。アイス放送。 「超軽量」ではありませんが、RaspPiで正常に動作します。
いいえ、ストリームが欲しくありません/dev/video1。代わりに、マルチキャストグループに正しく接続し、ネットワークからストリームを読み取ることができるクライアントを使用する必要があります。
VLCについて何を知っていて、なぜ不可能なのかわかりませんが、VLC（および他のほとんどのビデオプレーヤー）はRTSPストリーミングクライアントとしてうまく機能し、同期している場合はビデオとオーディオの同期に問題がないはずです。ストリーミング（ここでできる問題が発生するかどうかは、ハードウェアがRaspPiにどのように接続されているかによって異なりますが、最初はオーディオソースに言及していません。
編集する
ffmpegミニマリズムに固執するなら小川いくつかの方法がありますが、関連するプロトコル、違い、必要なコマンドラインオプションを理解するのに時間を費やす必要があります。
編集する
まあ、私はビデオを見ました（少なくとも最初はVLCと遅延のためにビデオを見るのが特に好きではありません）。
確かに適切なエンコード方式を使用すると、待ち時間が多く発生します。効果的にエンコードするにはかなりの数のフレームが必要です（そして、デコードにも同じ数のフレームが必要です）。何よりも、何も失われないように多くのバッファリングを実行します。
楽しみながらffmpegマルチキャストグループでRTPを試してみましたが、待ち時間も多く発生しました（H264の場合は約1～2秒、追加待ち時間追加ffplay）。待ち時間を減らすことはそれ自体科学であり、多くのオプションを見て、それについて読む必要があります。しかし、遅延は問題を示すものではなく、むしろその逆です。
したがって、待ち時間が絶対に低くなければならない場合は、圧縮、画像サイズ、エンコード品質、および帯域幅を考慮する必要があります。何も役に立たない場合は、エンコード手順を削除してください。