[FFmpeg-devel] [PATCH] ffmpeg: add ffmpeg_d3d11va

Hendrik Leppkes h.leppkes at gmail.com
Wed Dec 14 11:52:33 EET 2016


On Wed, Dec 14, 2016 at 10:30 AM, Stève Lhomme <robux4 at videolabs.io> wrote:
>>
>> I'm pretty much against this, since it duplicates the profile selection
>> code all over again, even if it could be shared. (And this code should
>> be in libavcodec in the first place.) Someone adding such code would
>> have to refactor ffmpeg_d3d11va too.
>
> I'm not sure how this relates to the line above. d3d11va and dxva2 are
> definitely not the same thing. On mobile you do not have DXVA2 at all
> but D3D11(VA) is present. There must be a way to have one without the
> other.
>

The point wm4 was making is that it should share a bunch of the code
with dxva2 (ie. the guid selection, for example, and whatever is
appropriate), instead of just duplicating it.
And on top of that, maybe even have it in avcodec since every
implementation needs a GUID -> codec mapping somewhere.

>>> +    ZeroMemory(&viewDesc, sizeof(viewDesc));
>>> +    viewDesc.DecodeProfile = decoderDesc.Guid;
>>> +    viewDesc.ViewDimension = D3D11_VDOV_DIMENSION_TEXTURE2D;
>>> +    for (i=0; i<ctx->initial_pool_size; i++)
>>> +    {
>>> +        hr = ID3D11VideoDevice_CreateVideoDecoderOutputView(device_hwctx->video_device,
>>> +                                                            (ID3D11Resource*) p_texture,
>>> +                                                            &viewDesc,
>>> +                                                            (ID3D11VideoDecoderOutputView**) &s->surfaces_internal[i]);
>>> +        if (FAILED(hr)) {
>>> +            av_log(ctx, AV_LOG_ERROR, "Could not create the decoder output %d\n", i);
>>> +            while (--i >= 0) {
>>> +                ID3D11VideoDecoderOutputView_Release(s->surfaces_internal[i]);
>>> +                s->surfaces_internal[i] = NULL;
>>> +            }
>>> +            ID3D11Texture2D_Release(p_texture);
>>> +            ID3D11Device_Release(d3d11_device);
>>> +            return AVERROR_UNKNOWN;
>>> +        }
>>> +    }
>>> +    ID3D11Texture2D_Release(p_texture);
>>> +
>>> +    texDesc.ArraySize = 1;
>>> +    texDesc.Usage = D3D11_USAGE_STAGING;
>>> +    texDesc.BindFlags = 0;
>>> +    texDesc.CPUAccessFlags = D3D11_CPU_ACCESS_READ;
>>
>> Doesn't this exclude upload?
>
> I only too decoding in consideration. Since it's a staging texture,
> adding ACCESS_WRITE is possible. When mapping the surface to the CPU
> I'll need to adjust the flags.

The hwcontext should indeed be universal for both download and upload,
even if its only used for download in the first step.

>>> +static int d3d11va_device_create(AVHWDeviceContext *ctx, const char *device,
>>> +                                 AVDictionary *opts, int flags)
>>> +{
>>> +    AVD3D11VADeviceContext *device_hwctx = ctx->hwctx;
>>> +    D3D11VADevicePriv *priv;
>>> +
>>> +    HRESULT hr;
>>> +    PFN_D3D11_CREATE_DEVICE createD3D;
>>> +    IDXGIAdapter *pAdapter = NULL;
>>> +    UINT creationFlags = D3D11_CREATE_DEVICE_VIDEO_SUPPORT;
>>> +    /* if the DirectX SDK is installed creationFlags |= D3D11_CREATE_DEVICE_DEBUG; */
>>> +
>>> +    if (device) {
>>> +        HMODULE dxgilib = dlopen("dxgi.dll", 0);
>>
>> Using dlopen instead of LoadLibrary is just odd.
>
> I used exactly what is used in other parts of the DXVA2 code. If it
> exists I suppose there's a reason for that.

ffmpeg has wrappers around LoadLibrary with some extra security
checks, and they mimick the dlopen API, IIRC.


More information about the ffmpeg-devel mailing list