In ten years time YouTube will be entirely inaccessible from the browser as the iPad kids generation are used to doomscrolling the tablet app and Google feels confident enough to cut off the aging demographic.
I think because it cost money and they get little benefit on doing so.
Major platform like Netflix etc. don't implement that DRM since they care, it's because they content they distribute requires that they employ that measures, otherwise who produces the content doesn't give it to them. Content on YouTube does not have this requirement.
Also: implementing a strict DRM on all videos is probably bad for their reputation. That would restrict the devices that are able to play YouTube, and probably move a lot of content creators on other platforms that does not implement these requirements.
For a long time, yt-dlp worked completely with Python. They implemented a lightweight JavaScript interpreter that could run basic scripts. But as the runtime requirements became more sophisticated it struggled to scale
More and more recently with youtube, they seem to be more and more confrontational with their users, from outright blocking adblockers, which has no bearing on youtube's service, to automatically scraping creators content for AI training and now anything API related. They're very much aware that there is no real competition and so they're taking full advantage of it. At the expense of the 'users experience' but these days, large companies simply don't suffer from a bad customer experience anymore.
adblocking "users" are not Youtube's users. What do you mean blocking ads has no bearing on their service? It sounds like you are saying user experience is "I should get this for free".
It's quite worrying. A sizeable chunk of cultural and educational material produced in the last decade is in control of greedy bastards who will never have enough. Unfortunately, downloading the video data is only part of it. Even if we shared it all on BitTorrent it's nowhere near as useful without the index and metadata.
I use yt-dlp (and back then youtube-dl) all the time to archive my liked videos. Started back in around 2010, now I have tens of thousands of videos saved. Storage is cheap and a huge percent of them are not available anymore on the site.
I also save temporary videos removed after a time for example NHK honbasho sumo highlights which are only available for a month or so then they permanently remove them.
how do you manage the archive? I mean the file hierarchy structures etc. i started archiving youtube videos recently, now saving descriptions and other metadatas too, but simply having them all in one directory doesn't seem to be a good idea.
Perhaps a stupid question, but is there some reason I can't potentially fall back to recording my screen / audio in realtime and saving videos that way? yt-dlp is obviously far superior to this, but just thinking about what my fallback points are.
I remember when QuickTime came out in 1991 and it was obvious to everyone that video should be copied, pasted and saved like any arbitrary data.
It's absolutely insane to me how bad the user experience is with video nowadays, even video that's not encumbered by DRM or complex JavaScript clients.
I was just reading how ATSC 3 (over the air TV) is kind of stalling because they added DRM fairly late in the roll out. Several people bought receivers that are now incompatible.
> It's absolutely insane to me how bad the user experience is with video nowadays, even video that's not encumbered by DRM or complex JavaScript clients.
The video experience for typical video files is great these days compared to the past. I think you may be viewing the past through rose colored glasses. For years it was a pain to deal with video because you had to navigate third party players (remember Real Player?), Flash plugins, and sketchy codec pack installs from adware infested download sites. If you were tech support for friends and family during that era, it was common to have to remove adware, spyware, and other unwanted programs after someone went down the rabbit home of trying to install software to watch some video they found.
The modern situation where your OS comes with software to play common files or you can install VLC and play anything is infinitely better than the past experience with local video.
I remember when QuickTime came out in 1991 and it was obvious to everyone that video should be copied, pasted and saved like any arbitrary data.
I remember when VCR's came out and everyone would take TV shows and share them with their friends.
By now we should be able to share video on SD Cards that just pop into a slot on the top of the TV, but the electronics companies are now also the content companies, so they don't want to.
> It's absolutely insane to me how bad the user experience is with video nowadays
Has nothing to do with video per se. Normal embeddings, using the standard `<video>` element and no unnecessary JS nonsense, still work the same way they did in the 90s: Right click the video and download it, it's a media element like any other.
The reason why user experience is going to shite, is because turbocapitalism went to work on what was once The Internet, and is trying to turn it into a paywalled profit-machine.
A specific issue with video data is that it’s much denser: the same concept in video takes up more bytes than in text or image. Therefore hosting is more expensive, so less people host and the ones that do (e.g. YouTube) expect revenue. Furthermore, because videos are dense, people want to download them streaming, which means hosts must not just have storage but reliable bandwidth.
Even then, there are a few competitors to YouTube like Nebula, PeerTube, and Odysee. But Nebula requires a subscription and PeerTube and Odysee have worse quality, because good video hosting and streaming is expensive.
A media business is predicated on exclusive rights over their media. The entire notion of media being freely copied and saved is contrary to their business models. I think there's a healthy debate to be had over whether those models are entitled to exist and how much harm to consumers is tolerable, but it's not really obvious how to create a business that deals in media without some kind of protection over the copying and distribution of that media.
I think what breaks computer peoples' brains a bit is the idea that the bytes flying around networks aren't just bytes, they represent information that society has granted individuals or businesses the right to control and the fact technology doesn't treat any bytes special is a problem when society wants to regulate the rights over that information.
I have worked on computer systems for media organizations and they have a very different view of intellectual property than the average programmer or technologist. The people I find the most militant about protecting their rights are the small guys, because they can't afford to sue a pediatrician for an Elsa mural or something.
Experience with video is excellent for most people. All the complexity is hidden from the end user, unless you are trying to hack something. In the 1990s, streaming effectively didn't exist because people didn't have enough bandwidth (it was mostly dial-up), and there was very little legal offering, and the little that existed was terrible. Home video was limited too, as few people knew how to make video files suitable for online diffusion.
Piracy did pretty well, but that's because the legal experience was so terrible. But even then, you had to download obscure players and codec packs, and sourcing wasn't as easy as it is now. For reference VLC and BitTorrent released in 2001.
I'd say the user experience steadily improved and peaked in the mid-2010s. I think it is worse now, but if it is worse now, back then, it was terrible, for different reasons.
It took quite far into the 90's before things like truecolour displays and hardware accelerated video scaling appeared as well. Computers would struggle to view anything bigger than a postage stamp. Hard drive space was also really expensive. It started to change fast towards the end of the decade, though.
It is downloading a solver at runtime, took maybe half a second in total, downloads are starting way faster than before it seems to me.
[youtube] [jsc:deno] Solving JS challenges using deno
[youtube] [jsc:deno] Downloading challenge solver lib script from https://github.com/yt-dlp/ejs/releases/download/0.3.1/yt.solver.lib.min.js
It would be great if we could download the solver manually with a separate command, before running the download command, as I'm probably not alone in running yt-dlp in a restricted environment, and being able to package it up together with the solver before runtime would let me avoid lessening the restrictions for that environment. Not a huge issue though, happy in general the start of downloads seems much faster now.
How are you using Youtube if you feel like it is "barely working"?
I personally use Youtube almost exclusively for my entertainment. I am using Chromium on Raspberry Pi 5. I am running some flavor of uBlock, SponsorBlock, and some Shorts remover extension. It just works.
What environment are you using that:
- Has access to Youtube
- Can run Python code
- Can’t run JS code
If the concern is security, it sounds like the team went to great lengths to ensure the JS was sandboxed (as long as you’re using Deno).
If you’re using some sort of weird OS or architecture that Deno/Node doesn’t support, you might consider QuickJS, which is written in pure C and should work on anything. (Although it will be a lot slower, I’m not clear just how slow.) Admittedly, you then loose the sandboxing, although IMO it seems like it should safe to trust code being served by Google on the official Youtube domain. (You don’t have to trust Google in general to trust that they won’t serve you actual malware.)
It was just updated again today, and at least for me, when you install it using the package name "yt-dlp[default]", it already downloads both deno and the solver automatically.
Just one question. I see all these 3rd party clients solving the problem separately. Isn't it easier for everyone to build a unified decoder backend that exposes a stable and consistent interface for all the frontends? That way, it will get more attention and each modification will have to be done only once.
Since JS is the big issue here, the backend itself could be written in JS, TS or something else that compiles to WASM. That way, the decoder doesn't have to be split between two separate codebase. Deno also allows the bundle to be optionally compiled into a native executable that can run without having to install Deno separately.
Alternatively, I'm not sure if this might be an impetus to move the bulk of the codebase itself to TS/JS and just use Deno/Node/Bun or otherwise to move to Rust with rusty_v8 or deno_core directly.
Knock on wood not to jinx it, but I wonder why this manages to stay up on github when eg paywall-busting chrome extensions get banned from there (because of DMCA takedowns I guess?)
there was already an attempt to take it down back in 2020/2021 [0]. The DMCA claim's main argument was that ytdl was circumventing Techincal Protection Measures (TPMs) in order to access the content. Thanks to a letter from the EFF [1] which explains how ytdl accesses content in the same way that a browser does (i.e. it does circumvent anything such as DRM), github rejected the takedown.
this is also why ytdl has stood firm in saying they will never attempt to be compatible with anything protected by DRM.
We use this for AI transcriptions internally on our Linode VPS server.
It's been working great by itself for the most part since the beginning of the year, with only a couple of hiccups along the way.
We do use a custom cookies.txt file generated on the server as well as generate a `po_token` every time, which seems to help.
(I originally thought everything would just get blocked from a popular VPS provider, but surprisingly not?)
Most recently though, we were getting tons of errors like 429 until we switched to the `tv_embedded` client, which seems to have resolved things for the most part.
> What about Selenium or a headless browser solution?
>
> The yt-dlp maintainers have no interest in doing this except as a measure of last resort. A headless browser solution would be an admission of defeat and would go against the spirit of this project.
> if using QuickJS, version 2025-4-26 or later is strongly recommended for performance reasons
Oh, I wonder if they got performance to a reasonable level then? When the external JS requirements were first announced, they said it took upwards of half an hour, and a QuickJS developer wrote in the ticket that they didn’t see a path towards improving it significantly enough.
92 comments
[ 3.6 ms ] story [ 83.9 ms ] threadIs it because it would break compatibility with some devices? Is it too expensive?
(not that I'd like that; I always download videos from YouTube for my personal archive, and I only use 3rd party or modified clients)
Major platform like Netflix etc. don't implement that DRM since they care, it's because they content they distribute requires that they employ that measures, otherwise who produces the content doesn't give it to them. Content on YouTube does not have this requirement.
Also: implementing a strict DRM on all videos is probably bad for their reputation. That would restrict the devices that are able to play YouTube, and probably move a lot of content creators on other platforms that does not implement these requirements.
https://github.com/yt-dlp/yt-dlp/wiki/EJS
it looks like deno is recommended for these reasons:
> Notes
> * Code is run with restricted permissions (e.g, no file system or network access)
> * Supports downloading EJS script dependencies from npm (--remote-components ejs:npm).
I also save temporary videos removed after a time for example NHK honbasho sumo highlights which are only available for a month or so then they permanently remove them.
I used to be an MP3 and movie hoarder, then somehow I realized it was not worth my time.
Now I only hoard my photos and I keep them all on my phone (slash cloud) for me to actually scroll through regularly.
It's absolutely insane to me how bad the user experience is with video nowadays, even video that's not encumbered by DRM or complex JavaScript clients.
The video experience for typical video files is great these days compared to the past. I think you may be viewing the past through rose colored glasses. For years it was a pain to deal with video because you had to navigate third party players (remember Real Player?), Flash plugins, and sketchy codec pack installs from adware infested download sites. If you were tech support for friends and family during that era, it was common to have to remove adware, spyware, and other unwanted programs after someone went down the rabbit home of trying to install software to watch some video they found.
The modern situation where your OS comes with software to play common files or you can install VLC and play anything is infinitely better than the past experience with local video.
https://en.wikipedia.org/wiki/Perian
I remember when VCR's came out and everyone would take TV shows and share them with their friends.
By now we should be able to share video on SD Cards that just pop into a slot on the top of the TV, but the electronics companies are now also the content companies, so they don't want to.
Has nothing to do with video per se. Normal embeddings, using the standard `<video>` element and no unnecessary JS nonsense, still work the same way they did in the 90s: Right click the video and download it, it's a media element like any other.
The reason why user experience is going to shite, is because turbocapitalism went to work on what was once The Internet, and is trying to turn it into a paywalled profit-machine.
Even then, there are a few competitors to YouTube like Nebula, PeerTube, and Odysee. But Nebula requires a subscription and PeerTube and Odysee have worse quality, because good video hosting and streaming is expensive.
I think what breaks computer peoples' brains a bit is the idea that the bytes flying around networks aren't just bytes, they represent information that society has granted individuals or businesses the right to control and the fact technology doesn't treat any bytes special is a problem when society wants to regulate the rights over that information.
I have worked on computer systems for media organizations and they have a very different view of intellectual property than the average programmer or technologist. The people I find the most militant about protecting their rights are the small guys, because they can't afford to sue a pediatrician for an Elsa mural or something.
Piracy did pretty well, but that's because the legal experience was so terrible. But even then, you had to download obscure players and codec packs, and sourcing wasn't as easy as it is now. For reference VLC and BitTorrent released in 2001.
I'd say the user experience steadily improved and peaked in the mid-2010s. I think it is worse now, but if it is worse now, back then, it was terrible, for different reasons.
Download a random video and then copy ejs from yt-dlp’s cache directory (I think it’s in /home/username/.cache)
> being able to package it up together with the solver
`make yt-dlp-extra`
YouTube barely works in a full-on browser these days, props to the team that keeps it accessible via a Python script!
I personally use Youtube almost exclusively for my entertainment. I am using Chromium on Raspberry Pi 5. I am running some flavor of uBlock, SponsorBlock, and some Shorts remover extension. It just works.
If the concern is security, it sounds like the team went to great lengths to ensure the JS was sandboxed (as long as you’re using Deno).
If you’re using some sort of weird OS or architecture that Deno/Node doesn’t support, you might consider QuickJS, which is written in pure C and should work on anything. (Although it will be a lot slower, I’m not clear just how slow.) Admittedly, you then loose the sandboxing, although IMO it seems like it should safe to trust code being served by Google on the official Youtube domain. (You don’t have to trust Google in general to trust that they won’t serve you actual malware.)
...Can they not just bundle a solver? For that matter, deno is available as a PyPI package.
> as I'm probably not alone in running yt-dlp in a restricted environment
...An environment that doesn't allow you to install Deno, but does allow you to install yt-dlp?
Since JS is the big issue here, the backend itself could be written in JS, TS or something else that compiles to WASM. That way, the decoder doesn't have to be split between two separate codebase. Deno also allows the bundle to be optionally compiled into a native executable that can run without having to install Deno separately.
https://paulgraham.com/ambitious.html
Knock on wood not to jinx it, but I wonder why this manages to stay up on github when eg paywall-busting chrome extensions get banned from there (because of DMCA takedowns I guess?)
this is also why ytdl has stood firm in saying they will never attempt to be compatible with anything protected by DRM.
[0] https://github.blog/news-insights/policy-news-and-insights/s...
[1] https://github.com/github/dmca/blob/master/2020/11/2020-11-1...
It's been working great by itself for the most part since the beginning of the year, with only a couple of hiccups along the way.
We do use a custom cookies.txt file generated on the server as well as generate a `po_token` every time, which seems to help.
(I originally thought everything would just get blocked from a popular VPS provider, but surprisingly not?)
Most recently though, we were getting tons of errors like 429 until we switched to the `tv_embedded` client, which seems to have resolved things for the most part.
> What about Selenium or a headless browser solution?
>
> The yt-dlp maintainers have no interest in doing this except as a measure of last resort. A headless browser solution would be an admission of defeat and would go against the spirit of this project.
Oh, I wonder if they got performance to a reasonable level then? When the external JS requirements were first announced, they said it took upwards of half an hour, and a QuickJS developer wrote in the ticket that they didn’t see a path towards improving it significantly enough.
Looks like the packaging will be a mess?