Re: [MSE] Timestamp offset mechanism

On Mon, Jun 18, 2012 at 4:25 AM, Duncan Rowden <Duncan.Rowden@bbc.co.uk> wrote:
> -          Ideally, when inserting an advert, this won’t contaminate the
> main media item’s timeline. The reasoning for this is that when ads are
> inserted, a content provider may only wish these to be viewed once. So when
> rewinding back through a given point either another ad can be inserted or
> playback can occur without showing an ad.

My understanding was that duration calculation from an initialization
segment was not possible, at least in BMFF, given that neither edit
lists nor the 'mehd' box are required, and anyway hitherto-unimagined
uses of the Media Source API would be difficult to account for with
any standard notion of a single timeline. As a result, it seems like
the intention is to leave presentation of a scrubber and transport
controls to the application for complex cases. It's easy to verify the
behavior of a scrubber across multiple platforms (just look at it and
maybe interact with it); it seems much harder to deal with subtle
implementation-specific details of a source buffer switching mechanism
across multiple platforms, since one can only interact with it
temporally and indirectly.

Although using source-switching to composite seamlessly to a single
timeline below the source-buffer level is conceptually similar to
compositing to a single timeline at an application-controlled level, I
feel that source-switching would be the origin of a lot of platform
quirks that would be challenging to understand and correct for. The
source buffer logic is already both very author-friendly and quite
non-trivial to implement correctly; adding another invisible layer
beneath that would be more complicated still. I believe that making
things easier on implementors by giving them a single contiguous
stream of buffers with consistent timestamps – which is basically what
they get anyway from a traditional demuxer – will result in much more
consistent behavior across platforms, which is better for authors and
users.

> -          The point at which ads need to be inserted may not necessarily
> coincide with a segment boundary, which as I understand it would be required
> using this proposal.

Interstitials must always start _with_ a segment boundary, but they
don't necessarily need to be inserted starting _on_ a segment boundary
in the original timeline. A UA can call sourceAbort() and start
appending the interstitial, or can simply append a complete segment of
the original content and then append the interstitial media.

[That said, the quality of experience on some platforms is likely to
be significantly degraded (i.e. system crash) if interstitials start
anywhere but a segment boundary. We're working around it, but these
kinds of issues are likely to be common, and unlikely to be fixable
without some kind of user-obvious deviation from the spec like long
pipeline flushes.]

Steve

Received on Monday, 18 June 2012 17:02:31 UTC