But is there headroom for JPEG to replace animated gifs? If I look at mobile social apps these days, animated GIFs eat up enormous amounts of data. JPEG doesn't seem to have an answer for this, and no one has yet, it appears, made the <video> element work for this use case.
I really wish people on HN stopped linking to gfycat and linked to mediacrush instead. The former seems like a very scummy "lowest common denominator" type of site, while the latter is open source, allows self-hosting, has deterministic hashes, uses strong https encryption, ...
I looked over mediacru.sh and unless I'm missing something it doesn't serve the same purpose as gfycat. The point of gfycat is to upload a gif, it converts it to webm then it gives you a bit of embed code that will try to use the webm variant but will fall back to the gif when unsupported. I didn't see anything in mediacru.sh's code that would allow gif <-> video conversion, I tried uploading a few gifs on their site as well and didn't get any video options back from the API.
It would be better if the iPhone would play <video> tags without user interaction. I get the reason why they disabled that back when the iPhone first came out, but GIFs use up more bandwidth than videos, so they're actually punishing users.
Disagree. On the consumer side, I care more about auto-playing audio than bandwidth. On the content owner side, I only want my videos to autoplay (in most circumstances) if it were accompanied by the audio. If I didn't care about audio accompaniment I can already use GIF.
Perhaps the iPhone should autoplay videos, but muted until you hit a speaker icon (or something). Either way, forcing everyone to use GIF is horrible because of how inefficient it is.
I'd like a global option and also some simple per site UI.
This is how the click to play in Firefox works, it's nice. One thing I haven't figured out how to do is trust embeds from a site (for example, Youtube and Vimeo both have well behaved embeds, so I'd like to whitelist them, but not many of the third party sites I see them on).
That's only a UI issue. You don't need compression to be horribly inefficient to achieve that :)
For example <img src=vid.mp4> could autoplay looped video without audio, just like GIF, except using tiny fraction of bandwidth and CPU (thanks to HW acceleration) than GIF.
Expanding on Ray's comment above, this is really the compelling use case for WebP: a better container that does it all. Right now we have PNG, GIF and JPEG for three different use cases: animation, transparency and lossy encoding.
I can't easily pick and choose which of these I want, which means that we end up with 20MB GIFs that could easily be 1/5 the size, and crazy hacks to get lossy images working with transparency.
This is particularly painful for HTML5 gaming in my previous experience. For one of my projects that involved a giant, high-res game board with transparency (Nick's online Pai Sho), I ended up manually slicing the board up, converting center pieces to JPEG and leaving the edges in PNG. The images are all pasted together to make the final, seamless experience. What a PITA!
> no one has yet, it appears, made the <video> element work for this use case.
4chan has, and it's significant not only because they have a lot of traffic, but also because their implementation has to be pretty solid -- 4chan users would love nothing more than to troll the administrators by breaking this.
That and 4chan is a big content generator for the internet. Everything further down the line (reddit, imgur, 9gag, tumblr) should support it. Especially tumblr, who can consume over a gig of ram if you scroll down long enough.
>4chan users would love nothing more than to troll the administrators by breaking this
Not really worth it. You'd post something once, then you'd get banned for a week. Unless you have a fleet of proxies or can keep changing ip address somehow, and can keep posting while they try to fix whatever exploit it is you found. Kind of hard to target admins when they're all anonymous, too.
I have a cable internet connection and know the difference between a modem and a router. You'll have to take my word for it that every time I change my router's MAC address, my public IP does as well.
Honestly, animated GIF (like all other image formats) is a terrible format for video-style stuff. It's fine for line art (well, sort of fine, anyways), but if you actually using it for video you really should be using <video>, because it takes into account temporal information. (gfycat is a service based around this already.)
It might be possible to do an APNG-style backwards-compatible animated JPEG, but it'll still be worse at it than video formats will be.
Thanks to the ACID3 test, all modern browsers support animation in SVG and svg in an img tag. Which means you can do extremely small vector based animations, or write an encoder that embeds jpegs and animates them like a film strip. You can have alpha transparency using a mask image via SVG filters. You can get really fancy and animate with deltas. The efficiency you lose by the base64 encoding is regained by gzipping.
Actually SMIL (the declarative way to do animation with SVG, for those who don't know) has always been controversial (as far as I know, IE never passed that part of Acid3), is more or less on the chopping block as far as browsers are concerned, wasn't extensively tested in the original Acid3, and, in any case, was removed from Acid3 as of 2011[1]
It was removed from Acid3 (or at least made optional), letting IE pass the test without implementing it. Furthermore SMIL is fairly complex, performs worse than script animation in today's browsers and (iirc) doesn't play well with CSS animation. I think I've read on the mailing list that there is effort done to harmonise those two in the future.
To review, it would seem that while you have a blog post from ian hickson making a passive reference to deprecating smil. Indeed he followed up by removing the feature from the ACID3 test. But the damage was already done:
evidence of actual standards activity and implementations from as recently as June 2014 show instead an active merging of css animation with svg animation into a single consistent model called "web animation" [1]
the implementation of this merging effort in chrome's blink rendering engine [2], and a rationalisation for this webanimation effort that promotes not a removal of the svg animation features (which are already implemented in everything but IE), but an expansion of their powers, being advocated by both google and mozilla [3]
Just because IE is lagging behind doesn't mean this feature is cut. Just because Ian Hickson says the feature is deprecated doesn't mean that it is, or that browser devs will follow whatever he says.
What it does mean though, is they are attempting to cut the feature's dependence on "SMIL", while retaining the currently implemented features. so I think that whatever works in browsers now, you can more or less rely on that working in future browsers as well. So yes, my suggestion is still useful and it's still awesome. And if you use css animations inside the svg (which totally works) instead of svg-smil animations, you can even get it working in IE10
I see many "big" webm videos on 4chan, much bigger than gifs. (in dimensions, not in bytes) and they are still smaller (in bytes) than the (dimensionally) smaller gifs.
Wouldn't it bring a huge traffic shrink, if every uploaded gif was converted to a, probably, tiny webm?
you can use javascript mpeg1 decoder instead of <VIDEO>
you get auto playing animated mpeg files instead of gif
mpeg is pretty much jpeg stream with bonus I frames
Motion JPEG is arguably even worse than GIF. It's literally just a sequence of JPEG images -- there's no extra compression; 100 frames of MJPEG are 100 times larger than a single image. GIF is a bad format for videos, but at least it can try to be more efficient than this.
