High CPU usage decoding 4K 60fps video

[Tim-Philipp Müller]

On Tue, 2022-07-26 at 09:36 +0200, Sergio González via gstreamer-devel
wrote:

Hi Sergio,

> 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.

How do you feed buffers into appsrc? Time-based (e.g. 60 buffers per
second) or as fast as possible?

appsink has an unlimited queue internally, so if you feed buffers as
fast as possible on the source side, nothing will throttle the decoding
until you run out of memory. You can set appsink max-buffers=5 or so to
work around that.

Do you force video conversion after the decoder (via caps on the
appsink) that you don't get in a playback pipeline?

Do you put proper timestamps on the buffers you push into appsrc, or
how is the data timestamped?


> 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.

That sounds like the appsrc/sink pipeline is decoding at a slower rate
than realtime? (But at the same time using much more cpu?)

> Do you have some insight on what might cause this? Maybe I am missing
> some property in some of the components?

There are properties on avdec_h265 that you can play with, like thread-
type=slice or max-threads=X but if the defaults are used in both cases
that doesn't really explain the difference in behaviour.

Cheers
 Tim

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20220726/95d4fab5/attachment-0001.htm>