GIF video has "privileged" support in browsers, because it used to be the only native video format, and that level of integration has been impossible with '90s QuickTime/RealMedia/WMW plug-ins.
And decade of this situation has conditioned us to think that only shitty video formats (like GIF, APNG, WebP with animation) can be allowed to have first-class support in browsers, and any video format that is technically competent must be kept isolated in special tags, must not work well with rest of the browser and must cargo-cult limitations of plugins of the '90s.
But browsers can and do support H.264/WebM natively now. Technically (patents aside) we could have <img src="video.mp4-or-webm"> work just as well as GIF (and maybe even faster given 10th of bandwidth needed and possibility of HW acceleration).
Besides the whole video codec debacle, APNG has many advantages for the web (which are shared with gif). Since you have transparency, you can make each frame transparent, and lay them on top of each other; which allows more efficient temporal compression. You could also used an indexed palette, to save a lot of space (but not be limited to 256 colours per frame). Then you also get proper lossless compression, which is important for logos when scaling.
While much more efficient in the long run, a video codec loses out for short animations when you consider the above points.
>Since you have transparency, you can make each frame transparent, and lay them on top of each other; which allows more efficient temporal compression.
There is simply no way that you are going to achieve more efficient compression with that crude technique than with the algorithms used by modern video codecs.
I also think that losslessness is probably relatively low concern with an animation.
The transparency thing is important, although that is achievable with video as well. WebM is apparently going to support it directly one of these days, but the cross-browser way is to store the alpha channel in a separate half of the frame and combine them using an off-screen canvas. (Edit: see this demo: http://jakearchibald.com/scratch/alphavid/)
Do any browsers offer that option from the GUI? It seems unlikely to be common. It also seems like an easy fix for browser developers to allow you to exclude from that rule any video that has no audio track.
There's probably too many places where embedding a full blown video isn't practical - at least not in existing products.
Avatars, emoticons, simple GUI elements (I'm thinking e.g. of a "copy file" dialog) and similar.
But isn't gif sufficient for that? apng is obviously technically superior, but gif is already supported everywhere. It's one of those cases where "perfect is the enemy of good" IMHO.
Don't forget that we now have javascript, CSS animations, canvas and webgl in addition to good old gifs to deal with animated features. Do we really need apng on top of that?
Refinement of video embedding would still be ideal in my opinion. Isn't APNG lossless? Something lossy but low-resource (an older compression format, in other words) embedded as the full file (instead of streaming) would be deal - like dumping a little MP2 in place of a GIF.
Can you elaborate on why it's impractical? I understand that at a gut level you have the concept of "full blown video", but I'm not sure instinct is faithful to reality.
Not a proper answer - but h.264 has one clear goal, good compression ratios at good quality. Performance is secondary and as such h.264 is pretty expensive. This makes it a little silly for small assets where filesize is not a concern.
Little emoticon stuff makes more sense with GIF which are very inefficient with filesize but with very very little performance overhead.
This is just 'my gut' like you have said. A proper analysis of the performance of h.264/GIF vs resolution would be nice though.
I expect that the performance issues with small assets are probably minor (and smart phones have hardware acceleration for it). H.264 is expensive to encode, but the decoding cost is much lower, and is also adjustable at the cost of the compression ratio. If you want transparency, then the workaround you currently have to do with going through an off-screen canvas is another story for performance.
I can think of one other hypothetical problem, although it would need testing to confirm: block sizes. h.264 works with block sizes that are a multiple of 4, and AFAIK codecs often perform sub-optimally with input that cuts off mid-block. For large videos that doesn't matter much, since you don't usually focus on the edge of a video, but for a small asset, it might be a problem. Someone with more knowledge of h.264 might be able to correct me on this.
I tend to agree with you, but apparently people _really_ like GIFs, irrationally. I built a service[1] that converts GIF files to HTML5 video (h264 MP4 + OGV) and people reacted very violently, arguing that "it's not a GIF". It makes me kind of sad, but oh well. It even has a simple embedding mechanism[2].
Excellent! I had this same idea in 2011, kudos on the execution! The size difference between animated GIF and actual video codecs is vast and the idea seemed obvious. I made a quick mashup with ffmpeg+Django (I'd use Go/MongoDB for web instead of Django these days.)
HTML5 video wasn't uniformly supported across browsers (and remember Google announced Chrome would drop h.264 around that time) and I didn't get positive responses on the idea. Maybe with more tools to support HTML5 video in animated GIF use cases and educational tools showing the difference in loading times and encoding algorithms this idea could take hold.
Also the WebP engineers have developed an animated WebP format which I disagree with but could be a step toward breaking GIF's monopoly on short animations.
>HTML5 video wasn't uniformly supported across browsers
It's still the case, IMHO. For example, mobile devices are a lost battle, in my experience, when it comes to HTML5 video (with autoplay and without controls). So MC ends up serving the straight up GIF to them.
I hope animated WebP becomes a thing but I have my doubts. I'm not sure whether the three major browsers will support it to an extent that it's actually sensible to use animated webp.
It'd be nice if that would change, though. Some forum software allows you to embed video from YouTube and friends, so it wouldn't be too much of a leap to embed short video clips using the mechanism described in the MediaCrush docs. I think it's an elegant solution.
The point is not that it looks the same (although it does). The point is that videos load much, much faster than gifs. I've seen gifs converted to videos, with the video loading 30 times faster than the gif.
With a higher-end stretch goal of $20,000: Python native extensions, it is apparent someone doesn't understand Python. On a humorous note, isn't import apngasm part of the batteries included?
animated gifs are used instead of video, because the restrictions lend it to less cruft, fast(er) downloads and widespread browser support without plugins.
Building extensions/plugins to increase quality is not only missing the point, it's directly opposed to it.
