"A GIF is literally a sequence of independent images squeezed into the same file. An mp4 video can take advantage of all kinds of fancy compression techniques like keyframes and forward-predictive frames."
That's not why the mp4 is smaller. A GIF is not [just] independent images, you can have each frame reuse pixels from previous frames.
The mp4 is smaller because lossy jpeg compression is used on each frame, while the gif stores each frames losslessly.
This has implications from the predictive frames as well - the jpeg is lossy, so two almost similar parts of the images can be considered "the same", while the gif is not, so they must be identical in order to compress that way, and the realities of video noise makes that unlikely.
GIFs store deltas, true, but they are still raster images.
H.264 on the other hand contains specific techniques for compressing sequential frames, including things like recording only pixel motion for some frames. You can see it in those "corrupt movies" gifs (which on twitter would be mp4s... talk about irony) where you take a clip and remove some keyframes from it - then transformations are applied on the wrong blocks and you get really weird things like someone's head splitting open and stuff flowing into each other.
Additionally keyframes in movies are usually compressed with even more loss than standard jpegs. In most cases only the Y channel is recorded at full resolution and the two colour channels - U and V - are recorded at half.
There is also motion-jpeg which really is literally a sequence of jpeg images.
With a good palette (which most software is terrible at) and proper delta frames (without artificial differences created by blindly applied diffusion) GIFs can be 1/4th of the size you get from an average GIF maker.
Still, it's a terrible video codec.
I think trauma caused by awful plugins like RealPlayer and QuickTime made people stuck thinking that "animated images" and "proper video" are completely different things. But with native video support in browsers IMHO there should be no divide between <video> and GIF at all. It's the same thing, except the latter wastes more bandwidth, needs more memory or CPU (to enable seeking, used when you switch tabs) and can't be hardware-accelerated.
> Gif is pretty bad, yes, but somehow I can browse pages with thousands of gifs. I can't browse pages with thousand of embedded videos.
That's true, but it's not limited by compression, only by assumptions/optimizations in the browsers.
For example browsers try very hard top stop decoding GIFs that are not currently visible on the screen. This could be done even better with a properly seekable video codec, but it's just not implemented.
No argument there. I was just stating a reason why gif-heavy site operators are reluctant to switch to video. It's chicken and the egg. They won't switch because video is not as optimised yet, the browser vendor has no reason to optimise video further because sites usually don't have that many embedded videos.
Sorry but H264 does not use JPEG for its keyframes, although it's not very different. There are a lot of differences between GIF and H264, like H264 specifies that you can use multiple reference frames, which is not the case with Animated GIF. Also H264 has motion compensation, which does not exist with GIF.
GIF basically rewrites completely a part of the picture, while the remaining part is reused. And if you consider that a rewrite of a small part of the frame to reuse the remaining part from the previous frame is just displaying a new gif on top of a part of the old one, the you can consider that it is a sequence of independent images. Maybe they don't all have the same size and are not meant to be displayed at the same position, but they are independent in the sense that you don't need a previous or future frame to display one frame.
And I wouldn't refer to GIF as lossless, except maybe if your original animation used only 256 simultaneous colors per frame. You lose information by down-sampling your colors.
It's not just lossless/lossy. GIF is also rather primitive; you can store a delta from frame to frame, but the delta has to include every pixel that changed. A lossless animated format invented today wouldn't have that restriction, it would support things like pixel motion (which e.g. H.264 has).
Some years ago there were multiple efforts to produce animated PNGs. There was MNG (Multiple-image Network Graphics, which could contain both PNG and something called JNG) in 2001, and more recently, APNG (Animated PNG) in 2008. The problem here is the spotty support for these formats. AFAIK MNG is effectively dead. I thought APNG was as well (with Firefox being the only browser to support it), but interestingly, the Wikipedia page claims that Safari 8.0 (the upcoming version in OS X 10.10 and iOS 8) supports it. Chrome, Opera, and IE don't, but there is a Canvas-based library for rendering APNG which could presumably be used to polyfill support if you wanted to experiment with APNG.
In any case, the point here is that something like APNG probably has much better compression than GIF while still being lossless (I haven't done any actual comparisons here, but the PNG format itself has support for a lot of fancy compression stuff that GIF doesn't).
---
Reading a bit more, I'm actually really surprised to see that Safari 8.0 apparently supports APNG. It seems that the PNG Group officially rejected APNG back in 2007, which means that libpng will never support APNG.
Really? How curious. Why APNG? I would have assumed slot machines would want specific control over their animations and so would use something actually designed for that sort of control.
Totally true, ars. I came here to nerd-rage that, no, a GIF is NOT “literally a sequence of idependent images.” That is NOT what makes common video formats use less bandwidth, and I thank you for making this clear.
One thing you can do with video that you can’t do with GIF is programmatically describe motion — shift frame to the left, for example. GIF, you’d have to re-draw it all.
Correct me if I'm wrong, but wasn't the whole reason gifs started proliferating on the net because people wanted to share short video loops, but didn't want to embed flash or video which may not load or play correctly in a user's browser? And now we are championing the conversion of those gifs back into video? Seems like a strange round-about way of doing things.
I forsee a future where all video clips on the net have been converted back and forth between gif and video so often that they all slowly merge into a single amorphous blob of greyish-brown pixels. Actually, now that I think about it, that would almost certainly be an improvement over the current situation.
I don't think gifs' recent surge in popularity has anything to do with technical issues like browser compatibility. They became popular because of artistic/aesthetic value and web culture. These features all differentiate gifs from 2010-mainstream forms of embedded video like Youtube:
- starts playing automatically
- loops seamlessly
- never has sound
- no logos or buttons like "share" and "embed"
- no scrubber bar on the bottom
- repeated instances of the same gif play back in lockstep
- no frame around it
- pixel-perfect control
All these features make it possible to create art that wouldn't work with embedded video. (Defining art broadly; captioned movie clips are included.) In the past few years, some creative people started making really good gifs that took advantage of these features. Then the trend spread through web culture. The next generation made gifs because "making gifs is what clever artistic people do on the internet".
It's always been easy to create a looped animation format that combines the feature list above with a better compression scheme. Now that gifs are so popular, someone recognized the need and made one.
IMO, the 256-color dithering was more of a necessary evil for most gif creators, although some took advantage of it. It looks nostalgic on 90s Gourard-shaded untextured computer graphics. But for movie clips, etc, I think many will be glad to get rid of it. I bet we'll see a sect of gif creators who think mp4s are not authentic while most people won't care.
Your last comment reminds me of Alvin Lucier's "I Am Sitting In A Room" (wiki/youtube). Someone repeats that idea with every lossy medium we invent. I've seen jpeg and vhs examples but I can't find the links right now.
I think your list of features is spot on, but I don't think their mainstream popularity had much to do with artistic expression. I'd include one other big feature:
- They are dead simple to save (or link to) and drop into your own page/blog/comment.
and claim that GIFs are just really easy to share and view. They've offered a better experience both for post and viewing a short soundless clip than could be provided by an embedded Youtube player.
How about the fact that there is zero advertising. IMO this is the number one piece of friction for videos (mainly YT) and the users don't want them for especially quick moments (a la Vine).
> They've offered a better experience both for post and viewing a short soundless clip than could be provided by an embedded Youtube player.
I'm not sure that's always true, as there some very noticeable problems with GIFs. Most significantly they're often huge, and must be entirely loaded to play properly, which can result in long delays before they can be viewed (usually with no obvious indication to the viewer) and massive resource usage (besides the problems related to size, animated images also usually don't benefit from the sort of acceleration and optimization that videos do). A page with a bunch of embedded GIFs (not at all uncommon), can completely kill a browser.
[There are other problems, of course, e.g. the complete lack of user control over playback, but the size of GIFs seems to be one of the worst.]
> IMO, the 256-color dithering was more of a necessary evil for most gif creators, although some took advantage of it.
I'm under the impression that the format only specified 256 colors per palette, and that you could use different palettes on a per-frame basis, including frames with 0ms delays between them. and I know some software existed to make this possible, though I don't recall if it made it possible with animation at the same time...
the format permits frames with 0ms delays.
the problem is that there has never ever been a browser that respects the 0ms delay. On the whole, the status quo is that any delay under 10ms gets upgraded to 10ms.
Newer (current) browsers have lowered that to 6ms, and in chrome, 3ms. As yet, there has been no browser that respects the 0ms delay (as in, supposed to display instantaneously, so 2 frames with 0ms delay is supposed to look like 1 frame).
The justification for this is backwards compatibility with incorrectly authored gifs. So .. there you go.
Yes, in ancient history, video codecs sucked, browsers sucked, and the only way to play video was through plugins that sucked.
Now, all the browsers are pretty good at dealing with video, the codecs are hugely improved (although, there's some headaches with IP) and the plugin is dead.
Nobody ever actually wanted gifs. They want short, small videos that are guaranteed to work in their browser and that they can be pretty sure aren't going to have sound. We can now deliver that.
To be fair: they don't want short, small videos any more than they specifically wanted gifs.
They want moving images that load quickly. Which has meant short/small/gifs, because most US bandwidth still sucks. And thanks to the mobile explosion it now means short/small/h264.
But I bet that as people become used to 5-10x space savings from h264, they'll quickly respond with videos having 5-10x more data. (larger/longer/higher-res clips)
In ancient times before plugins, animated gifs or any sort of video, we would painstakingly screen cap individual frames from movie clips and use "push" via CGI to force feed the browser a series of images that gave the illusion of animation. It was just a hi-tech spin on flip cards.
The guy is baiting in his first couple of paragraphs. By the end of the article, he reveals that he approves of Twitter's decision. Indeed, the automatic conversion from GIF to HTML 5 is well underway with sites like gfycat, which is getting integrated into major extensions like RES if it's not there already (RES [finally] merged the code to support this last night). HTML 5 video is greatly superior to GIF; the files are many times smaller and you can pause and/or control the loop, and normal video players are equipped to handle them, which makes platform integration easier (Android's browser famously didn't play GIFs due to memory constraints in the browser's early implementations).
gifs are not necessarily video loops. take for example the works of nicolas sassoon (http://nicolassassoon.com/) which occupy the grey area between video and still image
GIFs don't load or play correctly in my browsers, despite being up to date and running on unreasonably powerful hardware. Animated GIFs are so unbelievably inefficient that they're often unwatchable even on modern computers. I can't count how many times I've clicked a link to a GIF, decide I didn't want to wait five minutes for the thing to fully load, and moved on to the next amusing link.
This article makes it sound like Twitter invented a whole new optimization, when they really just recycled a concept already in use by gfycat (http://www.gfycat.com/) and MediaCrush (https://mediacru.sh/).
I'm curious if anyone is noticed the flickering Loading icon when the .mp4 version loops? It only shows up for 50 ms, but seems kind of annoying. Or maybe it's just my machine?
I saw it too. The odd thing is that 4chan's equivalent doesn't show any such loading indicator. Also, looping a video in HTML5 doesn't require Javascript.
Support for mp4 isn't bleeding-edge tech on other operating systems / distributions, unfortunately. It's a couple of years old in terms of being supported by Chrome; it's supported in Firefox as of last August.
At this point, desktop configurations that can't play mp4s are at risk of being considered "broken."
Is it really that difficult to supply a free format like WebM in addition to patent-encumbered H.264? If you only supply H.264, you're cutting out Firefox on OS X, Chromium, and Opera.
Interestingly, the gif->mp4 in the source link uses Constrained Baseline H264, the only profile that's supported by Cisco's BSD-licensed OpenH264[1]. The MPEG-LA patent fees are already covered, so that small projects can freely use the decoder/encoder.
It does mean you need to transcode and store twice as many files, which can be a serious pain if you've got a number of different bitrate H.264 assets. It can be a big pain if your software assumes there'll only be a single media file. Not insurmountable but painful for small operations (and for large operations, where there may be a back-catalogue to worry about)
I'm with you in spirit, but in practice I think we can all understand why people often just go for H.264
Yes, until we get client-side transcoding, it is that difficult. Video files, even files compressed with modern codecs, are really big, and the concepts are generally really hard for most people to grok. The knowledge is so arcane that if you have a basic grasp of ffmpeg you are already a wizard. Most people's eyes will glaze over the second you start talking about how they should use a different container, or codec, or whatever. That's why GIFs (for sub-one-minute videos) and Flash (for long videos and/or videos with sound) became the universal language of video; there was no more "Here's this video, but you have to install WMP/RealPlayer/QuickTime/Bonzai Buddy to see it!" In fact, Flash probably became the standard because it did such a good job at integrating with the rest of the browser and didn't shove obtrusive branding in the user's face.
The tl;dr is that the support needs to very near universal for this to work, and no one is interested in WebM. Google probably could've forced the issue with YouTube, and they initially claimed they were going to, but they chickened out for some reason. I've heard it's because VP8 didn't live up to expectations and that they'll renew the push when VP9 is done, but whatever the motive, the reality is that if you want HTML 5 video to work, you must use H.264, as even Mozilla has been forced to admit.
> Video files, even files compressed with modern codecs, are really big, and the concepts are generally really hard for most people to grok.
As the article points out, the video files are generally much smaller than the source gifs.
Similarly, while there are real impediments to transcoding for many developers, I'm confident that the Twitter engineers in this specific case are capable of building a VP8 pipeline. After all, they built one for H.264.
Yes, in this specific case, application-specific compression codecs are better for the storage of video, but that doesn't mean that video is small and that you can afford to transcode 4-8 different copies for every single image that would be uploaded (avail resolutions * formats * single piece of content), as that requires both a lot of CPU and a lot of disk space. It also doesn't mean any person around you has the expertise to figure out how to do this in a semi-reasonable manner, because as stated, most people don't understand the concepts used in modern video storage. You also assume that either WebM or H.264 will be supported by the user's browser. I don't think this is entirely correct, and in any case, it may always change, at which point the demand on the individual site becomes that much worse.
I think the real solution is to automate this and allow the client to request on-the-fly transcodes to the formats the browser can support, similar to the way some UPnP servers work.
Are you saying that WebM, a file format introduced in 2010, is less bleeding-edge than H.264 MP4, a file format introduced in 2003? What definition of "bleeding-edge" are we using here?
Same story. Most browsers supported H.264 first (because it was dominant before WebM was even born). Internet Explorer, Safari and MobileSafari still do not support WebM. I don't see any reasonable way to say that WebM is well-established and H.264 is not.
It does weird things on some mobile devices that do support it, too, mostly interrupting the audio player (on some devices, movie playback grabs the audio).
More like, "stop using technology from the late 80s or go fuck yourself". GIF is awful and nobody should reasonably expect sites to accommodate it anymore.
Okay, so take my question and s/HTML/hierarchical file systems/ or s/HTML/C/ or make any other substitution. Why ditch something just because it's old?
Well, there's a reason for the second half of my comment. GIF isn't bad because it's old, it's bad and old, and it's unreasonable to expect it to continue to be supported because that's a nasty combination.
If something sucks but is still the standard technique in recent years then it's reasonable to think it should be supported. Similarly, if something is old but great, it's reasonable to think it should be supported. But GIF is old and crappy and there's no reason to expect support for something old and crappy to continue indefinitely.
I'd also note that your other examples have received substantial revisions over the years that have improved them enormously. I'd happily say the same thing about not supporting 1987-era C or filesystems.
I recall reading on gfycat's subreddit that desktop Chrome's H264 support is occasionally spotty, so they chose to force on VP8/WebM in Chrome.
The upside is that users get a reliable experience. the downside is that laptop Chrome users get a reliably lower battery life, as VP8 isn't typically hardware accelerated.
Strangely I get that same message on my win7 machine running current chrome as well as my lubuntu machine running chromium. On both when I click the "click to view on original site" link it works fine.
What percentage of Twitter's users do you think use Linux for browsing? Much less RHEL. Anyway, this is purely a front-end enhancement mostly for the benefit of mobile users.
Also lol @ mp4 being "bleeding edge" tech. It certainly is not. Even in the Linux community.
It is an enhancement for the benefit of front-end performance. I'd like to hear how you think that is not true?
Anyway, that is why I asked the loaded question about how many users you think there are that browse Twitter.com on their RHEL box? Hint: HN is not a good sample to answer this.
And how is a ~14-year old technology (that has been ubiquitous now for at least 6 years) considered bleeding edge?
You choose not to use the appropriate software to experience what is being offered. This is akin to riding a decrepit horse on a racetrack while whining about how everyone else that is riding a healthy horse is going faster and having a better experience than you.
Your analogy is stupid and your comments are not helpful. I'm not modifying 3,600 workstations because some web programmer decided to mangle user-uploaded content without doing fundamental work to ensure graceful degradation.
you're seeing that because they wanted to show you what it looked like as an MP4. My understanding was that twitter would ship you the GIF if your browser didn't support MP4.
I think it's probably too early to call Gfycat the "winner", and I don't necessarily see why there isn't room for multiple providers. There's no reason image sharing needs to be a "winner-take-all" game; in fact, it behooves everyone if there is a bit of diversity in the space. I understand that reddit (the organization, not only the community) likes to aggressively favor single image sharing vendors, and that sucks, but surely there are other places where such a site can find usage.
"Videos allow Twitter to leverage the browser. This means play, pause, and seek, but also cool things like slow-motion. Think your GIF is funny now? Wait til you see it in slow motion."
Gifs have built in slow motion, it's called waiting for the 10mb file to download frame by frame upon initial play-through.
Unfortunately the MP4 looks worse than the GIF, due to chroma compression in the YUV 420 colorspace. While each pixels luminance value is kept, the color information for a 4-pixel square is stored as a single CrCb pair, which is really obvious when you look at how the orange hat has artifacts against the blue background. Increasing the bitrate won't solve this either, since it's a limitation of the colorspace.
Thank you! I was gonna post the exact same thing. Nice website, though.
I encoded the gif in 420 (subsampling), 422 and 444, having a nice quality with 444 with VLC, I embed the three different videos in a web page and when playing in my browser, they are all as bad as the twitter video! I thought that Firefox was using a standard library to play MP4?
Firefox uses the Windows-bundled decoder on Windows Vista or later. Chroma upsampling happens after decoding so it's the renderer's responsibility (Firefox, Chrome, VLC, madVR etc).
Depending on the webpage you uploaded them, the videos could be re-encoded (or VLC's options could be no-ops and the artifacts hidden when played back in VLC due to better chroma upsampling) hence the problem.
Okay, thanks for the explanation on the chroma upsampling! I use Linux but it should work all the same.
When I said that I embedded the videos in a web page, I wrote a small page from scratch to display them in my browser, locally, without any server. So no re-encoding. I think that VLC just has a better chroma upsampling.
Seeing as how the quality of the source is already completely destroyed by the 256 color gif, I don't think image fidelity really matters that much to the people sharing these...
We've been doing that at my company on our mobile applications for a few years now. There is no reason to be shoving 5-10mb GIFs down a users throat on a mobile device. Not only does are MP4s smaller (file size), frames per second will be constant on all browsers, unlike GIF (although most browsers are supporting up to 50fps these days). Although outdated, you can read more about that here. http://nullsleep.tumblr.com/post/16524517190/animated-gif-mi...
I wrote a simple js lib for detecting the duration of a GIF for each browser. It was a fun weekend project. https://github.com/rfrench/gify
If webp gains more adoption, it's another alternative now that it supports animation.
If you have a H.264 decoder installed (and most computers do), new-ish versions of Firefox will try to use it to play embedded H.264 videos. Unfortunately, a lot of sites are still in "Firefox == Flash" mode and automatically serve up the Flash version to Fx users without even trying a <video> tag.
Is there a flash blocker solution that removes all traces of the page element rather than leave an ugly placeholder? It's going to be annoying to see this on Twitter from now on.
I had a convoluted method using gifsicle to extract the frames and then encode as a stream of frames, but then sometime in the past year or so ffmpeg improved native gif support. This is what I use (the options are both for compatibility):
GIFs indeed are bad for video (quality, size, no control, no sound, etc.) but in order for that to be really true, the site must allow embedding videos using the video tag (i.e. videos which people upload in proper video formats). Does Twitter allow it?
How long has twitter been doing this? Just out of curiousity.
(Yes I know 4chan doesn't convert but there was some talk that 4chan might be a major player in pushing webm forward. Is it even webm or x264? On mobile. Can't check right now.)
For me the main lesson here is that I should be more attentive and investigate. I remember noticing some ungiffy vibe about animated clips on Twitter, but quickly dismissing the observation. Perhaps if my timeline contained a lot of GIFs I'd dig deeper, but it doesn't help feeling shallow.
"A GIF is literally a sequence of independent images squeezed into the same file. An mp4 video can take advantage of all kinds of fancy compression techniques like keyframes and forward-predictive frames."
That's not why the mp4 is smaller. A GIF is not [just] independent images, you can have each frame reuse pixels from previous frames.
The mp4 is smaller because lossy jpeg compression is used on each frame, while the gif stores each frames losslessly.
This has implications from the predictive frames as well - the jpeg is lossy, so two almost similar parts of the images can be considered "the same", while the gif is not, so they must be identical in order to compress that way, and the realities of video noise makes that unlikely.