[Bug 19676] timestampOffset accuracy

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

--- Comment #16 from Aaron Colwell <acolwell@chromium.org> ---
(In reply to comment #14)
> Thanks for the updated draft. Some initial comments below based on my
> attempts at implementing the algorithm.
> 
> > and presentation timestamp lies within a coded frame already
> > let overlapped frame be the coded frame in track buffer that contains presentation timestamp.
> 
> What do 'lie' and 'contain' mean? Specifically, do we mean ''overlapped
> frame' -= 'existing frame N' such that 'existing frame N presentation
> timestamp' <= presentation timestamp < 'existing frame N+1 presentation
> timestamp' ?
>

My most recent changes removed these terms and use >= & < language that is
basically equivalent to this.

> > If track buffer contains video coded frames and presentation
> > timestamp is less than 1 microsecond beyond the presentation
> > timestamp of overlapped frame, then remove overlapped frame
> > and any coded frames that depend on it from track buffer.
> 
> What does 'beyond' mean?

I meant >, but it sounded weird to say "less than 1 microsecond greater than."
I've rearranged this text in my latest update to make this clearer.

> 
> Does 'overlapped frame' mean the coded frame whose presentation timestamp is
> 'presentation timestamp' +/- 1 us, or something else?
> 
> The note below the paragraph states "as long as it is within 1 microsecond".

I clarified the definition for this as well. Overlapped frame only gets removed
by the 1 microsecond rule only if the "presentation timestamp" is greater than
the overlapped frame's presentation timestamp. If it is before then the normal
frame removal logic applies. This 1 us rule is just there to prevent the
existing frame from staying in the buffer if the web application slightly
overshoots the existing frame's presentation timestamp. 

> 
> > Let overlapped frame be the coded frame in track buffer that overlaps
> > with new coded frame (ie. it contains presentation timestamp).
> 
> In contrast with coded video frames, the timestampOffset for coded audio
> frames does not include a rounding tolerance, so ambiguities can occur. See
> below an example using AC3 frames containing 44.1 kHz audio.
> 
> (5*1536)/44100 - 5*(1536)*(1/44100) = -2.7755575615628914e-17
> 
> > Round & update presentation timestamp and decode timestamp
> 
> 'round' should be defined. Do we mean floor(x + 0.5)?

I've removed the word round because it isn't really accurate. The UA just
computes the sample timestamps that is higher and lower than the presentation
timestamp and just picks the closest one. I've also added text to describe what
to do in the equidistant case. There is no need for a rounding tolerance for
audio.

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

Received on Tuesday, 12 March 2013 22:58:38 UTC