[Bug 12544] MEDIA CONTROLLER requires track kind for in-band tracks

http://www.w3.org/Bugs/Public/show_bug.cgi?id=12544

Mark Watson <watsonm@netflix.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |watsonm@netflix.com

--- Comment #2 from Mark Watson <watsonm@netflix.com> 2011-04-25 17:16:14 UTC ---
It is to be expected that adaptive streaming media formats will more often
expose multiple in-band audio and video tracks, since with these formats it is
possible to download only the media being presented.

3GPP have explicitly asked W3C [1] to define labels of this kind for in-band
tracks and intend to align with W3C on the specific symbols. Specifically, they
state:

"It is possible, in our system, to express that the presentation can be built
from multiple streams of media, and we have identified the need to be able to
explain to the client software what the purpose of the separate streams is, in
particular for the case where additional streams offer accessibility
provisions; a textual caption stream is one of the more obvious cases.
We are using a general labelling technique for this aspect, and other aspects,
of our specification: we identify a specification, registration authority, or
other source by using a URI (normally expected to be a URN), and then provide
values from the set defined by that source.
Though this enables multiple organizations to define sets of names, we are
hoping very much that in the case of labelling of streams that we could
recommend use of a set of labels defined by the W3C, as this will help the
industry converge, and make it much easier to embed one of these streams in an
HTML5 context."

The MPEG DASH group is following the same approach as 3GPP, but their
documentation of this discussion is not yet public.

Certainly, this information will not be present in all container formats, so
there is a need for getKind() to be able to return "unknown", in which case the
situation is no worse than if getKind() was not present at all.

[1] http://www.3gpp.org/ftp/tsg_sa/WG4_CODEC/TSGS4_64/Docs/S4-110502.zip

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 25 April 2011 17:16:17 UTC