ストリーミングRTP/RTSP：同期/タイムスタンプの問題

Question

私はRTSP上でH.264ビデオをストリーミングいくつかの問題を抱えています。目標は、RTSPクライアント（理想的にはブラウザプラグインの最後）にカメラ画像をライブストリーミングすることです。ビデオは数秒ごとに吃音、起動時に遅れる、と〜4秒の遅延があります。これは、1つの問題を除いて、これまでのところ非常にうまく働いています。これは悪いです。

設定はx264（w/zerolatency & ultrafast）でエンコードし、ffmpeg 0.6.5のlibavformatを使用してRTSP/RTPにパックすることです。テストのために、RTSPサーバーに接続するときにgst-launchを使用してストリームをGStreamerパイプラインで受信しています。しかしは、私はRTPを持つ別のGStreamerインスタンスから直接ストリーミングするときに、同じ問題を再現することができました。

送信機：

gst-launch videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=10.89.6.3 

受信機は：

gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink 

また、送信者だけに127.0.0.1にホストを変更するには、同じマシン上で両方これらを実行することができます。受信側では、コンソール上の繰り返し警告とともに、吃音と一般的に悪い行い映像に気づくはずです。私はすべてインターネット上で見てきた

WARNING: from element /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: A lot of buffers are being dropped. 
Additional debug info: 
gstbasesink.c(2875): gst_base_sink_is_too_late(): /GstPipeline:pipeline0/GstXvImageSink:xvimagesink0: 
There may be a timestamping problem, or this computer is too slow. 

1つの一般的-提案「修正」を使用することですxvimagesinkとsync=false：

gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink sync=false 

ビデオは、私たちのカメラのソフトウェアをテストした場合でも、ほぼゼロレイテンシで再生されます。これは、テストのために有用であるが、それはトーテム、VLCでは動作しませんよう、展開のために非常に有用ではない、または、ブラウザのプラグインが組み込まれています。

私はソースで問題を解決しようとしたいと思います。私は、何らかの種類のタイムスタンプ情報がH.264ストリームでx264で欠落しているか、おそらくRTPペイロード上に存在していないか疑いがあります。私ははないが受信機にsync=falseを使用する必要がないようにソース GSTパイプラインを変更する方法はありますか？

これが不可能な場合、クライアントに（SDPなどを介して）ストリームに同期させないように伝えるにはどうすればよいですか？最終的には、VLCプラグインを使用してブラウザに埋め込みますので、そこで動作するソリューションはさらに優れています。

Answer 1

"sync = false"をソースgstパイプラインに追加できます。 Ubuntu 12.04では、遅れやエラーメッセージが取り除かれているようです。ここで

は、私はソースに使用するコマンドです：

gst-launch videotestsrc ! x264enc tune=zerolatency ! rtph264pay ! udpsink host=127.0.0.1 sync=false 

、ここでは、私が受信機で使用されるものです：

gst-launch udpsrc ! application/x-rtp,payload=96 ! rtph264depay ! decodebin ! xvimagesink 

は残念ながら、私はそれが動作するかさえコンポーネント理由はわかりません"sync = false"プロパティは（ソースパイプライン上に）属します。

Answer 2

root.ctrlcが送信されたので、sync = FALSEを使用できます。ただし、送信者側のCPU使用量が大幅に増加することがあります。その理由は、sync = FALSEは、シンクにバッファを受け取るとすぐにバッファをプッシュするように指示するためです。シンクはパイプライン全体を駆動します。したがって、sync = FALSEを指定すると、パイプラインはビデオをエンコードし、可能な限り高速にUDPにプッシュします。 100％CPUを使用します。

必要なものはgstrtpjitterbufferです。ここで壊れているタイムスタンプも処理します。

例の送信者：

gst-launch-0.10 -v videotestsrc ! videorate ! video/x-raw-yuv, framerate=30/1 ! ffmpegcolorspace ! x264enc ! rtph264pay ! udpsink port=50000 host=<sender IP> 

例の受信機：

gst-launch-0.10 udpsrc port=50000 caps="application/x-rtp, media=(string)video, clock-rate=(int)90000 , encoding-name=(string)H264 , payload=(int)96" ! gstrtpjitterbuffer ! rtph264depay ! ffdec_h264 ! ffmpegcolorspace ! videoscale ! "video/x-raw-yuv, width=320, height=240" ! xvimagesink 

Answer 3

私はこれが本当どのくらいあるかわからないが、私は私のラップトップにバッテリー充電器を接続せずに私のパイプラインを実行すると、それは私に同じ警告を投げていました、そして、私が電源を差し込んだとき、私はそれが働いたと信じていました。私はそれがあるべきであるように動作していない古いCMOSバッテリーのためかもしれないと思う。クロック生成を担当するためです。