If you take a look at the source of the .gifv link from their blog posting it looks like this is exactly what they are doing:

    <video height="370" width="660" autoplay="" loop="" muted=""><source type="video/mp4" src="http://i.imgur.com/zvATqgs.mp4"></video>

If you open up zvATqgs.mp4 you are redirected to a .gifv file, which is an HTML document. It has a video tag that mutes the audio.

edit: This is interesting, though:

    ~/temp curl -I http://i.imgur.com/zvATqgs.mp4
    HTTP/1.1 200 OK
    Last-Modified: Fri, 26 Sep 2014 20:44:27 GMT 
    ETag: "2342c1e692a327e61be8395bf4d9109c"
    Content-Type: video/mp4

Browsers, however, are redirected to the .gifv link, while curl gets the raw mp4 file. Interesting. I was expecting a 30x response code.

Further edit: Passing a user agent to curl also causes the raw mp4 file to be returned, with no redirection. Anyone know how they are doing this redirection for browsers but not for curl?

I managed to get a 302 response code in curl by passing both a Firefox user-agent and an accept header.

Neither the accept header alone nor the user-agent alone are sufficient. It seems they are testing for both.

  curl -H "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8" -A "Mozilla/5.0 (Windows NT 6.3; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0" -I http://i.imgur.com/zvATqgs.mp4

They need to get the raw MP4 file eventually so the browser can display it, it can not always redirect.

I understand that, I'm just curious as to the mechanism that they are using.

I'm not sure, and the server response from your sample certainly does not fit with this idea, but maybe it's because curl uses http/1.0?

Or is that wget that uses 1.0... Fire up wireshark ;)

Edit:

So it was the useragent and accept header that did it. Nevermind my stupid idea.

I think it's the same thing that sometimes redirects hotlinked .jpgs to a gallery representation of themselves: for anything that looks like a web browser, it checks whether the referrer is the embedding page, and if not, redirects to the embedding page.

You can't put element tags on a imgur.com/rickroll.mp4 raw file link.

An important feature of gifs is that you know they will not make noise. Videos however like to blare obnoxious music and yell at you to grab your attention.

If it somehow became a browser convention that .gifv videos will not play sound by default, then users would be much less anxious about clicking and sharing .gifv links compared to .mp4 links.

As a user, before I click a link to a file with a .gifv extension, I know in advance that there won't be any audio. I like that.