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

[Rémi Denis-Courmont]

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
>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é.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20190403/5836c1f3/attachment.html>