[FFmpeg-devel] DXVA Question.

[Hendrik Leppkes]

On Sun, Apr 26, 2015 at 12:52 PM, Matt Oliver <protogonoi at gmail.com> wrote:
> On 26 April 2015 at 18:01, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>
>> On Sun, Apr 26, 2015 at 8:45 AM, Anton Fedchin <anightik at gmail.com> wrote:
>> > Hi,
>> >
>> > I'm working on porting our project Kodi to DirectX11. We also use ffmpeg
>> > and I've implemented patch to ffmpeg dxva related code to work with d3d11
>> > video API. It works good. Before we send the patch we have a question.
>> >
>> > Question is what you prefer a configure switch or something else?
>>
>> Part of the dxva support in ffmpeg is public API (ie. dxva_context).
>> Unfortunately, you cannot touch this struct without a major version
>> bump of ffmpeg.
>> This being public API also means that you cannot modify it based on
>> configure switches, since the API must remain the same.
>>
>> So keeping in mind that you cannot touch the public API, personally, I
>> think the cleanest way to do this would be to just leave ffmpeg alone,
>> and a user-app that needs D3D11 could just write a simple wrapper
>> IDirectXVideoDecoder that internally calls ID3D11VideoContext instead.
>> This would not need any changes to the public API, or ffmpeg at all,
>> at only a small level of effort to write this wrapper (which is
>> probably half an hour).
>
>
> Having the DXVA context as public API is a bit of a hindrance with respect
> to updates obviously. Although given that the context is already there from
> a usability and functionality stand point it would be better to have an
> updated version than rely on users to write their own code to get around it
> (kind of goes in the category of whats the point of having it if people
> have to write around it in the first place).

The context always needs to be public API, or you couldn't use/fill it
(or you use an opaque context with AVOptions, but I really don't like
passing pointers through AVOptions).
That in itself isn't terrible, as we have plenty public contexts. The
problem is that the size is also part of the ABI right now - which
means you cannot even extend it by adding new fields.
Obviously a better design would be if at least it had an allocation
function, so that it could be extended with new fields at the end
freely, without violating the ABI - but while we can introduce that
function now, we still cannot change the size of the struct until a
major bump.

>
> But that said I understand version bumps are a pain so anything that can
> avoid that would be recommended (worst case an additional dx11_context?).
> Also given that the existing context only contains pointers for DX related
> stuff (like the D3D9 surface) if a version bump is out of the question then
> would it be suitable to perhaps use the existing context but change the
> types pointed to internally (i.e. if DX11 then treat as D3D11 surface
> internally etc.)? Just trying to think of alternatives here.

D3D11 needs one additional pointer at least (ie. instead of only the
decoder, it needs a decoding context and a decoder), so you cannot
cheat it like that, not without really evil hackery.

As a kind-of-maintainer of the DXVA2 code (really just the only one
who touched it over the last few years), I'm not sure I would like to
see a hack solution just to get it working right now.
The approach I suggested has the added benefit that it works with any
past version of ffmpeg as well, so there is no need to hurry in
anything now, and we could think about supporting both cleanly and in
parallel in the future.

- Hendrik