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

Rémi Denis-Courmont remi at remlab.net
Fri Oct 4 08:50:43 CEST 2019


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 :
>What I wrote for the window provider basically inserts a different
>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:
>Reversing the dependency between vout_thread and vout_window seems
>against what
>we designed, decided and implemented from the window workshop of this
>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
>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
>with simplicity or sanity, but I fail to see how. Would you have any
>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
>> 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:

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/20191004/2be2f24a/attachment.html>

More information about the vlc-devel mailing list