[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] video/tv production issues

On 03/04/2013, at 9:51 AM, Florian Bösch <pyalot@gmail.com> wrote:

On Tue, Apr 2, 2013 at 11:48 PM, Dean Jackson <dino@apple.com> wrote:
I assume you meant the current frame? The problem, at least on Apple platforms, is that the video decoding and the compositor might each be in another process, making it difficult for the browser to get access to the frames :(
Wait a second. The compositor is implemented by the browser (the page compositor).

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]

So it is known that browsers are capable to playback Full-HD video. It is also known that these days the compositor is hardware accelerated. So this has to mean that, if you are decoding video in a separate process, that there is a fast way to share that with the compositor. And because the compositor is also sharing with the WebGL context, that has to mean that there has to be a fast way to share video with WebGL in principle.

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