Streaming von RTP / RTSP: Synchronisierungs- / Zeitstempelprobleme

Ich habe Probleme beim Streaming von H.264-Videos über RTSP. Das Ziel ist es, ein Kamerabild live auf einen RTSP-Client zu streamen (am Ende idealerweise ein Browser-Plugin). Dies hat bisher ziemlich gut funktioniert, mit Ausnahme eines Problems: Das Video wird beim Start verzögert, stottert alle paar Sekunden und hat eine Verzögerung von ~ 4 Sekunden. Das ist schlecht.

Unser Setup ist es, mit x264 (w / zerolatency & ultraschnell) zu codieren und mit libavformat von ffmpeg 0.6.5 in RTSP / RTP zu packen. Zum Testen erhalte ich den Stream mit einer GStreamer-Pipeline mit gst-launch, wenn eine Verbindung zu einem RTSP-Server hergestellt wird.jedochIch konnte das gleiche Problem reproduzieren, wenn ich direkt von einer anderen GStreamer-Instanz mit nur RTP gestreamt habe.

Sendemaschine:

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

Empfangsmaschine:

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

Sie können diese beiden auch auf demselben Computer ausführen. Ändern Sie einfach den Host auf 127.0.0.1 auf dem Absender. Auf der Empfangsseite sollten Sie stotternde und im Allgemeinen schlecht funktionierende Videos sowie wiederholte Warnungen auf der Konsole bemerken:

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.

Eine häufig vorgeschlagene "Lösung", die ich im ganzen Internet gesehen habe, ist die Verwendungsync=false mit xvimagesink:

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

Das Video wird dann mit einer Latenz von nahezu Null wiedergegeben, selbst wenn es mit unserer Kamerasoftware getestet wurde. Dies ist nützlich zum Testen, aber nicht sehr nützlich für die Bereitstellung, da es nicht mit Totem, VLC oder deren eingebetteten Browser-Plugins funktioniert.

Ich möchte versuchen, das Problem an der Quelle zu lösen. Ich bin misstrauisch, dass im H.264-Stream von x264 oder möglicherweise in den RTP-Payloads eine Art Zeitstempelinformation fehlt. Gibt es eine Möglichkeit, das zu ändern?Quelle gst pipeline damit ich machenicht verwenden müssensync=false auf dem empfänger?

Wenn dies nicht möglich ist, wie kann ich Clients (über SDP oder auf andere Weise) mitteilen, dass der Stream nicht synchronisiert werden soll? Letztendlich haben wir dies mit einer Art VLC-Plugin in den Browser eingebettet, sodass eine Lösung, die dort funktionieren würde, noch besser wäre.

Antworten auf die Frage(3)

Ihre Antwort auf die Frage