UDPSINK live stream bug

[Angel Martin]

Hi,

Let me say what I have understood from your words and more tests.

1) udpsink sync=true -> the rhythm of the throughput is performed according
to the clock from the buffers.

2) when we are re-packing packets in groups of packets for UDP, is the
resulting group timestamped only when the first packet from the group has
timestamp?

3) only the first MPEGTSMUX packet of a actual video frame has timestamps?

4) If above answers is YES, I guess that the reason is that when we are
setting min=max=1316 or alignment=7 it is more likely to have a first
packet in a group without timestamp or GST_CLOCK_NONE.

Extra tests:

This works "min=max=94 (half a MPEG-TS packet - 188)", blocksize has no
impact:
gst-launch-1.0 filesrc location=test.ts ! tsparse ! tsdemux ! h264parse !
mpegtsmux ! rndbuffersize min=94 max=94 ! udpsink port=5014 host=127.0.0.1
sync=true enable-last-sample=false send-duplicates=false blocksize=1316
But wireshark points ~140 bytes per UDP packet

This also works "min=max=188", blocksize has no impact:
gst-launch-1.0 filesrc location=test.ts ! tsparse ! tsdemux ! h264parse !
mpegtsmux ! rndbuffersize min=188 max=188 ! udpsink port=5014
host=127.0.0.1 sync=true enable-last-sample=false send-duplicates=false
blocksize=1316
But wireshark points ~230 bytes per UDP packet

This also works "alignment=1", blocksize has no impact:
gst-launch-1.0 filesrc location=test.ts ! tsparse ! tsdemux ! h264parse !
mpegtsmux alignment=1 ! udpsink port=5014 host=127.0.0.1 sync=true
enable-last-sample=false send-duplicates=false blocksize=1316
But wireshark points ~230 bytes per UDP packet

This works similar to sync=false "alignment=7" <- for UDP streaming:
GST_DEBUG=basesink:6 gst-launch-1.0 filesrc location=test.ts ! tsparse !
tsdemux ! h264parse ! mpegtsmux alignment=7 ! udpsink port=5014
host=127.0.0.1 sync=true enable-last-sample=false send-duplicates=false
blocksize=1316
The good thing is that wireshark points ~1360 bytes per UDP packet <- this
is good but not live streaming

The debug conclusion is:
gstbasesink.c never prints "do_sync 1", always "do_sync 0"
if (GST_CLOCK_TIME_IS_VALID (timestamp)) {
..
*do_sync = TRUE;

Thank you a lot for the prompt answer.

Best,

Angel

On 25 February 2016 at 10:17, Sebastian Dröge <sebastian at centricular.com>
wrote:

> On Do, 2016-02-25 at 00:29 -0800, Baby Octopus wrote:
> > I don't think thats correct. rndbuffersize used to set input
> > timestamp only for the first buffer belonging to the input buffer,
> > and rest of the buffers has GST_CLOCK_NONE as the timesstamp
> >
> > So in theory, certain 7 packets, should synchronize and this pipeline
> > should work fine
>
> It doesn't have any timestamp related code and also no changes since
> 1.4.0. If anything the adapter would copy over timestamps, but it only
> does that if the beginning of an output buffer is exactly the beginning
> of an input buffer. This is unlikely to happen and does not happen
> here.
>
> Set min=max=84 (half a MPEG-TS packet) and you'll see every second
> packet with a timestamp here.
>
>
> In any case, rndbuffersize is not meant for this. You probably want the
> alignment property on mpegtsmux (but for some reason this also does not
> result in timestamps).
>
> --
> Sebastian Dröge, Centricular Ltd · http://www.centricular.com
>
>
> _______________________________________________
> 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/6fa95a62/attachment.html>