- From: Rob Coenen <coenen.rob@gmail.com>
- Date: Wed, 12 Jan 2011 00:30:51 +0000
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 >
Received on Tuesday, 11 January 2011 16:30:51 UTC