On 31/08/2019 05:22, Fu, Linjie wrote: >> -----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/...
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 ... 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. - Mark _______________________________________________ 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".
