- From: Dirk-Willem van Gulik <Dirk-Willem.van.Gulik@BBC.co.uk>
- Date: Wed, 12 Jan 2011 00:48:15 +0000
On 11 Jan 2011, at 23:57, Glenn Maynard 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. Correct - or know what the coordinate is in time space of the 'now' shown -AND- when the next seminal event is going to happen (i.e. 'change' - which marks the passage of time in the sense of detectable change) - AND- the clock relative to shutter/gating to the end user - as this is what you need to avoid flicker, interlace issues, half the frame showing the next scene, etc. > 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. I do not think any one does - and the world is already using them on a small scale. > (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.) Aye - could not agree more ! Dw..
Received on Tuesday, 11 January 2011 16:48:15 UTC