I kind of feel like .gif's as a format need to die, and this really demonstrates why, in my opinion. this page demonstrates a way to add stop/start abilities to a gif, as well as syncronized audio, which is literally what a video is but without all the ability for compression and support for more than 256 colors.
People don't really want GIFs; what people want are filesize-limited, auto-playing-but-only-while-visible, auto-looping, and silent-by-default videos. Let's call these "animated images."
The problem is thus: you're designing a piece of forum software, and you're considering whether to allow people to embed various elements in their posts.
There's problems with allowing people to embed arbitrary videos: they can steal bandwidth, slow the browser to a crawl, make sudden noises, play to completion while the tab is in the background, etc.
But if you allow people to embed static images, then there's no additional consideration required in allowing them to embed animated images. Wherever a static image works, an animated one works.
Right now, there are two ways to allow people to embed animated images: either you allow .gif as an image upload format, and then display it without processing--or you allow videos, but do quite a bit of server-side processing (of the kind Vine and Facebook do) to make the result into an animated image.
If there was an adapter format -- some simple file format that:
1. referred to a video by URL (maybe it could be an HTML5 document whose root is a <video> element?), which would then be embedded in place of the metafile;
2. whose media type fell under the image/* hierarchy;
3. and for which the browser would automatically enforce "animated image" semantics,
then that format would be a perfect replacement for GIFs.
All of those criteria are satisfied by a <video> element with the "muted" attribute set, plus a little bit of JS if you want to be able to pause the video when it's scrolled out of view or the user is looking at a different tab.
I don't buy the argument about stealing bandwidth. A 50MB GIF is just as much of a bandwidth leech as a 50MB MP4.
It's the image-hosting ecosystem. An animated image format needs to be accepted for upload by public image-hosts; it needs to keep its animated-image semantics when hotlinked and displayed "raw" by a browser; and it needs, needs to work when hotlink-embedded inside an <img src=""> element.
These are all things that are true of GIFs, and aren't true of any other video format. (And this doesn't even address the fact that many people use GIFs for the combination of animation and transparency, which <video> doesn't currently offer.)
The image-hosting ecosystem also naturally deals with the bandwidth-drain issue: image-hosts don't want their bandwidth stolen either, so they have a cap on upload sizes. By allowing just <img src=""> embedding, you naturally lean on the image-hosting ecosystem's bandwidth economics to protect your users.
By allowing arbitrary <video> embedding, though, you invite the nascent video-hosting ecosystem, which has achieved a different balance: far looser bandwidth limits, but far stricter caps on concurrent requests (e.g. the Dropbox-Public-folder model.)
There's one specific case which is close to impossible with 'video' formats: referring to animated images in CSS. This is quite important for certain sites where users can modify CSS but not HTML.
Except that with a muted video, you need to communicate to your forum users that yes, they can upload a video, but it will be played back without sound. It's a different thing.
Everything that http://gfycat.com/about says about GIFs is also true of APNGs. For things that are actually video (i.e. not a pixel-precise hand-drawn three-frame 32-bit image loop), using a video codec is just better in every way.
I agree that for most uses of GIF nowadays, a video codec would be superior, but better in every way? What about decoder overhead? For certain sizes of GIF, the combination of GIF + GIF "codec" (a trivial XOR) will consume less memory than, say, h264 + h264 codec - in some cases far less. A modern video codec is not at all trivial, and also is optimised for filesize, not CPU load.
> For certain sizes of GIF, the combination of GIF + GIF "codec" (a trivial XOR) will consume less memory than, say, h264 + h264 codec - in some cases far less.
Memory, maybe. But CPU?
I keep this snippet[1] at hand at all times, because pages with multiple animated GIFs peg my CPU and make my fan spin up for as long as they're open (even when they're in hidden tabs! even when the GIFs are scrolled off the screen!) This doesn't happen with <video> elements.
I think the problem is that web browsers never bothered to move GIF decoding/rendering/compositing to the GPU. It's especially bad if a GIF is animating while it has CSS image-scaling applied to it, which leads me to believe that--since the GIF "codec" must be re-applied on each frame--the browser doesn't cache the decoded frames, and thus can't cache the scaled decoded frames.
