Re: GStreamer xwidget

[Alexandre Garreau <galex-713@galex-713.eu>]

Le merkredo, 1-a de decembro 2021, 8-a horo kaj 7:47 CET Richard Stallman 
a écrit :
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> I just saw some messages from Saturday that I had overlooked while
> falling behind.
> 
>   > >   > It depends on GStreamer, gst-plugins-base, and
>   > >   > gst-plugins-good and is
>   > >   > thus a compile-time option.
>   > 
>   > The plugins that this change takes advantage of will only stream
>   > free
>   > software, as it doesn't depend on gst-plugins-ugly or
>   > gst-plugins-bad.
> 
> Can you please show me how Emacs invokes get-plugins-good?
> How does that function specify plugins to use?
> 
>   > > We also have to think about whether it is good or bad to introduce
>   > > this nonmodularity.  What is better about showing videos this way,
>   > > rather than just launching vlc in another window?
>   > 
>   > People seem to want that in Emacs.
> 
> That's not a very convincing reason.

Windowing is confusing, while embeding is more ergonomic, because it’s 
more straightforward to figure out/remember where things are, since they’re 
more related/constrained

>   > Reading web pages that have embedded videos is quite common.
> 
> Those videos are very often links to Youtube, which depend on running
> nonfree JS code.    If the aim of linking with GStreamer is to make
> those embedded Youtube videos work in Emacs, we should not do it!
> 
> Unless we can bypass the JS code of Youtube.
> 
> We may be able to do that, if we make those embedded video links
> automatically talk to invidious proxies rather than to youtube.
> 
> Can someone see how to implement that?

It would be better to mimick mpv or vlc in that respect, and use youtube-
dl or libquvi to get the direct links to the streams, and give that to 
gstreamer.  It would avoid an intermediary (what if the invidious proxy is 
malicious, requires a proprietary captcha, is overloaded, or stops 
working?).  Plus youtube-dl would allow that to work with most streaming 
platforms, not only youtube.  And youtube-dl devs are really active and do 
most of the up-to-date work of reverse engineering to keep those working 
correctly.

Isn’t that how ViewTube used to work?