[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


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é.
-------------- 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