"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.
> 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.