poor playback of MPEG-TS-over-UDP stream

[Mark Howell]

On 02/04/2016 03:59 PM, Tim Müller wrote:
> On Thu, 2016-02-04 at 14:16 -0700, Mark Howell wrote:
>
> Hi Mark,
>
>> I'm working with a network video widget that provides
>> H.264-on-MPEG-TS-on-UDP. I'm having a hard time getting reliable
>> clean
>> decode and display of the video with low latency.
>>
>> Using GStreamer 1.6.3 on Linux.
>>
>> This pipeline works fine, plays back with reasonable latency and
>> without
>> drops or glitches at 30 fps:
>>
>> $ gst-launch-1.0 -v udpsrc port=15004 ! video/mpegts ! tsdemux !
>> h264parse ! avdec_h264 ! fpsdisplaysink sync=false
> Right, this (sync=false) basically disables timestamp and latency
> handling at the sink, so everything is just processed and displayed as
> fast as possible.
>
> Which will probably be "ok" generally speaking, since the sender sends
> video in real-time, but the video frames will not be timed correctly
> according to their original timing, so there might be significant
> amount of jitter. It might look smoothest, but it's probably far from
> perfect.
>
> drops or glitches most likely happen either because packets got lost
> (or re-ordered) between sender and receiver, or because the default
> size of the kernel-side udp buffer is rather small, and we're not
> always reading the data out fast enough, in which case packets will be
> dropped when the udp receive buffer overflows.
>
> You can play with the buffer-size=N property of udpsrc, and you can
> change the max allowed sizes for receive/send buffer like this (for
> example):
>
>    sudo /sbin/sysctl -w net.core.rmem_max=33554432
>    sudo /sbin/sysctl -w net.core.wmem_max=33554432
>

Thanks Tim, this was the key, had to both set a larger buffer-size in 
the udpsrc *and* poke the Linux kernel to allow it.

I ended up using your kernel poke cmds as above (for 32 MiB buffers) and 
a udpsrc buffer-size param of 16 MiB. I thought this was larger than 
would seem necessary for a 10 Mbps stream, but 4+ MiB is what got best 
results.

Also left my 50 ms tsdemux latency patch in place for now; that might 
get a minor tweak yet, but 700 ms is too long.

End-to-end playback latency is pretty much what I hoped now, with 
tolerable jitter.

Cheers,

Mark.