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

[Val Packett]

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)


~val