[FFmpeg-devel] [PATCH] lavc/decode: allow users to shrink the hw frames pool size, if they so desire.

Timo Rothenpieler timo at rothenpieler.org
Mon Nov 26 11:45:35 EET 2018

On 25/11/2018 15:05, Mark Thompson wrote:
> I see what you're trying to do here, but I'm not sure that overloading this option is the best way to achieve it.  This option has a specific meaning in terms of the consumer of the frames, and is intended to be negotiated (any consumers of hardware frames should declare how many they will hold onto at most in a given configuration), but since that is very much configuration-dependent it hasn't yet been done.  Setting it to, for example, -3 ends up saying "I want the frame pool to be large enough for the consumer to be able to hold onto at most -2 frames at any given time", which is nonsensical in the meaning of the particular option.
> Presumably the case you're actually imagining wanting this option is to reduce memory use when a stream doesn't actually use the maximum number of reference frames - given that this is generally signalled in the stream, can you instead propagate the real number of reference frames into the allocation so that it uses the correct number rather than the maximum?  Alternatively, if you have some particular program in mind then it could just use hw_frames_ctx rather than hw_device_ctx and do this allocation itself.

The case I'm targeting is that for example the CUDA yadif filter needs 
to hold onto a buffer of up to 2 frames, which it in turn steals from 
the nvdec decoders buffer. But if you don't use yadif, that's 2 unused 
frames, which is potentially quite a bit of VRAM.

nvdec already uses some logic based on the stream, but that logic is 
sometimes wrong in both directions. So the idea here is to give the user 
an option to optimize a given commandline for memory use.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4538 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20181126/b6ce9a5d/attachment.bin>

More information about the ffmpeg-devel mailing list