[FFmpeg-devel] [PATCH 0/2] nvenc: Fix inaccurate use of YUV444P16 format

Philip Langdale 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?

Bit layouts
-----------

P010 / nvenc YUV444P10:

123456789Axxxxxx

ffmpeg YUV444P10:

xxxxxx123456789A

YUV444P16:

123456789ABCDEF0

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
for >10bit.

>> 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.

--phil


More information about the ffmpeg-devel mailing list