youtube-dl fallback for sources not recognized/added

[twilight-sparkle-irl]

This would be probably not too hard, seeing as youtube-dl has an embedding API, and the benefits would be...quite frankly ridiculously large. seeing as this would fix the need for a userscript to watch Google Drive videos, and around a thousand websites would work suddenly.

[Xaekai]

The YouTube-DL embedding API is just a fancy way of saying that it lends itself being embedded into other python applications. It's not meant for browser usage

[twilight-sparkle-irl]

Oh, yeah, I figured the server would be able to embed it...which on second thought, may cause a few issues.

[calzoneman]

To extend what was mentioned above about the youtube-dl documentation using a different sense of the word "embed" than the website meaning, it isn't of much help to CyTube because youtube-dl is used to download a video locally whereas for website usage it needs to be available to every user.

You could invoke youtube-dl on the server to download the video, but I have a rule against hosting any type of video content on the CyTube server itself (bandwidth costs are prohibitively expensive and I don't want the liability of hosting videos that may violate my server host's acceptable use policy or USA law).

You could invoke youtube-dl to extract just the metadata and pass the URL along to clients, but this comes with its own problems, as many websites' video links are IP or time-bound and aren't generally shareable across clients -- which is the reason the Drive userscript has to exist currently.

In principle, support for thousands of websites could be considered a feature, but in recent years I've come to see it as more of a burden than anything. Yes, maintaining the existing dozen APIs requires some effort, but at the very least there is some level of commitment from the provider in terms of how the API works (they are relatively stable), and it weeds out a lot of sketchy porn sites, Russian warez sites, and other garbage I'd rather not consider an "officially supported" source by virtue of only whitelisting specific providers.

Google Drive hails from a bygone era where I was experimenting more to see what would stick and in hindsight I really wish I hadn't tried to support it because it built up an expectation of it working among users while being a pain in the ass to support because it's not really a documented API.

If you are curious, I think someone in IRC has developed a script to expose a subset of youtube-dlable sites via the custom media manifest support (intended for self-hosted content, so I won't provide any support if you choose to expose someone else's content through it as noted on that specification, but I guess it's an option).

[twilight-sparkle-irl]

Hmm, I was suggesting the URL metadata extraction, but that's true.

I figured it wouldn't be supported officially as long as if anyone asked, you pointed at youtube-dl -- "it just happens to support that" isn't your fault.

...Also, fair on the "wishing you didn't support Google Drive thing" -- while it's the most useful thing for uploading content without having to deal with youtube, in a perfect world everyone would be using AWS or some such.

I would wish for a port of youtube-dl to JS for christmas, but the closest we'll get is maybe an API for the custom media manifest, or an emscripten port (seeing as you need ffmpeg)

[calzoneman]

Ideally I'd like to avoid having to explain to people that certain links they might paste in are "kinda" supported as in you can try it but it might not work -- a lot of people I talk to in IRC or email don't have a clear understanding of what problem they're having and sometimes it can take 15-20 minutes of my time just to determine that the problem they're having is caused by something that's not under my control (most commonly, a browser extension). I consider most support contacts to be a defect -- even if it's not a bug in my code, it means the resulting behavior or error reporting was insufficient to help the user help themselves understand or resolve the problem.

If you want to surface 3P content via custom media, you at least have some understanding of what you're getting into because the barrier to entry is higher than "pasting a link", and you probably have enough tech savvy to distinguish between bugs in the service vs. things that don't work because you did something unsupported / the website you tried to embed doesn't expose compatible videos.

[calzoneman]

As an aside, I've already seen this situation unfold once when I added support for raw files (ffprobing mp4 links to grab the metadata) -- I've since added quite a few checks for various common error scenarios, but I still occasionally get asked about a broken link that winds up being a misconfigured server or a link to an HTML page etc., despite only "officially" supporting self-hosted files via this mechanism.

[twilight-sparkle-irl]

Ooof. Perhaps I'll make a fork for "supporting more experimental behavior" so that it's not on cytu.be and not confusing everyone.

[kr4ssi]

I did it by Xaekai's Bot: https://github.com/kr4ssi/PonkBot/blob/master/balloons/ponk_add.js

Hit me up on the cytube-irc if you got any questions.