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

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

--- Comment #5 from Aaron Colwell <acolwell@chromium.org> 2012-08-30 02:05:37 UTC ---
(In reply to comment #4)
> (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.

I agree. I believe text should be added to encourage using the largest
timestamps possible to avoid overflow.

> > 
> > 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.

I believe Bob is saying that this WILL happen about once a day in MPEG-2 TS
deployments so it needs to be addressed.

> 
> > 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.

I believe the best compromise is to require support for a rollover within a
single media segment. It should only do this if it has exhausted the maximum
available bits it can use to represent a timestamp(ie 64 for MP4, 56 for WebM,
33 for MPEG2-TS). If such a rollover happens within a media segment it is
pretty straight forward what to do. Just add 2^x to the timestamp that have
rolled over. It is the web application's responsibility to detect this case
though and adjust SourceBuffer.timestampOffset to an appropriate value before
appending the next segment so that the next timestamps map to the correct
position in the timeline. 

Since MPEG2-TS is the most frequent rollover example we are dealing with here I
believe it would be pretty easy for the web application to periodically inspect
the bitstream and predict when it should expect a rollover. When that time
approaches it can inspect every media segment it appends until it finds where
the rollover happens and then updates SourceBuffer.timestampOffset at the
appropriate time. This should only happen for a brief period once a day so I
don't think it should be a huge performance concern.

What do you think?

-- 
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 Thursday, 30 August 2012 02:05:39 UTC