From: Timo Rothenpieler <timo@rothenpieler.org> To: ffmpeg-devel@ffmpeg.org Subject: Re: [FFmpeg-devel] [PATCH] avcodec/cuviddec: correctly handle buffer size and status when deinterlacing Date: Wed, 26 Feb 2025 20:58:46 +0100 Message-ID: <382f8ebd-2088-48a9-9bb6-a71477839a8b@rothenpieler.org> (raw) In-Reply-To: <ca0e1abe-bb90-4680-9333-a950c73fbe2d@gmail.com> On 26.02.2025 03:42, Scott Theisen wrote: > On 2/25/25 13:43, Timo Rothenpieler wrote: >> --- >> libavcodec/cuviddec.c | 24 +++++++++++++----------- >> 1 file changed, 13 insertions(+), 11 deletions(-) >> >> diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c >> index 67076a1752..312742fb8c 100644 >> --- a/libavcodec/cuviddec.c >> +++ b/libavcodec/cuviddec.c >> @@ -131,7 +131,7 @@ static int CUDAAPI >> cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form >> CUVIDDECODECREATEINFO cuinfo; >> int surface_fmt; >> int chroma_444; >> - int fifo_size_inc; >> + int old_nb_surfaces, fifo_size_inc, fifo_size_mul = 1; >> int old_width = avctx->width; >> int old_height = avctx->height; >> @@ -349,20 +349,24 @@ static int CUDAAPI >> cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form >> return 0; >> } >> - fifo_size_inc = ctx->nb_surfaces; >> - ctx->nb_surfaces = FFMAX(ctx->nb_surfaces, format- >> >min_num_decode_surfaces + 3); >> + if (ctx->deint_mode_current != cudaVideoDeinterlaceMode_Weave >> && !ctx->drop_second_field) { >> + avctx->framerate = av_mul_q(avctx->framerate, (AVRational){2, >> 1}); >> + fifo_size_mul = 2; >> + } >> + old_nb_surfaces = ctx->nb_surfaces; >> + ctx->nb_surfaces = FFMAX(ctx->nb_surfaces, format- >> >min_num_decode_surfaces + 3); >> if (avctx->extra_hw_frames > 0) >> ctx->nb_surfaces += avctx->extra_hw_frames; >> - fifo_size_inc = ctx->nb_surfaces - fifo_size_inc; >> + fifo_size_inc = ctx->nb_surfaces * fifo_size_mul - >> av_fifo_can_read(ctx->frame_queue) - av_fifo_can_write(ctx->frame_queue); >> if (fifo_size_inc > 0 && av_fifo_grow2(ctx->frame_queue, >> fifo_size_inc) < 0) { >> av_log(avctx, AV_LOG_ERROR, "Failed to grow frame queue on >> video sequence callback\n"); >> ctx->internal_error = AVERROR(ENOMEM); >> return 0; >> } >> - if (fifo_size_inc > 0 && av_reallocp_array(&ctx->key_frame, ctx- >> >nb_surfaces, sizeof(int)) < 0) { >> + if (ctx->nb_surfaces > old_nb_surfaces && av_reallocp_array(&ctx- >> >key_frame, ctx->nb_surfaces, sizeof(int)) < 0) { >> av_log(avctx, AV_LOG_ERROR, "Failed to grow key frame array >> on video sequence callback\n"); >> ctx->internal_error = AVERROR(ENOMEM); >> return 0; >> @@ -374,9 +378,6 @@ static int CUDAAPI >> cuvid_handle_video_sequence(void *opaque, CUVIDEOFORMAT* form >> cuinfo.bitDepthMinus8 = format->bit_depth_luma_minus8; >> cuinfo.DeinterlaceMode = ctx->deint_mode_current; >> - if (ctx->deint_mode_current != cudaVideoDeinterlaceMode_Weave >> && !ctx->drop_second_field) >> - avctx->framerate = av_mul_q(avctx->framerate, (AVRational){2, >> 1}); >> - >> ctx->internal_error = CHECK_CU(ctx->cvdl- >> >cuvidCreateDecoder(&ctx->cudecoder, &cuinfo)); >> if (ctx->internal_error < 0) >> return 0; >> @@ -448,11 +449,12 @@ static int cuvid_is_buffer_full(AVCodecContext >> *avctx) >> { >> CuvidContext *ctx = avctx->priv_data; >> - int delay = ctx->cuparseinfo.ulMaxDisplayDelay; >> + int mult = 1; >> if (ctx->deint_mode != cudaVideoDeinterlaceMode_Weave && !ctx- >> >drop_second_field) >> - delay *= 2; >> + mult = 2; >> - return av_fifo_can_read(ctx->frame_queue) + delay >= ctx- >> >nb_surfaces; >> + // "- mult + 1" ensures that the buffer is still signalled full >> if one half-frame has already been returned when deinterlacing. >> + return av_fifo_can_read(ctx->frame_queue) + (ctx- >> >cuparseinfo.ulMaxDisplayDelay * mult) >= ctx->nb_surfaces * mult - >> mult + 1; > > I think this is clearer: > return ((av_fifo_can_read(ctx->frame_queue) + mult - 1) / mult) + ctx- > >cuparseinfo.ulMaxDisplayDelay >= ctx->nb_surfaces Yeah, though I've used a shift instead, purely as a minimal speed optimization. > Integer ceiling division to get the number of referenced surfaces in > frame_queue. > > However, when going from mult = 2 to 1, it thinks the buffer is more > full than it really is, which probably isn't a problem. Unfortunately, > when going from mult = 1 to 2, if there is more than one frame in > frame_queue, it will think there are less surfaces referenced than there > are, which may be a problem. That's not the case, only new frames added to the queue are be doubled. Patch is applied now, thanks! _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".
prev parent reply other threads:[~2025-02-26 19:58 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2025-02-20 20:37 [FFmpeg-devel] [PATCH] libavcodec/cuviddec.c: increase CUVID_DEFAULT_NUM_SURFACES Scott Theisen 2025-02-21 13:26 ` Timo Rothenpieler 2025-02-22 2:52 ` Scott Theisen 2025-02-22 13:16 ` Timo Rothenpieler 2025-02-25 5:36 ` Scott Theisen 2025-02-25 18:10 ` Timo Rothenpieler 2025-02-25 18:43 ` [FFmpeg-devel] [PATCH] avcodec/cuviddec: correctly handle buffer size and status when deinterlacing Timo Rothenpieler 2025-02-25 23:15 ` Timo Rothenpieler 2025-02-26 2:42 ` Scott Theisen 2025-02-26 17:17 ` Scott Theisen 2025-02-26 19:58 ` Timo Rothenpieler [this message]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=382f8ebd-2088-48a9-9bb6-a71477839a8b@rothenpieler.org \ --to=timo@rothenpieler.org \ --cc=ffmpeg-devel@ffmpeg.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel This inbox may be cloned and mirrored by anyone: git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \ ffmpegdev@gitmailbox.com public-inbox-index ffmpegdev Example config snippet for mirrors. AGPL code for this site: git clone https://public-inbox.org/public-inbox.git