[Bug 22137] changes in number of audio tracks during advert insertion

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

--- Comment #7 from Michael Thornburgh <mthornbu@adobe.com> ---
the original description for this bug is concerned with the case of "main
content has several languages but the spliced ad only has one" case.

i believe a much more common case will be "main content has separated video and
audio" (using separate SourceBuffers for video and audio to accommodate
multiple language tracks) but the spliced ad will have multiplexed video and
audio.  in other words, during main content appending, one SourceBuffer will
have one video track and zero audio tracks, and the other SourceBuffer will
have zero video tracks and one audio track.  during ad appending, one SB will
have one video track and one audio track, and the other will have zero video
and zero audio tracks.

in this case, not appending anything to the "other" SB will cause a stall.

one way to handle this would be to treat SourceBuffers as a filter & switch for
append-time buffering behavior rather than being directly connected to decoder
buffers.  SBs could indicate the track configuration of the current
initialization segment, and a means of controlling the mapping of those tracks
onto HTMLMediaElement tracks could be given.  if a SB had no mapped tracks,
then it wouldn't stall playback if nothing was appended.  otherwise data would
have to be filtered and mapped through the SB and onto the media timeline for
playback.

by decoupling SourceBuffers from the decoders, it could be reasonable to have
more than two SourceBuffers supported in an implementation.  one could have
three, for example: one for demuxed video, one for demuxed audio, and one for
muxed video+audio.  the SB's tracks could be mapped/unmapped *at append time*
to control what was laid down into the decode buffer for playback.  this would
allow for seamless (format changes notwithstanding) transitions without a
time-critical timeline-synced JavaScript track change call.

if SBs are filters&mappers, they could be created and destroyed on-the-fly
during append without affecting data already placed into the decode buffers. 
the media engine would be responsible for playing back the decode buffers as
seamlessly as possible.

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

Received on Tuesday, 9 July 2013 21:22:37 UTC