Video decoder performance and QoS

[Bruce Tsai]

Thanks for the QoS opinion.
I found enlarging queue size could fit my needs and I will improve from this direction.

I also took a look at “playsink”.
The function “gen_video_chain” creates a queue for video samples and set “max-size-buffers” to 3.
And “gen_audio_chain” does not set any limits on audio queue.
I think “max-size-buffers=3” is too small for video samples.

--
Yi-Lung (Bruce) Tsai
wagamama.tsai at gmail.com





> On Jan 6, 2017, at 5:53 PM, Tim Müller <tim at centricular.com> wrote:
> 
> 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
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20170110/c6cc1a32/attachment.html>