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
tracker.
Regards,
Chris Pearce.
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?
-Rob
On Fri, Jan 7, 2011 at 5:02 PM, Eric Carlson<eric.carl...@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
HTML5
video?
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
video
on a frame-by-frame basis (even though you the Flash Media Server to make
it
work).
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
already
implemented.
'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.
eric
