3 台のカメラから rtsp 経由でビデオを受信しようとしています。ffmpeg の説明どおりに複数の出力で ffmpeg を使用していますが、3 つの異なる Linux プロセスを直接実行するよりも遅延がひどくなります。3 台のカメラの録画プロセスを正確に開始する ffmpeg コマンドの組み合わせを見つけることは可能ですか。
現在、次のコマンドを使用しています:
ffmpeg -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -rtsp_transport tcp -i rtsp://admin:[email protected]:554 -map 0 -vcodec copy video1.mp4 -map 1 -vcodec copy video2.mp4 -map 2 -vcodec copy video3.mp4 -y
およそ 2 秒の遅延が発生します。
また、録画中にすべてのフレームを同期させようとしていますが、異なるデバイスからのフレームの場合は不可能のようです。ビデオ間で遅延が変動するはずです...
答え1
さまざまなソースからのビデオの開始方法、相互作用、同期の維持方法 (または維持しない方法) に影響を与える要素は数多くあります。
- 3台のカメラではその通り同じフレームレート。25fpsでタイムベースが1/1000異なるだけでも、40秒ごとに1フレーム分の差が生じます。
- ストリームが「開始」するには (つまり、最初の出力画像が表示されるには)、デコーダーは最初の完全な画像 (I フレーム) を待機する必要があります。この画像に基づいて、後続の B フレームと P フレームを構築できます。この上限は GOP の長さによって決まり、ストリーミング カメラの場合は通常 1 ～ 2 秒の範囲です。I フレームはほとんどの場合、各 GOP 境界でスケジュールされるだけでなく、大幅に変更された画像コンテンツ (シーン変更時の「日和見的な」I フレーム) でもスケジュールされるため、同時に来る可能性は非常に低くなります。これは、複数の入力がある場合、最小の遅延は、異なるストリームの I フレーム間の最大時間差であることを意味します。覚えておいてください: h.264 ストリームは、設計上、特定の時点から解釈することはできず、その時点に続く最初のキーフレーム (I フレーム) からのみ解釈できます。
- 本当に正しい質問をしているのでしょうか? 入力段階をもっと早く開始し、キーフレームのみの形式にデコードして (すぐに起動できます)、再エンコードする方がよいのではないでしょうか? これが、放送業界で最小の遅延を実現する方法です。
最初の 2 つの箇条書きは、異なるプロセスが単一のプロセスよりも速く起動するように見える理由に対する答えです。各プロセスは、3 つすべてではなく、単一のキーフレームを待機する必要があります。