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

[Rémi Denis-Courmont]

Hi,

As Alexandre already pointed out, vlc-devel is not the place to discuss the features and internals of YoutubeDL.

The whole point of this patchset is to use YoutubeDL as is and through supported API's.

Le 23 septembre 2020 01:20:08 GMT+03:00, Pierre Ynard via vlc-devel <vlc-devel at videolan.org> a écrit :
>> > 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."
>_______________________________________________
>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/20200923/45b819cd/attachment.html>