On 22.02.2021 12:20, Ricardo Monteiro wrote:
Hi Timo,Thank you for your reply! The main intention of this patch is to allow FFmpeg to respect the presets that are available. Without this patch if for example one of our users wants to use preset p5 for example, FFmpeg will not allow it to use B frames. The preset would only be respected if the user also specified "-bf 3" in addition to the preset. In nvenc.c the ctx->encode_config.frameIntervalP is configured based on the number of B frames, which is loaded through the selected preset. If the user wants to use a certain preset and specify a different number of B frames, he can use -bf to do so. However, since we are checking for avctx->max_b_frames >= 0 and this value is initialized to 0 (in nvenc_h264/ nvenc_hevc) this means that ctx->encode_config.frameIntervalP will be overwritten with avctx->max_b_frames + 1, i.e. 1, every time. This basically sets the number of B frames to 0 for every preset. With the patch the respective number of B frames for each preset is respected and it can also be overwritten using -bf if the user wants to do so.
Yes, no objections there. I was purely referring to the first hunk of the patch:
- if (avctx->max_b_frames >= 0) {
+ if (avctx->max_b_frames > -1) {
Which does not actually change the logic at all. Changing the default for "bf" from 0 to -1 should be enough. On that note, I applied the patch without said no-op logic change. Thanks for bringing this to attention, seems to be some very old oversight.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
