Opened 3 years ago

Closed 11 months ago

Last modified 11 months ago

#6619 closed defect (worksforme)

CUDA/CUVID decoding error

Reported by: lasereyess Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: CUDA
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no


Apologies if this isn't filled out properly, my version of ffmpeg is not listed and I don't know what component this falls under (codecs I think?).

When decoding files with CUDA on mpv I get some garbage lines on the bottom, I have only been able to reproduce it with a single file, so it may be an issue with the aspect ratio of the file? I'm not sure.

With ffmpeg I can reproduce by decoding with CUDA to an image

% ffmpeg -c:v h264_cuvid -ss 00:00:10.0 -i test.mkv -vframes 1 output.png

with mpv (I know this isn't useful to you guys but it's how I discovered this bug) it can be reproduced using:

mpv --hwdec=cuda --no-config test.mkv 

ffmpeg version:

ffmpeg version 3.3.3 Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 7.1.1 (GCC) 20170630
  configuration: --prefix=/usr --disable-debug --disable-static --disable-stripping --enable-avisynth --enable-avresample --enable-fontconfig --enable-gmp --enable-gnutls --enable-gpl --enable-ladspa --enable-libass --enable-libbluray --enable-libfreetype --enable-libfribidi --enable-libgsm --enable-libiec61883 --enable-libmodplug --enable-libmp3lame --enable-libopencore_amrnb --enable-libopencore_amrwb --enable-libopenjpeg --enable-libopus --enable-libpulse --enable-libschroedinger --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libv4l2 --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxcb --enable-libxvid --enable-shared --enable-version3
  libavutil      55. 58.100 / 55. 58.100
  libavcodec     57. 89.100 / 57. 89.100
  libavformat    57. 71.100 / 57. 71.100
  libavdevice    57.  6.100 / 57.  6.100
  libavfilter     6. 82.100 /  6. 82.100
  libavresample   3.  5.  0 /  3.  5.  0
  libswscale      4.  6.100 /  4.  6.100
  libswresample   2.  7.100 /  2.  7.100
  libpostproc    54.  5.100 / 54.  5.100

OS: GNU/Linux 64 bit
GPU: Nvidia GTX 960

Attachments (3)

output.png (2.1 KB) - added by lasereyess 3 years ago.
example of decoding issues
LB-test-small.mkv (797.9 KB) - added by lasereyess 3 years ago.
file in question that produces garbage decoding
ffmpeg-20170826-094813.log (12.4 KB) - added by lasereyess 3 years ago.

Download all attachments as: .zip

Change History (12)

Changed 3 years ago by lasereyess

example of decoding issues

Changed 3 years ago by lasereyess

file in question that produces garbage decoding

comment:1 Changed 3 years ago by oromit

Please provide the full ffmpeg output.
And the sample you used to create this behavior.

Right now I suspect it's an error in the file, where it might be missing cropping information.
But it's impossible to tell without those things.

Does it work fine when software decoded?

comment:2 Changed 3 years ago by lasereyess

Log file is now attached.The sample used to create that image is also attached. LB-test-small.mkv. Specifically I reran the command with

ffmpeg -report -c:v h264_cuvid -ss 00:00:01.0 -i LB-test-small.mkv -vframes 1 output.png

and it indeed produces the same output.png with the green line at the bottom.

It plays back fine using vdpau as well as software decoding.

Changed 3 years ago by lasereyess


comment:3 Changed 3 years ago by oromit

  • Reproduced by developer set
  • Version set to git-master

Yeah, same thing is happening here.
Not sure what causes it yet.

comment:4 Changed 3 years ago by lasereyess

Is there any more information that could be useful that I can give?

comment:5 Changed 3 years ago by philipl

It'll either be a driver bug or some incompatibility with some hardware constraint (and nvidia do a poor job of documenting the hardware constraints and capabilities around nvdec). My first thought was the 534 vertical resolution but this was correctly padded out to 544 in your sample when encoding, so that shouldn't be a problem.

comment:6 Changed 3 years ago by philipl

(And for what it's worth, I was able to reproduce with your sample)

comment:7 Changed 3 years ago by lasereyess

FWIW I'm using the latest nvidia drivers for linux and my GPU is 'rev a1' (no idea if this is relevant)

NVRM version: NVIDIA UNIX x86_64 Kernel Module  384.59  Wed Jul 19 23:53:34 PDT 2017
01:00.0 VGA compatible controller: NVIDIA Corporation GM206 [GeForce GTX 960] (rev a1)

Is it worth trying to report this as a bug to nvidia? Do they take bug reports like this? If they take them, do they care about them at all?

comment:8 Changed 3 years ago by philipl

They sometimes care about it. You can report on their forums:

comment:9 Changed 11 months ago by Balling

  • Resolution set to worksforme
  • Status changed from new to closed

Working for me. (1280 x 534 all pixels are black, though checked only in windows, everything in it the last version). Checked both:

ffmpeg.exe -hwaccel nvdec -ss 00:00:10.0 -i LB-test-small.mkv -vframes 1 output.png
ffmpeg.exe -c:v h264_cuvid -ss 00:00:10.0 -i LB-test-small.mkv -vframes 1 output.png
Last edited 11 months ago by Balling (previous) (diff)
Note: See TracTickets for help on using tickets.