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

On Fri, Dec 7, 2012 at 9:49 AM, Aaron Colwell <acolwell@google.com> wrote:

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

Agreed. This pattern usually shows up implementations naturally in my
experience, no great burden to require it.


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

Makes sense.


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

Agreed. Would the UA drop the RAP requirement altogether and discard data
before the first GOP it sees, or still require a RAP fragment as the first
media segment after an abort()?

Thanks,
Steve