I wonder how the whole thing works when I open a youtube video from a preview inside a chat application on my mobile phone. It looks like the video loads and starts playing in some kind of in-app browser, but there is just full-screen video and nothing else. I also never faced any ads in this "mode" of playing a video, yet recently some strange things started happening where the playback would start together with an…
Not sure what you’re asking. You can get fullscreen video in a desktop browser by pressing F or clicking the fullscreen icon (broken rectangle) below the video. You can get ad-free playback by paying for Premium or sometimes with an ad blocker. Outside the browser, you can get both with yt-dlp, which also integrates into video players like mpv.
Yt-dlp: External JavaScript runtime now required for full YouTube support
571–580 of 646 posts
Re: Yt-dlp: External JavaScript runtime now required for full YouTube support
#572Tangentially related. Youtube web is now, as of the last month, strictly enforcing "referrer header" for embedded videos. Even if you spoof it, it doesn't always work. You can't navigate directly to "youtube.com/embed/ " to watch something without giving google some direct information. Since when are public-facing error codes just lies? "Oh Error 15 something went wrong, tee hee." "Oh Error 153 better try again, (got…
Re: Yt-dlp: External JavaScript runtime now required for full YouTube support
#573From 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).
It's fine for this project since google is probably not in the business of triggering exploits in yt-dlp users but please do not use deno sandboxing as a your main security measure to execute untrusted code . Runtime-level sandboxing is always very weak. Relying on OS-level sandboxing or VMs (firecracker & co) is the right way for this.
I mean, this gives me pause:
> Both QuickJS and QuickJS-NG do not fully allow executing files from stdin, so yt-dlp will create temporary files for each EJS script execution. This can theoretically lead to time-of-check to time-of-use (TOCTOU) vulnerabilities.
https://github.com/yt-dlp/yt-dlp/wiki/EJS
TOCTOU from temporary files is a solved problem.
Re: Yt-dlp: External JavaScript runtime now required for full YouTube support
#574Just 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…
Re: Yt-dlp: External JavaScript runtime now required for full YouTube support
#575Earlier quoted context omitted.
I use YouTube on a daily basis. I haven't seen any of these problems.
It is likely you use Chrome or a browser that uses Blink for its engine and the OP uses a non-blink browser like Firefox. I use Firefox and I can cofirm since the last few months Youtube usability borders on usable
Re: Yt-dlp: External JavaScript runtime now required for full YouTube support
#576Earlier quoted context omitted.
YouTube had a $10B Q3. I cannot imagine them spending $10B on servers and staff in three months.
Making a profit doesn't mean that their costs aren't so high that adblocking isn't compatible. Walmart has profits of $157B in 2024, but their business model isn't compatible with people just walking in and grabbing stuff without paying - and doesn't make it ethical to do so even if "they'll be just fine even if I do that"
Re: Yt-dlp: External JavaScript runtime now required for full YouTube support
#577Earlier quoted context omitted.
long press -> save image/video is perfectly supported on a phone, it's just content diffusion platform that arbitrarily restrict it.
No, it's also iOS that's arbitrarily restricting it. I opened a bare .webm directly in Safari and got nothing on long press and nothing in any of the control widgets to save it.
Nemo auditur propriam turpitudinem allegans
Re: Yt-dlp: External JavaScript runtime now required for full YouTube support
#578Earlier quoted context omitted.
> But I'll always miss VirtualDub. Miss? I still used it just last week! Still haven't found anything that is as fast and easy to take a directory of frames in .png and concatenating them together into a proper video. I use it post 3D renders all the time :)
ffmpeg?
Re: Yt-dlp: External JavaScript runtime now required for full YouTube support
#579Earlier quoted context omitted.
I have an e-ink photo frame on the wall that switches picture once every 24h, picking one of my pictures of the last 10+ years by random. So every single one of my tens of thousands of pictures gets a real chance to be seen at least once during my lifetime :)
Which frame do you use? I’ve been looking for this for a long time, but I wasn’t aware color e-ink was good enough for this yet.
Re: Yt-dlp: External JavaScript runtime now required for full YouTube support
#580Seems its already in Arch's repositories, and seems to work, just add another flag to the invocation: yt-dlp --cookies-from-browser firefox --remote-components ejs:github -f "bestvideo[ext=mp4]+bestaudio[ext=m4a]/best[ext=mp4]/best" 'https://www.youtube.com/watch?v=XXX' 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] [js…
Glad to hear it’s faster now! 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.