Sync=true Adding 6 seconds latency

[Eric-Stone]

>You should describe what you are doing. I see in your code that you 
>play with pipeline base time, could be your error. Latency depends on 
>elements you place in your pipeline.

Thanks for the feedback everyone.

What I did was run playbin at my rtmp endpoint, and used that to create a
dot file. Then I built a new pipeline off of the elements listed in that dot
file and switched things around to find out where the latency was occurring.
This left me with the command:

gst-launch-1.0 rtmpsrc location=rtmp://my-url-here ! flvdemux ! queue !
h264parse ! avdec_h264 ! videoconvert ! autovideosink

This has very low latency, but only plays in "bursts" where the video stalls
while waiting on the next packets to arrive. I think this is because it's
playing the video as fast as possible without any buffer. To remedy this, I
added a queue of 1 second, leaving me with the command:

gst-launch-1.0 rtmpsrc location=rtmp://my-url-here ! flvdemux ! queue
min-threshold-time=1000000000 max-size-buffers=0 max-size-time=0
max-size-bytes=0 ! h264parse ! avdec_h264 ! videoconvert ! autovideosink

This plays back somewhat smoothly, but not as smoothly as ffplay. I think
this is because I'm just making a queue of the packets instead of an actual
jitterbuffer.

Would anyone happen to know if it's possible to use rtpjitterbuffer with an
rtmp stream? Or are there any alternatives that might be able to smooth the
playback of this stream?



--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/Sync-true-Adding-6-seconds-latency-tp4680232p4680302.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.