[Bug 18642] Handle timestamp overflow in append(data)

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

--- Comment #4 from Philip Jägenstedt <philipj@opera.com> 2012-08-29 07:59:49 UTC ---
(In reply to comment #3)
> (In reply to comment #0)
> > http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#dom-append
> > 
> > There's already a check to trigger MEDIA_ERR_DECODE when any modified timestamp
> > would underflow (< 0) but nothing about how to handle overflow. This is
> > particularly likely with 32-bit timestamp fields, but can of course happen
> > regardlessly.
> > 
> > Suggestion: If any modified timestamp would overflow in the representation used
> > in the byte stream, trigger a MEDIA_ERR_DECODE.
> > 
> > In addition, the byte stream specs could place the necessary requirements to
> > make this situation as unlikely as possible.
> 
> The MPEG-2 TS Presentation Time Stamp and Decode Time Stamp fields are 33bit
> counts of a 90KHz clock, which will rollover every 26.5 hours. This is a normal
> event in a linear (e.g. broadcast) video channel. This does not represent a
> decode error.

It should be the byte stream specification that defines what time stamps can be
represented. If MPEG-2 has no such restrictions, nothing would be considered
overflowing and the condition will not be hit.

> It is not clear if/how a receiver could make this situation unlikely while
> still remaining compliant with the transport stream specification.

The receiver cannot do anything. What I mean is that the byte stream specs
should recommend using the largest possible timestamps (I've been told that
MPEG-4 supports both 32 and 64 bits) and as large-grained a timescale as
possible. But this is just spec fluff, the main thrust of this bug is to handle
overflow on the receiving side for MPEG-4 and WebM.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Wednesday, 29 August 2012 07:59:56 UTC