Cuda outputs green line and incorrect resolution

[Jason Dove]

Summary of the bug:

When overlaying this content using overlay_cuda, there is a green line at the bottom of the output, and the output height is 1088 instead of 1080.

Using a software decoder avoids the issue, using a software encoder avoids the issue, and for whatever reason seeking .001 seconds into the test input (before -i) also avoids the issue.

How to reproduce:

% ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_5MB.mp4 -i https://peach.blender.org/wp-content/themes/bf-bunny/graphics/header1.jpg -filter_complex '[0:0]scale_cuda=format=yuv420p[v];[1:0]hwupload_cuda[wm];[v][wm]overlay_cuda[ov]' -map '[ov]' -t 00:00:05 -c:v h264_nvenc -y green-line.mkv

ffmpeg version N-120352-gda18c2a373-20250722 Copyright (c) 2000-2025 the FFmpeg developers
built with gcc 15.1.0 (crosstool-NG 1.27.0.42_35c1e72)
configuration: --prefix=/ffbuild/prefix --pkg-config-flags=--static --pkg-config=pkg-config --cross-prefix=x86_64-ffbuild-linux-gnu- --arch=x86_64 --target-os=linux --enable-gpl --enable-version3 --disable-debug --enable-iconv --enable-zlib --enable-libfribidi --enable-gmp --enable-libxml2 --enable-openssl --enable-lzma --enable-fontconfig --enable-libharfbuzz --enable-libfreetype --enable-libvorbis --enable-opencl --enable-libpulse --enable-libvmaf --enable-libxcb --enable-xlib --enable-amf --enable-libaom --enable-libaribb24 --enable-avisynth --enable-chromaprint --enable-libdav1d --enable-libdavs2 --enable-libdvdread --enable-libdvdnav --disable-libfdk-aac --enable-ffnvcodec --enable-cuda-llvm --enable-frei0r --enable-libgme --enable-libkvazaar --enable-libaribcaption --enable-libass --enable-libbluray --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librist --enable-libssh --enable-libtheora --enable-libvpx --enable-libwebp --enable-libzmq --enable-lv2 --enable-libvpl --enable-openal --enable-liboapv --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenh264 --enable-libopenjpeg --enable-libopenmpt --enable-librav1e --enable-librubberband --disable-schannel --enable-sdl2 --enable-libsnappy --enable-libsoxr --enable-libsrt --enable-libsvtav1 --enable-libtwolame --enable-libuavs3d --enable-libdrm --enable-vaapi --enable-libvidstab --enable-vulkan --enable-libshaderc --enable-libplacebo --enable-libvvenc --enable-libx264 --enable-libx265 --enable-libxavs2 --enable-libxvid --enable-libzimg --enable-libzvbi --extra-cflags=-DLIBTWOLAME_STATIC --extra-cxxflags= --extra-libs='-ldl -lgomp' --extra-ldflags=-pthread --extra-ldexeflags=-pie --cc=x86_64-ffbuild-linux-gnu-gcc --cxx=x86_64-ffbuild-linux-gnu-g++ --ar=x86_64-ffbuild-linux-gnu-gcc-ar --ranlib=x86_64-ffbuild-linux-gnu-gcc-ranlib --nm=x86_64-ffbuild-linux-gnu-gcc-nm --extra-version=20250722
libavutil      60.  6.100 / 60.  6.100
libavcodec     62.  8.100 / 62.  8.100
libavformat    62.  1.103 / 62.  1.103
libavdevice    62.  0.100 / 62.  0.100
libavfilter    11.  3.100 / 11.  3.100
libswscale      9.  0.100 /  9.  0.100
libswresample   6.  0.100 /  6.  0.100

[Timo R.]

You'll need to define what "sometimes" means here. It's certainly not random?
1080p actually being 1088p that crops off the bottom 8 pixels is normal, cause some codecs like h264 demand the dimensions to be a multiple of 16.
But you should normally never actually see that line.

[Jason Dove]

Do I? The ticket contains a 100% repro where the output file is the wrong size. It is 1088 not 1080.

[Jason Dove]

By sometimes I just mean I don't know the exact conditions or cause beyond what I described in the ticket.

[Jason Dove]

Ah, I see. I didn't realize how h264 was stored, frame cropping, etc.

This produces output (100% for me) that doesn't have cropping set properly:

ffmpeg -hwaccel cuda -hwaccel_output_format cuda -i https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_5MB.mp4 -i https://peach.blender.org/wp-content/themes/bf-bunny/graphics/header1.jpg -filter_complex '[0:0]scale_cuda=format=yuv420p[v];[1:0]hwupload_cuda[wm];[v][wm]overlay_cuda[ov]' -map '[ov]' -t 00:00:05 -c:v h264_nvenc -y green-line.mkv

while this version that seeks slightly does have cropping set properly (again, 100% for me):

ffmpeg -hwaccel cuda -hwaccel_output_format cuda -ss 00:00:0.01 -i https://test-videos.co.uk/vids/bigbuckbunny/mp4/h264/1080/Big_Buck_Bunny_1080_10s_5MB.mp4 -i https://peach.blender.org/wp-content/themes/bf-bunny/graphics/header1.jpg -filter_complex '[0:0]scale_cuda=format=yuv420p[v];[1:0]hwupload_cuda[wm];[v][wm]overlay_cuda[ov]' -map '[ov]' -t 00:00:05 -c:v h264_nvenc -y no-green-line.mkv

[Jason Dove]

Looking at this a little more, the behavior was introduced with 9a97f9cf3a95f4c2f13abc52702bd19e3a748b66.

The parent b295ec31f351d8cc2dfad6f7c0cb261c1b19b7d9 does not have the green line, and ffprobe reports 1080, not 1088.