- From: Cyril Concolato <cyril.concolato@telecom-paristech.fr>
- Date: Fri, 22 Feb 2013 15:24:30 +0100
- 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 -- Cyril Concolato Maître de Conférences/Associate Professor Groupe Multimedia/Multimedia Group Telecom ParisTech 46 rue Barrault 75 013 Paris, France http://concolato.wp.mines-telecom.fr/
Received on Friday, 22 February 2013 14:24:51 UTC