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

[James Darnley]

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?



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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 603 bytes
Desc: OpenPGP digital signature
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20191205/a045f21f/attachment.sig>