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

[Clément Péron]

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.

After browsing there is some custom implem for decklink and the
side_data timecode.
Which do exactly the same thing,
https://github.com/FFmpeg/FFmpeg/blob/master/libavdevice/decklink_dec.cpp#L1351-L1359

I will respin this series without this patch and start a dedicated
thread about this issue.

Thanks,