Live data from Hacker News

Reverse-Engineering YouTube: Revisited

tyrrrz.me

11–20 of 43 posts

Re: Reverse-Engineering YouTube: Revisited

#11
post #3

> There is one thing that developers like more than building things — and that is breaking things built by other people. Haha. 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 cros…

Unfortunately the halting problem takes all your mathematical certainty and throws it out the window. It's very easy to take your application which will halt within a finite amount of time to one that will not. You'll find most programmers and companies are not going to spend the massive amount of time to ensure their logic is correct, but instead throw the application out there quickly and fix it based on crashes and feedback.

Re: Reverse-Engineering YouTube: Revisited

#13
post #4

Its too bad such an important resource (youtube) has a secret API - that changes all the time.

Why? YouTube has a proper public API, that doesn't change all the time.

They however a few years ago started forcing API users to authenticate, so when I had to spend months in bed after a bad road accident and later a heart attack, I couldn't anymore watch my favorite electronics channels using the Kodi YT extension unless I would authenticate. I guess they still allow anonymous use with a browser only because by doing that they can profile more people.

Re: Reverse-Engineering YouTube: Revisited

#15
post #12

Does anyone know if YouTube runs Ffmpeg internally?

Circumstantial evidence that they used to: https://multimedia.cx/eggs/googles-youtube-uses-ffmpeg/

These days they use special hardware accelerators: https://gwern.net/doc/cs/hardware/2021-ranganathan.pdf

Re: Reverse-Engineering YouTube: Revisited

#16
Interestingly I found that YouTube's web UI actually requests range URLs rather than range HTTP headers, allowing it to seek around the video faster than mpv with yt-dlp (and conveniently avoiding throttling as well). I suspect this may be related to DASH: https://github.com/mpv-player/mpv/issues/10601

Unfortunately mpv and ffmpeg do not currently have mature DASH support and cannot benefit from fast seeks: https://github.com/mpv-player/mpv/issues/7033 (didn't look deeply)

Re: Reverse-Engineering YouTube: Revisited

#17
post #7

Ive said it before on GitHub, I dont think `TVHTML5_SIMPLY_EMBEDDED_PLAYER` is the great solution everyone thinks it is. Yeah, you can get the age-restricted videos anonymously. However you can also get those videos by logging in, which the author doesn't mention: POST /youtubei/v1/player HTTP/1.1 Host: www.youtube.com Authorization: Bearer ya29.a0AVvZVsqRwNWFI3R0MSxnugyNlxbqIOXcwXkeA6NMOcpv_... { "contentCheckOk": t…

> However you can also get those videos by logging in, which the author doesn't mention.

> 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.

The author mentioned both, the login option as well as the chunking mechanism. Sorry, but did you actually read the blog post?

Re: Reverse-Engineering YouTube: Revisited

#18
post #7

Ive said it before on GitHub, I dont think `TVHTML5_SIMPLY_EMBEDDED_PLAYER` is the great solution everyone thinks it is. Yeah, you can get the age-restricted videos anonymously. However you can also get those videos by logging in, which the author doesn't mention: POST /youtubei/v1/player HTTP/1.1 Host: www.youtube.com Authorization: Bearer ya29.a0AVvZVsqRwNWFI3R0MSxnugyNlxbqIOXcwXkeA6NMOcpv_... { "contentCheckOk": t…

If you can afford to always be logged in, then sure, but it's not always an option. Especially if you need a general solution.

Re: Reverse-Engineering YouTube: Revisited

#20
post #3

> There is one thing that developers like more than building things — and that is breaking things built by other people. Haha. 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 cros…

> I'd prefer my victories to be against the frontier of knowledge, and to win universal truths.

You wouldn't need to tear down barriers if the people that built them thought the same in the first place. Nonetheless, keep up that attitude.

Post reply on HN