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.
