[Bug 19676] timestampOffset accuracy

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

Aaron Colwell <acolwell@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|adrianba@microsoft.com      |acolwell@chromium.org

--- Comment #10 from Aaron Colwell <acolwell@chromium.org> ---
So I plan on adding a note indicating that implementations don't have to use
double precision floating point for the timestamps, and indicate that they are
simply used in the spec for clearly describing the intended addition behavior
for applying timestampOffset to the timestamps in the media data. While I think
that is an important clarification to the spec, I don't think it fully
addresses your concern here and I'm not sure what else needs to be done for
this bug. 

- I don't think it makes sense to convert the timestampOffset field to a
rational.

- closest frame boundary is a hard concept to nail down when multiple frame
rates or sample rates could be used in a single presentation. It is only really
defined when you are overlapping existing frames in the buffer. That makes me
nervous because it means, rounding only happens during overlaps which I think
could lead to other problems down the road.

- I understand that rationals can be computed several ways that don't always
result in the same double precision value, but the only way I can think of to
address that is to define some delta which indicates how close the timestamps
have to be for them to be considered identical. That is where I was going with
the microsecond resolution comments. It provides a content independent grid
that all timestamps can be mapped to.

How would you like me to proceed?

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

Received on Thursday, 31 January 2013 18:39:35 UTC