- From: Steven Robertson <strobe@google.com>
- Date: Thu, 12 Jul 2012 13:16:12 -0700
- To: Duncan Rowden <Duncan.Rowden@bbc.co.uk>
- Cc: Aaron Colwell <acolwell@google.com>, public-html-media@w3.org
On Wed, Jul 11, 2012 at 8:04 AM, Duncan Rowden <Duncan.Rowden@bbc.co.uk> wrote: > Kevin S and Steven R mentioned on this point that you could get a > non-deterministic delay if you use this method, but I don’t think this is a > problem as long as the content is paused frame-accurately. I think a frame-accurate stream switch proposal as a separate specification is a useful idea. However, I think it should not be part of Media Source, nor should it influence the presence of a timestamp offset mechanism in MS. YouTube will require timestamp offsets, either by it being in the API or by rewriting media data from JavaScript, and we think many other applications will use it too. We need this even if a frame-accurate switch were part of a standard, because a lot of platforms which can do Media Source couldn't do frame-accurate pausing. (To give an example: on one platform, encrypted media samples disappear down a trusted path, and the browser gets a single, session-long opaque texture reference which it can use to composite the latest video frame into a write-only framebuffer (rather than raw buffers or a texref per frame). Playback time is retrieved by polling the crypto processor, which carries an unknown latency. Pause instructions would also carry an unknown latency. No guarantees of frame-accurate seeking are available.) Steve
Received on Thursday, 12 July 2012 20:17:20 UTC