Live data from Hacker News

Bypassing YouTube video download throttling

blog.0x7d0.dev

201–210 of 242 posts

Re: Bypassing YouTube video download throttling

#201

I've never tried YouTube, but I have downloaded videos from sketchier streaming websites using the web developer tools. Almost all of them have the same protection: some code that triggers only when you open the tools and stops the video by creating a debugger statement you cannot skip and triggering some cpu-heavy code (probably an infinite loop, although I wouldn't discard cryptominers). More importantly this code…

> some code that triggers only when you open the tools I've seen this technique too, but I feel that this is a major flaw on the browser's side. It should be impossible to tell if the dev tools is open or not. Surely this can be done right?

A LOT of things should be impossible for the website to tell. Focus, drm, mobile/Desktop

All (3) Browser engines are anti consumer spyware. There is no way to convince me otherwise. Why google and apple are not fixing this is obvious but Mozilla just keeps disappointing.

I'm desperately waiting for a Foss alternative.

Re: Bypassing YouTube video download throttling

#202

Earlier quoted context omitted.

> No it doesn't. If you're using a PC with a Nvidia GPU, run `nvidia-smi dmon -s u` and start playing a random Youtube video in Chrome. You'll notice how dec% moves from 0% to at least 2%. Pause, and start playing Widevine protected video and notice how dec% stays at 0% because decoding is happening on the CPU. > It's not fullproof but it would certainly make tools to bypass it clearly illegal in most of the world. G…

> If you're using a PC with a Nvidia GPU, run `nvidia-smi dmon -s u` and start playing a random Youtube video in Chrome. You'll notice how dec% moves from 0% to at least 2%. Pause, and start playing Widevine protected video and notice how dec% stays at 0% because decoding is happening on the CPU. It's because Widevine have embedded decoder into its lib and its using CPU instructions but from user perspective it's not…

> but from user perspective it's not a huge change on modern CPUs as most have specialized instructions to handle decoding of H264

There are no "instructions to decode H264", there is dedicated hardware acceleration like Intel QSV and AMD VCN, but these gets bypassed just like Nvidia's decoding acceleration from my previous example. All of this is trivially observable, playing back DRM-protected video wastes an obscene amount of resources, relatively speaking.

From user perspective you'll notice stuttering, unusually high CPU usage, dropped frames and more, especially once you try to play multiple videos at once.

> There are no "Techniques to bypass it", the only way currently to get L1 streams is to use legit hardware keys from some devices

That's exactly what I meant. Being pedantic over my choice of words isn't very productive.

Re: Bypassing YouTube video download throttling

#203
post #32

Earlier quoted context omitted.

> Companies do not have ethics, only interests. While that's certainly true (although an simplification - they are just managed by people with low ethics), we can do better. If I behaved like managers of Google, Meta or Microsoft, I'd be ashamed of myself.

I despise this philosophy. Megacorps are shit, so we should be better than them? It's a popular theme because it makes one feel like they have control over the world around them: they just have to be better than it. No. I shouldn't have to work harder myself to somehow cancel out the evil in the world. Because if we were less cowards and calling them for what they are - evil - they wouldn't hold so much power over us…

> Because if we were less cowards and calling them for what they are - evil - they wouldn't hold so much power over us.

three years of covid nonsense -> crickets

video download speed throttle -> rage

Something is wrong here.

Re: Bypassing YouTube video download throttling

#204

Earlier quoted context omitted.

> I wonder what is their reasons for not using it - Introduces a decryption step, which is slow - Forces software video decoding, which is slow - Web browsers only support the weakest form of Widevine which is ineffective It would effectively push a significant portion of their user base off the platform while not being very effective in its goals.

> Introduces a decryption step, which is slow It's not slow, after you decrypt the AES key, then you are using hardware AES instruction set supported by most CPUs currently. https://en.wikipedia.org/wiki/AES_instruction_set

Relatively speaking. You might not notice it when playing back a single video, but I promise you that you're not going to have a good time if you try to play back multiple high bitrate videos on slightly older hardware (think HTPC).

Re: Bypassing YouTube video download throttling

#205

Earlier quoted context omitted.

Try Anti-Anti-Debug [0]. It's a simple extension to bypass those kinds of anti-debugging techniques. Made it in a few hours a while ago for similar reasons. 0: https://chrome.google.com/webstore/detail/anti-anti-debug/mn...

Can you make one for Firefox too? ;-)

it's a simple script, should be portable to firefox with minor modifications. The source code is available on Github [0].

0: https://github.com/Andrews54757/Anti-Anti-Debug

Re: Bypassing YouTube video download throttling

#206

Earlier quoted context omitted.

You can also use mitmproxy to remove or add debugger statements.

How does that work with certificate pinning?

It doesn't, you'd have to unpin certificates in whatever application you're using. Browsers generally don't do certificate pinning though, they'll (correctly) respect your installed certificates, which would include the mitmproxy one.

Re: Bypassing YouTube video download throttling

#207

Earlier quoted context omitted.

Sponsorblock is almost this... But it uses real human labour to replace the AI, and works really well.

Sponsorblock is absurdly wonderful, but needs an option to exclude certain channels. I want to watch Internet Historian's ads.

The feature already exists [1].

[1]: https://github.com/ajayyy/SponsorBlock/issues/547

Re: Bypassing YouTube video download throttling

#208

Earlier quoted context omitted.

> Companies do not have ethics, only interests. While that's certainly true (although an simplification - they are just managed by people with low ethics), we can do better. If I behaved like managers of Google, Meta or Microsoft, I'd be ashamed of myself.

Allow me to wire 500k+ in your account every year, and you'll see that your morals are easily bought.

No, fuck that. There are many people I know who have explicitly rejected a payoff to do the right thing.

If your morals go away when they actually matter, you didn't actually have morals, you just had an excuse why you weren't already rich. A person is judged by what they do, explicitly and especially when it actually matters.

Re: Bypassing YouTube video download throttling

#209

Earlier quoted context omitted.

There is no throttling when using the JSON returned by the HTTP request in the shell script or generated by the utilities I wrote. it's not the key the author is using, it's the post-data. Moreover, to get throttled videoplayback URLs with the "WEB" key and client info like the author is using, one does not need to make POST requests to /youtubei/v1/player. There are throttled videoplayback URLs in the HTML of the /w…

Interesting. I ran the script to extract the json - that part was almost instant, then i used the first `url` field of `streamingData.adaptiveFormats`. I then ran curl 'https://...googlevideo.com...' --output video.mp4 for me the download is throttled to "768k", i assume thats in bits per second and not bytes which is very low: the random video i tried would take 8 minutes. on the other hand, yt-dlp videoIdHere does…

[deleted]

Re: Bypassing YouTube video download throttling

#210
post #109

Earlier quoted context omitted.

There is no throttling when using the JSON returned by the HTTP request in the shell script or generated by the utilities I wrote. it's not the key the author is using, it's the post-data. Moreover, to get throttled videoplayback URLs with the "WEB" key and client info like the author is using, one does not need to make POST requests to /youtubei/v1/player. There are throttled videoplayback URLs in the HTML of the /w…

iOS and Android clients do not yet have URLs with the "n" parameter. This is why specifying the clientName as "IOS," along with the specific YouTube key, currently yields URLs that remain unthrottled. However, acquiring this key requires decompiling the mobile application, monitoring requests through a proxy, or relying on values discovered by others. It's not necessarily straightforward. I do agree that the code is…

"However, acquiring this key decompiling the mobile application, monitoring requests through a proxy or relying on values discovered by others."

This is again not true. The key is in the HTML of every /watch?v= YouTube page. It's a public key; it's not hidden in any way.

Further, it's possible, up until today at least, to use the "WEB" key with clientName "ANDROID" of "IOS" and receive unthrottled URLs. The key in the shell script is in fact the WEB key. The key for IOS is different.

   curl -40s https://www.youtube.com/watch?v=aqz-KE-bpKQ \
   |grep -o \"INNERTUBE_API_KEY...[^\"]*\"
Post reply on HN