Reverse-Engineering YouTube: Revisited
1–10 of 43 posts
Re: Reverse-Engineering YouTube: Revisited
#2Re: Reverse-Engineering YouTube: Revisited
#3Haha. This is not as universal as the author thinks. Every time I need to reverse-engineer something obscured on purpose, I wish we could just get along.
Every time I have to reverse-engineer something obscured by accident, I call it debugging.
But even if I solve the puzzle, it's like solving crosswords: I just defeated a human mind, the victory is transient, and will soon be forgotten. I'd prefer my victories to be against the frontier of knowledge, and to win universal truths. That means building things rather than tearing down those humans built.
I just wish there was more mathematical certainty and less human vices in programming.
Re: Reverse-Engineering YouTube: Revisited
#4Re: Reverse-Engineering YouTube: Revisited
#5Re: Reverse-Engineering YouTube: Revisited
#6Its too bad such an important resource (youtube) has a secret API - that changes all the time.
Re: Reverse-Engineering YouTube: Revisited
#7 POST /youtubei/v1/player HTTP/1.1
Host: www.youtube.com
Authorization: Bearer ya29.a0AVvZVsqRwNWFI3R0MSxnugyNlxbqIOXcwXkeA6NMOcpv_...
{
"contentCheckOk": true,
"context": {
"client": {
"clientName": "ANDROID",
"clientVersion": "18.04.35"
}
},
"racyCheckOk": true,
"videoId": "Cr381pDsSsA"
}
and `TVHTML5_SIMPLY_EMBEDDED_PLAYER` comes with strong drawbacks. Some videos under that client require a JavaScript signature for BOTH downloading and unthrottling. Each person is welcome to their own opinion, but I just dont think its worth the complexity of parsing some arbitrary JavaScript with Python when you can just log in (programmatically as above). Personally I use the ANDROID client, which avoids all JavaScript signatures. Also not mentioned in the article is that you can actually take the throttled URLs as is, and download pieces concurrently for a pretty good result. So each piece is still downloading slowly, but if you use on the order of 99 connections, you get decent speed. You would think you get IP blocked or something for this, but I downloaded quite a bit using this method as a test and the YouTube server allowed it. The combined resultant speed was only something like 2 MB/s, so big picture it doesn't seem like an abuse. My YouTube OAuth code is here for any interested:Re: Reverse-Engineering YouTube: Revisited
#8Its too bad such an important resource (youtube) has a secret API - that changes all the time.
Re: Reverse-Engineering YouTube: Revisited
#9Re: Reverse-Engineering YouTube: Revisited
#10Well, kids being clever figured out the Chromebook browser shows a preview video if you hit the 'share' button and go to embed video. This is not content blocked. I didn't dig in to see if it would play age restricted content as I assume all access is being logged somewhere and want to minimize future fall out.