> -----Original Message----- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Sunday, September 1, 2019 01:57 > To: FFmpeg development discussions and patches <ffmpeg- > de...@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...@intel.com>: > > > > > -----Original Message----- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > > Of Mark Thompson > > > Sent: Saturday, August 31, 2019 23:10 > > > To: ffmpeg-devel@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-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 ... > > > > 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. >
Hi, Rethink about this, hardware decoder should support a valid alpha data. Default 0x00 or 0xFF for alpha channel doesn't make sense in HEVC Rext decoding. Filed an issue in media driver: https://github.com/intel/media-driver/issues/719 Will rebase and resend the patch set for QSV HEVC REXT decoding, basing on AYUV,Y410, Y210. 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".
