[whatwg] HTML5 video: frame accuracy / SMPTE

[Dirk-Willem van Gulik]

On 11 Jan 2011, at 18:10, Eric Carlson wrote:
> On Jan 11, 2011, at 9:54 AM, Rob Coenen wrote:
> 
>> just a follow up question in relation to SMPTE / frame accurate playback: As
>> far as I can tell there is nothing specified in the HTML5 specs that will
>> allow us to determine the actual frame rate (FPS) of a movie? In order to do
>> proper time-code calculations it's essential to know both the video.duration
>> and video.fps - and all I can find in the specs is video.duration, nothing
>> in video.fps
>> 
>  What does "frames per second" mean for a digitally encoded video file, where frames can have arbitrary duration?

Right - so that breaks into three cases - 1) where we have a constant frame rate outputted by the decoder (i.e. the decoder creates a snapshot every 1/framerate second - relative to some point in time) and presents that for display, 2) where we have a decoder output some into some (frame) buffer and then schedule it for display at some specific time in the near future - and where those time stamps are NOT equidistant to each other or 3) where we have a frame buffer filled by a decoder in a timely fashion - and something making a snapshot of that frame buffer at very regular intervals - but where the actual updating does not happen/is synchronised at the same rate or even may vary over time.

All 3 cases are can happen, and do happen. However:

-	Regardless of the wire and what is happening inside the decode time wise - We 
	generally try grab our output at regular rates - as it also helps prevent flicker
	and is easier on the audio.

-	As soon as we're above SD level - virtually all wire-formats we use decode to frames
	with in effect a specific time stamp - and these timestamps are on the same 
	'grid' - i.e. they are exactly 1/framerate apart from each other (though some may 
	be skipped). (And in fact - the industry currently lacks the technology to author
	anything else - any time/frame shuffling/moving in the temporal domain is a lossy
	sort of interpolation by a encoder).

-	And above tends to happens with a totally constant phase delta and we often re-normalize
	on the grabbing/frame buffer - esp. if audio is involved.

So that means that SMPTE time code have a meaning - and skipping/scrubbing through a video at one output frame at the time makes perfect sense. Likewise for audio. And for any creative scenario - being able to do exactly that - pause, jump, cut at an exact time code - is pretty much the number one requirement.

So being able to ensure that an exact SMPTE timecode is show - or know which is shown - is the basic need.

Or am I missing something ?

Thanks,

Dw.