This is completely terrible.

This completely disregards anything motion estimation. Every single frame is encoded from scratch and that means a huge amount of space is wasted. And because of how JPEG works if even a single pixel is different in a macroblock you're throwing away most of the compressibility. Even GIF, GIF has the option of overlaying the previous GIF, which is how it's possible to get more than 256 colours in a GIF, among other net little tricks. GIF with even a small measure of dithering makes more sense than this, in all honesty. "GIFs, but better"? That's only because you're a) not using GIFs right and b) GIFs are terrible, but there's worse for the majority of use cases. This is one example.

It also means that the browser has to load every single frame of this. If you've got a minute long video with 15 frames per second, that's 900 JPEG images in base64 hopping around in memory. Which do you think a tablet would be better at? Playing a minute of H.264, hardware accelerated and all, or shuffling through 900 JPEG images, 15 a second for at least a minute? How about 60 fps and 15 seconds? MPEG has been invented for a reason. Motion estimation is a good thing and has been built into everything since the 90s. Including virtually all mobile browsers, through whatever codec. Sorry, but this at best solves only a UI problem. Something like gifv is a much, much better solution. Also, unless you have the JPEG quantiser set to a wasteful 100, you're going to see the maroblock boundaries sitting around there and cutting lines into the picture, each frame differently depending on the quantiser level. I wouldn't even call it a neat little hack - just check out the memory usage. And don't even get me started on the name - XNG.

Using canvas with JavaScript to render something akin to simple MPEG - that would be cool, amazing, brilliant. Finding a way to optimise dithering patterns within a GIF to minimise frame sizes would be absolutely fascinating. This is terrible.

This is not a format problem. Hell, storing a movie in three different actual formats next to each other to get browser support for everything would waste less space than a single file of this. This is a UI problem at worst.

If you want to use SVG for animations, go nuts. By all means. But never use it for anything like what I'm seeing here - actual videos instead of animations.

The only use I can see for XNG that leaves it at least an order of magnitude as good as something else is if each frame shares almost nothing in common with the previous frame and is a full actual picture. But even then MPEG-1 with every frame a keyframe would do about just as well. gfycat and gifv are perfectly fine and superior on almost every level (apart from maybe the UI on esoteric devices x y or z that also somehow have a fast processor and a lot of RAM) than this.

tl;dr: 60% CPU usage and a memory leak pushing my Chrome past a GB and that's just the start of it.

"Terrible" is taking it a bit far. This is basically a prototype and certainly has potential.

> This completely disregards anything motion estimation

A good xng encoder could work around this by doing the motion estimation and encoding transparent regions where things don't change on subsequent frames which could reduce file size dramatically.

There's no question that for longer video clips, a native format like mpeg4 will outperform, especially on mobile. This XNG thing does play smoothly on my iPhone 5s with iOS 8 however.

> Using canvas with JavaScript to render something akin to simple MPEG

This has been done and jsmpeg is one such implementation - https://github.com/phoboslab/jsmpeg

Live demo here: http://stream.imdeity.com [ The macro blocks/visual glitches in that demo are a result of the live capture/encoding via ffmpeg and not a jsmpeg problem ]

The downside with the jsmpeg approach is that it requires accompanying Javascript to work and won't animate as a standalone file unlike this XNG method.

> 60% CPU usage and a memory leak pushing my Chrome past a GB and that's just the start of it.

Seeing high memory use on my Chrome as well but only 8% CPU usage with the multiple XNGs on that page playing at the same time (which is about the same as a single Flash-based Youtube video playing in another tab).

Again, definitely not production ready but has high potential when paired with a good encoder.