On 12/5/19, James Darnley <james.darn...@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.
>
>
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
