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

[Nikolay Dimitrov]

Hi Marco,

On 11/18/2014 01:01 PM, Marco Trillo wrote:
> 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.

Yes. I went to use decodebin just to be able to force the usage of
udpsrc in multicast mode, because I was not sure what was actually
happening inside playbin2. But tend to agree that custom pipelines (and
even C-application) are the way to go.

> 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.

"low-latency" definitely lowers the time to display 1st frame (< 1s),
but need to test whether it affects long-term stability. Hope to be
able to test soon "qos" property.

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

It's quite possible. Unfortunately, RTP this is not an option for me at
the moment.

>> 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.

Yep, I also found this out the hard way. After enabling the
CONFIG_IP_MULTICAST it's much better now. I can't remember exactly what
was the error message I saw several days ago, but it was something like:

"added **something**: -1, Not found"

So this is why I said that the multicast didn't worked out of the box.
Obviously, I wasn't right and now it works. But I can't reproduce this
error message anymore.

>>> 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.

Same here, tests performed with ffmpeg & vlc on x86 machines showed
that at least the TS stream and LAN network were OK.

Regards,
Nikolay