[FFmpeg-devel] [PATCH v2 3/3] avcodec/cuvid: introduce a ringbuffer to reattach additional data

[Hendrik Leppkes]

On Tue, Dec 3, 2024 at 12:54 PM Clément Péron <peron.clem at gmail.com> wrote:
>
> On Mon, 2 Dec 2024 at 13:01, Timo Rothenpieler <timo at rothenpieler.org> wrote:
> >
> > On 02/12/2024 12:03, Clément Péron wrote:
> > > Hi Timo,
> > >
> > > I try to look deeper into this and compare it with others codec.
> > > And I'm not 100% sure why only cuviddec, dav1d and xevd set this flag
> > > "FF_CODEC_CAP_SETS_FRAME_PROPS"
> > > I would expect also nvdec to set this, as by design the hardware could
> > > buffer multiple packets and when the decoded frame is retrieve the
> > > "avctx->internal->last_pkt_props" sync is not guarantee.
> > >
> > > I think we could simplify this patch a bit, reusing the FFmpeg ObjPool.
> > > But I don't see how we could avoid this packet<->frame sync?
> > >
> > > Maybe we could try to move it out of the cuviddec,
> > > So all this stuff should go in the decode.c and we should use this
> > > pool buffer instead of only using the avctx->internal->last_pkt_props.
> > >
> > > As it could also impact other codec, is there some FFMpeg Maintainers
> > > architect / maintainers feedback on this?
> > >
> > > Thanks,
> >
> > I don't quite understand why you are so insistent on adding it to
> > cuviddec at all.
> > This decoder is just barely not deprecated.
> >
> > If the native decoders and in turn the various hwaccels, including
> > nvdec, don't support it, adding it there would be a much easier solution
> > that adds support for a lot more hardware all at once.
> > Most likely you won't even need to touch any hardware specific code.
>
> I'm open to other suggestions and would be glad to find a solution
> that works for all hardware decoders.
>

The real question is, why are you using cuviddec instead of nvdec?
side data would already pass through natively with nvdec, and other
hwaccel-based decoders.

- Hendrik