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

> From: Cyril Concolato [mailto:cyril.concolato@telecom-paristech.fr]
> Sent: Friday, February 22, 2013 6:25 AM
> 
> 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).

this is exactly the same issue as with the current overlap model (section 2.1.3 "End Overlap" in particular). the only difference is in how the media gets into the buffer in the first place. see the note in section 2.1.3 about avoiding creating a gap.  i would propose a similar notice to accompany this proposed mechanism.

[...]

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

laying out discontinuous media regions in the timeline and seeking around to them will probably increase the likelihood of QUOTA_EXCEEDED_ERRs, complicate maintaining a sufficiently full playback buffer, and not yield seamless playback since you'd need to perform a seek operation at exactly the right time.  for seamless playback you really want the media to be all laid out in the buffer as it is to be rendered so that it can be without a time-sensitive operation in Javascript.  note that you aren't going to get frame-accurate synchronized execution in Javascript.  note also that an API-level seek will flush decoder buffers and likely be much more disruptive than a contiguous play-through, even if the underlying implementation is done in terms of a seek deep into A4.

> Cyril
[...]

-michael thornburgh

Received on Friday, 22 February 2013 22:04:25 UTC