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

[Steve Lhomme]

Also on a side note with regards to cleaning. It seems there is now
overlapping between picture_context_t and picture_sys_t. They seem to
serve the same storage purpose but with different owners (decoder vs
vout). I think it should be possible to use only one of them.

On Wed, Jun 21, 2017 at 9:31 AM, Steve Lhomme <robux4 at gmail.com> wrote:
> 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