[whatwg] HTML5 video: frame accuracy / SMPTE
chris at pearce.org.nz
Sun Jan 9 15:05:33 PST 2011
As Eric pointed out, the spec specifies that you can seek to a specific
time, and therefore a specific frame. Firefox seeks video to the frame
which contains the seek target time in Ogg and WebM videos FWIW, and
begins audio playback from, and syncs the clock to, the start of the
Vorbis audio packet which contains the seek target time.
If a browser doesn't seek accurately enough, that is an implementation
issue in that browser, and you should file a bug in that project's bug
On 10/01/2011 8:14 a.m., Rob Coenen wrote:
> I have written a simple test using a H264 video with burned-in timecode
> (every frame is visually marked with the actual SMPTE timecode)
> Webkit is unable to seek to the correct timecode using 'currentTime', it's
> always a whole bunch of frames off from the requested position. I reckon it
> simply seeks to the nearest keyframe?
> On Fri, Jan 7, 2011 at 5:02 PM, Eric Carlson<eric.carlson at apple.com> wrote:
>> On Jan 7, 2011, at 8:22 AM, Rob Coenen wrote:
>>> are there any plans on adding frame accuracy and/or SMPTE support to
>>> As far as I know it's currently impossible to play HTML5 video
>>> frame-by-frame, or seek to a SMPTE compliant (frame accurate) time-code.
>>> The nearest seek seems to be precise to roughly 1-second (or nearest
>>> keyframe perhaps, can't tell).
>>> Flash seems to be the only solution that I'm aware of that can access
>>> on a frame-by-frame basis (even though you the Flash Media Server to make
>>> Seeking to a SMPTE time-code is completely impossible with any solution I
>>> have looked at.
>>> Very interested to learn what the community POV is, and why it isn't
>> 'currentTime' is a double so you should be able to seek more accurately
>> than one second - modulo the timescale of the video file and how the UA
>> supports seeking to inter-frame times.
More information about the whatwg