Clock / queue issue

[Angel Martin]

Hi,

I have posted this behavior in another post but I think it is close related
with that one:
"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."

In Gstreamer 1.4.4 the udpsink plugin with sync=true works in real-time. It
means to stream a 2 minutes video file it takes 2 minutes (like a live
source)

In Gstreamer 1.7.1 (also in 1.6.0) the udpsink plugin with sync=true works
similar to sync=false. It means to stream a 2 minutes video file it takes 5
seconds (like a on demand source)

I used the next pipelines in the different Gstreamer versions:

1) Create a sample file
gst-launch-1.0 -e videotestsrc ! video/x-raw, framerate=10/1, width=320,
height=240, format=I420 ! timeoverlay font-desc="sans bold 40" halignment=0
valignment=2 ! x264enc bitrate=200 key-int-max=10 ! h264parse
config-interval=1 ! mpegtsmux ! filesink location=test.ts

2a) Stream the file
gst-launch-1.0 filesrc location=test.ts ! tsparse ! tsdemux ! h264parse !
mpegtsmux ! rndbuffersize min=1316 max=1316 !udpsink port=5014
host=127.0.0.1 sync=true enable-last-sample=false send-duplicates=false
blocksize=1316

3a) Play the Stream
gst-launch-1.0 udpsrc uri=udp://127.0.0.1:5014 ! video/mpegts ! tsdemux
name=demux ! video/x-h264 ! queue ! decodebin ! autovideosink

I have also tried with RTP packet encapsulation (the way you are
discussing), but the problem persists:

2b) Stream the file RTP
gst-launch-1.0 -e filesrc location=test.ts ! tsparse ! tsdemux ! h264parse
! mpegtsmux ! rndbuffersize min=1316 max=1316 ! rtpmp2tpay pt=96 ! udpsink
port=5014 host=127.0.0.1 sync=true enable-last-sample=false
send-duplicates=false blocksize=1316

3b) Play the Stream RTP
gst-launch-1.0 udpsrc uri=udp://127.0.0.1:5014 caps="application/x-rtp,
media=video, clock-rate=90000, encoding-name=MP2T-ES, payload=96" !
rtpmp2tdepay ! tsdemux ! video/x-h264 ! queue ! decodebin ! autovideosink

Best,

Angel

On 26 December 2015 at 11:34, Sebastian Dröge <sebastian at centricular.com>
wrote:

> 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
>
>
> _______________________________________________
> 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: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160224/c7a2f890/attachment-0001.html>