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/
