This affects both my youtubedown script, and Miro. Since Miro is what I use to subscribe to most of the blogs through which I discover new music videos, this negatively impacts my mixtapes, which is how it impacts you.
So help me reverse-engineer their new countermeasures, ok? If we fix this bug, my mixtapes get better.
Here's an example: http://vimeo.com/43940325.
As of their new site roll-out a month or two ago, the new way to download that video would be to load "http://vimeo.com/
On a private video, when you hit "Play" in either the Flash player or the HTML5 player, it loads "http://av.vimeo.com/
The fact that this works in the HTML5 player means that they are computing those URLs from Javascript somehow, rather than with a secret key that is baked into their Flash player, so that's promising. But I don't have a lot of experience reverse-engineering gigantic Javascript apps.
Since it will be the first thing you find when googling, let me point out that the old moogaloop URLs like "http://vimeo.com/
Ideas?
This jumped out at me.
getVideoUrl: function(a) {
var b = this.config, e = this.controller.playableFiles,
d = e[a], c = null;
if (!e[a]) {
u.warn("No playable file of quality", a);
return a == S && g.mobileCanPlaySD() ? this.getVideoUrl(Da) : c
}
if (((new Date).getTime() / 1E3).round() - this.loadedTime > 21E3) {
u.info("Old signature expired, getting a new one!", b.request.signature);
e = "//" + b.request.player_url + "/config/" + b.video.id + "/signature?prev_signature=" + b.request.signature + "&prev_timestamp=" + b.request.timestamp;
e = (new XHR).getWithCredentials(e);
b.request.signature = e.signature;
b.request.timestamp = e.timestamp;
this.loadedTime =
((new Date).getTime() / 1E3).round();
u.info("New signature:", b.request.signature)
}
if (d) {
c = "//" + b.request.player_url + "/play_redirect";
c = c + ("?quality=" + a) + ("&codecs=" + d) + ("&clip_id=" + b.video.id);
c = c + ("&time=" + b.request.timestamp);
c = c + ("&sig=" + b.request.signature);
c = c + ("&type=html5_" + this.controller.playerMode + "_" + (b.embed.on_site ? "local" : "embed"))
}
u.debug("Video URL: " + c);
return c
That URL is constructed like
https://player.vimeo.com/play_redirect?quality=hd&codecs=h264&clip_id=43940325&time=1340866292&sig=3b3b5e1bcae716a071f6640679b5410a&type=html5_desktop_local
(to continue with your example)Then it's a 302 redirect to the raw MP4 on their CDN. (
https://av.vimeo.com/56703/323/102884975.mp4?aksessionid=3b3b5e1bcae716a071f6640679b5410a&token=1340867357_e59053ffeddd9dd017d31e1b07b2fe37
)Yeah, or use the code timdoug pointed at. It scrapes the page, too easy!
rg3's youtube-dl works fine with Vimeo links:
$ youtube-dl http://vimeo.com/43940325
[vimeo] 43940325: Downloading webpage
[vimeo] 43940325: Extracting information
[download] Destination: 43940325.mp4
[download] 100.0% of 74.49M at 835.22k/s ETA 00:00
$
The Vimeo-specific code here might help.
Wow, that was fast! Thanks!
I had looked at the HTML in the page before, but plugging those values in to the av.vimeo.com URL didn't work; I hadn't realized that the play_redirect URL was key.
youtubedown updated, Miro notified!
I see your problem has already been solved, but I'll leave this neat trick here anyway because it neatly circumvents this kind of website silliness by directly grabbing the local temp file created by the flash player plugin. (Caveat: you will need linux).
Step 1: find the temporary file (which will already be unlinked):
$ lsof +L1 | grep /tmp/Flash
plugin-co 17666 paol 20w REG 8,2 78111247 0 130956 /tmp/FlashXXfU7zHE (deleted)
Step 2: since the file is unlinked we can't open it by name, but with the PID and FD returned by lsof we can get it from the /proc filesystem:
$ cp /proc/17666/fd/20 whatever.mp4
Step 3: profit!
That's actually much more generally useful. Thanks!
You can even hard-link the file (faster than cp, no extra space needed)
$ ln /proc/17666/fd/20 whatever.mp4
If any Windows user is looking for a solution: StreamTransport (http://www.streamtransport.com/) seems to work fine. The downloaded video has the filename "404 Not Found.mp4" but it works fine.
#! /bin/bash
clip=$1
[ x$clip == x ] && clip=43940325
rm -f $clip
cat > cookie.txt <<EOF
html_player=1; clips=$clip
EOF
wget --load-cookie=cookie.txt --save-cookie=xxx http://vimeo.com/$clip
signature=$(cat $clip | tr "," "\n" | grep \"signature | cut -d\" -f4)
timestamp=$(cat $clip | tr "," "\n" | grep \"timestamp | cut -d: -f2)
echo $signature $timestamp
wget --load-cookie=xxx "https://player.vimeo.com/play_redirect?quality=hd&codecs=h264&clip_id=$clip&time=$timestamp&sig=$signature&type=htm\
l5_desktop_local"
i was going to leave a comment about how the vimeo thing worked but it looks like everyone beat me too it (makes sense it didnt take long to figure out)
Cool story, Bro.
Well you can also use firefox with the FlashGot add-on. It grabs most of the flv out there (youtube, vimeo,etc)
Either way the bastards should be reported to the W3C for flagrant violation of HTTP status code semantics.