Re: MSE: Ad-insertion and seeking

Hi David,

I am one of the current co-editors of the MSE spec. Thanks for your
question.

This appears to be a problem that "sequence" appendMode may alleviate: it
collapses all discontinuities into one continuous buffered region, so long
as there are no other intervening operations like explicitly changing
timestampOffset or appendMode. This "sequence" appendMode is in
experimental support currently in Chrome M46 (it's hidden behind an
experimental flag). The caveat for using sequence appendMode (beyond, of
course, having implementations in user agents) is that the appends must be
done in the order they are desired on the timeline, not in a scattered
fashion.

While implementations are pending "sequence" appendMode support, explicitly
updating timestampOffset to collapse potentential discontinuities would be
feasible if you:
1) know the current SourceBuffer.buffered() range(s) end time(s): this is
available in MSE.
2) know the start timestamp of media about to be appended (by inspection
offline, or even in a js parser)

Combined, these are like timestamp rewriting, except the rewriting is done
implicitly by timestampOffset, rather than updating the timecodes in the
appended byte stream.

Is the latter method (explicitly updating timestampOffset using data from
the API and from the byte stream (or offline inspection/metadata/some other
assumption)) sufficient for your use case?

Matt

On Tue, Aug 25, 2015 at 7:53 AM David LaPalomento <
dlapalomento@brightcove.com> wrote:

> Hi all,
> I'm a contributor to video.js and am working to convert an existing
> Flash-based HLS playback plugin to using Media Source Extensions. We
> support a number of server-side ad insertion services, all of which seem to
> compose existing media files without doing timestamp rewriting and signal
> this to the player through metadata in the HLS manifest.
>
> One of the technical challenges we've faced in the existing implementation
> is handling seeking across multiple timestamp discontinuities before the
> entire video has been downloaded. HLS v3 rounds segment durations to the
> nearest whole number which can introduce a significant amount of timeline
> error in long-form content. Ignoring the shortcomings of HLS though, the
> duration values provided by ad-insertion services may lack precision and
> the wild-west of ad creatives doesn't help the situation.
>
> We handle this issue today by recalculating the media timeline whenever a
> new segment is downloaded and processed. Since the buffer always grows
> forward, media timeline adjustments occur ahead of the current playback
> position and the player's media timeline converges on reality as more
> content is buffered.
>
> Preamble out of the way, here's my question for this group: how would one
> seek across discontinuities without frame-accurate durations using Media
> Source Extensions? If we had perfectly accurate duration information, I
> believe we could use timestamp offsets on the source buffer to place the
> new content at the appropriate position. With inaccurate or low-precision
> duration information, it seems like we run the risk of mis-placing the
> media data and creating overlaps at discontinuities and misreporting the
> total content duration. Is there a solution in the spec I'm missing?
>