Am I misunderstanding something here? I don't see anything other than an .mp4 video served via a <video> tag from a URL that ends in .gifv. I was interested in seeing how it worked to look into supporting it for a mime type detection library I've written.
The blog post mentions submitting a specification to the relevant standards organization. Are they planning on creating a new mp4 ftyp and registering a mimetype with IANA?
Can I start serving .html files as .awesome files?
Sure, go ahead. Extensions in a URL have little to do with the actual type of content, and .html has long been abandoned by dynamic systems, who originally went to extensions being an implementation detail, and on many current systems being a lie (e.g. the .aspx extension that actually runs a PHP page that returns an HTML5 file).
They're using a URL extension to signal to their system what to do with the file, which in the case of GIFV is to wrap an MP4 video in a simple HTML5 container. Eh.
If IE chooses to use file extension over MIME type, then it is broken and should be ignored.
Yes, I'm aware that this is probably a workaround for broken web servers, or brain-dead server admins. This workaround should never have been deployed, as it breaks interactions with non-broken web servers.
It's not just IE that plays loose like this. Chrome will ignore even the Content-Type header if it can see the content is an audio or video file. For example, upload a .wav to puush and open it in FF and Chrome. FF will show a dump of the bytes interpreted as text because the server sent it with Content-Type: text/plain. Chrome will show an <audio> element.
You can't call either browser broken here. One is doing what the spec says is correct. The other is doing what the user says is correct.
I could see them recommend that “GIFV” be standardized as video/gifv+mp4 (and it wouldn’t need standardization if it provided it as video/vnd.imgur.gifv+mp4), which would provide the necessary signals in a fairly standards-compliant way, as well as a clear indication that mp4 is the fallback.
It does sound like they are angling for a mime type. That way the server can detect if it accepts the mime type and return a html wrapped video player if it doesnt, and the mp4 file raw if it does.
the imgurl community is always asking for more servers and bandwidth, and the imgurl team is only delivering crappy feature on top of crappy feature that only makes things worse.
their goal is not pleased users, its a big fat huge "exit". thats why new feature and buzzwords abound. it impresses investors, which is their goal.
> the imgurl community is always asking for more servers and bandwidth
They serve 2 billion images per day, and they never delete pictures that are still actively accessible from the internet.
At no cost to the user.
In any case, cache is golden, and a 5 MB gifs off of their front page could be a 500kb MP4. That difference adds up superfast it's off of their front page and has 30M views.
the post i just answered to asked what is so special about gifv if all they are doing is a video tag.
also, similar arguments where done when adding lazy loading etc... with the idea that "loading images progressively is better" etc... it all backfires in the end when done by those guys. now the user actually PERCEIVES the slow loading. before, images would take a long time, but if you waited you could see the whole album. now, thanks to lazy loading done bad, they will load AS YOU SCROLL... you get to witness all the wait! it is hell.
The blog post mentions submitting a specification to the relevant standards organization. Are they planning on creating a new mp4 ftyp and registering a mimetype with IANA?