From: Marco Trillo <martri@arantia.com>
To: Nikolay Dimitrov <picmaster@mail.bg>
Cc: "meta-freescale@yoctoproject.org" <meta-freescale@yoctoproject.org>
Subject: Re: [dizzy] Choppy gstreamer video (MPEG TS over UDP)
Date: Tue, 18 Nov 2014 12:01:20 +0100 [thread overview]
Message-ID: <546B2700.2020300@arantia.com> (raw)
In-Reply-To: <5467DB7F.1000604@mail.bg>
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.
next prev parent reply other threads:[~2014-11-18 11:07 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-14 18:46 [dizzy] Choppy gstreamer video (MPEG TS over UDP) Nikolay Dimitrov
2014-11-14 20:25 ` Daiane Angolini
2014-11-15 23:02 ` Nikolay Dimitrov
2014-11-16 18:29 ` Daiane Angolini
2014-11-18 11:01 ` Marco Trillo [this message]
2014-11-18 15:06 ` Nikolay Dimitrov
2014-11-19 7:36 ` Marco Trillo
2014-11-19 21:45 ` Nikolay Dimitrov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=546B2700.2020300@arantia.com \
--to=martri@arantia.com \
--cc=meta-freescale@yoctoproject.org \
--cc=picmaster@mail.bg \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.