On 03/04/2013, at 9:51 AM, Florian Bösch <firstname.lastname@example.org> wrote:
I'm not sure what you mean by page compositor, but our compositor is not implemented by the browser.
[It's a bit misleading to say "the" compositor, because there are many different compositing paths - I'm talking about our most common hardware path]
In principle yes, because all the memory is shared. But not in practice. Our video decoder is sharing with our compositor. WebGL is writing to a surface the compositor puts on the screen. The compositor is the one that takes the image queue (of frames) and draws the right thing at the right time, while WebGL just tells the compositor an update is ready. My point was that it isn't necessarily easy to just get "the last decoded" frame into WebGL and do something with it. There is also audio sync to take into account. If you want to get the video frame and do something with it, you'll need to keep up with the audio, or at least tell the compositor and AV engine what's happening. This is the type of thing that isn't exposed in WebGL (or to any page content).