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.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
