Clock / queue issue

Thu Feb 25 12:40:43 UTC 2016

I don't think this is related to the clock issue I was having.

I wasn't able to debug my issue as Sebastian suggested but I believe it was
something to do with TSDemux. In summary the TS stream was obtained from a
live BBC broadcast and would have contained timestamps from some
synchronised source. The PC running GStreamer was not synchronised and was
free to drift. I had an rtpbin that was correcting the timestamp skew of
the rtp packets but once they hit TSDemux those rtp timestamps were
discarded in favour of the timestamps obtained from within the TS stream
itself. The skew between the TS stream and the local clock wasn't corrected
and so the pipeline slowly drifted behind the input stream. The sync option
on the UDP sink was doing its job.

The simple solution in that case was to synchronise the PC to a NTP time
source.

I did experience exactly the same issue as you are seeing when I tried to
create an artificial TS stream from a local file on the disk to test the my
pipeline. Just as you are seeing it streamed the entire file as fast as
possible. I didn't have time to look into it so I forgot about it.

On 24 February 2016 at 12:36, Angel Martin <amartin at vicomtech.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20160225/b752d3da/attachment-0001.html>