This is not a "new animated image format", it's just using the capabilities of something that existed before.
In other words, it's basically MJPEG in an inefficient text-based container. Many browsers can already play back MJPEG streams (common with IP cameras), so I do not see the point of this other than as an "it can be done" exercise.
Also worth noting that animated SVG (vector format) is usually bigger than the equivalent SWF file - despite all the hate Flash gets (after the Adobe acquisition was when it seemed to get worse), I think it's a great compact vector animation format. You can also put MJPEG inside a SWF, so they're on equal footing with respect to that.
The author talks about lacking support for apng, but ironically apng has better support than his hack and is a superior format in every respects.
Any animation form that a) just uses a still image form (jpg) and b) base64 encodes the data is destined to be terrible. SVG support is also not significantly better than apng... in fact, taking arbitrary photo viewing applications I'd bet that animated svg would fall far below apng in support.
Calling this a new format is also very charitable since je did no work on improving the actual image compression algorithms. Google's WEBP/WEBM are examples of a new format that truly is pushing the boundaries. This, not so much.
there is also the apngasm kickstarter project (already funded) that is building tools for legacy browsers to work with apng ... including pure javascript based graceful degradation.
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
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.
This is just MJPEG in disguise and then worse again. And MJPEG is already near the bottom of the list of things I would ever send over the web. Better or 'good' XNG encoder is an oxymoron. Also, it's JPEG so there's no transparency so you'd be using clipping masks in SVG. And that wouldn't give you motion estimation. For that you might want to subdivide the JPEG and...
But then you're already trying to put lipstick on a horse that's been beaten to death.
It doesn't have potential. Unless you have a slideshow of a low integer number of photographs and no access to JavaScript or a scroll wheel.
Good encoder? It's just JPEG, any good encoding is already figured out and this is the wrong tool for the job. gifv or even just silent webm for the win.
Also, nice that video played smoothly on your few month old device. Does it still have a battery left now?
It's neat to see this as a can be done exercise. But now it's time to set fire to it. As it probably has done to quite a few devices already.
iPhone 5s came out over a year ago. And yes it had plenty of battery left.
Also, transparency is possible because it's not limited to jpeg. PNG frames could just as easily be used where needed.
The point is the technique can be improved. Whether it can be shaped into anything useful is yet to be seen. In the meantime, cool down and take a deep breath.
meh, it boils down to whatever image format you use, you take a 33% increase in file size cause it's base64 encoded, and then a huge hit cause you can't do frame to frame encoding, like true motion estimation. It's trying (poorly) to solve an already solved problem with bad tech. Different platforms support it horribly differently, it burns cpu power on some (on Firefox, cpu hits 100% when normal web browsing, including youtube, is 10%). The true way to do it is to use modern html5 video tags, which are gonna work anywhere that svg would. Video tags are supported back to IE9, and SVG is only marginally supported in IE9. So the only thing you could gain is not having to use 3 video formats to hit all the browsers, and that's a pitiful excuse.
except motion estimation is looking for blocks that move around without the content changing, then recording those movements. NOT saying "oh, this bit didn't move, so don't reencode it". No matter what you do, this is going to be horrendous on your memory and cpu.
There is exactly one reason animated gif still lives, and that's the simplicity and universality of the img tag. If this can run in all modern browsers in an img tag, it's useful. If it can't, it's not.
How do I load an h.264 video in markdown? bbcode? Filtered html? I can't. But anything that lives in an img tag? That just works.
Cool :)
SVG that contains frames and instructions to transition between the frames after given durations.
This could be even animations embedded into the main HTML page.
It's interesting and shows how extensible web platforms are. However, it's also a horrific misuse of SVG that slowed my web browser to a halt. The concept is fascinating but it's far from useful at this point.
"gifv" is just an mpeg4 file that imgur serves a fallback gif for based on browser headers (mediacrush, gfycat have been doing the same thing for a while).
The "xng" here is a series of images animated/wrapped in SVG.
In hindi also there is a simliar saying "Dudh ka jala chach bhi phoonk phoonk kar peeta ha" meaning
Someone who is burnt with milk is very careful while drinking buttermilk as well.
This is not a "new animated image format", it's just using the capabilities of something that existed before.
In other words, it's basically MJPEG in an inefficient text-based container. Many browsers can already play back MJPEG streams (common with IP cameras), so I do not see the point of this other than as an "it can be done" exercise.
Also worth noting that animated SVG (vector format) is usually bigger than the equivalent SWF file - despite all the hate Flash gets (after the Adobe acquisition was when it seemed to get worse), I think it's a great compact vector animation format. You can also put MJPEG inside a SWF, so they're on equal footing with respect to that.