High CPU usage decoding 4K 60fps video

[Michiel Konstapel]

On 26-07-2022 09:36, Sergio González via gstreamer-devel wrote:
> Dear All,
>
> I am having an issue when using gstreamer to decode 4K 60fps video in 
> a custom app.
>
> The pipeline's structure is as follows:
>
> appsrc ! queue ! typefind ! h265parse ! capsfilter ! avdec_h265 ! 
> queue ! videoconvert ! queue ! appsink
>
> What I am observing is that when I push buffers to the appsrc, if the 
> decoding components are linked, there is a high surge of CPU 
> consumption (as in, 12 of the 16 cores are at 100%). However, if on 
> the same machine I just execute the same pipeline with gst-launch, the 
> cpu usage is way more reasonable and the decoding goes smoothly.
>
> Adding a Probe to the sink and the source pads of the avdec_h265 tells 
> me that the time between decoding buffers at the beginning is of about 
> 200ms, but as app keeps decoding, it soon reaches 600ms.
>
> Do you have some insight on what might cause this? Maybe I am missing 
> some property in some of the components?
>
> Any help would be much appreciated. Let me know if you need any more 
> information.
>
> Cheers,
> Sergio


When running with gst-launch, what source do you use? One difference 
might be how you are feeding data to the appsrc. It might also help to 
increase the queue sizes, especially after the decoder; a 4K raw video 
frame will be larger than the default queue max-size-bytes 
<https://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer-plugins/html/gstreamer-plugins-queue.html#GstQueue--max-size-bytes> 
so it will only hold one frame. I would set it to zero so it's only 
limited by time and buffers, so you get some more concurrency in the 
pipeline. However, that doesn't explain the difference between your two 
cases; when running from the command line the queue would be just as big.

HTH,
Michiel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220726/f4db3c5f/attachment.htm>