Cuvid decoder problem with deinterlacing

[ua0lnj]

Summary of the bug:
After commit 99e2af4 ​https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/99e2af4e7837ca09b97d93a562dc12947179fc48
I have frame jerking with vdr-plugin-softhddevice and vdr-plugin-softhdcuvid.(​https://github.com/ua0lnj/vdr-plugin-softhddevice, ​https://github.com/jojo61/vdr-plugin-softhdcuvid), with interlaced video and cuvid deinterlace bob or adaptive. No errors in libavcodec debug log. But ffplay works without problems: DISPLAY=:0 ffplay -x 1920 -y 1080 -vcodec h264_cuvid -deint 2 -drop_second_field 0 -v debug ./00001.ts

The only difference i found in the logs:
ffplay:
[h264_cuvid @ 0x7139edffb2c0] Format nv12 chosen by get_format().
[h264_cuvid @ 0x7139edffb2c0] Formats: Original: nv12 | HW: nv12 | SW: nv12

softhddevice:
[h264_cuvid @ 0x7a36343b0900] Format cuda chosen by get_format().
[h264_cuvid @ 0x7a36343b0900] Formats: Original: nv12 | HW: cuda | SW: nv12

How to reproduce:
ffmpeg version latest from git, Nvidia driver 570, Ubuntu 24.04.
vdr with vdr-plugin-softhddevice, -v cuvid.

I know about nvdec and softhddevice supports it too, here we are talking about cuvid.

[ua0lnj]

If I change ​https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/99e2af4e7837ca09b97d93a562dc12947179fc48:/libavcodec/cuviddec.c#l457

to:

return ((av_fifo_can_read(ctx->frame_queue) + shift) >> shift)*2 + ctx->cuparseinfo.ulMaxDisplayDelay >= ctx->nb_surfaces;

then all works fine.

[GqU]

The problems is also present in normal h264_cuvid decoding with -deint 2 .
ffmpeg -c:v h264_cuvid -deint 2 -i input.mkv output.mkv
adding "*2" fixed the problem.

return ((av_fifo_can_read(ctx->frame_queue) + shift) >> shift)*2 + ctx->cuparseinfo.ulMaxDisplayDelay >= ctx->nb_surfaces;

[Balling]

Duplicate with #10709
Set -c:v h264_cuvid -deint 2 -surfaces 9 -i.

[Timo R.]

Multiplying that value by 2 makes no sense, it undoes the shift right before it, and will cause it to basically always signal the buffer to be full immediately, severely hurting performance.

I can't immediately reproduce any issues here.
You have to keep in mind that when using the ffmpeg CLI tool, you need to manually provide it with the doubled framerate, since ffmpeg.c does not have any provisions to account for a decoder changing the framerate. It trusts what the demuxer reports.

So if you have 1080i50 content for example, ffmpeg recognizes it as 25 fps.
To then deinterlace it with cuvid:
./ffmpeg_g -c:v h264_cuvid -deint adaptive -r 50 -i yourfile.mp4 [...] out.mp4

This produces perfectly smooth output for me. Without it, it looks quite juddery.
Alternatively, you can add -drop_second_field 1, to just get 1080p25 back. But that obviously looks bad as well, by nature of being only 25 fps.

[ua0lnj]

However, before the patch there were no problems with the softhddevice, and as I do not see any with the value of multiplying by 2. So far I have not been able to change the code of the softhddevice so that it works normally with the current state of libavcodec. ffmpeg seems to work differently and does not allow to reproduce this problem, maybe because ffmpeg uses the avctx->pix_fmt == AV_PIX_FMT_NV12, while the softhddevice uses the pix_fmt == AV_PIX_FMT_CUDA.

[Balling]

and as I do not see any with the value of multiplying by 2.

There is a problem. AS was said it now takes all resources instead of minimally needed. Sure, you file needs it, but most files do not.

ffmpeg uses the avctx->pix_fmt == AV_PIX_FMT_NV12, while the softhddevice uses the pix_fmt == AV_PIX_FMT_CUDA.

CUDA is a hardware format. You can select in ffmpeg hardware format with -hwaccel_output_format cuda

Provide is the video file btw.

[ua0lnj]

file 1920x1080x25i
​https://streams.videolan.org/ffmpeg/incoming/00001.ts

I can't reproduce the problem with ffmpeg, with -hwaccel_output_format cuda or with -hwaccel_output_format nv12 it still have:
[h264_cuvid @ 0x6518e2bc8100] Format nv12 chosen by get_format().
[h264_cuvid @ 0x6518e2bc8100] Formats: Original: nv12 | HW: nv12 | SW: nv12

I can't get with using ffmpeg "Formats: Original: nv12 | HW: cuda | SW: nv12"

[ua0lnj]

This is how it looks on the TV
​https://streams.videolan.org/ffmpeg/incoming/VID_20250528_231010.mp4
vdr-2.7.5+softhddevice plugin, cuvid decoder.

[Balling]

vdr-2.7.5+softhddevice plugin, cuvid decoder.

I mean this is clearly a bug in that plugin. Why are you reporting a bug against us?

[ua0lnj]

Because before the change in ffmpeg everything worked fine. You want to say that since the appearance of cuvid in ffmpeg the cuvid decoder was incorrect, and all the code in the softhddevice and softhdcuvid vdr's plugins is also incorrect, and now everything needs to be redone.However everything worked fine before this change.

Is it possible get with ffmpeg:
Format cuda chosen by get_format().
Formats: Original: nv12 | HW: cuda | SW: nv12

As I already wrote, ffmpeg always uses nv12, and I could not check this problem using ffmpeg.

[ua0lnj]

Replying to Balling:

There is a problem. AS was said it now takes all resources instead of minimally needed. Sure, you file needs it, but most files do not.

How to see how many resources the decoder has taken up,in nvidia-smi?