[vlc-devel] [PATCH 2/4] ytdl: access module for YoutubeDL

[Pierre Ynard]

> > Wait I just noticed that in at least some if not all cases, it
> > actually connects to the website, sends a HEAD then a GET request,
> > and downloads the whole page, before figuring out that the website
> > is unsupported and exiting?! That's some god-awful and rather
> > pointless overhead, why??
> 
> https://github.com/ytdl-org/youtube-dl/blob/master/README.md#how-can-i-detect-whether-a-given-url-is-supported-by-youtube-dl

Okay, I figure. It's actually sensible - in the context of a standalone
tool that tries to do the best of what it's given. Not so much for one
of several VLC modules.

I'm going to assume that it sends a HEAD request to check the content
type or other headers, and downloads and parses it only if it's a web
page or something it has a chance to extract a supported stream from.
So far that makes sense, because apart from the similar lua playlist
feature, VLC doesn't aim to play HTML anyway.

However youtube-dl will also "support" URLs such as web radio streams,
or even plain static media files: it will return their own URL. (By
default the youtube-dl executable attempts to download them, even for an
infinite web radio stream...) It's good to have something to prevent the
recursion that would ensue, but it would be better if the design wasn't
prone to it in the first place: maybe the access or helper script can
check if the returned URL is identical to the input one, and fail in
that case.

That's not all though. Apparently youtube-dl will download and parse a
lot of stuff, for example text files; or also M3U playlists, apparently
as M3U8, so not properly. From what I understand, this plain breaks
existing support for M3U hosted over HTTP, which would be a showstopper.
And I don't know what else it would interfere with and in what measure
it would prevent other VLC modules or features from working properly:
basically, potentially anything in the codebase that creates a VLC
stream. I don't feel comfortable about that.

To come back to the performance issue, between launching the Python
script and hitting the URL over the network, the ytdl access module
can add in the order of one second of delay on the main HTTP path -
when things go right. Saying that my computer must be slow is just an
indication that we lack an accurate estimation to discuss whether the
impact would be acceptable.

I'd like to have youtube-dl in VLC, but those are serious integration
issues linked to youtube-dl's design. I hope we can work them out.
Maybe something like what Marvin suggested can help. Maybe the default
behavior can also be limited, requiring explicitly enabling an option to
let youtube-dl attempt to leverage its full feature set.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."