[vlc-devel] [PATCH 1/3] player: add "vout window" context getter/setter

[Thomas Guillem]

On Wed, Apr 3, 2019, at 15:37, Rémi Denis-Courmont wrote:
> 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.

I don't remember: is it planned for 4.0 ?

> 
> 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 a 
>>>>>>> écrit :
>>>>>>>>  This will be used by the libvlc media_player (when we switch from
>>>>>>>>  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 need to
>>>>  create multiple window. It was in the multiple vout/multiple ES mapping
>>>>  with callback discussion, within the context of a mosaic output with
>>>>  opengl rendering.
>>>> 
>>>>  iirc, what has been said is mostly that each view of the mosaic would be
>>>>  a different video output and a different window which defines either a
>>>>  subsurface/subwindow or a viewport. The vout window provider was the
>>>>  mechanism to provide that. I'm not sure we defined anything else about
>>>>  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 that is
>>>>  not needed right now. So maybe we can use one of the suggested
>>>>  solution, even if marking it as deprecated right now, and refactor it
>>>>  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 it 
>>> should be done now.
>> 
>> No matter what we decide in VLC Core, we won't touch the following  LIBVLC API:
>>       - 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:
>>> https://mailman.videolan.org/listinfo/vlc-devel
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>> https://mailman.videolan.org/listinfo/vlc-devel
> 
> -- 
> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté. 
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190403/e0194e41/attachment.html>