[FFmpeg-devel] [PATCH 0/2] nvenc: Fix inaccurate use of YUV444P16 format
philipl at overt.org
Thu Feb 2 20:20:18 EET 2017
On 2017-02-02 00:15, Carl Eugen Hoyos wrote:
> 2017-02-01 23:54 GMT+01:00 Philip Langdale <philipl at overt.org>:
>> We have been pretending that the nvenc YUV444P10 format is our
>> YUV444P16 format, and this is not a good idea. It leads to us
>> failing to dither >10bit content when transcoding
> Could you provide samples for me (or explain how I can
> reproduce this) to improve my understanding?
P010 / nvenc YUV444P10:
So, obviously, if you directly map the two YUV444P10 formats,
all the bits are interpreted incorrectly.
If you pass YUV444P16 from the ffmpeg side, then you lose
the last six bits (the BCDEF0) without dithering.
How to test? You need nvenc capable hardware and then modify
the code to map the two P10 formats and disable P010. ffmpeg
will then preferentially convert to YUV444P10 and you'll
see the output is all wrong.
Seeing bit truncation for >10bit content with the current
mapping is harder. I have no good way to do that, but you
should assume it's happening if they don't claim support
>> and also results in encoded files with 4:4:4 sampling
> Could you elaborate? How is this different from x264?
It's not different, but if your input is 4:2:0 you almost
certainly don't want ffmpeg to up convert to 4:4:4 and
then end up with 4:4:4 in the output file which isn't
compatible with anything mainstream.
More information about the ffmpeg-devel