私は問題があります。ウェブカメラからffmpegを使用してライブストリーミングを行います。
別の端末からffmpegを起動して、このコマンドでストリーミングすると動作します。
Sudo ffmpeg -re -f video4linux2 -i /dev/video0 -fflags nobuffer -an http://localhost:8090/feed1.ffm
私の構成ファイルには、次のストリームがあります。
<Stream test.webm>
Feed feed1.ffm
Format webm
NoAudio
VideoCodec libvpx
VideoSize 720x576
VideoFrameRate 25
# Video settings
VideoCodec libvpx
VideoSize 720x576 # Video resolution
VideoFrameRate 25 # Video FPS
AVOptionVideo flags +global_header # Parameters passed to encoder
# (same as ffmpeg command-line parameters)
AVOptionVideo cpu-used 0
AVOptionVideo qmin 10
AVOptionVideo qmax 42
#AVOptionVideo quality good
PreRoll 5
StartSendOnKey
VideoBitRate 400 # Video bitrate
</Stream>
ストリームを起動します
ffplay http://192.168.1.2:8090/test.webm動作しますが、4秒の遅延があります。アプリケーションにとって不可欠なので、この遅延を最小限に抑えたいと思います。ありがとう
FFMpegのストリーミングガイドには、待ち時間を短縮する方法に関する特定のセクションがあります。まだすべての提案を試していません。 http://ffmpeg.org/trac/ffmpeg/wiki/StreamingGuide#Latency
彼らは、ffplayが導入するレイテンシーについて特別な注意を払っています:
デフォルトでは、
ffplay
は独自の小さなレイテンシを導入します。また、mplayer
は-nocache
レイテンシーのテスト用(または-benchmark
)。 SDL outを使用することは、最小限のレイテンシでフレームを表示するとも言われています:ffmpeg ... -f sdl -
ライブストリームの遅延を減らすのに役立つ3つのコマンドを見つけました。最初のコマンドは非常に基本的でわかりやすいもので、2番目のコマンドは各環境で異なる動作をする可能性のある他のオプションと組み合わせられ、最後のコマンドはドキュメントで見つけたハッキングバージョンです。最初のオプションはより安定しています。
-fflags nobuffer
を使用した基本この形式フラグは、初期入力ストリームの分析中にバッファリングによって導入される遅延を削減します。このコマンドは、顕著な遅延を減らし、オーディオのグリッチを導入しません。
ffplay -fflags nobuffer -rtsp_transport tcp rtsp://<Host>:<port>
-flags low_delay
およびその他のオプション。以前の-fflags nobuffer
フォーマットフラグを他の汎用オプションおよびより精巧なコマンドの高度なオプションと組み合わせることができます。
-flags low_delay
このコーデックジェネリックフラグは、低遅延を強制します。-framedrop
:ビデオが同期していない場合にビデオフレームをドロップします。マスタークロックがビデオに設定されていない場合、デフォルトで有効になります。このオプションを使用して、すべてのマスタークロックソースのフレームドロップを有効にします。-strict experimental
、最後に-strict
は標準に従う方法を厳密に指定し、experimental
オプションは非標準の実験的なもの、実験的な(未完成/進行中/十分にテストされていない)デコーダーとエンコーダーを許可します。このオプションはオプションであり、experimental decodersはセキュリティリスクを引き起こす可能性があることを忘れないでください。これは、信頼できない入力をデコードするためのものです。ffplay -fflags nobuffer -flags low_delay -framedrop \
-strict experimental -rtsp_transport tcp rtsp://<Host>:<port>
このコマンドは、オーディオの不具合を引き起こす可能性がありますが、めったに起こりません。
また、追加を試すこともできます:* -avioflags direct
はバッファリングを削減し、* -fflags discardcorrupt
は破損したパケットを破棄しますが、非常に積極的なアプローチだと思います。 これにより、オーディオとビデオの同期が壊れる可能性があります
ffplay -fflags nobuffer -fflags discardcorrupt -flags low_delay \
-framedrop -avioflags direct -rtsp_transport tcp rtsp://<Host>:<port>
これは、-probesize
および-analyzeduration
を低い値に設定して、ストリームをより速く起動できるようにすることに基づくデバッグソリューションです。
-probesize 32
は、調査サイズをバイト単位で設定します(つまり、ストリーム情報を取得するために分析するデータのサイズ)。値を大きくすると、ストリームに分散している場合により多くの情報を検出できますが、待ち時間が長くなります。 32以上の整数である必要があります。デフォルトでは5000000です。analyzeduration 0
は、入力をプローブするために分析されるマイクロ秒数を指定します。値を大きくすると、より正確な情報を検出できますが、待ち時間が長くなります。デフォルトは5000000マイクロ秒(5秒)です。-sync ext
は、マスタークロックを外部ソースに設定して、リアルタイムを維持しようとします。デフォルトは音声です。マスタークロックは、オーディオとビデオの同期を制御するために使用されます。つまり、このオプションは、オーディオとビデオの同期をタイプに設定します(つまり、type = audio/video/ext)。ffplay -probesize 32 -analyzeduration 0 -sync ext -rtsp_transport tcp rtsp://<Host>:<port>
このコマンドにより、オーディオの不具合が発生する場合があります。
-rtsp_transport
は、ストリーミングに応じてudp
またはtcp
として設定できます。この例では、tcp
を使用しています。
flags
のAVFormatContext
をAVFMT_FLAG_NOBUFFER | AVFMT_FLAG_FLUSH_PACKETS
に設定してみてください
AVFormatContext *ctx;
...
ctx->flags = AVFMT_FLAG_NOBUFFER | AVFMT_FLAG_FLUSH_PACKETS;
次に、デコーダースレッドを1に設定してみてください。スレッドが増えると、レイテンシが長くなるようです。
AVCodecContext *ctx;
...
ctx->thread_count = 1;