On Jul 6, 2012, at 2:27 PM, Florian Bösch <firstname.lastname@example.org> wrote:
On Fri, Jul 6, 2012 at 11:17 PM, Chris Marrin <email@example.com> wrote:
The video decoder has no idea (nor should it) how fast or how consistently a 3D frame is being rendered. So it's possible that the time at which we need to acquire the video frame will be many ms before it actually makes it to the display. We might not even be acquiring the frame the same number of ms in advance in every frame. So we could hit on one side or the other of a new frame being available and that will cause inconsistent video playback.
When we use requestAnimationFrame to time the WebGL rendering, we have the timestamp for the start of that cycle, which will be very consistent. If we pass that to the video acquire function, then we will get a very consistent frame progression, even if our WebGL rendering is not making framerate.
And think about the future when we will be able to render multiple WebGL frames at a time. In that case we will need to tell the acquire function when we intend to display the given frame or we will get wildly inconsistent video playback.
Video is timed media. I believe we need to make our requests to it explicitly time based, or we'll have playback quality issues, and we will limit our ability to effectively use future hardware.