[whatwg] HTML5 video: frame accuracy / SMPTE

[Roger Hågensen]

On 2011-01-22 01:27, Silvia Pfeiffer 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.
>>
> Chapters have an API:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#dom-texttrack-kind-chapters
> .
>
> However, chapters don't have a seeking API - this is indeed something
> to add, too. Could it fit within the seek() function? e.g.
> seek(chaptername) instead of seek(time)?
>
> Silvia.

The issue with that is that if chapter or index info does not exist the 
seek will fail.
At least with TIME and FRAME you are guaranteed to seek (and even if 
frame is keyframe you'd still end up at a frame near).

To me only TIME makes sense right now as HH:II:SS.MS 
(hours:minutes:seconds.milliseconds) and FRAME if <1ms for rare cases 
where video is more than 1000fps.
Benefit of TIME is it's framerate agnostic, so 00:15:20.050 would be the 
same wether the FPS is 24 or 30.
Which is ideal in the case of framerate changes due to being bounced 
up/down to a higher or lower quality stream while seeking or during 
buffering.
I saw the spec mentioning doubles, I'm assuming that TIME would be a 
double where you'd have: seconds.fraction (which would even handle FPS 
in the thousands)
So I think that focusing on TIME and really pushing that would benefit 
all in the short and long run. an author can "easily" calculate and use 
FRAME from TIME anyway for the few users that would actually need to 
work with that.
Myself I've done some video editing, but I've done more audio editing 
than I can recall, and I've never missed using frames for audio or 
video, I prefer time and millisecond fractions myself, I sync audio on 
timestamp and not frames for example.

So maybe just let the flag be default and nothing else, but as mentioned 
previously, leave it an enum "just in case" for the future (I'm thinking 
possible future timing standards that might appear, though it's hard to 
beat doubles really).


-- 
Roger "Rescator" Hågensen.
Freelancer - http://www.EmSai.net/