[vlc-devel] [PATCH 09/39] vout: request the display with a decoder device

[Alexandre Janniaux]

Hi,

That's indeed a pivotal point to tackle, but it's probably not an
issue in this design.

The main point of window providing is that you don't have to actually
close the native window when the vout_window is closed by the core.

Audio visualization are creating a vout_thread, which creates a window
so this doesn't conflict with this AFAIK.

I planned this construction so mosaic can be implemented as a video
splitter, itself of which could be able to handle multi-track video
instead of splitting only one track in the future. This was a subject
we discussed during the window workshop of this year too.

Regards,
--
Alexandre Janniaux
Videolabs

On Fri, Oct 04, 2019 at 09:50:43AM +0300, Rémi Denis-Courmont wrote:
> Hi,
>
> That can't work since the window may not have a vout or may outlive the vout, notably with audio visualization.
>
> Le 4 octobre 2019 00:36:30 GMT+03:00, Alexandre Janniaux <ajanni at videolabs.io> a écrit :
> >Hi,
> >
> >What I wrote for the window provider basically inserts a different
> >providing
> >method in vout_Create which is conveyed from the interface by a
> >vlc_player_SetWindowProvider function call.
> >
> >It means that the vout_thread is still the one creating the window, and
> >it is
> >far simpler to handle core callbacks of display windows.
> >
> >I'll send a proper branch as soon as everything is supported, but you
> >can check
> >a WIP state here:
> >https://github.com/alexandre-janniaux/vlc/commit/88ab28d920423764a47728c54f73e58377e380b2
> >
> >Reversing the dependency between vout_thread and vout_window seems
> >against what
> >we designed, decided and implemented from the window workshop of this
> >year.
> >Ideas like vout dummy came exactly from the fact that we want the
> >vout_thread to
> >be configurable before any window exists and actually runs.
> >
> >About the decoder device going from the vout to the decoder, being
> >understood
> >that it represents the graphics device resources location that should
> >be used to
> >do the drawing and synchronize the whole pipeline on it, it seems to me
> >a rather
> >good idea that it comes from the window (graphical resource allocator)
> >and thus
> >the vout thread when it comes to what comes intuitively. It might not
> >match
> >with simplicity or sanity, but I fail to see how. Would you have any
> >hints?
> >
> >
> >
> >On Thu, Oct 03, 2019 at 09:51:30PM +0300, Rémi Denis-Courmont wrote:
> >> Le keskiviikkona 2. lokakuuta 2019, 17.23.24 EEST Steve Lhomme a
> >écrit :
> >> > NULL for now, it will turn into a video context once we pass it
> >from the
> >> > decoder.
> >>
> >> In the normal playback case (not encoder), the decoder device is
> >supposed to
> >> stem from the window. The window is supposed to stem from the player,
> >via a
> >> yet-to-be-written player owner callback. One consequence is that the
> >vout will
> >> eventually have to stem from the window, rather than the other way
> >around in
> >> the current limbo.
> >>
> >> And then, it's not obvious at all that the decoder device should go
> >from the
> >> vout to the decoder. It's possible, but I'm not sure that's the
> >simplest/
> >> sanest approach.
> >>
> >> --
> >> レミ・デニ-クールモン
> >> http://www.remlab.net/
> >>
> >>
> >>
> >> _______________________________________________
> >> 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