[vlc-devel] [vlc-commits] skins2: ensure playlist gets stopped before terminating vlc.

[Alexandre Janniaux]

Hi,

I was talking about this:

commit 64fcc45a149bb553b59e6ed902edd6bc57a09ac5
Refs: 4.0.0-dev-5623-g64fcc45a14
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.

Regards,
--
Alexandre Janniaux
Videolabs


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 Qt rewrite.
>
> Le 3 décembre 2019 01:03:52 GMT+02:00, Alexandre Janniaux <ajanni at videolabs.io> a écrit :
> >Hi,
> >
> >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 a
> >é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 an
> >> interface, not the stand-alone ones, and thus it should be handled by
> >the
> >> 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 just
> >that
> >> 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 for
> >this.
> >
> >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 code,
> >which is
> >> the most obvious but not the only symptomatic case. This really is a
> >problem
> >> 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?
> >
> >Regards,
> >--
> >Alexandre Janniaux
> >Videolabs
> >_______________________________________________
> >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