W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] HTML5 video: frame accuracy / SMPTE

From: Roger Hågensen <rescator@emsai.net>
Date: Sat, 22 Jan 2011 00:13:27 +0100
Message-ID: <4D3A1317.7040003@emsai.net>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC