[Bug 19676] timestampOffset accuracy

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19676

--- Comment #9 from Aaron Colwell <acolwell@chromium.org> ---
(In reply to comment #8)
> In the same spirit, why is the spec mandating in section 4.5.6 "Coded Frame
> Processing" point 1.1 and 1.2 that the Media Source Engine maintains
> internal timestamps as double precision floating points, as in:
> 
> "Let presentation timestamp be a double precision floating point
> representation of the coded frame's presentation timestamp."
> An implementation could decide to store the timestamp and run the algorithm
> using  rationals.
> 
> I suggest deleting the part "a double precision floating point
> representation of" in those two points.

The reason I added text about converting to double precision floating point was
to address issues with timestamp rollover in that can occur in bytestreams like
MPEG2-TS. The idea is to convert the bytestream timestamp representation to a
common representation that doesn't have the same rollover problems that the
bytestream format may have. I picked double since that is what all timestamps
in the existing HTML5 API's as well as the MSE API's use. It is also easier to
talk about adding the timestamp offset to these timestamps because addition of
doubles is well defined and doesn't require any consideration for timestamp
rollover.

I don't think removing "a double precision floating point representation of" is
sufficient to address these original concerns. Perhaps adding a note indicating
something along the lines of "Implementations do not have to store timestamps
internally as doubles but they must use sufficient precision to avoid timestamp
rollovers when applying a timestamp offset. The conversion to double precision
floating point is suggested here to make understanding timestamp modification
easier."

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 28 January 2013 22:00:40 UTC