[meta-freescale] [dizzy] Choppy gstreamer video (MPEG TS over UDP)

[Marco Trillo]

Hi Nikolay,

On 11/16/2014 12:02 AM, Nikolay Dimitrov wrote:
> Playbin was very unstable for most of my tests (either refuses to play 
> stream at all, or freezes on 1st or consequent frames). Then I started 
> to use decodebin to have more control of the pipeline, and more stable 
> results (to some minimal extent).

We have been doing extensive tests with MPEG-TS streaming over UDP and 
RTP with GStreamer 0.10, and we agree with your results.
Playbin2 is unrealible for UDP or RTP streaming. However, I don't think 
using "decodebin2" will be an improvement -- it is better to build the 
full pipeline manually.

That way you can configure your elements individually. In particular, we 
found that setting the `low-latency' property to true in `vpudec' and 
the `qos' property to false in `aiurdemux' provided better results.

Also, RTP streaming worked much better for us than raw UDP.

>
> Most, if not all of these examples are hard to be applied in my case: 
> my customer has already deployed infrastructure for the previous 
> product generation, where they use MPEG-TS transport over multicast 
> UDP, and I can't deviate from that. Also currently gstreamer-0.10 just 
> doesn't support multicast, that's why I'm testing on unicast for now, 
> and will have to fix the multicast bug soon.

gstreamer-0.10 does support multicast perfectly well: consult the 
`multicast-group' and `port' properties of `udpsrc' for more information 
(with gst-inspect).

Make sure your kernel has the multicast support enabled:
# zcat /proc/config.gz | grep -i multicast

For some reason, the default config for some kernels (linux-wandboard 
and linux-boundary IIRC) doesn't enable multicast.

>
>> Another thing, your network does matter, a lot! So start with a local
>> network or even ppp.
>
> Totally agree. I'm using Gigabit LAN, which is dedicated to this 
> development. Also, when deployed, the final product will also run on 
> dedicated network segments with dedicated media servers, so I don't 
> expect issues with that.

Yes; as said, we found the same choppy playback results and the network 
was perfectly fine. An alternative client (FFMPEG or VLC) worked fined 
at the same point.

Kind regards,
Marco.