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

Since I haven't heard any objections yet, I'm going to move forward with
the proposal to require abort() calls before out-of-order appends so I can
get the MPEG2-TS text integrated.

For now, I don't plan on dropping the RAP requirement for media segments. I
think we should open a new bug for this request and address it after FPWD
is published.

Aaron


On Fri, Dec 7, 2012 at 11:00 AM, Steven Robertson <strobe@google.com> wrote:

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