On 26 April 2015 at 18:01, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
> On Sun, Apr 26, 2015 at 8:45 AM, Anton Fedchin <anigh...@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 ;) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
