aboutsummaryrefslogtreecommitdiffstats
path: root/libavcodec/ituh263dec.c
diff options
context:
space:
mode:
authorPhilip Langdale <philipl@overt.org>2017-11-24 10:05:49 -0800
committerPhilip Langdale <philipl@overt.org>2017-11-24 12:19:31 -0800
commit4186a77f26a82b4e15109d3286d6de98c2cfe7b6 (patch)
tree4c3ee3280a4260a21484e864be6c6bdcafd2c978 /libavcodec/ituh263dec.c
parentfa4121507ca426d3640268cb87c8c1bc547a6103 (diff)
downloadffmpeg-4186a77f26a82b4e15109d3286d6de98c2cfe7b6.tar.gz
avcodec/nvdec: Round up odd width/height values
nvdec will not produce odd width/height output, and while this is basically never an issue with most codecs, due to internal alignment requirements, you can get odd sized jpegs. If an odd-sized jpeg is encountered, nvdec will actually round down internally and produce output that is slightly smaller. This isn't the end of the world, as long as you know the output size doesn't match the original image resolution. However, with an hwaccel, we don't know. The decoder controls the reported output size and the hwaccel cannot change it. I was able to trigger an error in mpv where it tries to copy the output surface as part of rendering and triggers a cuda error because cuda knows the output frame is smaller than expected. To fix this, we can round up the configured width/height passed to nvdec so that the frames are always at least as large as the decoder's reported size, and data can be copied out safely. In this particular jpeg case, you end up with a blank (green) line at the bottom due to nvdec refusing to decode the last line, but the behaviour matches cuviddec, so it's as good as you're going to get.
Diffstat (limited to 'libavcodec/ituh263dec.c')
0 files changed, 0 insertions, 0 deletions