[FFmpeg-devel] [PATCH] lavc/amfenc: DXVA2 textures support implementation by AMF encoder

[Mark Thompson]

On 13/04/18 10:21, Alexander Kravchenko wrote:
> 
> This patch contains DXVA2 textures support implementation by AMF encoder (in addition of D3D11 textures)
> 
> Samples of usage:
> DXVA2 decoder -> dxva2_vld texture -> AMF Encoder:
> ffmpeg -hwaccel dxva2 -hwaccel_output_format dxva2_vld -extra_hw_frames 16 -i input.mp4 -an -c:v h264_amf out.mkv
> 
> D3D11va decoder -> d3d11 texture -> AMF Encoder:
> ffmpeg -hwaccel d3d11va -hwaccel_output_format d3d11 -extra_hw_frames 16 -i input.mp4 -an -c:v h264_amf out.mkv
> 
> ---
> Sending updated patch (Fixes according Mark's review):
>>> ---
>>    ^
>> (When adding commentary which isn't part of the commit message to an email please place it after this line so that it doesn't end up in the commit message.)
> Done here, hopefully correctly
> 
>>>      { AV_PIX_FMT_D3D11,      AMF_SURFACE_NV12 },
>>> +    { AV_PIX_FMT_DXVA2_VLD,  AMF_SURFACE_NV12 },
>>
>> As with D3D11, this isn't necessarily true.  This was ignored before, but do you have any plan for how P010 (and others?) will be handled here?
> removed HW types from format map, and added logic reading pixel format from avctx->sw_pix_fmt in case if avctx->pix_fmt is HWACCEL type
> 
>> +static void get_dx9_device_from_devmgr(IDirect3DDeviceManager9 *devmgr, IDirect3DDevice9 **device, void *avcl) {
>> ...
>> Might be cleaner using an error return rather than the null device?
> Fixed
> 
>> Everything using D3D9 types needs to be inside CONFIG_DXVA2
> Fixed
> 
>> Passing NULL here will make this case succeed in cases where it shouldn't, I think?
> Agree, fixed
> 
>> Tbh I don't think this fallback case should exist at all, it should just fail.
>> Is there any use-case for having it?  The user passed a DXVA2 frames context on a 
>> non-AMD device and expects it to work with that hardware input, this fallback makes 
>> it kindof work with at least two copies in a way which is likely to be very slow.  
>> Even if the user does want to do that, it would be better for them to do it explicitly 
>> to ensure that they aware of the problem.  (We don't automatically do this in any other case.)
> Agree, fixed
> 
>> Spurious whitespace.
> Fixed in changed blocks/functions

I've sent a new set containing this patch as 3 and 4 (I split out the format check part, since that doesn't have anything to do with DXVA2), which hopefully makes the initialisation and surface mapping setup cleaner.  Would you like to look at that and comment?  Quite a bit of stuff got moved around in the merge.

>> Tested on Windows 7, works well.  
>> Unlike with D3D11 the OpenCL interop works properly as well, 
>> so e.g. -vf 'hwmap=derive_device=opencl,convolution_opencl=0 1 0 1 -4 1 0 1 0,hwmap=derive_device=dxva2:reverse=1:extra_hw_frames=16' as encoder input works too.
> Could you send the samples (or link if they are published, I will add to my tests and will check OpenCL interop with D3D11)

Use any OpenCL filter with mapping to/from DXVA2.  For example:

./ffmpeg_g -y -hwaccel dxva2 -hwaccel_output_format dxva2_vld -i input.mkv -an -vf 'hwmap=derive_device=opencl,convolution_opencl=0 1 0 1 -4 1 0 1 0,hwmap=derive_device=dxva2:reverse=1:extra_hw_frames=16' -c:v h264_amf output.mkv

(Applies an edge-detect convolution on the luma plane.)

The source filter is also usable with a little trickiness to get the right setup:

./ffmpeg_g -y -init_hw_device dxva2=d3d -init_hw_device opencl=cl at d3d -filter_hw_device cl -filter_complex 'openclsrc=source=sierpinski.cl:kernel=sierpinski_carpet:size=1920x1080:format=nv12,hwmap=derive_device=dxva2:reverse=1:extra_hw_frames=16' -c:v h264_amf output.mkv

(Using the sierpinski carpet example from the documentation.)

Note that OpenCL <-> D3D11 won't work on AMD for normal video surfaces (NV12) because there is no support for multiple-plane textures, so it's only going to work with DXVA2 currently.  Intel has an extension ("cl_intel_d3d11_nv12_media_sharing") which adds a simple hack overloading the subresource index and therefore it is usable on Intel GPUs, but other vendors don't have that.

(There should probably be a wiki page on all of this.  I've never got around to writing it.)

Thanks,

- Mark