[vlc-devel] [PATCH v4 5/7] libvlc: don't force "dec-dev" with libvlc_media_player_set_xwindow()

Rémi Denis-Courmont remi at remlab.net
Tue Mar 17 12:15:29 CET 2020

Le tiistaina 17. maaliskuuta 2020, 12.27.52 EET Steve Lhomme a écrit :
> >> Even if not removed, for technical reasons yet to determine, it can use
> >> the set_hw_acceleration() API instead of this call.
> > 
> > No. There are zero reasons why the application developpers should have to
> > care about this implementation detail of LibVLC.
> At the very least we should be able to enable/disable hardware decoding.

Forcefully disable, maybe. Forcefully enable, no way. There are just too many 
variables involved in deciding when/how to use hardware acceleration, to 
reduce it to a boolean.

> In some cases it doesn't work properly and users may decide not to use it.

> In custom builds some people may decide they only want NVDEC because
> they want a particular GPU/driver to be used and maybe even provide some
> CUDA modules of their own. Or for example to support HEVC 444 decoding
> which DXVA2/D3D11VA doesn't provide for the same GPU.

Again and again and again, custom builds are *not* a criteria for LibVLC API 
design. You can do whatever you want in your custom builds, including freely 
messing with the API. Nobody is going to prevent that.

> > Loading VLC plugins is not free, especially those involving display
> > drivers.
> Correct but I don't see the link with the rest of the discussion.

It justifies the fact that changing the windowing mode changes the hardware 
acceleration. This includes vmem forcefully turning off probing hardware 
acceleration.  This could in the future include skipping hardware 
accelerations that are known incompatible with a given window type, especially 
if the plugin is slow to "fail safe".

Rémi Denis-Courmont

More information about the vlc-devel mailing list