On Wed, 12 Jan 2011 03:16:35 +0100, Eric Carlson <eric.carl...@apple.com>
wrote:
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.
For the record, Opera is very similar to Firefox and WebKit in this
regard, making no use of fps metadata from the media engine (typically
GStreamer).
--
Philip Jägenstedt
Core Developer
Opera Software