Re: timestampOffset accuracy

Hi Pierre,

Double was chosen for timestampOffset because doubles are used for all
presentation times exposed by the HTMLMediaElement (currentTime, buffered,
seekable, etc.). We may need to specify rounding rules to address your
concerns, but I don't think we should change timestampOffset to use
rationals. Rationals could also get tricky to deal with if content with
different sample rates or frame rates are spliced together. If we
require at least microsecond timestamp resolution, then I'm pretty sure we
should be able to handle most real world cases without introducing any
major artifacts.

Aaron


On Mon, Oct 22, 2012 at 12:45 PM, Pierre-Anthony Lemieux
<pal@sandflow.com>wrote:

> Per the suggested process in our last call, below is a question re:
> choice of 'double' as the type for timestampOffset.
>
> Has this topic been considered before?
>
> Thanks,
>
> -- Pierre
>
> Time offsets and durations within media streams, e.g. to specify
> splice points, are often expressed in multiples of video frame or
> audio sample durations. These durations are typically rational
> numbers, e.g. 1/24, 1001/30000, 1/48000, etc. Many container formats
> (ISO BMFF, MXF...) express durations and offsets as rationals, e.g. as
> integer multiples of a rational timescale expressed as the ratio
> between an integer numerator and an integer denominator.
>
> Can timestampOffset (as a double) exactly represent such rational time
> offsets? For example, (double) ((1/24)*17) < 17*1/24 < (double)
> (17/24) -- at least in Win32 python.
>
> Accuracy can be important when a splice point needs to fall on a
> specific frame boundary or when comparing timestampOffsets.
>
>