[vlc-devel] [PATCH v4 5/7] libvlc: don't force "dec-dev" with libvlc_media_player_set_xwindow()
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".
More information about the vlc-devel