[meta-freescale] [dizzy] Choppy gstreamer video (MPEG TS over UDP)
martri at arantia.com
Tue Nov 18 03:01:20 PST 2014
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
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.
More information about the meta-freescale