Clock / queue issue

[David Jaggard]

Thank you Sebastian,


On 24 December 2015 at 08:40, Sebastian Dröge <sebastian at centricular.com>
wrote:

>
> By not using MPEG-TS we could at least check if the problem is because
> of MPEG-TS or a generic problem.
>
> The hardware in this case will only stream MPEG-TS. I'm wondering if using
a pipeline like udpsrc -> tsdemux -> h264parse -> rtph264pay -> udpsink
[sync = false] (and similar for audio) would be a valid way to convert it
to rtp without affecting the timestamps (as there is no jitter buffer and
no synchronization at the sink) and I could then pipe these streams into
the transcoder for testing. Do you think this would be valid?



> No, because udpsink is going to sync the buffers to the clock before
> sending them. This prevents in the normal case that buffers are sent
> faster than real-time. For your case (where the input is only provided
> in real-time anyway), you could also try setting sync=false on the
> udpsinks but in general that's not recommended and it would be better
> to find the underlying problem here.
>
> I have to have sync=true on the sinks otherwise the video and audio
streams would be offset.

Do you suspect that the buffer timestamps downstream of tsdemux are derived
from the MPEG-TS stream and without taking any consideration of the
compensation performed by the jitter buffer?





> --
> Sebastian Dröge, Centricular Ltd · http://www.centricular.com
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151224/d0208b6b/attachment.html>