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

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

--- Comment #7 from Aaron Colwell <acolwell@chromium.org> 2012-08-30 05:32:26 UTC ---
(In reply to comment #6)
> Sorry to be nit-picky here, but since our organization spends an astonishing
> amount of resources annually to re-encode perfectly compliant files in order to
> work around broken video stacks, I'm pretty keen on hammering down the details
> regarding media formats ;)
> 
> (In reply to comment #5)
> > > > > 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.
> 
> I'm not sure I understand why this would be helpful.
> 
> Field-size decisions are local to a box in BMFF, and local to a field in EBML.
> This means that any media segment can be muxed to the maximum field width
> should its local timestamps overflow smaller field widths, regardless of
> previous timestamp sizes.

I agree. I wasn't trying to say that the maximum timestamp field size must
always be used. I was trying to say that we should only allow rollover if all
possible bits have been exhausted. WebM allows 7 - 56 bits to be used and I'd
expect a muxer to use 7 bits for times near 0 and more bits later in the file.
I'd only expect a rollover when the timestamps exhausted available 56 bits.

> 
> The only application I can see that might require modifying these values
> in-place would be to rewrite timestamps from JavaScript. This is, however,
> precisely the manipulation that the offset mechanism obviates. As a result,
> there does not seem to be a use for suggesting oversized timestamps in media
> formats from the JavaScript layer. Is there another use of rewriting values
> in-place that I'm not seeing?

I was not intending to imply byte stream rewriting. It appears I need to
clarify that text. I intended this to mean that the timestampOffset was applied
to whatever timestamps were the result of demuxing the appended data. I'm
assuming that the UA is using more than 32 bits to represent timestamps
internally. I guess I need to clarify this. 

> 
> As previously mentioned, it is not possible to implement a Source Buffer
> without demuxing media segments and storing metadata in a private, sample-based
> format, in order to support mandatory spec features such as incremental parsing
> of segments, 'abort()' of partially-appended media segments, and segment
> overlapping. Is there an implementation reason why such a private format would
> have a precision limited by the precision of the incoming media format?

No. My intent was not to limit presentation timestamp range to only what can be
represented by the format. All the time related fields in HTMLMediaElement are
doubles so I assumed that the UA would take advantage of that sizable range.
Any UA that properly supports long running live broadcasts in a format with
only 32-bit timestamp fields should already deal with this and represent
timestamps w/ more than 32-bits. 

> 
> Even if the implementation of the source buffer is only loosely coupled to the
> DOM, these features require additional side-channel information for these Media
> Source-specific elements of a spec in addition to the media data pushed into
> the Source Buffer. If this information is provided via a side-channel, it seems
> reasonable to me that the information regarding the timestamp offset could be
> provided in the same side-channel. In that case, there does not seem to be a
> reason to rewrite timestamps in place at the implementation level. Is there a
> reason why information like 'abort()' calls could be transmitted to the
> demuxer, but not information like the timestamp offset?

This seems like an implementation detail that a UA needs to sort out. In Chrome
we do not rewrite the byte stream data. We demux the data and then apply the
offset to our internal timestamp representation, which happens to be 64-bit
integer. It was never my intent for a decoder error to occur if applying a
timestamp offset would cause a rollover in the format's timestamp
representation. It was my intent to have the format timestamp representation
converted to a UA internal representation which then eventually gets exposed as
a double through TimeRanges. I think it would be very surprising to a developer
if the range of a double was truncated in some way by the byte stream format
being used.

> 
> Is there a reason why spec-compliant files which did not use the maximum field
> width for all fields would result in a degraded experience beyond those
> discussed above?
If a format could use 64-bits, but chose to wrap around at 32-bits this would
provide an ambiguous situation for the UA. Within a single media segment it
isn't ambiguous, but across media segments it is because there is no way to
determine if the segment actually is a roll over or just and out-of-order
append. Only the web application is in a position to determine what is going on
because it knows whether the two media segments are supposed to be adjacent or
not.

-- 
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 05:32:28 UTC