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

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

--- Comment #6 from Steven Robertson <strobe@google.com> 2012-08-30 03:15:59 UTC ---
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.

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?

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?

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?

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?

-- 
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 03:16:01 UTC