W3C home > Mailing lists > Public > public-html-media@w3.org > February 2013

Re: [MSE] buffering/splicing/overlap model, ad insertion and video editing goals

From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
Date: Fri, 22 Feb 2013 15:24:30 +0100
Message-ID: <51277F9E.9020403@telecom-paristech.fr>
To: public-html-media@w3.org
Hi Michael,

Le 21/02/2013 20:48, Michael Thornburgh a écrit :
> for the ad insertion example above, this looks like:
> 0s               14s              0s         11s
>                   +-- cue B                   +-- cue A
> prog A           v                           v
> |-----------|----:XXXXXX|. . . . .|>>>>>>>>>>:---|-----------|-----------|
>   A1(1)       A2  :       A3(-)     A4(6)     :    A5(7)       A6(8)
>              (2)  :B1(3)     B2(4)     B3(5)  :
>                   |---------|---------|-------|
>                   prog B
>                   0s                       28s
With this model, because of the position of keyframes in A4, you would 
probably require a parallel decoding of A and B, decoding the beginning 
of A4 while playing B3 (or decoding B3 faster than real time and then 
decoding the beginning of A4 also faster than real time).

In my understanding, the MSE API doesn't control the decoding/playback. 
The decoding/playback is driven by the video element itself. The MSE API 
only controls what is fed to the video decoder. So you wouldn't be able 
to do what you suggest with MSE without changing the video element behavior.

Note that on desktop, you can already achieve this use case in a 
different way using 2 video elements, switching them on/off. However, on 
mobile (like iOS where only 1 video plays at a time), achieving seamless 
playback in that case would be tricky.

Another option (not tested though) would be to play with the timeline. 
You could append B at a time X different from the live time Y, and then 
seek to X when the ad should be played and then seek back to Y when the 
ad is done. This option is a bit unnatural maybe but I think it could 
work. It doesn't remove the double decoding problem though, but maybe it 
is not an MSE problem but an HTML5 general video problem and having a 
way to inform the player that there will be a seek in the coming seconds 
could help good implementations to do a proper seek.


Cyril Concolato
Maître de Conférences/Associate Professor
Groupe Multimedia/Multimedia Group
Telecom ParisTech
46 rue Barrault
75 013 Paris, France
Received on Friday, 22 February 2013 14:24:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:32 UTC