[vlc-devel] [PATCH v3 09/14] libvlc: allow selecting the video hardware acceleration

[Steve Lhomme]

On 2020-02-17 13:06, Alexandre Janniaux wrote:
> Hi,
> 
> On Fri, Feb 14, 2020 at 07:58:32AM +0100, Steve Lhomme wrote:
>> On 2020-02-13 18:56, Rémi Denis-Courmont wrote:
>>> Le torstaina 13. helmikuuta 2020, 17.44.50 EET Steve Lhomme a écrit :
>>>> The values in the enum reflect the currently available decoder devices.
>>>> ---
>>>>    include/vlc/libvlc_media_player.h | 53 +++++++++++++++++++++++++++++++
>>>>    lib/libvlc.sym                    |  1 +
>>>>    lib/media_player.c                | 22 +++++++++++++
>>>>    3 files changed, 76 insertions(+)
>>>>
>>>> diff --git a/include/vlc/libvlc_media_player.h
>>>> b/include/vlc/libvlc_media_player.h index 5e0255a10ac..ad19c383a0c 100644
>>>> --- a/include/vlc/libvlc_media_player.h
>>>> +++ b/include/vlc/libvlc_media_player.h
>>>> @@ -503,6 +503,59 @@ void libvlc_video_set_format_callbacks(
>>>> libvlc_media_player_t *mp, libvlc_video_cleanup_cb cleanup );
>>>>
>>>>
>>>> +/**
>>>> + * Enumeration of the Video hardware processing acceleration to be used.
>>>> + * can be passed to @a libvlc_video_set_video_acceleration
>>>> + */
>>>> +typedef enum libvlc_video_acceleration_t {
>>>
>>> No way.
>>>
>>> Plugins come and go. They can be added externally, or with new versions, they
>>> can be removed, and of course, they depend on the platform and build options.
>>> They cannot be described with an enum.
>>
>> The documentation says there's no guarantee it will be respected. Most
>> people will never need to touch this. Those who do that's because they have
>> a reason to do it.
> 
> People having a reason to do this might use the options as well
> or provide additional API through another libvlccore wrapper.
> 
> Using this feature could be nice but it could probably provide
> a list of accepted identifiers (strings or richer opaque structure)
> instead of relying on an enum. It will provide a clearer API and
> more stable over time, but I wonder what cost it implies on the
> user in term of complexity, like making application work with
> HW acceleration on a platform but silently disable it on another.
> 
> I also don't think that this feature really makes a lot of sense
> as a libVLC user because it's too low level for the majority of
> cases, but I'm not really sure what simpler concept could be
> exposed instead.
> 
> What use case do you have that is not solved by the automatic
> probing ?

NVDEC. There's no way for the user to tell if it's there or not and 
usable or not. It may support more formats that DXVA or VAAPI (even if 
less efficient copy-wise).

On Windows it's also possible to force D3D11VA on Win7.

On Linux I suppose it would also be nice to be able to pick between 
VAAPI, VDPAU (and MMAL) to test the performance of each.

A string might be enough:
"any", "none", "d3d11va", "nvdec,d3d11va", etc