On Jan 11, 2011, at 5:43 PM, Chris Pearce wrote: > On 12/01/2011 2:22 p.m., Dirk-Willem van Gulik wrote: >> On 12 Jan 2011, at 01:17, Chris Pearce wrote: >> >>>> I cannot think of a format where this would in fact be the case - but for >>>> a few arcane ones like an animated push gif without a loop. >>>> >>> WebM can be variable frame rate. At best the WebM container specification >>> [http://www.webmproject.org/code/specs/container/#track] lists the >>> FrameRate block as "Informational only", which presumably means the value >>> stored in the container can't be trusted. >> Right - but is there a WebM decoder which is able to hand it off that way ? >> AFAIK they all use that value or select a default/measured rounded heuristic >> to solve flicker ? >> > > Firefox 4 doesn't use the frame rate stored in the container for WebM. Each > frame is stored with its presentation time, and we request repaints as each > frame fall due for painting. The prevention of flicker is handled by our > graphics layer, video doesn't really participate in that, it just hands off > frames downstream when they're due for painting. We have plans to schedule > video frame painting more preemptively in future, but I imagine we'd still > use the presentation time encoded with each frame when we do that. > Video in WebKit is handled a similar same way. Media engines that decode into a bitmap signal the graphics layer when a new frame is available, and the new frame is composited overlapping page content during the next paint. Media engines that render into a hardware layer do so completely asynchronously. In both cases, the media engine is free to decode a whatever rate is appropriate for video file.
eric
