[FFmpeg-devel] Added - HW accelerated H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -----Original Message-----
> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: October 29, 2017 3:49 PM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added - HW accelerated H.264 and HEVC
> encoding for AMD GPUs based on AMF SDK
> 
> On 29/10/17 14:54, Mironov, Mikhail wrote:
> >> -----Original Message-----
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-bounces at ffmpeg.org] On
> Behalf
> >> Of Carl Eugen Hoyos
> >> Sent: October 28, 2017 3:19 PM
> >> To: FFmpeg development discussions and patches <ffmpeg-
> >> devel at 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.mironov at 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 at 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.

Currently 709 or 601 is decided based on frame size. It is crude but works for folks 
who don’t want to deal with a separate AMF component. I am thinking of adding these 
parameters to the encoder in the driver and to AMF API. But so far it was low priority 
because of the separate component which has these parameters.

> 
> (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...)

As I said, I would be glad to work on this or ask someone in my team to do it 
once the encoder is in place. 

> 
> Thanks,
> 
> - Mark
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks, Mikhail