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

Timo Rothenpieler timo at rothenpieler.org
Mon Dec 2 14:02:07 EET 2024


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.


More information about the ffmpeg-devel mailing list