We can't have an API based on frame rate because at least in WebM, the
frame rate is just an informational piece of metadata that may not match
what's in the file and may not be there at all. Thus, the browser has no
way of exposing .framerate or anything like it.
For now, I suggest that the framerate is given separately, e.g. in <video
data-fps="30000/1001"> and then using .currentTime to seek, it has more
than enough precision to hit any frame, it's just a questions of browsers
implementing frame-exact seeking.
(Also, it might be useful to be able to chose whether seeking should be
fast or exact, as frame-accurate seeking is hardly necessary in most
normal playback situations.)
Philip
On Wed, 12 Jan 2011 01:30:51 +0100, Rob Coenen <coenen....@gmail.com>
wrote:
I guess that I'm looking at HTML5 from the POV as a video-producer rather
than a video-consumer.
As a producer I'm much more intrested in the "legacy" video formats. The
way
video is being produced is simply on a frame-by-frame basis. I cannot
think
of any 3D animation tool video sequencer, video editor, or anything that
allows you to work with video- that works with anything but full frames.
video-consumer who only playback the video in a linear way are probably
much
more intrested in bandwith saving features such as he WebM non-frame
based
approach.
Obviously we do don't want to have some API that break future video
standards, but I cannot see why we can't have both to make at the same
time.
It would make the video-producers happy: frame-by-frame accuracy, fixed
frame rates and SMPTE timecodes.
-Rob
On Tue, Jan 11, 2011 at 11:57 PM, Glenn Maynard <gl...@zewt.org> wrote:
On Tue, Jan 11, 2011 at 5:40 PM, Rob Coenen <coenen....@gmail.com>
wrote:
> Hi David- that is b/c in an ideal world I'd want to seek to a time
expressed
> as a SMPTE timecode (think web apps that let users step x frames back,
seek
> y frames forward etc.). In order to convert SMPTE to the floating
point
> value for video.seekTime I need to know the frame rate.
I'd suggest that you don't want to know the "framerate"; rather, you
want a separate seek call to seek using timecodes directly.
Please don't dismiss video formats with variable framerates under
assumptions like "nobody's using them in webpages right now". That's
shortsighted, and can only lead to an API that will fall apart in a
couple years.
(Being able to seek to "the next frame" is by itself obviously useful,
even outside of editing applications, to allow users to single-step
videos as you can in any native video player.)
--
Glenn Maynard
--
Philip Jägenstedt
Core Developer
Opera Software
