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

Steve Lhomme robux4 at ycbcr.xyz
Tue Mar 17 11:27:52 CET 2020


On 2020-03-17 9:05, Rémi Denis-Courmont wrote:
> Le tiistaina 17. maaliskuuta 2020, 8.56.44 EET Steve Lhomme a écrit :
>> On 2020-03-16 17:40, Rémi Denis-Courmont wrote:
>>> Le maanantaina 16. maaliskuuta 2020, 12.14.22 EET Steve Lhomme a écrit :
>>>> On 2020-03-16 11:01, Rémi Denis-Courmont wrote:
>>>>> Le maanantaina 16. maaliskuuta 2020, 10.48.13 EET Steve Lhomme a écrit :
>>>>>> On 2020-03-13 16:46, Rémi Denis-Courmont wrote:
>>>>>>> Le perjantaina 13. maaliskuuta 2020, 14.28.36 EET Steve Lhomme a écrit
> :
>>>>>>>> It should use the default value or the one set with
>>>>>>>> libvlc_video_set_hw_acceleration().
>>>>>>>
>>>>>>> "" *is* the default value.
>>>>>>
>>>>>> If that's the case the current code would be a no-op. But it's not. If
>>>>>> you set the --dec-dev in the libvlc command-line, using set_xwindow()
>>>>>> resets that value, for no particular reason.
>>>>>
>>>>> Actually, it resets that value for very particular reasons - re-enabling
>>>>> the X11 accelerations that vmem disabled.
>>>>
>>>> It should be removed as well.
>>>
>>> No.
>>
>> 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. 
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.

On Win7 DXVA2 is used but the coder might prefer to use D3D11 which 
supports shaders and better colour handling.

On Linux it's probably better to use VAAPI for some vendors and VDPAU 
with some others.

I agree we should provide good default but we'll probably never cover 
everything.

> And even setting the decoder device explicitly depending on the video window
> embedded regime becomes no longer "necessary" for correct functionality, it
> remains highly desirable for performance reasons.

Yes although for the reasons given above there can be cases where the 
default value is not the best.

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


More information about the vlc-devel mailing list