[vlc-devel] [vlc-commits] skins2: ensure playlist gets stopped before terminating vlc.
remi at remlab.net
Tue Dec 3 11:19:11 CET 2019
And? That's not what caused the current skins issue. This is literally just removing one useless layer of indirection - nonfunctional change.
Le 3 décembre 2019 10:50:00 GMT+02:00, Alexandre Janniaux <ajanni at videolabs.io> a écrit :
>I was talking about this:
>Author: Rémi Denis-Courmont <remi at remlab.net>
>AuthorDate: Sat Dec 1 17:54:41 2018 +0200
>Commit: Rémi Denis-Courmont <remi at remlab.net>
>CommitDate: Sun Dec 2 19:57:32 2018 +0200
> qt: move window code
> This removes one layer of function calls. This also removes the old
> check for interface destroyed before window, which would not work
> properly, since most vout displays cannot cope with their window going
> away asynchronously.
>I don't mean that it is wrong, but that I never saw a
>correct implementation done with the core.
>On Tue, Dec 03, 2019 at 09:40:57AM +0200, Rémi Denis-Courmont wrote:
>> I did not remove my and Laurent's hacks there. There were removed by
>the people who merged the last playlist rewrote and/or the half-baked
>> Le 3 décembre 2019 01:03:52 GMT+02:00, Alexandre Janniaux
><ajanni at videolabs.io> a écrit :
>> >On Mon, Dec 02, 2019 at 07:05:13PM +0200, Rémi Denis-Courmont wrote:
>> >> Le maanantaina 2. joulukuuta 2019, 10.20.15 EET Alexandre Janniaux
>> >écrit :
>> >> > Hi,
>> >> >
>> >> > Actually stopping the playlist wont kill the video output
>> >> > module, only killing the input resource, meaning releasing
>> >> > the vlc_player will do.
>> >> >
>> >> > However, player and playlist might be used by multiple
>> >> > control interface and this problem is only a concern for
>> >> > the one providing the vout_window. Hence I believe it must
>> >> > be solved by the mechanism providing the window instead of
>> >> > relying on a much wider API like playlist and player.
>> >> By the same logic, it's only a problem for the window provider of
>> >> interface, not the stand-alone ones, and thus it should be handled
>> >> interface. Obvious logical flaw is obvious.
>> >I'm sorry, I tried, but I really don't understand neither what
>> >you call obvious nor your example. Can you provide details ?
>> >> Besides, technically there is already a way to handle this. It's
>> >> interface implementors cannot be bothered (UI frameworks make it
>> >hard) to
>> >> handle the window being allocated before the interface, or
>> >deallocated after
>> >> the interface. At the core level, everything is already in place
>> >Which one ? The issue has been fighting here for years with
>> >hacks that you removed because they were hacks. I never saw
>> >an interface working with this design in the ML archive.
>> >> And I really don't see how you can fix that in the video window
>> >which is
>> >> the most obvious but not the only symptomatic case. This really is
>> >> between the playlist and the main interfaces.
>> >Why ? I started working on this month ago and while I'm not
>> >full time on this, I see only a simple problem: interface and
>> >window share a common context, so you cannot kill the
>> >interface resource before the window. Either you make the
>> >interface resource refcounted and living in the wild while
>> >there still are window using those, or you make correct
>> >resource management and manage the lifetime correctly.
>> >I detailed the issue, suggested a solution and have half a PoC.
>> >What is the issue that you're trying to solve and how?
>> >Alexandre Janniaux
>> >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é.
>> vlc-devel mailing list
>> To unsubscribe or modify your subscription options:
>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...
More information about the vlc-devel