On Mon, Nov 21, 2016 at 1:10 AM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > 2016-11-21 0:24 GMT+01:00 Hendrik Leppkes <h.lepp...@gmail.com>: >> On Sun, Nov 20, 2016 at 9:06 PM, Carl Eugen Hoyos <ceffm...@gmail.com> wrote: >>> 2016-11-20 21:02 GMT+01:00 Timo Rothenpieler <t...@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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
