[FFmpeg-devel] [PATCH, v3, 1/7] lavu/pixfmt: add new pixel format 0yuv/y210/y410

[Paul B Mahol]

On 12/5/19, James Darnley <james.darnley at gmail.com> wrote:
> On 2019-12-04 15:43, Linjie Fu wrote:
>> Previously, media driver provided planar format(like 420 8 bit),
>> but for HEVC Range Extension (422/444 8/10 bit), the decoded image
>> is produced in packed format because Windows expects it.
>>
>> Add some packed pixel formats for hardware decode support in VAAPI
>> and QSV:
>>
>> 4:2:2 10 bit: Y210
>> 4:4:4  8 bit: 0YUV
>> 4:4:4 10 bit: Y410
>>
>
>> +    [AV_PIX_FMT_Y410LE] = {
>> +        .name = "y410le",
>> +        .nb_components = 4,
>> +        .log2_chroma_w = 0,
>> +        .log2_chroma_h = 0,
>> +        .comp = {
>> +            { 0, 32, 10, 0, 10, 31, 9, 11 },        /* Y */
>> +            { 0, 32,  0, 0, 10, 31, 9,  1 },        /* U */
>> +            { 0, 32, 20, 0, 10, 31, 9, 21 },        /* V */
>> +            { 0, 32, 30, 0,  2, 31, 1, 31 },        /* A */
>> +        },
>> +        .flags = AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BITSTREAM,
>> +    },
>
>
>
>> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
>> index d78e863..a163350 100644
>> --- a/libavutil/pixfmt.h
>> +++ b/libavutil/pixfmt.h
>> @@ -348,6 +348,12 @@ enum AVPixelFormat {
>>      AV_PIX_FMT_NV24,      ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and
>> 1 plane for the UV components, which are interleaved (first byte U and the
>> following byte V)
>>      AV_PIX_FMT_NV42,      ///< as above, but U and V bytes are swapped
>>
>> +    AV_PIX_FMT_Y210BE,    ///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
>> big-endian
>> +    AV_PIX_FMT_Y210LE,    ///< packed YUV 4:2:2, 32bpp, Y0 Cb Y1 Cr,
>> little-endian
>> +    AV_PIX_FMT_0YUV,      ///< packed YUV 4:4:4, 32bpp,  X  Y Cb Cr,
>> X=unused/undefined
>> +    AV_PIX_FMT_Y410LE,    ///< packed YUV 4:4:4, 32bpp, Cr  Y Cb  A,
>> little-endian
>> +    AV_PIX_FMT_Y410BE,    ///< packed YUV 4:4:4, 32bpp, Cr  Y Cb  A,
>> big-endian
>> +
>>      AV_PIX_FMT_NB         ///< number of pixel formats, DO NOT USE THIS
>> if you want to link with shared libav* because the number of formats might
>> differ between versions
>>  };
>>
>
> I will ask again.  From
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-June/245929.html
>
>> Why am I suspicious that at least one of those is a re-ordered v210?  I
>> seem to recall that we rejected adding v210 to this list.  Either they
>> don't belong in this list or they don't belong because libavcodec has a
>> proper decoder (at least for v210).
>>
>> This might be the thread I was remembering but March seems too recent
>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2019-March/241549.html
>>
>> No real conclusion was reached there.
>>
>> Do bit-packed formats belong in an AVPixelFormat?
>
> Despite what was said last time I do believe this is packed.  I have
> taken a little time to actually understand these magic number structs.
>
> y410 is clearly packed like v210.  Look at the those offsets: 0, 10, 20,
> 30.  Packed into a 32-bit word.  Flagged with AV_PIX_FMT_FLAG_BITSTREAM.
>
> How is that any different to v210?  Can you address a single sample in
> that 1 plane format without using shifts and bit-wise ands?  Isn't that
> the definition of packed?  I do not mean interleaved.
>
> Okay, y410 is a little better in that it is 444 so the sample order does
> not change through 6 word cycle.  Is that the key difference?
>
>
>
> Do bit-packed formats belong in an AVPixelFormat?
>
> If yes then I do not object to this patch or any others like this.
>
> If no then why is this not rejected?

Please summon Technical Committee, they sure will know the answer ;-)

>
>
>
> Does the AV_PIX_FMT_FLAG_BITSTREAM flag mean they do belong?  I admit I
> haven't seen this before so maybe I should shut up and not send this email.
>
>
>