[MSE] Proposal to require abort() call before out-of-order appends.

During the discussions with Bob Lund and Alex Giladi about supporting
MPEG2-TS it has become clear that out-of-order appends make things very
difficult for supporting that format in a sane way. Timestamp rollovers &
discontinuities can only be resolved by looking at previously appended data
and knowing for sure that the data is actually adjacent in time. I started
down the path of requiring that the web application be responsible for
making sure that a rollover or discontinuity must happen in the middle of a
buffer passed to a single append() call, but this puts some unnecessary
burden on the web application to know exactly where all the rollovers and
discontinuities are and forces it to properly update timestampOffset before
the next append.

I'd like to propose that abort() be called before any out-of-order append
happens and change the expectation that a sequence of append() calls are
assumed to contain data that is adjacent in time. Doing this make handling
rollovers and discontinuities easy because the UA knows that the data in a
previous append is adjacent no matter how the byte stream is split into
buffers.

I think requiring the abort() will have minimal impact on existing
applications because presumably they already know when they are about to do
an out-of-order append and can call abort() appropriately. In the case of
an adaptive streaming bitrate switch, the switching algorithm would always
call abort() before it starts appending data for the new bitrate just to be
safe.

I also believe this will simplify adding formats that don't have
timestamps, like MP3 or ADTS in the future because a starting timestamp for
a sequence of frames could be specified with timestampOffset, and the UA
could just increment an internal timestamp counter as frames are appended.
abort() or setting timestampOffset could reset this interal timestamp
counter to 0 so that frames could be appended at different parts of the
timeline.

I've also been getting some comments from people who want to do live
streaming with ISO-BMFF. They would like the "The first sample in each
Track Fragment Run Box (trun) must indicate that the sample is a random
access point" requirement loosened to lower latency. I think my proposal
would make this request easier to accommodate because it makes it clear to
the UA that append()s without an intervening abort() are adjacent. A GOP
spanning multiple fragments wouldn't be a problem for the UA to deal with
in this case.

I welcome your feedback. Please let me know if you have any objections to
this proposal ASAP. I want to resolve this quickly so I can get the
MPEG2-TS text added to the spec.

Aaron