[Bug 21333] consequences of requirement in section 8 on initialisation segments

https://www.w3.org/Bugs/Public/show_bug.cgi?id=21333

Michael Thornburgh <mthornbu@adobe.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mthornbu@adobe.com

--- Comment #7 from Michael Thornburgh <mthornbu@adobe.com> ---
regarding "1) How to seamlessly transition between SourceBuffers", i also feel
this is crucial, both for acceptable user experience and for maintaining a
reasonable and achievable level of burden for the Javascript programmer.  i
strongly support the Reporting Party opening a new bug specific to this issue.

(user experience) if a transition between buffers must be managed from
Javascript (based on current timeline playback position or triggers/cues in a
text track), you can't guarantee frame-precise transitions because of
Javascript scheduling latency. depending on how the media is laid out, you
could have a late transition to an ad end up showing an inappropriate or
premature part of the main program, or missing a beginning portion of an ad. 
depending on how the video decoder works (and how many video decoder contexts
the platform supports), missing the first keyframe of the ad could cause a skip
or blackness til the next keyframe (so potentially not showing several seconds
of the ad).

(Javascript burden) it is conceivable that the main program and every ad to be
inserted (potentially multiple back-to-back ads in one ad break) may have a
different format requiring separate SourceBuffers in the current model.
especially in circumstances where the format isn't known ahead of time (it
should be sufficient to just extract the format at play time directly from the
media), handling the possibility of different formats without having to parse
the media files in Javascript, this could lead to a large number of
SourceBuffers that must be maintained in Javascript, switched between for
playback and seek, and routed to during append.  the browser may not allow
enough SourceBuffers to be instantiated simultaneously to maintain the desired
amount of ahead-buffering.  the Javascript application will have to manually do
garbage collection on all these SourceBuffers as their respective portions of
the timeline are evicted.

having to maintain the separate SourceBuffers seems like an unnecessary and
artificial complication to the API, when conceptually you have a timeline of
media that you've laid out and that you just want to play out [as] seamlessly
[as possible].

i propose removing the constraint that a SourceBuffer can't have its codecs or
number/type of tracks change, and dispatch events to notify Javascript when
transitions/track configuration changes are reached and automatically handled. 
this can guarantee the most seamless transition possible on the platform, with
simple Javascript and no time-critical JS execution required.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Monday, 25 March 2013 23:04:10 UTC