From cb3453eb25e249b7c428badd24d8dbcfc74ec3e7 Mon Sep 17 00:00:00 2001 From: Timo Rothenpieler Date: Thu, 15 Jun 2023 00:45:44 +0200 Subject: [PATCH] Revert "avcodec/nvenc: fix b-frame DTS behavior with fractional framerates" This reverts commit 9a245bdf5d7860b8bc5e5c21a105a075925b719a. This commit basically broke all samples with fractional framerates, rather than fixing them. I at this point do not understand the original issue anymore, and I'm not sure how this slipped my initial testing. All my test samples must have happened to have a simple timebase. The actual dts values pretty much always are just a simple chain of 1,2,3,4,5,... Or maybe slightly bigger steps. Each increase by one means an advance in time by one unit of the timebase. So a fractional framerate/timebase is already not an issue. So with this patch applied, the calculation might end up substracting huge values (1001 is a common one) from the dts, which would be an offset of that many frames, not of that many fractions of a second. This broke at least muxing into mp4, if the sample happened to have a fractional framerate. I do not thing the original issue this patch tried to fix existed in the first place, so it can be reverted without further consequences. --- libavcodec/nvenc.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c index 50a4fa6f69..9acf3e8697 100644 --- a/libavcodec/nvenc.c +++ b/libavcodec/nvenc.c @@ -2266,8 +2266,7 @@ static int nvenc_set_timestamp(AVCodecContext *avctx, dts = reorder_queue_dequeue(ctx->reorder_queue, avctx, pkt); if (avctx->codec_descriptor->props & AV_CODEC_PROP_REORDER) { - pkt->dts = dts - - FFMAX(ctx->encode_config.frameIntervalP - 1, 0) * FFMAX(avctx->ticks_per_frame, 1) * FFMAX(avctx->time_base.num, 1); + pkt->dts = dts - FFMAX(ctx->encode_config.frameIntervalP - 1, 0) * FFMAX(avctx->ticks_per_frame, 1); } else { pkt->dts = pkt->pts; }