Video decoder performance and QoS

[Tim Müller]

Hi,

> >  ... ! fpsdisplaysink text-overlay=false video-sink="fakesink
> > sync=true
> > max-lateness=20000000"
> > 
> 
> In this case, average fps could also exceed 30 to the end. 
> > 
> > 
> >  ... ! fpsdisplaysink text-overlay=false video-sink="fakesink
> > sync=true
> > max-lateness=20000000 qos=true"
> > 
> 
> In this case, the measure result is unstable.
> Sometimes average fps ranges from 27 to 30.
> But sometimes average fps is down to around 20. 
> > (^^^ like above but syncing to the clock and configure more like a
> > videosink, with QoS enabled)
> > 
> > 
> Here is also an interesting found.
> In case 3 above, there is no help if the "max-size-buffers" of queue
> between decoder and video sink is set to 60.
> But in my real playback pipeline, average fps would be 29.8~30.1 if
> "max-size-buffers" is set to 60 as well.

Mind that the lowest max-* limit wins, so if you decode an large video
then the byte size might easily kick in (e.g. 10MB =~ a few frames @
1080p).

I don't know why it would behave differently though.

It might also be interesting to look at what QoS events basesink sends
exactly - how much frames are late, etc.


> According to testing results with "fakesink" above, the key point
> would be QoS.
> However, in my real playback, enlarging max size of queue seems an
> option to get better performance.

A queue between decoder and videosink is certainly a good idea.


> Is turning QoS a good option?

It depends a bit on your device/environment. The goal is to recover
when decoding/rendering are too slow for a short time for some reason.
If you don't need that then you can disable QoS of course. The sink
will still throw away and not render buffers that are way too late in
that case.

Cheers
 -Tim

-- 
Tim Müller, Centricular Ltd - http://www.centricular.com