
<html><head></head><body>Hi,<br><br>As Alexandre already pointed out, vlc-devel is not the place to discuss the features and internals of YoutubeDL.<br><br>The whole point of this patchset is to use YoutubeDL as is and through supported API's.<br><br><div class="gmail_quote">Le 23 septembre 2020 01:20:08 GMT+03:00, Pierre Ynard via vlc-devel <vlc-devel@videolan.org> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Wait I just noticed that in at least some if not all cases, it<br>actually connects to the website, sends a HEAD then a GET request,<br>and downloads the whole page, before figuring out that the website<br>is unsupported and exiting?! That's some god-awful and rather<br>pointless overhead, why??<br></blockquote><a href="https://github.com/ytdl-org/youtube-dl/blob/master/README.md#how-can-i-detect-whether-a-given-url-is-supported-by-youtube-dl">https://github.com/ytdl-org/youtube-dl/blob/master/README.md#how-can-i-detect-whether-a-given-url-is-supported-by-youtube-dl</a><br></blockquote><br>Okay, I figure. It's actually sensible - in the context of a standalone<br>tool that tries to do the best of what it's given. Not so much for one<br>of several VLC modules.<br><br>I'm going to assume that it sends a HEAD request to check the content<br>type or other headers, and downloads and parses it only if it's a web<br>page or something it has a chance to extract a supported stream from.<br>So far that makes sense, because apart from the similar lua playlist<br>feature, VLC doesn't aim to play HTML anyway.<br><br>However youtube-dl will also "support" URLs such as web radio streams,<br>or even plain static media files: it will return their own URL. (By<br>default the youtube-dl executable attempts to download them, even for an<br>infinite web radio stream...) It's good to have something to prevent the<br>recursion that would ensue, but it would be better if the design wasn't<br>prone to it in the first place: maybe the access or helper script can<br>check if the returned URL is identical to the input one, and fail in<br>that case.<br><br>That's not all though. Apparently youtube-dl will download and parse a<br>lot of stuff, for example text files; or also M3U playlists, apparently<br>as M3U8, so not properly. From what I understand, this plain breaks<br>existing support for M3U hosted over HTTP, which would be a showstopper.<br>And I don't know what else it would interfere with and in what measure<br>it would prevent other VLC modules or features from working properly:<br>basically, potentially anything in the codebase that creates a VLC<br>stream. I don't feel comfortable about that.<br><br>To come back to the performance issue, between launching the Python<br>script and hitting the URL over the network, the ytdl access module<br>can add in the order of one second of delay on the main HTTP path -<br>when things go right. Saying that my computer must be slow is just an<br>indication that we lack an accurate estimation to discuss whether the<br>impact would be acceptable.<br><br>I'd like to have youtube-dl in VLC, but those are serious integration<br>issues linked to youtube-dl's design. I hope we can work them out.<br>Maybe something like what Marvin suggested can help. Maybe the default<br>behavior can also be limited, requiring explicitly enabling an option to<br>let youtube-dl attempt to leverage its full feature set.<br></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>