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

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

Aaron Colwell <acolwell@chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |acolwell@chromium.org

--- Comment #9 from Aaron Colwell <acolwell@chromium.org> ---
(In reply to comment #7)
> 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.

I don't believe this should be a goal for v1. The existing spec is already
particularly taxing for existing media engines and I believe that this will
just add another huge amount of work that isn't really needed right now. I
think this is a "nice to have" not a "must have". If content providers & ad
providers decide not to unify their content, then that is a choice, but like
any choice there are consequences. I feel like we already have allowed much
more change then the current HTML5 spec allows so I think we should wait and
see how the things we've speced out so far pan out before adding something like
this.

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

Received on Tuesday, 26 March 2013 18:47:30 UTC