vc04_services: codec: Allocate the max number of buffers on the VPU

[6by9]

The VPU's API can't match the use of VIDIOC_CREATE_BUFS to add buffers to the internal pool whilst a port is enabled, therefore allocate the maximum number of buffers possible in V4L2 to avoid the issue. As these are only buffer headers, the overhead is relatively small.

@jc-kynesim. This fixes up the kernel splats in your test case.

I do still get the error

** (vidtest:1157): WARNING **: 17:02:45.336: videodecoder: 8 frames 218-225 left undrained after CMD_STOP, eos sent too early: bug in decoder -- please file a bug

after the first couple of loops. That's a funny one, but likely down in the codec rather than framework. Yet more logging required.

[6by9]

@JamesH65 from our discussion.

[pelwell]

Feedback from @jc-kynesim would be nice, but I could be persuaded to merge this now.

[6by9]

Feedback from @jc-kynesim would be nice, but I could be persuaded to merge this now.

I was waiting for the same.

...

And have just had an email from John

Further to my last reply. On a Bookworm 64-bit Pi4 with a kernel that
contains (this fix) compiling their demo with the higher bitrate
streams & multiple buffers seems to (at least to me) produce output that
is smooth. There is still spam from gstreamer to the effect of "**
(vidtest:1005): WARNING **: 16:18:16.961: videodecoder: 8 frames 783-790
left undrained after CMD_STOP, eos sent too early: bug in decoder --
please file a bug" whenever they seek but that doesn't seem to impact
playback.

Merge away.

[jc-kynesim]

Seems good to me - I am just running the exact same test I gave you, and apart from the caveat above it seems good. Doesn't break vlc either.

[6by9]

Logging it for my own info, each buffer adds 656 bytes to the allocation, so we've probably added 40kB per decode instance (~30 extra buffers on each of 2 queues). That doesn't seem to extreme to me.

[jc-kynesim]

Even if that is GPU memory (and I assume it is?) that seems completely survivable to me. I guess there may be someone somewhere running 16 decodes of tiny video but that is still only +640k which seems entirely reasonable to me.

[6by9]

It's VPU non-relocatable heap.
Memory says it's around 16MB in size, so the increase isn't at a level that I'm overly worrying about, particularly as less and less is using the firmware.