[vlc-devel] [PATCH 1/3] player: add "vout window" context getter/setter
remi at remlab.net
Wed Apr 3 15:37:14 CEST 2019
LibVLC needs to support the callbacks approach. The most common use case is for the application to only allocate a window when needed (like Qt VLC does).
The existing APIs should be retained, but they can be backward compatibility wrappers around the callbacks. As such, there are no needs for the VLC player / input manager to support the existing/old APIs.
Le 3 avril 2019 11:11:36 GMT+03:00, Thomas Guillem <thomas at gllm.fr> a écrit :
>On Wed, Apr 3, 2019, at 10:09, Steve Lhomme wrote:
>> On 4/2/2019 2:21 PM, Alexandre Janniaux wrote:
>> > Hi,
>> > On 2019-04-02 12:49, Steve Lhomme wrote:
>> >> On 4/2/2019 9:15 AM, Thomas Guillem wrote:
>> >>> On Mon, Apr 1, 2019, at 17:24, Rémi Denis-Courmont wrote:
>> >>>> Le maanantaina 1. huhtikuuta 2019, 14.21.42 EEST Thomas Guillem
>> >>>> écrit :
>> >>>>> This will be used by the libvlc media_player (when we switch
>> >>>>> input_thread_t to vlc_player_t).
>> >>>>> This will be used by the following libvlc calls:
>> >>>>> - libvlc_media_player_set_nsobject
>> >>>>> - libvlc_media_player_set_xwindow
>> >>>>> - libvlc_media_player_set_hwnd
>> >>>>> - libvlc_media_player_set_android_context
>> >>>> No it won't. We agreed at the last meeting to use callbacks.
>> >>> I don't remember.
>> >> I don't remember talking about making any changes there either.
>> >> _______________________________________________
>> >> vlc-devel mailing list
>> >> To unsubscribe or modify your subscription options:
>> >> https://mailman.videolan.org/listinfo/vlc-devel
>> > In my notes, I had a mention of a "vout window provider" when we
>> > create multiple window. It was in the multiple vout/multiple ES
>> > with callback discussion, within the context of a mosaic output
>> > opengl rendering.
>> > iirc, what has been said is mostly that each view of the mosaic
>> > a different video output and a different window which defines
>> > subsurface/subwindow or a viewport. The vout window provider was
>> > mechanism to provide that. I'm not sure we defined anything else
>> > it.
>> > In the context of this thread, it would solve the issue for the Qt
>> > window context, but I would say it needs an additional refactor
>> > not needed right now. So maybe we can use one of the suggested
>> > solution, even if marking it as deprecated right now, and refactor
>> > out later to define and introduce this concept?
>> No sure we want to change the libvlc API's yet again for VLC 5.0. IMO
>> should be done now.
>No matter what we decide in VLC Core, we won't touch the following
> - libvlc_media_player_set_nsobject
> - libvlc_media_player_set_xwindow
> - libvlc_media_player_set_hwnd
> - libvlc_media_player_set_android_context
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the vlc-devel