[vlc-devel] [PATCH 04/17] dxva: split the directx related parts from the pool/va parts

[Steve Lhomme]

On Wed, Jun 21, 2017 at 9:16 AM, Rémi Denis-Courmont <remi at remlab.net> wrote:
> Le 21 juin 2017 09:46:37 GMT+03:00, Steve Lhomme <robux4 at gmail.com> a écrit
> :
>>
>> On Tue, Jun 20, 2017 at 6:31 PM, Rémi Denis-Courmont <remi at remlab.net>
>> wrote:
>>>
>>>  Le tiistaina 20. kesäkuuta 2017, 17.45.36 EEST Steve Lhomme a écrit :
>>>>
>>>>  ---
>>>>   modules/codec/Makefile.am                   |   2 +
>>>>   modules/codec/avcodec/d3d11va.c             |  89 ++++++-------
>>>>   modules/codec/avcodec/directx_va.c          | 151
>>>> +--------------------
>>>>   modules/codec/avcodec/directx_va.h          |  49 +------
>>>>   modules/codec/avcodec/dxva2.c               |  76 +++++------
>>>>   modules/codec/avcodec/va_surface.c          | 198
>>>>  ++++++++++++++++++++++++++++ modules/codec/avcodec/va_surface.h
>>>> |
>>>>  41 ++++++
>>>>   modules/codec/avcodec/va_surface_internal.h |  91 +++++++++++++
>>>
>>>
>>>  IMO, unfortunate files naming for DX-specific stuff insofar as the
>>> directory
>>>  is not DX- nor Windows-specific.
>>
>>
>> It's on purpose. The goal being that all libavcodec va use this in the
>> end. The algorithm and logic is the same as what is found in VDPAU.
>> After refactoring the code I manage to use the same thing.
>>
>> Still undetermined is whether the context is responsible for freeing
>> the surfaces and associated resources. Or when closing the module. In
>> VDPAU it's the former and in my code the latter.
>>
>>>  --
>>>  雷米‧德尼-库尔蒙
>>>  https://www.remlab.net/
>>>
>>> ________________________________
>>>
>>>  vlc-devel mailing list
>>>  To unsubscribe or modify your subscription options:
>>>  https://mailman.videolan.org/listinfo/vlc-devel
>>
>> ________________________________
>>
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
>
>
> Are you sure that the design fits well with the latest libavcodec hwaccel
> framework? Currently, VLC uses the previous generation.

No I'm not. But I don't think we'll be supporting it soon since we
need to be able to compile VLC 3.0 on some not too old FFmpeg. And we
don't want to support 2 incompatible implementations for the same
thing.

I don't think it will change the fact that we'll pass the opaque
surfaces in the context with the current structures anyway. And with
more common code, that will be less to adapt in the future.

> --
> Rémi Denis-Courmont
> Typed on an inconvenient virtual keyboard
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel