[vlc-devel] [PATCH 04/17] dxva: split the directx related parts from the pool/va parts
Steve Lhomme
robux4 at gmail.com
Wed Jun 21 09:33:15 CEST 2017
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
More information about the vlc-devel
mailing list