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

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

--- Comment #3 from Aaron Colwell <acolwell@google.com> ---
Over the weekend I was thinking about this a little more and I think I have
come up with a way of relaxing the constant track count restriction to
accomodate this use case without introducing the large increase in complexity
that I am worried about. The initial idea is to limit mandatory behavior to
only playing back a single track of each type. If we start here then it is
pretty straight forward to allow some flexibility on this front w/o having to
significantly increase complexity.

In the single track of each type it is pretty straight forward to specify rules
for which track to select in each initialization segment. For example
- For each track type (i.e. audio, video, text) select the first track in the
initialization segment that has its "default flag" set.
- If the initialization segment has tracks of a particular type but none of
them have the "default flag" set, then select the first track, of that type,
that appears in the initialization segment.
- The first initialiation segment appended must contain at least one track for
each type that the application wants renderered. If a track for a specific type
is not specified in this first initialization segment, then the UA does not
have to render a track of that type if it happens to appear in a later
initialization segment.

This provides a deterministic way to select tracks no matter how may exist in
the initialization segment while at the same time bounds the number of tracks
the UA actually has to handle. These rules could likely be expanded to multiple
tracks of the same type by using the kind, label & language to figure out what
tracks should be mapped to the same logical track. The multi-track case though
would NOT be mandatory for implementations. This is how complexity for mobile
and embedded devices could be mitigated.

I realize that this may not be ideal, but it is the best I can think of right
now to contain complexity and give you a little of what you want.

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

Received on Wednesday, 29 May 2013 00:19:29 UTC