snarly
commented
8 years ago Thanks for taking your time to check my code.
I'd have figured a professional coder would back out in an instant at the first glance of this mess, it's so all over the place, haha.
Sorry that I did not reply sooner. I don't check my emails often 'cause I'm not in touch with anybody on a daily basis.
I also hope you don't mind that I did this little project based on -- among others -- your code, but without your consent. I started from practically zero javascript knowledge and very little programming experience, and I have no intention to ever ask for anybody's money for the usage of this program.
Regarding your question -- no, there is no parsing of the MPD videos done here. I merely extract the links from the MPD file (via XMLHttpRequest) and queue them as an option to choose from, that's it. There is a second, hidden, featureless player which is supposed to play one of the audio sources along with the main player's video-only source. This solution is now more resource demanding but it also works on a lot of outdated browsers/systems which was one of my main goals to begin with. I'm not sure what is the deal with those "yt_otf" files though.
Here is one example: https://www.youtube.com/watch?v=EXJ9mIjrx4E
The signature decryption works with the normal "youtube" links found inside the MPD file but not with these. I figure yt_otf files are maybe a chunk of live streams? The last time I checked, the otherwise efficient "YouTube Video and Audio Downloader" Firefox extension (with the orange box) could not extract these yt_otf media sources either, whereas it was able to extract the beginning chunk of an actual live stream. Strange.
I'm sure it would take a tremendous amount of time and work to make my code capable of handling live streams via DASH. Even YT/Google's bloody professionals themselves struggled with getting it to work between 2012 and late 2014, and the native player's streaming performance used to be pretty effing horrendous. It seems okay now, though.
Lately, I've been trying to conform to the newest YT layout which is still in the testing phase and it tends to break a lot of stuff including your own code. In Google Chrome it's easy to try the new layout: just clear the "VSITOR_INFO1_LIVE" entry of the youtube-cookie and enter this command on the Developer's Console:
document.cookie="VISITOR_INFO1_LIVE=Qa1hUZu3gtk;path=/;domain=.youtube.com";
after that, just refresh the YT-page.
I don't know a trick for other browsers, may not even exist. In Firefox, I experienced seemingly random switches to the new layout (for the current session only) after browser launch with cleared cookies.
As a final note, if I may suggest a little fix to your bookmarklet:
When called, it breaks YT's player. This can be avoided by directing the player creation procedure to any other empty div element with a unique name instead of "player-api" which would overlap the existing original stuff. The process won't create an actual player in the DOM inside the specified div, but in memory it plays out just like it did and you can get the necessary data just like before. (I experimented with this in my own code and I could produce links in a similar fashion but with the YT-player still intact.)
With regards,
Snarl
ghost
I see that you are searching for
yt_otfin your code:http://github.com/snarly/yt6/blob/69a0c5a/yt6.js#L4648
Videos with this source produce different URLs. Here is a normal URL:
https://r3---sn-q4fl6n7y.googlevideo.com/videoplayback?id=88f20b21feebbb8f&itag=137&source=youtube
Here is MPD URL:
https://r2---sn-q4fl6n7e.googlevideo.com/videoplayback/id/0814fe666fcdc379/itag/137/source/yt_otf
Does your code actually parse these MPD videos? Currently my bookmarklet does not support them. Pulling the manifest URL is easy enough:
but I would prefer to avoid XMLHttpRequest.