[FFmpeg-devel] [PATCH 2/2] swscale: Add swscale and fate support for AYUV

[Fu, Linjie]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Thursday, August 29, 2019 05:18
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] swscale: Add swscale and fate
> support for AYUV
> 
> Am Mi., 28. Aug. 2019 um 09:52 Uhr schrieb Fu, Linjie <linjie.fu at intel.com>:
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> Behalf
> > > Of Carl Eugen Hoyos
> > > Sent: Wednesday, August 28, 2019 14:58
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH 2/2] swscale: Add swscale and fate
> > > support for AYUV
> > >
> > >
> > >
> > > > Am 28.08.2019 um 08:22 schrieb Linjie Fu <linjie.fu at intel.com>:
> > > >
> > > > Add swscale support for AYUV and make it more robust.
> > >
> > > The path that converts from AYUV to planar YUV(A) seems to be missing
> the
> > > handling of alpha values.
> >
> > Alpha channel information in AYUV are treated in the same way for
> RGBA/BGRA and
> > is reusing rgbaToA_c to handle the alpha values.
> >
> > When converting AYUV to YUA/YUVA, two methods are acceptable:
> > - For YUV, just cut the alpha and discard the transparency
> > - For format which also contains an alpha channel(YUV444P), copy the
> > alpha information seems good.
> 
> But since the input does not contain (valid) alpha, this does not apply.

If we convert from a input with valid alpha, then it makes sense. (like ARGB to AYUV)

And IMHO, swscale function should focus on CSC itself and should be able to cope with
the color space convert even if the alpha data is kind of not valid.
The validation judgement for alpha may be better if it was implemented in the user level.

- linjie