Clock / queue issue

[Sebastian Dröge]

On Do, 2015-12-24 at 10:19 +0000, David Jaggard wrote:
> 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?

That won't work as your stream is not plain MPEG-TS but MPEG-TS over
RTP AFAIU. You at least need the depayloader before the tsdemux.

This would work then but wouldn't account for packet reordering and
packet loss, and you will likely get worse results.


> >  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.

Offset how? What's the receiver of the stream you're creating there?

The RTP packets should have exactly the same timestamps, no matter if
you use sync=true or sync=false on the udpsink. However if your
receiver implements RTP wrongly (that is: it ignores RTP timestamps)
then it could get synchronization off indeed.

The only thing that the sync=false on the udpsink would do is that
packets are sent immediately when they're ready instead of waiting
until their time to be sent arrives. This would potentially cause e.g.
audio packets for time T+10s to be sent at the same time as the video
packets for time T (and that would be a problem!) but if that causes
synchronization problems then your receiver is also doing things wrong.


Did you test if outputting the streams on normal sinks instead of
sending them again over the network works as expected? There's no point
in further debugging this without knowing on which side of the pipeline
the problems are introduced.

> 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?

It would be doing both, but tsdemux might do things in a way that
causes problems here. Try outputting the stream locally and then we can
continue debugging this once we know a bit more where the problem is.

-- 
Sebastian Dröge, Centricular Ltd · http://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20151226/b2e85fde/attachment.sig>