- From: Roger Hågensen <rescator@emsai.net>
- Date: Sat, 22 Jan 2011 00:13:27 +0100
On 2011-01-21 23:48, Gregory Maxwell wrote: > > It seems surprising to me that we'd want to expose something so deeply > internal while the API fails to expose things like chapters and other > metadata which can actually be used to reliably map times to > meaningful high level information about the video. Well you would never seek to a chapter or scene change anyway, the author would instead preferably get a list of index/chapter/scene points which point to a TIME or FRAME and seek using that value instead. I was thinking that in my other post I mentioned the flags default and TIME and FRAME. But essentially the browser always does best effort, so the flag TIME or the flag FRAME should only indicate that the author wish to either use TIME or FRAME when seeking, it is entirely up to the browser etc. if seeking actually occurs that way or not. It's just that TIME or FRAME is the base being used. In which case KEYFRAME could just be dropped from my other post really. So if the author uses/wish to use the flag TIME but the browser only presents FRAME then the author can still use time, or they could use FRAME but convert that to time for the user. If TIME can be millisec. (i.e: 00:45:10.958 the 23rd frame of minute 45 and second 10 if 24fps) Then TIME is basically synonymous with FRAME which would be 1343. I assume that we won't run into issue with this normally. (who'd actually have 1000+ fps? and if that is the case then FRAME must be used for super highspeed/slowmo etc.) So under normal use TIME and FRAME would be the exact same thing. This means the flags would only be: * default (TIME or FRAME) * FRAME (frame "must" be used/supported as TIME is not accurate, <1ms accuracy needed.) -- Roger "Rescator" H?gensen. Freelancer - http://www.EmSai.net/
Received on Friday, 21 January 2011 15:13:27 UTC