shaka-player 4.6.4 → 4.7.0

package/docs/design/bg-fetch-after.gv

@@ -1,29 +0,0 @@
-# Generate png with: dot -Tpng -O after.gv
-digraph storage_after {
-  subgraph cluster_0 {
-    label="Shaka Player";
-    parse[label="Download and parse manifest (parseManifest)"];
-    drm[label="Make DRM engine and load keys (createDrmEngine)"]
-    filter[label="Filter manifest (filterManifest_)"];
-    segments[label="Download segments (downloadSegments_)"];
-    store[label="Store manifest (cell.addManifests)"];
-    parse -> drm;
-    drm -> filter;
-    filter -> store;
-    store -> segments[label="BG Fetch Not Available"];
-  }
-  subgraph cluster_1 {
-    label="Service Worker";
-    bgSegments[label="Download segments in background (backgroundFetch.fetch)"]
-    store -> bgSegments[label="BG Fetch Available"];
-  }
-  subgraph cluster_2 {
-    label="Shaka Player Static Methods";
-    storeSeg[label="Store segments one-by-one (assignStreamToManifest)"]
-    remove[label="Clean up (cleanStoredManifest)"];
-    segments -> remove[label="On Fail"];
-    segments -> storeSeg;
-    bgSegments -> storeSeg;
-    bgSegments -> remove[label="On Fail"];
-  }
-}

package/docs/design/bg-fetch-before.gv

@@ -1,18 +0,0 @@
-# Generate png with: dot -Tpng -O before.gv
-digraph storage_before {
-  subgraph cluster_0 {
-    label="Shaka Player";
-    parse[label="Download and parse manifest (parseManifest)"];
-    drm[label="Make DRM engine and load keys (createDrmEngine)"]
-    filter[label="Filter manifest (filterManifest_)"];
-    segments[label="Download and store segments (downloadManifest_)"];
-    store[label="Store manifest (cell.addManifests)"];
-    remove[label="Clean up (cell.removeSegments)"];
-    parse -> drm;
-    drm -> filter;
-    filter -> segments;
-    segments -> store;
-    segments -> remove[label="On Fail"];
-    store -> remove[label="On Fail"];
-  }
-}

package/docs/design/bg-fetch.md

@@ -1,134 +0,0 @@
-# Shaka Player Background Fetch Support
-
-last update: 2021-7-12
-
-by: [theodab@google.com](mailto:theodab@google.com)
-
-
-## Overview
-
-The feature of background fetch has been in Shaka Player’s backlog [since 2017].
-At the time it was added to the backlog, the feature was not quite ready for
-use. Since then, it has matured, and now is something we could feasibly use, but
-it has still been a low-priority feature.
-
-[since 2017]: https://github.com/shaka-project/shaka-player/issues/879
-
-## Design Concept
-
-This design attempts to reuse existing code whenever possible, in order to
-minimize the amount of new code that has to be tested. The code will be made in
-two main stages:
-1. Refactor the offline download process to change the order that the asset is
-downloaded. The manifest should be downloaded and stored first, and then every
-segment should be downloaded. As a segment is downloaded, it should be stored.
-The code for storing a segment, in particular, should be broken out into an
-exported static (e.g. stateless) function.
-1. Modify the Shaka Player wrapper to add the appropriate background fetch event
-listeners if the environment is detected to be a service worker, so that a
-compiled Shaka Player bundle can be used as a service worker. If background
-fetch is used, the segment downloading step should be passed to this service
-worker. When each segment is downloaded, it should be passed to the static
-storage functions added in stage 1.
-
-By restructuring the offline storage code in this way, switching between
-foreground and background fetch will just be a matter of calling a different
-segment-downloading function. In addition, it is possible that, in the future, a
-plugin interface could be made for this. That probably won’t be necessary unless
-another browser makes a competing API for downloading in the background (which
-is admittedly a possibility, as background fetch [is not yet a W3C standard]).
-
-[is not yet a W3C standard]: https://wicg.github.io/background-fetch/
-
-### Storage System Process: Before
-
-![Shaka storage system flow before](bg-fetch-before.gv.png)
-
-
-### Storage System Process: After
-
-![Shaka storage system flow after](bg-fetch-after.gv.png)
-
-
-## Implementation
-
-### Changes to shaka.offline.Storage
-
-1. Change createOfflineManifest_ to leave the storage indexes on the segments
-null at first. With this change, downloadManifest_ will now only be downloading
-the encryption keys (which cannot be downloaded via background fetch, as they
-require request bodies).
-1. Create a new step within store_, after the manifest is stored, called
-“downloadSegments_” that makes a Set of SegmentReference objects that need to be
-downloaded.
-   1. We use SegmentReference objects in order to contain the URI, startByte,
-   and endByte.
-   1. This change also means we will no longer need an internal cache for
-   downloaded segments, as they will be deduplicated by the use of a Set.
-1. If background fetch is not available, downloadSegments_ will simply download
-the segments from this set as before, and then once they are all downloaded,
-pass them all to assignStreamsToManifest.
-1. If background fetch is available, this set will be turned into an array,
-Request objects should be made for the individual uris (with appropriate headers
-applied), and then that array will be passed to the service worker with a
-background fetch call. The service worker will then, after everything is
-downloaded and stored, call assignStreamsToManifest.  An estimate of the total
-download size will need to be computed here, and padded to avoid premature
-cancellation for inaccurate manifests.
-1. Create a new public static method, assignStreamToManifest. This is a static
-method that requires no internal state, so that the service worker can call it.
-It stores the data provided, loads the manifest from storage, applies the
-storage id of the data to the appropriate segments (based on uri), and then
-stores the modified manifest. It should have a mutex over the part that loads
-and changes the manifest, to keep one invocation from overriding the manifest
-changes of another. It should have the following parameters:
-   1. manifestStorageId
-   1. uri
-   1. data
-   1. throwIfAbortedFn
-1. Create a second public static method, cleanStoredManifest. This method is
-meant to be called by the service worker in the instance of the fetch operation
-being aborted, and will simply clear the manifest away. It will also clear any
-segments that have been stored already. This also means we will no longer need
-the segmentsFromStore_ array, which we had previously been using to un-store
-after canceled or failed downloads. It should have the following parameters:
-   1. manifestStorageId
-1. When filling out shaka.extern.StoredContent entries for the list() method,
-the storage system should be sure to set the offlineUri field to null if the
-manifest is still “isIncomplete”, to mark that the asset has not yet finished
-downloading. This will help developers detect that an asset is mid-download on
-page load, so that they can set up progress indicators if they so wish.
-
-
-### Service Worker Design
-
-1. This code should go in, or at least be loaded in, the wrapper code. This will
-let us access Shaka Player methods inside the service worker, without having to
-coordinate how to load a compiled Shaka Player bundle from a service worker;
-the user can simply load a Shaka Player bundle as a service worker.
-1. When the background fetch message is called (see [the documentation]), the
-“id” field should be set to the storage id of the manifest, with an added prefix
-of “Shaka-”. The API does not provide any field for custom data, but this value
-still needs to be provided to the service worker somehow. Luckily, this is the
-only extra data the service worker needs, so it can just be the id of the fetch
-operation.
-   1. When handling background fetch-related events, we can simply ignore any
-   event that does not start with the prefix. This will help prevent any
-   contamination with other service worker code from the developer.
-1. As each segment is downloaded, the assignStreamToManifest method should be
-called to store that data in the manifest.
-1. If the download is canceled, call the cleanStoredManifest method, so that the
-player doesn’t pollute indexedDb with unused segment data.
-1. As a service worker is essentially just a collection of event listeners, one
-can theoretically listen to the same event multiple times. This is relevant
-because [a given scope] can only have a single service worker, so our service
-worker code will have to be something that other people can load into their
-existing service workers, if they have any.
-1. Our system should use the message event to pass a specific identifying
-message to the service worker, and the service worker will be expected to
-respond with a specific response message. This way, we won’t mistake an
-unrelated service worker for our own.
-   1. This message can also be used to make sure the versions are the same.
-
-[the documentation]: https://developers.google.com/web/updates/2018/12/background-fetch#starting_a_background_fetch
-[a given scope]: https://developers.google.com/web/fundamentals/primers/service-workers#register_a_service_worker

package/docs/design/cast.gv

@@ -1,35 +0,0 @@
-# Generate png with: dot -Tpng -O cast.gv
-
-digraph shaka2_cast {
-  label=<<u>Shaka 2 Cast Diagram</u>>
-  labelloc=t
-  node [ shape=rectangle ]
-  edge [ fontsize=10 ]
-
-  # Video tags are part of the local browser and remote Cast device
-  "local <video>" [ shape=oval ]
-  "remote <video>" [ shape=oval ]
-
-  # Controls are provided by the app
-  "video controls" [ shape=polygon ]
-
-  # The CastProxy class creates proxies for both Player and video tag
-  CastProxy -> "proxy Player" [ label=".getPlayer()  " ]
-  CastProxy -> "proxy <video>" [ label=".getVideo()  " ]
-
-  # Each Player owns its respective video tag
-  "local Player" -> "local <video>"
-  "remote Player" -> "remote <video>"
-
-  # The proxies forward/delegate to the correct instance based on casting state
-  "proxy Player" -> "local Player" [ style=dotted label="delegate" dir=both ]
-  "proxy Player" -> "remote Player" [ style=dotted label="delegate" dir=both ]
-  "proxy <video>" -> "local <video>" [ style=dotted label="delegate" dir=both ]
-  "proxy <video>" -> "remote <video>" [ style=dotted label="delegate" dir=both ]
-
-  # The app's controls go through the proxy and don't worry about cast state
-  "video controls" -> "proxy Player" [ label=".configure()\n.load()\nevents" dir=both ]
-  "video controls" -> "proxy <video>" [ label=".play()\n.pause()\n.currentTime\nevents" dir=both ]
-  # The app asks the proxy to cast
-  "video controls" -> CastProxy [ label=".cast()" ]
-}

package/docs/design/chromecast.md

@@ -1,151 +0,0 @@
-# Shaka Player v2 Chromecast Design
-
-last update: 2016-05-07
-
-by: [joeyparrish@google.com](mailto:joeyparrish@google.com)
-
-
-## Overview
-
-Shaka Player v2 will support Chromecast in the library for both sender and
-receiver.  This is in contrast to v1, where we demonstrated cast sending and
-receiving in the demo app, but provided no direct Chromecast support in the
-library.
-
-Senders will use a `shaka.cast.CastProxy` object which wraps both `shaka.Player`
-and `HTMLMediaElement`.  The proxy will delegate to either local or remote
-objects based on the current cast state.  Senders must also load the Cast Sender
-API JavaScript library in addition to Shaka.  Applications can be quickly
-modified to use a `CastProxy` without changing their use of `Player` and
-`HTMLMediaElement` APIs.
-
-Receivers will use a `shaka.cast.CastReceiver` object which wraps both
-`shaka.Player` and `HTMLMediaElement` on the Chromecast.  The `CastReceiver`
-will receive commands from the sender and update the sender with the status of
-the `Player` and `HTMLMediaElement` objects.  Receiver apps only have to worry
-about their UI, while the `CastReceiver` takes care of playback and
-communication.
-
-To enable an Android (TV) receiver apps set `androidReceiverCompatible` to true.
-
-
-#### `CastProxy` API sketch
-
-```js
-new shaka.cast.CastProxy(video, player, receiverAppId, androidReceiverCompatible)
-
-// Also destroys the underlying local Player object
-shaka.cast.CastProxy.prototype.destroy() => Promise
-
-// Looks like shaka.Player, proxies to local or remote player based on cast
-// state
-shaka.cast.CastProxy.prototype.getPlayer() => shaka.Player
-
-// Looks like HTMLMediaElement, proxies to local or remote video based on cast
-// state
-shaka.cast.CastProxy.prototype.getVideo() => HTMLMediaElement
-
-// True if there are cast receivers available
-shaka.cast.CastProxy.prototype.canCast() => boolean
-
-// True if we are currently casting
-shaka.cast.CastProxy.prototype.isCasting() => boolean
-
-// Fired when either canCast or isCasting changes
-shaka.cast.CastProxy.CastStatusChangedEvent
-
-// Resolved when connected to a receiver, rejected if the connection fails
-shaka.cast.CastProxy.prototype.cast() => Promise
-
-// Transmits application-specific data to the receiver (now or on later connect)
-shaka.cast.CastProxy.prototype.setAppData(appData)
-
-// Disconnect from the receiver
-shaka.cast.CastProxy.prototype.disconnect()
-```
-
-
-#### `CastReceiver` API sketch
-
-```js
-new shaka.cast.CastReceiver(video, player, appDataCallback)
-
-// True if there are cast senders connected
-shaka.cast.CastReceiver.prototype.isConnected() => boolean
-
-// Fired when isConnected changes
-shaka.cast.CastReceiver.CastStatusChangedEvent
-```
-
-
-#### Implementation
-
-`CastProxy` in local mode will pass all attribute and method accesses directly
-to the local objects.  In cast mode, it will have to implement certain
-attributes and methods differently from others.
-
-In cast mode, reads of attributes and calls to synchronous getter methods will
-be backed by a cache of attribute values pushed by the `CastReceiver`.  They
-will synchronously return the most recent value sent by the receiver.  Writes to
-attributes and calls to methods without a return value will be proxied to the
-remote objects and treated as synchronous.  Attribute writes will replace the
-most recent values pushed by the receiver.  Methods which return a `Promise`
-will return a Promise which is resolved when the `CastReceiver` pushes a return
-value back.
-
-`CastProxy` and `CastReceiver` must share a list of events, attributes, getter
-methods, void methods, and methods which return a `Promise`.  If a key is not
-explicitly listed, its type is not known and it is not supported by the proxy.
-
-`CastReceiver` will periodically push values of attributes and getters to the
-`CastProxy` on the sender.  It will also push events to the `CastProxy`.  As of
-our first draft, `CastReceiver` pushes attribute updates every 500ms.  Based on
-experiments, this seems to be a good balance between performance and UI
-responsiveness.
-
-`CastProxy` will have to have a special handler to simulate `TimeRanges`, since
-the object cannot be pushed directly by `CastReceiver`.  `CastReceiver` will
-read out the values of each range and push an anonymous object containing the
-information.  `CastProxy` will provide an object that looks and acts like
-`TimeRanges`, but which is backed by the anonymous object pushed by
-`CastReceiver`.
-
-`CastReceiver` will have to connect `volume` and `muted` attributes to the
-system volume, not the video volume.  The ChromeCast documentation states:
-
-> All user-initiated actions on volume should impact the system volume, not the
-> stream volume.
-
-When we first cast, `CastProxy` will send its initial state to `CastReceiver`,
-including its configuration, manifest URI, selected tracks, text visibility,
-side-loaded text tracks, current timestamp, and any custom app data from the
-sender application.  `CastReceiver` will invoke a receiver app callback to
-process any custom app data before initiating playback.
-
-Custom app data can be used to pass information that cannot be transferred from
-the sender app's config to the receiver app's config.  For example, network
-filters, custom dash scheme callbacks, and custom ABR callbacks are all
-functions defined in the sender app.  These cannot be serialized and transferred
-to the receiver without security risks, because the receiver would have to use
-`eval()` to deserialize them.  Instead, the sender app must send whatever data
-is necessary for the receiver to construct equivalent callbacks if needed.  For
-example, if network filters are used to attach auth tokens to license requests,
-the app data would include the user's auth token.
-
-Sender apps must listen for `CastStatusChangedEvent`s because a receiver can be
-disconnected without going through the app's UI.
-
-Receiver apps must listen for `CastStatusChangedEvent`s because senders can
-disconnect at any time, and because Chromecast UI guidelines say that receiver
-apps should show a different UI while idle.
-
-
-#### Error conditions
-
-Errors during `cast()`:
-  - Cast API unavailable
-  - No cast receivers available
-  - Already casting
-  - Cast canceled by user
-  - Cast connection timed out
-  - Requested cast receiver app ID is unavailable or does not exist

package/docs/design/codec_preferences.md

@@ -1,158 +0,0 @@
-# Shaka Player Codec Preferences Upgrade Design
-
-last update: 2021-03-04
-
-by: [michellezhuo@google.com](mailto:michellezhuo@google.com)
-
-
-## Objective
-
-Allow the applications to make smarter, dynamic and configurable decisions to
-choose codecs and DRM key systems in Shaka Player.
-
-
-## Overview
-
-By adopting the [MediaCapabilities API][] in Shaka Player, we can leverage the
-decoding information, and select the most appropriate codec and resolution of
-the media content dynamically for the user’s device to play.
-
-This project allows us to:
-- Determine not only whether media assets are playable, but also whether they
-  are playable in an efficient and performant manner
-- Simplify the logic of determining the DRM key system compatibility
-
-Besides leveraging the decoding information from MediaCapabilities, we are
-offering a few new configurations for the applications to specify their codec
-preferences. The new configurations include:
-- `drm.preferredKeySystems`
-- `preferredDecodingAttributes`
-- `preferredCodecs`
-
-[MediaCapabilities API]: https://developer.mozilla.org/en-US/docs/Web/API/Media_Capabilities_API
-
-
-## API changes
-
-### Asynchronous `StreamUtils.filterManifest`
-
-Previously, all of the manifest filtering happens within the
-`StreamUtils.filterManifest`. Now `StreamUtils.filterManifest` will call
-`MediaCapabilities.decodingInfo` to get the decoding information for manifest
-filtering and then codec choosing.
-
-Since the `MediaCapabilities.decodingInfo` happens asynchronously, the
-`StreamUtils.filterManifest` will be changed to asynchronous.
-
-
-## New Configurations
-
-### Configurable codec preferences
-
-The MediaCapabilities API provides the Player with whether decoding the media
-is:
-- supported
-- smooth
-- power efficient
-
-We want to allow applications to choose the ideal codec based on the decoding
-information of the codecs dynamically. The application can specify by
-the following attributes:
-- smooth
-- power efficient
-- lowest bandwidth
-
-The `preferredDecodingAttributes` configuration allows the application to
-specify choosing the ideal codec based on which attributes. It takes an array
-of enum strings as its value. The order of the values in the array specifies
-the priorities of the attributes.
-
-For example, the application can set the configuration as:
-
-```js
-player.configure('preferredDecodingAttributes', [
-  'smooth',
-  'bandwidth',
-]);
-```
-
-Based on the configuration, Shaka Player will:
-1. Choose the codec with the smooth variants (unless there are none)
-2. If more than one codecs have smooth variants, choose the codec with the
-   lowest bandwidth.
-
-### Configurable codec priorities
-
-If more than one codec are supported and available for choosing, and
-`preferredDecodingAttributes` is not configured, an application can specify
-which codecs it prefers via the `preferredCodecs` config.
-
-```js
-player.configure('preferredCodecs', ['avc1', 'vp09']);
-```
-
-### Configurable key system priorities
-
-A platform may support multiple DRM key systems, (for example, Widevine and
-PlayReady). The `drm.preferredKeySystems` configuration allows the application
-to specify which key systems it wants to choose.
-
-[Github issue](https://github.com/shaka-project/shaka-player/issues/3002)
-
-Previously, Shaka Player chose a DRM key system based on:
-1. Only use the key systems supported by the platform.
-2. Only use the key systems with configured license server urls.
-3. Choose based on the order of the key systems in the manifest. We try the
-first one, then the second one, until we get a valid keySystemAccess.
-
-Now the application can set the configuration as:
-
-```js
-player.configure('drm.preferredKeySystems', [
-  'com.widevine.alpha',
-  'com.microsoft.playready',
-]);
-```
-
-With `drm.preferredKeySystems` configured, Shaka Player would:
-1. Based on the preference order specified with the `drm.preferredKeySystems`,
-   try to find the matching key systems. In the example above, the Player looks
-   for the codec with 'com.widevine.alpha' key system first. If none is
-   available, the Player looks for a codec with 'com.microsoft.playready'.
-2. If no preferred key system in the config is available in the manifest, we
-   fall back to the old behavior.
-3. If no such configuration is given, we fall back to the old behavior.
-
-
-## Codec Preferences Algorithm
-
-With the new configurations, the Player takes the following steps to choose a
-codec:
-1. Choose the supported variants
-2. If the content is encrypted:
-   1. If `drm.preferredKeySystems` is configured, choose the key system based on
-      the order of the preferred key systems.
-   2. Otherwise, fall back to the default behavior:
-      1. Use the key systems that we have a license server for.
-      2. Choose the first key system with the order in the manifest.
-4. If `preferredDecodingAttributes` is configured, sort the codecs by the
-   `preferredDecodingAttributes` in order.
-5. If `preferredDecodingAttributes` is not configured and more than one codecs
-   are available for choosing:
-   1. If `preferredAudioChannelCount` is configured, choose the variants with
-      the audio channel count equal to `preferredAudioChannelCount`.
-   2. If the `preferredCodecs` is configured, choose the codecs equal to the
-      preferred codec.
-   3. If the `preferredCodecs` is not configured, choose the codec with the
-      lowest bandwidth by default.
-
-If the new configurations are not specified, the codec preferences algorithm is
-consistent with the current Player behavior.
-
-
-## Challenges
-
-Currently the filtering, sorting and choosing algorithms are in various places
-in our code base, including `StreamUtils.filterManifest`, `DrmEngine`, and
-`StreamUtils.chooseCodecsAndFilterManifest`.  To simplify the code and improve
-readability, we’ll conduct the new codec preferences algorithm in one place.

package/docs/design/dash-audio-channels.md

@@ -1,123 +0,0 @@
-# Counting DASH Audio Channels
-
-Shaka Player parses channel count information from HLS manifests, but not yet
-from DASH manifests.  We have had an [open request][dash_channels_request] to
-do this for a year.
-
-[dash_channels_request]: https://github.com/shaka-project/shaka-player/issues/424
-
-
-## The DASH Spec
-
-A DASH manifest does not contain a simple count of audio channels.  Instead, it
-has a more general description of the audio channel "configuration", including
-the desired speaker layout.  Further, the way this is described is extensible,
-and there is no single format for this metadata.
-
-The DASH spec says this of the <AudioChannelConfiguration> element:
-
-> For the element AudioChannelConfiguration the @schemeIdUri attribute is used
-> to identify the audio channel configuration scheme employed.  Multiple
-> AudioChannelConfiguration elements may be present indicating that the
-> Representation supports multiple audio channel configurations. For example, it
-> may describe a Representation that includes MPEG Surround audio supporting
-> stereo and multichannel. If the scheme or the value for this descriptor is not
-> recognized the DASH client is expected to ignore the descriptor.
->
-> The descriptor may carry audio channel configuration using the URN label and
-> values defined for OutputChannelPosition in ISO/IEC 23001-8.
->
-> NOTE: A scheme for audio channel configuration is also defined in 5.8.5.4 of
-> this part of ISO/IEC 23009. This scheme is maintained for
-> backward-compatibility, but it recommended to use the signalling as defined in
-> ISO/IEC 23001-8.
-
-> 5.8.5.4 Audio channel configuration schemes
->
-> The following defines a URI that identifies channel configuration signalling
-> for Representations that contain an audio component. The URI
-> 'urn:mpeg:dash:23003:3:audio\_channel\_configuration:2011' is defined to
-> indicate the channel configuration as defined by Table 68 (Channel
-> Configurations, meaning of channelConfigurationIndex, mapping of channel
-> elements to loudspeaker positions') of ISO/IEC 23003-3. The @value shall be
-> the value as defined for OutputChannelPosition in ISO/IEC 23001-8.
->
-> The URN 'urn:mpeg:dash:outputChannelPositionList:2012' defines a list of
-> output channel positions to signal individual speaker positions. The @value
-> shall be a space-delimited list of values as defined of the
-> OutputChannelPosition as defined in ISO/IEC 23001-8. For example, the @value
-> for the 7.1 channel configuration 2 high as 2/0/0, 5 mid as 3/0/2 and 0.1 low,
-> where a/b/c indicates speaker count in front, side and back, respectively and
-> 0.1 indicates a subwoofer channel), is '2 0 1 4 5 3 17 1'.
-
-
-## Schemes
-
-### urn:mpeg:dash:outputChannelPositionList:2012
-
-This is described in the DASH spec as a list of OutputPosition values from
-ISO/IEC 23001-8:2016.  That spec gives a table in which 43 explicit speaker
-positions are given numerical values.  It would seem that when using this scheme
-in DASH, the @value attribute is a space-separated list of these speaker
-position values.  Therefore the number of channels is the length of this list.
-
-
-### urn:mpeg:dash:23003:3:audio\_channel\_configuration:2011
-
-The DASH spec says this is "the channel configuration as defined by Table 68 ...
-of ISO/IEC 23003-3. The @value shall be the value as defined for
-OutputChannelPosition in ISO/IEC 23001-8."
-
-The statement about OutputChannelPosition and 23001-8 conflicts with available
-evidence.  Both Shaka Packager and the [open source DASH encoder from Cast
-Labs][cast_labs_23003] use [the number of channels in the @value
-attribute][shaka_packager_23003]. Therefore, we assume that 23003-3 defines this
-very simply as the number of channels, and that the second statement about
-23001-8 was added to that paragraph in error.
-
-Neither 23003-3 nor the DASH spec corrigenda were freely available at the time
-of this writing, so we have not confirmed these assumptions.
-
-[cast_labs_23003]: https://github.com/castlabs/dashencrypt/blob/1d604896/dash.fragmencrypter/src/main/java/com/castlabs/dash/helpers/DashHelper.java#L193
-[shaka_packager_23003]: https://github.com/shaka-project/shaka-packager/blob/4ba5bec6/packager/mpd/base/xml/xml_node.cc#L378
-
-
-### tag:dolby.com,2014:dash:audio\_channel\_configuration:2011
-
-The [DASH-IF website][dash_if_audio_config] also lists the
-"tag:dolby.com,2014:dash:audio\_channel\_configuration:2011" scheme, with the
-description:
-
-> Dolby audio channel configuration information. The @value attribute shall
-> contain a four digit hexadecimal representation of the 16 bit field that
-> describes the channel assignment as defined by table E.5 in ETSI TS 102 366
-> where left channel is MSB. For example, for a stream with L, C, R, Ls, Rs,
-> LFE, the value shall be 'F801' (hexadecimal equivalent of the binary value
-> 1111 1000 0000 0001).
-
-From the example, it would appear that each channel is represented by a single
-bit, so we could count the number of one-bits.  [An enumeration in Shaka
-Packager][shaka_packager_ec3_enum] supports this interpretation.  This has not
-been confirmed from primary sources.
-
-[dash_if_audio_config]: http://dashif.org/identifiers/audio-source-data/
-[shaka_packager_ec3_enum]: https://github.com/shaka-project/shaka-packager/blob/47363dd0/packager/media/codecs/ec3_audio_util.cc#L34
-
-
-### urn:dts:dash:audio\_channel\_configuration:2012
-
-The DASH encoder from Cast Labs also supports
-"urn:dts:dash:audio\_channel\_configuration:2012" for DTS, which [seems to be a
-simple channel count][cast_labs_dash_2012].
-
-[cast_labs_dash_2012]: https://github.com/castlabs/dashencrypt/blob/1d604896/dash.fragmencrypter/src/main/java/com/castlabs/dash/helpers/DashHelper.java#L321
-
-
-### urn:dolby:dash:audio\_channel\_configuration:2011
-
-The DASH encoder from Cast Labs also supports
-"urn:dolby:dash:audio\_channel\_configuration:2011" for AC3 and EC3, which
-[seems to be identical to the hex string][cast_labs_dolby] used in the
-"tag:dolby.com,2014:dash:audio\_channel\_configuration:2011" scheme above.
-
-[cast_labs_dolby]: https://github.com/castlabs/dashencrypt/blob/1d604896/dash.fragmencrypter/src/main/java/com/castlabs/dash/helpers/DashHelper.java#L100