[FFmpeg-devel] DXVA Question.

Matt Oliver protogonoi at gmail.com
Sun Apr 26 12:52:35 CEST 2015


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

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.

Either way I would recommend atleast putting a patch up as people might be
able to work around it and then its publicly available on the mailing list
for those that want to apply it to their local repos anyway (assuming its
not to much effort). Or at the very least ready and waiting for when FFmpeg
has to do a version bump anyway.

PS. Big fan of Kodi ;)


More information about the ffmpeg-devel mailing list