Re: [Mlt-devel] [RFC] 10 bits

[Brian M. <co...@br...>]

On 2/12/2017 2:38 AM, Maksym Veremeyenko wrote:
> On 12.02.2017 0:23, Brian Matherly wrote:
>> On 2/11/2017 9:20 AM, Maksym Veremeyenko wrote:
>>  > any objection against introducing *mlt_image_yuv422p10* ?
>>  >
>>
>> I am in full support of 422 and planar formats. Just wondering about the
>> bit packing.
>>
>> What would be the corresponding AV format?
>>
>> Would it be 16 bpp with 6 bits unused? BE or LE?
>>
> AV_PIX_FMT_YUV422P10LE
>
>> If it is going to be 16bit samples, then why not call it
>> mlt_image_yuv422p16 and use it for any bit depth between 9 and 16?
>
> introducing *mlt_image_yuv422p16* that equal to AV_PIX_FMT_YUV422P16LE
> (http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavutil/pixdesc.c;h=3b9c45d035f5f2399a652a00b41832f55a8febe1;hb=HEAD#l1496)
> fine to me...

LE makes sense to me. AV_PIX_FMT_YUV422P10LE is the native output of 
ffmpeg for H.264 and h.265 10bit decoding. So no endian conversion would 
be required when decoding 10bit streams. And Decklink 10bit pixel 
packing is so complicated that BE or LE is equally difficult.

I would let Dan make the final call, but it might be good to consider 
mlt_image_yuv422p16.

Advantages:
    * Allows more support for greater bit-depths in the future.
    * Reduces rounding errors when processing <16bit images.
    * There is no additional performance cost when processing 12/14/16bit
      images in filters.
    * Avoids having p10, p12, p14 and p16 formats in the future.
    * There would be no additional performance cost for consumers that
      do not handle AV_PIX_FMT_YUV422P10LE because a conversion is
      required anyway (e.g. decklink 10bit output)

Disadvantages:
    * Would require a conversion when a producer is receiving native
      AV_PIX_FMT_YUV422P10LE (e.g. decoding 10bit h.264).
    * Would require a conversion when a consumer requires native
      AV_PIX_FMT_YUV422P10LE (e.g. encoding 10bit h.264)

~Brian