No one said it would be MORE complicated than the examples.
"Would also be interesting" and "fun to compare" give no implication of relative difficulty. I would like to see the algorithm though so please post the code if you get it working in JS! That would be awesome!
It is actually slightly more complicated. The existing effects work in GLSL and are just transforming single frames of video. For that effect to work, you need the previous buffer states; this means that seeking will cause the image to be different, and you need to feed the previous render state back as a texture.
You still need to remove the green-screen. This either means an expensive process on the CPU side, or pushing the frame to the GPU to remove it with a shader and then using RTT and rendering that or reading the framebuffer and drawing that to a canvas. Note, it's really not difficult to do this, it's just slightly more complex than the other effects, is all.
Well no, because each frame builds on all the frames before it. Either way, seeking is still broken unless you run through all the frames up to that point.
Each frame has the greenscreen turned into a fully transparent pixel, then gets blitted onto a buffer containing all of the existing buffer's data. That means that for each frame, you're building on the data from every frame that came before. This is fine if you're playing from beginning to end, but when you seek, you're going to break that continuity.
Yes, you do need to process from beginning to end. If you look at the original video, you see that each frame builds on the one before it, which builds on the one before that. Remember, the buffer is never cleared -- it's just overwritten with a few new pixels (the dude moving) each room.
