Re: [dizzy] Choppy gstreamer video (MPEG TS over UDP)

[Nikolay Dimitrov <picmaster@mail.bg>]

Hi Marco,

On 11/19/2014 09:36 AM, Marco Trillo wrote:
> Hi,
>
> On 11/18/2014 04:06 PM, Nikolay Dimitrov wrote:
>>> 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.
>
> One small correction: the `qos' property belongs to the video sink (we
> are using `mfw_v4lsink'), not to `aiurdemux' as I said in my first
> e-mail...

Thanks for the clarification.

> Regarding the time-to-first-frame you mention, we are also running in a
> big show-stopper issue with `aiurdemux': depending on the number of PIDs
> present in the program table -- for example if the program contains
> subtitles or multiple audio streams --, the demuxer takes a long, long
> time to provide the pads. Only in relatively simple programs (one audio
> and one video PID) the demuxer seems to behave right.

Well, I actually ditched aiurdemux and started using the latest
Fluendo's MPEG TS demuxer. I can't say with confidence that it's the 
best solution, but at least it allows me to go forward.

I personally think that the amount of available programs and elementary
streams in the MPEG TS is not an issue at all. The PAT is transmitted
regularly (at most on 140ms), in order to reduce the "time to 1st
acquisition". Also PMTs are sent regularly. The problem is actually how
the control packets trigger the additional demuxer logic.

For example, I noticed is that the Fluendo MPEG TS demuxer rely for
some reason on the regular update of PAT/PMT/CAT tables with the
current_next_indicator bit. The streams I have access to doesn't update
this bit regularly (if at all), that's why the demuxer waits
practically for inifinity before demuxing packets. What I did as an
experiment was to force the parsing of PAT/PMT/CAT table disregarding
this update bit, and suddenly the demuxer started to work quickly.

> It is quite possible this is not an issue for you if you control the
> source stream. In any case, more information is available at:
> <https://community.freescale.com/thread/324048>

Thanks, this was definitely useful info, and a very good remark -
mapping tables just describe relations between children and parent
logical streams, but packets of the actual streams (including PMT) can
start to arrive much later, so the demuxer should always work with
whatever is available *now*, not after 15min when the user is dead from
boredom :D.

In the end, I still have issues with the Gstreamer pipeline stability
with network streams - it sometimes freezes either for a while (1-3s),
or fully, begging for Ctrl-C. I plan to look at whether some of the
pipeline elements are mutually blocking each other, causing a deadlock.

Kind regards,
Nikolay

PS: Please forgive me if someone feels this is going too off-topic.