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

[Steve Lhomme]

On 2020-03-17 12:15, Rémi Denis-Courmont wrote:
> 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.

OK but there's still the other cases I mentioned.

>>> 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".

What is the rationale for vmem to disable hardware decoding ? From the 
code it sets the (CPU) chroma expected by the receiver. That doesn't 
mean a converter shouldn't be introduced by the core to handle it. In 
fact if the chroma is not I420 (RGB for example) there's a very high 
chance a converter will be introduced, even without hardware acceleration.

It's just because it might slow down the time to get the first decoded 
frame ?