> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, August 30, 2019 00:12
> To: FFmpeg development discussions and patches <ffmpeg-
> de...@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...@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
_______________________________________________
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".
