[whatwg] HTML5 video: frame accuracy / SMPTE

[Philip Jägenstedt]

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.rob at 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 <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
>>


-- 
Philip Jägenstedt
Core Developer
Opera Software