[FFmpeg-devel] [PATCH] avcodec/cuvid: Add support for P010 as an output surface format

Hendrik Leppkes h.leppkes at gmail.com
Mon Nov 21 02:31:35 EET 2016

On Mon, Nov 21, 2016 at 1:10 AM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> 2016-11-21 0:24 GMT+01:00 Hendrik Leppkes <h.leppkes at gmail.com>:
>> On Sun, Nov 20, 2016 at 9:06 PM, Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>>> 2016-11-20 21:02 GMT+01:00 Timo Rothenpieler <timo at rothenpieler.org>:
>>>> I don't really like outputting P016 as P010.
>>>> I'd prefer to add support for P016 to ffmpeg and swscale, which
>>>> shouldn't be too hard as most P010 code can be reused.
>>> Or change the existing P010 code to actually handle P016...
>>> (And do a rename on the next version bump)
>> These are two distinct formats and should be kept as such.
>> Hardware cares for the difference
> Please explain how this is possible.

I have no idea what your problem with the P01X formats is. You already
made a fuzz about adding P010 and now you are making one again.
Whats wrong with these?

Various hardware APIs make a distinct difference in handling P010 and
P016 for 10-bit and >10-bit pixels respectively, and if we want to
properly support these APIs fully, we need to be able to map these
types to pixel formats on our end - which is already done for HEVC
10-bit decoding with P010, and now follows with 12-bit decoding using
P016. Both are a common industry standard format for 4:2:0
high-bitdepth surfaces on the GPU.

They do technically share the same memory layout with a varying degree
of zeros at the end, however as the hardware and its APIs makes a
clear distinction between the two, so do we. Otherwise allocating
hardware surfaces in the appropriate format is going to be rather
cumbersome or flat out broken. The avutil hwcontext implementation
needs a clear mapping between pixfmts and surface formats.

- Hendrik

More information about the ffmpeg-devel mailing list