Re: [PATCH v10 0/5] Enable support for AV1 stateful decoder

[Nicolas Dufresne <nicolas.dufresne@collabora.com>]

[-- Attachment #1: Type: text/plain, Size: 3433 bytes --]

Hi Val,

Le jeudi 08 janvier 2026 à 16:25 -0300, Val Packett a écrit :
> 
> On 1/2/26 3:59 PM, Deepa Guthyappa Madivalara wrote:
> > 
> > On 1/2/2026 3:01 AM, Val Packett wrote:
> > > 
> > > On 1/2/26 7:44 AM, Bryan O'Donoghue wrote:
> > > > On 02/01/2026 10:43, Val Packett wrote:
> > > > > 
> > > > > On 12/10/25 3:59 PM, Deepa Guthyappa Madivalara wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > This patch series adds initial support for the AV1 stateful decoder
> > > > > > codecs in iris decoder. Also it adds support for AV1 stateful
> > > > > > decoder
> > > > > > in V4l2. The objective of this work is to extend the Iris decoder's
> > > > > > capabilities to handle AV1 format codec streams, including necessary
> > > > > > format handling and buffer management.
> > > > > 
> > > > > This is awesome, thanks!
> > > > > 
> > > > > I've tested it with rpi-ffmpeg as well, and it works great (only
> > > > > required one interesting logic change..
> > > > > https://github.com/jc-kynesim/rpi-ffmpeg/pull/108) \o/
> 
> 
> BTW, the rpi-ffmpeg maintainer is asking,
> 
> > for that flag_last code to trigger we have to have received an empty 
> > capture buffer, which is the legacy method of signalling EOS, so 
> > flag_last is a legitimate response. Is there something about AV1 
> > stateful that means it is legitimate to receive empty capture buffers 
> > mid stream? (grain & no-grain buffers spring to mind with an empty 
> > frame if grain isn't enabled but that is pure speculation on my part 
> > not supported by the documentation I've read). Now I'll grant that if 
> > we get an EOS signalled this way we probably shouldn't attempt to 
> > dequeue an event, but the "correct" answer of simply signalling EOS 
> > back down the chain isn't what you want either?
> 
> (`flag_last` being an internal variable for an end-of-stream condition, 
> so basically, I needed to make ffmpeg *not* interpret an empty capture 
> buffer as an end-of-stream. I never saw those with H264/H265/VP9, but 
> with AV1 one arrives after the first frame)

Just a shot in the dark here, but in the discussion about the definition of the
formats, we discussed about the lack of signalling of decode-only frames. But
for this codec, decode-only frames are wrapped with one display frame into Time
Units. So you should not hit that case if you submit TU. I'm wondering if this
empty frame isn't an effect of passing OBU Frames one by one (rather then
passing the complete TU). Can you confirm what is FFMPEG behaviour on this
regard ?

If that is correct, I think it raised back what we should do to signal decode
only buffers. Due to the legacy EOS flow (which I guess ffmpeg have supported
since day one), its not possible to just send an empty capture buffer. But at
the same time, not marking "done" any buffers makes userspace book keeping
difficult.

Not best, but currently, the only way push an empty buffer is by sending that
buffer with BUF_LAST flag (in which its pretty much the same as the old way, but
with an explicit flag) or empty buffer with an ERROR flag, which was always
allowed. The second could confuse a bit the application into thinking there was
some corruption, but with a payload of 0, it clearly means the buffer is
unusable for display, but allows for book keeping (using the timestamp cookie).

hopefully any of that can help,
Nicolas

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]