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

[Val Packett <val@packett.cool>]

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