On 29/10/17 14:54, Mironov, Mikhail wrote: >> -----Original Message----- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Carl Eugen Hoyos >> Sent: October 28, 2017 3:19 PM >> To: FFmpeg development discussions and patches <ffmpeg- >> de...@ffmpeg.org> >> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC >> encoding for AMD GPUs based on AMF SDK >> >> 2017-10-27 20:09 GMT+02:00 mmironov <mikhail.miro...@amd.com>: >>> +const enum AVPixelFormat ff_amf_pix_fmts[] = { >>> + AV_PIX_FMT_NV12, >> >>> + AV_PIX_FMT_BGRA, >>> + AV_PIX_FMT_ARGB, >>> + AV_PIX_FMT_RGBA, >> >> This is wrong, your encoders do not convert transparency information, there >> are 32 rgb formats without alpha channel. >> >>> + { AV_PIX_FMT_NV12, AMF_SURFACE_NV12 }, >>> + { AV_PIX_FMT_D3D11, AMF_SURFACE_NV12 }, >> >> Just curious: Can you explain this in simple words? >> >> I will try not to comment on the headers you sent, Carl Eugen >> _______________________________________________ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Sure: the native format for the encoder is NV12. It can work via D3D11 and > accept DXGI_FORMAT_NV12 texture or via D3D9 accepting > (D3DFORMAT)MAKEFOURCC('N', 'V', '1', '2') surface. AMF surfaces are wrappers > around these objects and converters from system memory. In addition, the > encoder has built-in shader-based color converter. It can accept BGRA and > RGBA formats and convert them into NV12 dropping alpha channel. This is why I > added these entries. Granted, the conversion lacks parameters and to support > more options AMF has a separate color space component, also shader-based. > Once encoder is integrated I planned to ask FFmpeg team opinion if it is > needed or not. > I made the FFmpeg encoder accepting DX objects from other FFmpeg components > if available.
If you're going to do the colour conversion here then please pass the necessary colour information (AVFrame.color_primaries|color_trc|colorspace) so that non-BT.709 (I'm guessing...) has some chance of being correct. (Though I'd say in general it's preferable not to have the encoder do this, because it becomes confused with actual encoding of RGB. A separate D3D11 shader implementation to do it as a filter would definitely be welcome...) Thanks, - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
