[whatwg] HTML5 video: frame accuracy / SMPTE

Rob Coenen coenen.rob at gmail.com
Tue Jan 11 16:30:51 PST 2011


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 <glenn at zewt.org> wrote:

> On Tue, Jan 11, 2011 at 5:40 PM, Rob Coenen <coenen.rob at 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
>



More information about the whatwg mailing list