W3C home > Mailing lists > Public > public-html-media@w3.org > August 2015

MSE: Ad-insertion and seeking

From: David LaPalomento <dlapalomento@brightcove.com>
Date: Tue, 25 Aug 2015 10:51:26 -0400
Message-ID: <CACh87oc9EYQ0bucqi-kQOgJHhAySyARVPOY_gU1M5sY4GmKr_Q@mail.gmail.com>
To: public-html-media@w3.org
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?
Received on Tuesday, 25 August 2015 14:51:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:05 UTC