'rolling cipher stuff' - I think you just do a regular web request to a Youtube video page URL (ie https://www.youtube.com/watch?v=...), and the response contains (in a json object) several URLs that point to the video content in various ordinary formats. You don't need to run any JS even, or pull any tricks, just parse the response string and fish out the URLs. 'rolling cipher' means the URLs change (over time, user?), so they aren't useful for sharing to others. What is the 'technical circumvention' here?
As I already said in another thread several days ago, not quite. For most videos, yes, you do a request to https://www.youtube.com/get_video_info?video_id=... and there are links to files and adaptive streaming playlists. But then there's stuff like VEVO music videos, and those have an additional layer of protection in the form of some signature IIRC that you need to add to those stream URLs to make them valid.
Source: I added a custom YouTube player to my app several years ago, and, actually, besides my own reverse engineering, youdube-dl sources were quite helpful with figuring it all out. It didn't play those "protected" videos though.
When I think of what it's like being an engineer (regardless of field), I think of the distance between "isn't the solution as simple as...?" and what the project actually looks like after a year in production after encountering the full domain of things that can go wrong.
Though youtube-dl also simply does more than what you're assuming. And ctrl-f for "drm".
True, if anything it just seems to do nothing. Though don't let me distract from the rest of the code. Just seems like initially simple code slowly encumbered by if-conditions in response to real world obstacles and feature creep.
