[FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format

[Fu, Linjie]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, August 30, 2019 00:12
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format
> 
> Am Do., 29. Aug. 2019 um 16:16 Uhr schrieb Fu, Linjie <linjie.fu at intel.com>:
> 
> > Thus AYUV will make more sense.
> 
> If your hardware decoding does not produce valid alpha data (0xFF
> for opaque, 0x00 for completely transparent), you cannot use an
> FFmpeg pix_fmt that defines alpha for decoding.
> If you define a pix_fmt that does not contain alpha information (as
> needed for your hardware decoder), please do not use "A" in its
> name.

The hardware decode output is in packed 4:4:4:4 8 bit(32 bits in total). Apart
from Y/U/V channel, there is an additional need for a channel to store the
zero byte in surfaces(nb_components = 4). And it is designed in hardware/driver
for VA_FourCC_AYUV and AYUV format.

It's not quite proper to use something like "0YUV" directly which indicates that
there is no Alpha channel data like"RGB0" or "0RGB"(nb_components = 3).

"0YUV": YUV0/YUV0/...
"RGB0":RGB/RGB/...

It's true that we could only map Y/U/V data from surface to frame in ffmpeg and
use a 3-components pixel format like "0YUV", but IMHO it's kind of improper because
the output from hardware/driver is forced changed in Application level even if user
didn't call for a CSC:
	- hardware/driver output (in AYUV):  YUV0/YUV0/...
	- ffmpeg output (in 0YUV):                     YUV/YUV/...

Please feel free to offer your opinions on this question(AYUV or 0YUV) and let me
know how to push it step-further.

Thanks,
Linjie