[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: Sunday, September 1, 2019 01:57
> 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 Sa., 31. Aug. 2019 um 19:25 Uhr schrieb Fu, Linjie <linjie.fu at intel.com>:
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> Behalf
> > > Of Mark Thompson
> > > Sent: Saturday, August 31, 2019 23:10
> > > To: ffmpeg-devel at ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel
> format
> > >
> > > On 31/08/2019 05:22, Fu, Linjie wrote:
> > > >> -----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/...
> > >
> > > I think you've misread what RGB0 is.  The component step is 4, not 3 (see
> > > libavutil/pixdesc.c) - the format with a step of 3 is RGB24.
> > >
> > > RGBA:  R G B A R G B A ...
> > > RGB0:  R G B 0 R G B 0 ...
> > > RGB24: R G B R G B R G ...
> >
> > Thanks for pointing out this.
> > Just took the nb_components into account and misread the step info at
> first.
> >
> > > Following the same pattern we would have:
> > >
> > > AYUV:  A Y U V A Y U V ...
> > > 0YUV:  0 Y U V 0 Y U V ...
> > >
> > > To me it looks like 0YUV is exactly what you want here.
> >
> > Will update the patch if 0YUV is more acceptable.
> 
> Could you double-check if there is no bug in the decoder?
> I ask because transparency is possible with hevc and the
> relevant Windows format does support transparency from
> how I read the specification.
> 

Double confirmed.
The alpha channel is configurable on HCP_SURFACE_STATE command,
currently driver(iHD) set zero as default value.

"0YUV" is good enough, "AYUV" could be hold on.

- linjie