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

Thomas Guillem thomas at gllm.fr
Wed Apr 3 10:11:36 CEST 2019


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


More information about the vlc-devel mailing list