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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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".
