"With all these improvements, Imgur will now denote converted MP4s with a .gifv extension. The intention is to signal to users throughout the Internet that these links will feature a GIF experience that incorporates all the current and future enhancements made through Project GIFV. Imgur plans to submit an accompanying specification to relevant standards organizations before the end of the year."
This is bizarre. GIFV isn't a new file format. It is just an alias for an existing format. The only reason the letters "GIF" are in this new file extension is to signal that the file was converted from a GIF, but who cares, apart from the so-called cultural connotations?
I mean, does anybody care to have a BMPJ (a JPEG file that was converted from a BMP) or a WAV3 (an MP3 that was converted from a WAV)? Or a .GIFMP4GIFMP4GIFMP4 file, which was converted back and forth a few times?
Browsers should display GIFVs without transport controls (unlike <video>), and ignore any audio tracks that are included - basically construct a limited MP4 profile and handle it appropriately. It's a useful construct imho.
We don't need to tie this behavior to a new video extension or a specific video format. A more sensible approach would be to allow video sources in <img> and restrict their profile to GIF-like behavior.
The extension doesn't necessarily have to just say what the file is, but it can also say how it should be used. This is done with the .apk extension. apks are zip files, the but apk extension says it should be loaded as an application in Android.
It also isn't only useful for computers. It helps people to know what they're getting into when they open a file.
An mp4 with a gifv extension makes sense to me. It says "I'll be loaded without audio and will play in a loop".
Extensions in HTTP mean jack-all. Content-types/MIME types are what actually tell you how the file should be treated.
Imgur is serving text/html in their ".gifv" files. If you tried to load a gifv in a <video> tag it would crash and burn on you because...it's serving you an HTML document with a text/html MIME type.
Imgur will happily serve you GIFs and JPEGs with incorrect extensions - for example, if you get this image with a .gif extension, it's going to serve you a JPEG, and it's going to be decoded by libjpeg. The extension doesn't provide any useful information to the client about what to do with the data.
You're right. I edited my post to clarify with "in HTTP". Though I'll argue that it's not really relevant in this context of this particular subject, since ".gifv" only makes sense in a browser/HTTP context. Everywhere else it's just HTML.
People like this format. GIF, gyfcat, Vine, and now this. Instagram and WebM on 4chan also have things keyed to this behavior. But the thing that GIF has on all of them is that it works everywhere. It plays in a browser, in an email, on the desktop, in an MMS message, etc..
We need a full stop replacement for the GIF that uses a modern encoder.
I agree completely, though I'd add that it's also unpleasant. There's a reason some browser and browser extensions try to help track down which tabs are producing audio.
Perhaps GIFV or equivalent should be defined as either requiring the browser not to play audio or as making audio optional, but required to default to off at start of play. The latter would require a minimal transport control, but I could live with a transparent mouseover-only volume button. There's no technical reason that a GIF successor must include or play audio. For that matter it would make a greasemonkey script or perhaps extension that forced sound off for regular mp4 much easier to write in this case.
We have a format for something like that — WebP. As a bonus, it's less processor-intensive, which makes it suited for things like tiling backgrounds, or embedding many of them on a page — a huge problem for MP4s that anyone who's enabled the on their services has no doubt already discovered.
Indeed. I'm disappointed that the new generation of codecs (h264/webM) has won out for small internet videos because they seem to be processing-power beasts.
Full-screen mpeg-2 (DVDs) was doable with a $40 device over a decade ago. Video compression is definitely a worse-is-better space.
The heavier use of CPU allows the files to be smaller while retaining quality (or vice-versa).
As all current platforms, including mobile because of dedicated hardware, have absolutely no problem with playing H.264 video while bandwidth is still a scarce resource I think it is logical and wise that H.264 won over MPEG-2 or other older codecs.
Don't forget that larger file size also might mean more power consumption (storage and radio need to be active longer) even if less CPU is consumed.
Why not just have an attribute or two in <video> tag that sets it to be no volume and whether there should be transport controls? That sounds more useful to me and applicable across all video formats.
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 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.
Ah, that actually makes some sense, as far as a file format specification. So GIFV would offer a subset of the functionality of a typical video file format (most notably, absence of sound). Although I would think it would make more sense to just strip out the audio, rather than instruct browsers to ignore any audio tracks.
> I would think it would make more sense to just strip out the audio, rather than instruct browsers to ignore any audio tracks.
On the server's side, yes, that would make more sense. However, the fact is that the MP4 format supports audio, and it will always be possible for a server to supply a webpage with a GIFV item that points to an MP4 file that contains audio. What should the browser do in that case? Playing the audio is probably not desired. Refusing to display the video, or displaying "Warning: this video file contains audio and isn't a valid GIFV file", would probably just confuse or irritate the user--it's probably not their responsibility to fix the server's website. The remaining option seems to be that the browser ignores the audio track, and I'd say this is the necessary conclusion.
(Cf. how browsers deal with HTML that's missing a bunch of end tags.)
One would assume the implementation does that too, for file size anyway, but it might be nice to tell the viewer that there is no need to show the controls.
There are a lot of uses for dumb, audio-free video files. Web forums, for instance. You can allow users to embed them without worrying about 100 different auto-playing videos with sound on your page.
Plenty of ways to implement that and I'm not sure this is the best approach, but it's not just "worse video". More features is worse, not better, a lot of the time. Like when people used to build entire websites in Flash before the iPhone's lack of flash player finally made them stop.
>entire websites in Flash before the iPhone's lack of flash player finally made them stop
I have a setting flipped in Chrome such that I have to click to enable each plugin on a page. This made me realize that the iPhone sadly didn't stop all such website builders (rare as it is to encounter one now.)
I feel especially bad for local restaurants that have sites built all in Flash. When I look up who designed their website, it's proudly hosted on the only local dial-up ISP left in town, designed by a "company" which is really just a high schooler who took a digital media class once.
I know there is no way that site is being redone, and they're now completely at the mercy of Yelp.
Only if they're all visible at once. Unlike GIF, which has to do CPU-bound stuff to compute its next frames even if it isn't visible in order to stay synchronized, videos that are scrolled off the screen take effectively zero resources. (Well, they'd take resources to play audio if there were an audio track, but not when they're muted like GIFVs are.) You could have e.g. a Tumblr dashboard loaded with hundreds of screens worth of an infinite scroll of GIFV-containing posts, and your computer would only be worried about the one on the screen at the moment.
Good point, hadn't thought of that. If I'm recalling the differences correctly, GIF will let you layer new frames with transparency directly over old frames basically forever, while video formats have full keyframes at regular intervals that allow you to jump to anywhere in the video by only calculating the chunk since the previous keyframe?
I haven't made any gifs since flashing "Under Construction" signs were a thing on web pages, so it's been a while. Maybe I should put some up on tilde.club.
Actually, exploiting bugs in image parsers has been a classic vector. Certainly tiff, jpeg and BMP to my memory. When i worked at symbian we had an svg parser vulnerability that went underreported.
And given the slew of bugs Google keep finding fixing in libraries like ffmpeg, there are likely lots of bugs lurking in something as complex as an MP4 player...
That was the first question I had after I read the article. What's the need of calling it 'gifv' when it's really mp4? Does imgur want to take credit for creating a new format when it really hasn't? Conversions happen all the time behind the scenes.
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.
Is Mediacru.sh banned from Reddit? I just saw a thread the other day where someone said the domain was blocked by admins to prevent it from competing with their preferred service (probably Gfycat).
another user brought up a good point in the comments section of the imgur post:
>GIFs being lossless, editable and universally supported are a pretty big part of what spawned this “culture of the GIF”.
Sure, video editing tools exist, but I think most people would agree that GIFs are more "remix-able" than MP4s. It's important that we preserve both formats. (Or perhaps it's time for a modern lossless animation format?)
I think the point is having a proper display option. Most photographers shoot and edit in RAW, but the final product is almost always displayed as a jpg. I don't think this is meant to eliminate gif entirely, just limit it to the areas it belongs, like editing as you pointed out. The only issue I see is that there needs to be an easy option to download the original pre-converted file.
But GIF is a terrible intermediate format. It's only 'lossless' in the sense that there's no advanced compression going on. But since it can only produce 256 colors gifs tend to be extremely lossy for video-like formats, often producing awful color banding.
Sure, if you're doing things with a very small color palette like pixel art or software tutorials then the current gif is fine for your needs, but gifs are increasingly used for video which typically has a huge color range in each frame, and we need something different for these cases.
I think this actually in response to Gyfcat, who have been doing this exact same thing for a while, and eating up quite a lot of imgur's redditshare: https://gfycat.com/
WebM is a format nobody asked for and nobody wants.
It's claimed that WebM is patent free, but this is impossible. There's just too many patents in the video space, any one of which could surface and tank this format.
Remember GIF itself was, for a while, subject to patent problems.
At least with H264 companies like Cisco are releasing implementations with indemnity from that (http://www.openh264.org/) which I think is better than coming up with some wonky new format.
As far as I understand it, although there are many patents in the video space, they are not evenly distributed across all possible approaches and algorithms. Instead, when the next MPEG/ITC standard begins to crystalize, a bazillion companies rush to file patents on some specific, small part of the format so they can join MPEG-LA and get a passive revenue stream.
In particular, if you design a video compression format that deliberately avoids doing what MPEG4 or H.264 does, your odds of patent infringement go down drastically.
I wonder how many (huge) sites like imgur it would take saying "we're doing webm, if your browser doesn't support it you get a huge, slow GIF instead" for everyone just to settle on a single format?
The whole debate is only hurting users and developers, while lining the pockets of MPEGLA (or whoever is responsible for h264 licensing).
>I wonder how many (huge) sites like imgur it would take saying "we're doing webm, if your browser doesn't support it you get a huge, slow GIF instead" for everyone just to settle on a single format?
It's very unlikely to see that happen, since using H.264 doesn't cost a dime in royalties for sites like imgur that serve the content for free (ads don't count as per the H.264 licensing terms). The only trouble is really on Firefox and any other browser that wants to implement a built-in H.264 decoder, but nothing stops them from working around that via things like OpenH264 or by using system decoders and so on.
The same will likely happen with H.265/HEVC, as the recently published licensing terms made it completely royalty-free to use the format itself (including for commercial purposes, you have to pay royalties for that with H.264), and you only have to pay to distribute decoders & encoders.
Personally I wish browser vendors would just use whatever's installed on the user system for playing web videos, but for some reason that's not okay because "we need at least one unified always playing format for the web!" and then we don't get that anyway, as the whole WebM mess has clearly shown...
Anyway, since imgur is doing the conversion to video by themselves, there's not really any reason why they couldn't do both H.264 MP4s and VP8 WebMs... supporting only one format makes more sense if you allow direct user-encoded video uploads like 4chan does with its WebM support for example. Gotta say I don't like this whole "hey we took HTML5 video with 'autoplay loop muted' properties and branded it GIFV!" shtick, though.
How many? A lot. And in the mean time, if imgur started to do that, then it will soon start to have a "pdf link warning" in short order as masses of ios/safari/ie users basically segment themselves out of the loop.
In the meantime then the alternative sites will pick up in use because they aren't being dicks about a video format.
Additionally, what about devices that only have mpeg decoding? Basically you're saying screw you non webm supporting people and your battery life. We don't like your kind around here.
Its a great way to kill your site in short. Unless everyone does it at once and upgrades happen to support things, its at best a slow burn like firefox. But at this point webm doesn't have half the use cases as firefox did.
It might be a fun exercise to guess how many big sites it would take, but it's more relevant to realize that there is very little reason for any big site to deliberately not support a huge number of potential visitors.
Pretty much everything has hardware to decode h264; webm hardware decoding is still thin on the ground. Bulk encoding h264 is also typically cheaper than webm; the software encoders are faster, and hardware assists are available.
Firefox supports MP4, and they changed their position two years ago when Google and Adobe weren't as all in as they claimed to be. Further through an appropriate media plugins that browser should support anything the platform supports, and it was pure dogma that had it refuse early on.
Apple is never going to support WebM. This kills the format. There are hundreds of millions of devices that can hardware decode MPEG4 than can't for WebM. Nay, billions of devices. Of course WebM is always just around the corner, but this has just led to a stagnation where the scourge of animated GIFs reigned supreme.
well mp5 is right around the corner as well. Out of curiosity, what do you think the world is going to do when it's confronted with the choice between pushing out open source competitors or letting them in?
Anyone try to browse images on Imgur on iOS lately? I have. It's a huge pain because M4V videos take over the entire screen when they open. This looks great on a desktop browser where the videos play right on the page, but on iOS the experience is markedly worse than before. The videos load faster, but having to tap play, watching it loop, then tapping on the video again to bring up the header/footer, then tapping Done to stop the video... How is that better than just tapping Play?
Now, I understand that this is an issue with iOS and not with Imgur, but honestly, GIFV is not a great improvement, technologically or otherwise.
Also, note that most GIF's on Imgur end up there as screen caps of various web videos. In other words the process is now M4V -> GIF -> M4V. Instead, Imgur could just build tools for better short video creation that they could then host.
I don't know if its just me, but the GIFVs embedded on the page dont load for me, unless I click on them to open them in a page on their own, and the second one doesn't play even in this case.
That's probably because Firefox on OS X (32.0.3) doesn't yet handle H.264, which is what these GIFV files really are.
FF on Windows (32.0.2) does support H.264, and the GIFV files play as expected. IIRC, FF on Android was the first version to get H.264 support, which it's had for some time now.
EDIT: You can check codec support for your current browser+platform at YouTube's HTML5 page, below. I briefly dug around in Bugzilla for this issue, but haven't found it yet.
You're right, the page you linked shows that my browser doesn't have support for H.264... though then I'm confused as to why the first GIFV loads for me when I open it on a separate page...
They work for me, Firefox 32.0.3 on Arch Linux. You'll likely need some gstreamer packages installed (I think the package on Arch is gst-plugins-good for h264), same as for watching YouTube videos in HTML5 mode rather than Flash.
There's also an about:config option "media.gstreamer.enabled" which needs to be set to true, but I don't remember ever having to set this myself.
I'm a little disappointed that they've not only created an absurd new file extension, but that they're settling on patent-encumbered H.264 video compression.
>This is a marketing endeavor that is pretending to be a technical innovation.
Most of us are asking, why isn't it format X, or format Y. When they are clearly superior in quality and compression. The answer is they don't have marketing power.
GIFV is directed at increasing attention to imgur. By trying to make more sites adopt it as their image/video hosting platform. Since imgur already has the size/market dominance to spread the GIFV platform. Increasing its chance of adoption.
Rise above, support webm. Better compression, better quality, more wide spread.
The reason Imgur is doing what they're doing makes sense (downloading animated GIFs is an absurd waste of bandwidth when people just want to see really short low-quality videos in their browsers).
The way they're going about it and the way they're marketing the decision is arguably kinda silly. But the monocle-popping that is occurring in this thread is an order of magnitude sillier than anything Imgur is doing.
This is really not worthy of the volume or intensity of the hand-wringing that is occurring in this thread. This is the type of news that you either ignore completely, or skim, nod, and move on. At worst it deserves some exaggerated eye rolling or a sarcastic joke to a cow-orker during lunch.
I cannot right click and save an MP4 video in my browser.
I cannot drag and drop it into an email.
As a regular end user, I can use approved sharing features only. As a developer, yeah, I can download it myself and rehost it somewhere that hopefully supports MP4 video.
The historical pissing match over how to best do animated PNG files is sad. An animated image format that is treated differently from videos is a nice thing to have.
People have entire folders full of appropriate reaction GIFs. With how MP4 video is treated online today, such a thing is not possble.
Dragging&dropping the video from that page into an email (Gmail) on another tab worked as expected. Don't know if Gmail is doing something special though.
I tried this on a desktop Firefox/Ubuntu. I'm actually quite surprised that it worked without any problems, considering the rough history of MP4 on Linux/OSS in general :D
To all of you here asking 'why not webm?' consider this -- gfycat serves both webm and h264, I'm pretty sure imgur will add that in future, so no big deal. As for support, most of you are sitting on Chrome already, so you won't have any troubles playing h264.
hint: if you only care about chrome users on every feature, and keep looking at you site access log to justify, you may find that there is a reason why your access log mostly have chrome user in the first place...
Beyond the webp/m debate that I'm sure will take place here adequately without my input:
I think one of the bigger concerns these days with "short video clips on the web" - which is what we're all trying to solve with whatever technology - is workflow. People finally understand how to make gifs even if they're super low quality, or super large, then these poorly compressed "images" are being converted into various other things. If the tools were there to create audio-less MP4 / webp/m, that would help a lot.
I think it all but caught up lately in VP8 vs h.264 performance. Google kept improving VP8 performance. However, webm has also added VP9 support recently, which is clearly superior.
This is not true. My work, written three years ago, showed that VP8 was inferior to H.264[1] at the time. A more recent paper showed that both VP8 and VP9 are inferior to both H.264 and HEVC[2].
Is VP9 in much use (compared to VP8)? I've definitely heard good things about it, but I have no idea how well supported it is or whether anybody has it in use yet.
Pedantry: WebM is not a compression format. It is a container format. At the moment it appears to support VP8 video, VP9 video, Vorbis audio, and Opus audio; there is no single form of compression that WebM implies.
The marketing here is a little disingenuous ("Imgur is reimagining the looping GIF video"), and a good number of Imgur users (those that have also used Gfycat, the intersection of which I presume are relatively dedicated users) will know it. Not a great move.
I've been hoping they'd do this for a while. I hate browsing Reddit and finding a link to a little 'video' that then takes minutes to download fully and still looks terrible because it's a 15MB gif.
As someone who runs a website with something similar, I'm hoping that Imgur is big enough to push for some open standards around this. I want embedding video to become as commonplace as embedding GIFs.
Part of the reason GIFs are so popular is because of the limited colorspace. The new colorspace and compression sort of turn this into an entirely new medium not a better GIF. Other than the sometimes better filesize I don't really understand the appeal of any of this. Especially since support is far from that of GIF.
I'm surprised nobody has mentioned this yet: why is imgur allowed to use copyrighted material to promote this new feature? I'm pretty certain they didn't get permission to use those clips from Tron or Star Wars. Does the fact that they were created by a user somehow give them immunity?
That's exactly my point -- (editing clarification) that the Copyright Act does not consider this fair use.
From the article you referenced, "A key consideration is the extent to which the use is interpreted as <transformative>, as opposed to merely <derivative>."
These are not parodies, being used for education or being used for critical analysis of the subject.
It doesn't have to be. Parody and education are the situations where you can pretty much use the entire thing... but they're not using the entire thing.
I clicked on this story hoping to find a clever alternative to the raster path for traversing images in GIF images, when used to compress video (highly correlated images). Something that preserves the spirit of GIF, but sucks less for what kids are using it online these days. Bummer.
I heard of a HTML5-based alternative some time ago called the "ugoira HTML5 zip player". It uses a ZIP file of PNG/JPG files and renders the animation using JavaScript onto a <canvas>. There's a detailed slide deck talking about it [1] and the source code is available too [2].
This is bizarre. GIFV isn't a new file format. It is just an alias for an existing format. The only reason the letters "GIF" are in this new file extension is to signal that the file was converted from a GIF, but who cares, apart from the so-called cultural connotations?
I mean, does anybody care to have a BMPJ (a JPEG file that was converted from a BMP) or a WAV3 (an MP3 that was converted from a WAV)? Or a .GIFMP4GIFMP4GIFMP4 file, which was converted back and forth a few times?