shaka-player 3.1.4 → 3.1.7

package/docs/design/REDESIGN.md

@@ -28,11 +28,11 @@ often requiring [multiple][] [fixes][] to get certain dependencies removed.
 This means users all end up using the same monolithic player library.
 Features in Shaka 2 should be modular and easy to exclude from the build.
 
-[difficult]: https://github.com/google/shaka-player/commit/671611ef3722169b9f6b51ab44bdd6b4098d959e
-[to exclude]: https://github.com/google/shaka-player/commit/603fae969550c69ea38a61249da905857c67b9f1
-[from the build]: https://github.com/google/shaka-player/commit/f248647685b92ba928bbfd06d45d2b99023d60c2
-[multiple]: https://github.com/google/shaka-player/commit/39be45d3d55cdcef20a6a529a87246b0ea11cb33
-[fixes]: https://github.com/google/shaka-player/commit/6fe239150a8939728876e93e1a4269032530d9f1
+[difficult]: https://github.com/shaka-project/shaka-player/commit/671611ef3722169b9f6b51ab44bdd6b4098d959e
+[to exclude]: https://github.com/shaka-project/shaka-player/commit/603fae969550c69ea38a61249da905857c67b9f1
+[from the build]: https://github.com/shaka-project/shaka-player/commit/f248647685b92ba928bbfd06d45d2b99023d60c2
+[multiple]: https://github.com/shaka-project/shaka-player/commit/39be45d3d55cdcef20a6a529a87246b0ea11cb33
+[fixes]: https://github.com/shaka-project/shaka-player/commit/6fe239150a8939728876e93e1a4269032530d9f1
 
 Some operations, in particular [starting playback and filling the buffer][],
 take longer than they need to.  Startup and buffering in Shaka 2 should be as
@@ -46,54 +46,54 @@ us from updating MediaSource duration][] and makes it [difficult to set initial
 playback time][] on browsers other than Chrome.  Shaka 2 should have a simpler
 streaming core that works better across browsers.
 
-[StreamVideoSource]: https://github.com/google/shaka-player/blob/v1.5.x/lib/player/stream_video_source.js
-[Stream]: https://github.com/google/shaka-player/blob/v1.5.x/lib/media/stream.js
-[SourceBufferManager]: https://github.com/google/shaka-player/blob/v1.5.x/lib/media/source_buffer_manager.js
-[prevents us from updating MediaSource duration]: https://github.com/google/shaka-player/blob/v1.5.1/lib/player/stream_video_source.js#L1807
-[difficult to set initial playback time]: https://github.com/google/shaka-player/issues/101
+[StreamVideoSource]: https://github.com/shaka-project/shaka-player/blob/v1.5.x/lib/player/stream_video_source.js
+[Stream]: https://github.com/shaka-project/shaka-player/blob/v1.5.x/lib/media/stream.js
+[SourceBufferManager]: https://github.com/shaka-project/shaka-player/blob/v1.5.x/lib/media/source_buffer_manager.js
+[prevents us from updating MediaSource duration]: https://github.com/shaka-project/shaka-player/blob/v1.5.1/lib/player/stream_video_source.js#L1807
+[difficult to set initial playback time]: https://github.com/shaka-project/shaka-player/issues/101
 
 [Buffering state][] in Shaka 1 involves coordination between several layers
 (from [Player][] to [Stream][]) and has been [tough][] [to][] [get][]
 [right][].  Buffering state in Shaka 2 should be simple and consistent.
 
-[Buffering state]: https://github.com/google/shaka-player/blob/v1.5.1/lib/player/player.js#L994
-[Player]: https://github.com/google/shaka-player/blob/v1.5.x/lib/player/player.js
-[Stream]: https://github.com/google/shaka-player/blob/v1.5.x/lib/media/stream.js
-[tough]: https://github.com/google/shaka-player/issues/44
-[to]: https://github.com/google/shaka-player/issues/63
-[get]: https://github.com/google/shaka-player/issues/127
-[right]: https://github.com/google/shaka-player/issues/221#issuecomment-152781243
+[Buffering state]: https://github.com/shaka-project/shaka-player/blob/v1.5.1/lib/player/player.js#L994
+[Player]: https://github.com/shaka-project/shaka-player/blob/v1.5.x/lib/player/player.js
+[Stream]: https://github.com/shaka-project/shaka-player/blob/v1.5.x/lib/media/stream.js
+[tough]: https://github.com/shaka-project/shaka-player/issues/44
+[to]: https://github.com/shaka-project/shaka-player/issues/63
+[get]: https://github.com/shaka-project/shaka-player/issues/127
+[right]: https://github.com/shaka-project/shaka-player/issues/221#issuecomment-152781243
 
 Shaka 1 relies on the browser to implement support for text types, and is
 therefore limited to non-segmented WebVTT.  Shaka 2 should also support
 [segmented text types][] and [types not natively supported by the browser][].
 
-[segmented text types]: https://github.com/google/shaka-player/issues/150
-[types not natively supported by the browser]: https://github.com/google/shaka-player/issues/111
+[segmented text types]: https://github.com/shaka-project/shaka-player/issues/150
+[types not natively supported by the browser]: https://github.com/shaka-project/shaka-player/issues/111
 
 Bandwidth estimation in Shaka 1 relies on the assumption that segments are not
 cached locally.  Use of [cache-busting techniques][] to enforce this makes
 Shaka very [cache][]-[unfriendly][].  Shaka 2 should be cache-friendly.
 
-[cache-busting techniques]: https://github.com/google/shaka-player/blob/v1.5.1/lib/util/ajax_request.js#L241
-[cache]: https://github.com/google/shaka-player/issues/76
-[unfriendly]: https://github.com/google/shaka-player/issues/191
+[cache-busting techniques]: https://github.com/shaka-project/shaka-player/blob/v1.5.1/lib/util/ajax_request.js#L241
+[cache]: https://github.com/shaka-project/shaka-player/issues/76
+[unfriendly]: https://github.com/shaka-project/shaka-player/issues/191
 
 Shaka 1 [uses HTTP headers to synchronize the user's clock][] with the server.
 This is [error-prone for some CDNs][] and also raises [CORS issues][], so Shaka
 2 should avoid using HTTP headers.
 
-[uses HTTP headers to synchronize the user's clock]: https://github.com/google/shaka-player/blob/v1.5.1/lib/util/ajax_request.js#L448
-[error-prone for some CDNs]: https://github.com/google/shaka-player/issues/205
-[CORS issues]: https://github.com/google/shaka-player/issues/159
+[uses HTTP headers to synchronize the user's clock]: https://github.com/shaka-project/shaka-player/blob/v1.5.1/lib/util/ajax_request.js#L448
+[error-prone for some CDNs]: https://github.com/shaka-project/shaka-player/issues/205
+[CORS issues]: https://github.com/shaka-project/shaka-player/issues/159
 
 [HttpVideoSource][] does not build on MSE and classes like [EmeManager][] have
 special cases to support it.  Since it was originally created for debugging
 purposes, Shaka 2 should drop HttpVideoSource and only support MSE-based
 playback.
 
-[HttpVideoSource]: https://github.com/google/shaka-player/blob/v1.5.x/lib/player/http_video_source.js
-[EmeManager]: https://github.com/google/shaka-player/blob/v1.5.x/lib/media/eme_manager.js
+[HttpVideoSource]: https://github.com/shaka-project/shaka-player/blob/v1.5.x/lib/player/http_video_source.js
+[EmeManager]: https://github.com/shaka-project/shaka-player/blob/v1.5.x/lib/media/eme_manager.js
 
 Integration tests using externally-hosted resources [can be flaky][],
 especially when run outside of Google's network.  Shaka 2 should avoid tests
@@ -106,34 +106,34 @@ and application developers sometimes [have to use error message strings][]
 hard-coded into the library.  Shaka 2 should have a consistent error format
 that is easy to read.
 
-[have to use error message strings]: https://github.com/google/shaka-player/issues/201
+[have to use error message strings]: https://github.com/shaka-project/shaka-player/issues/201
 
 Networking abstractions in Shaka 1 are built inside of AjaxRequest, which
 requires non-HTTP requests to [pretend to come from XmlHttpRequest][].  The
 networking abstraction in Shaka 2 should be simpler and should not treat
 XHR as the basis for all networking.
 
-[pretend to come from XmlHttpRequest]: https://github.com/google/shaka-player/blob/v1.5.1/lib/util/ajax_request.js#L305
+[pretend to come from XmlHttpRequest]: https://github.com/shaka-project/shaka-player/blob/v1.5.1/lib/util/ajax_request.js#L305
 
 A developer who wishes to use a custom network protocol or a custom manifest
 format in Shaka 1 will have to modify the library to do so.  Shaka 2 should
 [support external plugins for networking][] and manifest support.
 
-[support external plugins for networking]: https://github.com/google/shaka-player/issues/198
+[support external plugins for networking]: https://github.com/shaka-project/shaka-player/issues/198
 
 The functionality that can be injected into Shaka 1 ([IBandwidthEstimator][],
 [IAbrManager][]) is based on implementing class interfaces, which can be complex
 for those unfamiliar with the Closure compiler.  Plugins and extensions to Shaka
 2 should be as simple as possible.
 
-[IBandwidthEstimator]: https://github.com/google/shaka-player/blob/v1.5.1/lib/util/i_bandwidth_estimator.js
-[IAbrManager]: https://github.com/google/shaka-player/blob/v1.5.1/lib/media/i_abr_manager.js
+[IBandwidthEstimator]: https://github.com/shaka-project/shaka-player/blob/v1.5.1/lib/util/i_bandwidth_estimator.js
+[IAbrManager]: https://github.com/shaka-project/shaka-player/blob/v1.5.1/lib/media/i_abr_manager.js
 
 [Static members][] in Shaka 1 make it impossible in some cases to host multiple
 Player instances with different settings.  Player instances should be completely
 independent in Shaka 1.
 
-[Static members]: https://github.com/google/shaka-player/issues/126
+[Static members]: https://github.com/shaka-project/shaka-player/issues/126
 
 
 ## Shaka v2 Design Principles

package/docs/design/codec_preferences.md

@@ -97,7 +97,7 @@ 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/google/shaka-player/issues/3002)
+[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.

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

@@ -4,7 +4,7 @@ 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/google/shaka-player/issues/424
+[dash_channels_request]: https://github.com/shaka-project/shaka-player/issues/424
 
 
 ## The DASH Spec
@@ -79,7 +79,7 @@ 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/google/shaka-packager/blob/4ba5bec6/packager/mpd/base/xml/xml_node.cc#L378
+[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
@@ -101,7 +101,7 @@ 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/google/shaka-packager/blob/47363dd0/packager/media/codecs/ec3_audio_util.cc#L34
+[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

package/docs/design/dash-manifests.md

@@ -244,5 +244,5 @@ segments.  You can follow progress in [#999][].  But note that DASH requires
 accurate clock times, so even after that feature is added, your manifest may
 not play in other DASH players.
 
-[#999]: https://github.com/google/shaka-player/issues/999
+[#999]: https://github.com/shaka-project/shaka-player/issues/999
 

package/docs/design/gap-jumping.md

@@ -21,13 +21,13 @@ buffered ranges.
 
 There have been a number of bugs filed asking for this feature.
 
-#### [#180](https://github.com/google/shaka-player/issues/180)
+#### [#180](https://github.com/shaka-project/shaka-player/issues/180)
 One of the first bugs asking for gap jumping.  The author talks about how live
 streams can commonly lose source content (e.g. from network outages or weather).
 This can cause the packagers to introduce gaps in either the media segments or
 the manifest.
 
-#### [#555](https://github.com/google/shaka-player/issues/555)
+#### [#555](https://github.com/shaka-project/shaka-player/issues/555)
 This one is also asking about live streams and outages.  The author discusses
 several options for dealing with interruptions in the live streams.  The
 suggestions were:
@@ -41,7 +41,7 @@ can’t tell if a segment will never be available or is just not created yet.
 Also that dummy content is usually generated by the server; however, the author
 notes that this may not be feasible.
 
-#### [#661](https://github.com/google/shaka-player/issues/661)
+#### [#661](https://github.com/shaka-project/shaka-player/issues/661)
 This content with small gaps in the media that result in playback stalling.
 Chrome and Firefox will actually play through the gap, but we don’t allow it
 since it wouldn’t work on Safari.

package/docs/design/preload.md

@@ -15,7 +15,7 @@ This allows an application using Shaka Player to:
   the user is making a decision on which video to play.
 - Start to play the selected video almost immediately.
 
-[Github issue](https://github.com/google/shaka-player/issues/880)
+[Github issue](https://github.com/shaka-project/shaka-player/issues/880)
 
 
 ## Background & Context
@@ -296,4 +296,4 @@ When preloading, the MediaSourceEngine appends the data to the SourceBuffer.
    to the MediaSource.
 3. For a live stream video, StreamingEngine can keep fetching the latest piece
    of the content. The MediaSourceEngine stores the latest data, and abandons
-   the older data.
+   the older data.

package/docs/tutorials/faq.md

@@ -274,18 +274,18 @@ so don't declare it using a ref(), and if you put your player instance into a
 data() object, you can prefix the property name with "$" or "_" to make Vue not
 proxy them.
 
-[386]: https://github.com/google/shaka-player/issues/386#issuecomment-227898001
-[489]: https://github.com/google/shaka-player/issues/489#issuecomment-240466224
-[743]: https://github.com/google/shaka-player/issues/743
-[887]: https://github.com/google/shaka-player/issues/887
-[999]: https://github.com/google/shaka-player/issues/999
-[1667]: https://github.com/google/shaka-player/issues/1667
+[386]: https://github.com/shaka-project/shaka-player/issues/386#issuecomment-227898001
+[489]: https://github.com/shaka-project/shaka-player/issues/489#issuecomment-240466224
+[743]: https://github.com/shaka-project/shaka-player/issues/743
+[887]: https://github.com/shaka-project/shaka-player/issues/887
+[999]: https://github.com/shaka-project/shaka-player/issues/999
+[1667]: https://github.com/shaka-project/shaka-player/issues/1667
 [BigInteger.js]: https://github.com/peterolson/BigInteger.js
 [CORS]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
-[Shaka Player Embedded]: https://github.com/google/shaka-player-embedded
+[Shaka Player Embedded]: https://github.com/shaka-project/shaka-player-embedded
 [auth]: https://shaka-player-demo.appspot.com/docs/api/tutorial-license-server-auth.html
 [buffering]: https://shaka-player-demo.appspot.com/docs/api/tutorial-network-and-buffering-config.html
 [drm_tutorial]: https://shaka-player-demo.appspot.com/docs/api/tutorial-drm-config.html
 [eme_https]: https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
 [wrapping]: https://shaka-player-demo.appspot.com/docs/api/tutorial-license-wrapping.html
-[including mux.js]: https://github.com/google/shaka-player/blob/967f3399/demo/index.html#L39
+[including mux.js]: https://github.com/shaka-project/shaka-player/blob/967f3399/demo/index.html#L39

package/docs/tutorials/index.json

@@ -18,6 +18,7 @@
   { "offline": { "title": "Offline Storage and Playback" } },
   { "fairplay": { "title": "FairPlay support" } },
   { "application-level-redirects": { "title": "Application-Level Redirects" } },
+  { "selenium-grid-config": { "title": "Selenium Grid Config" } },
   { "faq": { "title": "Frequently Asked Questions" } },
   { "upgrade": {
       "title": "Upgrade Guide",

package/docs/tutorials/plugins.md

@@ -108,7 +108,7 @@ python build/build.py +@complete -@polyfill
 python build/build.py +@complete -@polyfill -@text
 ```
 
-To see the complete list of categories, its in [`build/types/`](https://github.com/google/shaka-player/tree/master/build/types)
+To see the complete list of categories, its in [`build/types/`](https://github.com/shaka-project/shaka-player/tree/main/build/types)
 
 #### Build Configs
 
@@ -177,5 +177,5 @@ If you have a great plugin that you'd like to contribute back to the community,
 we'd love to hear from you.  You can get in touch via our [issue tracker][] to
 discuss it, and once it's ready, you can send a [pull request][] on github.
 
-[issue tracker]: https://github.com/google/shaka-player/issues/new/choose
-[pull request]: https://github.com/google/shaka-player/pull/new/master
+[issue tracker]: https://github.com/shaka-project/shaka-player/issues/new/choose
+[pull request]: https://github.com/shaka-project/shaka-player/pull/new/main

package/docs/tutorials/selenium-grid-config.md

@@ -0,0 +1,122 @@
+# Selenium Grid Config
+
+Shaka Player's test runner (Karma) can be directed to run tests on a Selenium
+grid.  For this, you need a config file that defines what browsers are
+available, and how to request them via WebDriver.
+
+For a fully-worked, detailed example, see the config for the private grid in
+our lab at [build/shaka-lab.yaml](https://github.com/shaka-project/shaka-player/blob/main/build/shaka-lab.yaml)
+
+## Usage
+
+```sh
+python build/test.py \
+    --grid-config grid-config.yaml \
+    --grid-address selenium-hub-hostname:4444
+```
+
+## Syntax
+
+The config file is written in YAML.  We chose YAML because it has two big
+advantages over JSON:
+
+1. You can add comments
+2. You can define variables (with YAML "anchors") to factor out common configs
+
+### Variables
+
+You can define any common variables in the `vars` section, then refer to them
+elsewhere.  For example:
+
+```yaml
+vars:
+  # Generates an "anchor" with the given name.  Later, you can inject the
+  # contents of the variable with "*name".
+  firefox_config: &firefox_config
+    moz:firefoxOptions:
+      # Override Firefox default preferences in the temporary profile created
+      # for each test run.
+      prefs:
+        # Overrides Selenium's explicit default setting, to allow Firefox to
+        # install the Widevine CDM on demand.
+        media.gmp-manager.updateEnabled: true
+        # Overrides Firefox's Linux-specific default setting to disable DRM.
+        media.eme.enabled: true
+
+# These three browser definitions share the same config from above.
+FirefoxMac:
+  browser: firefox
+  os: Mac
+  extra_config: *firefox_config
+
+FirefoxWindows:
+  browser: firefox
+  os: Windows
+  extra_config: *firefox_config
+
+FirefoxLinux:
+  browser: firefox
+  os: Linux
+  extra_config: *firefox_config
+```
+
+### Browsers
+
+Each top-level key in the config file (except for `vars`) is the name of a
+browser made available to Karma.  Within each of those keys are the following:
+
+ - `browser`: The name of the browser.  This is case-sensitive, and must match
+       the string and case used by Selenium.
+ - `os` (optional): The name of the OS.  This is case-INsensitive, and must
+       match the name of the platform as used by Selenium.  For Generic
+       WebDriver Server, this can be omitted or set to the name of the host
+       platform.
+ - `version` (optional): The version of the browser.  This is case-sensitive,
+       and must match the string and case used in the Selenium node config.
+ - `disabled` (optional): If true, this browser is disabled and will not be
+       used unless explicitly requested.
+ - `extra_config` (optional): A dictionary of extra configs which will be
+       merged with the WebDriver launcher config in Karma.
+
+Examples of basic desktop browsers definitions:
+
+```yaml
+ChromeMac:
+  browser: chrome
+  os: Mac
+
+FirefoxMac:
+  browser: firefox
+  os: Mac
+
+Safari:
+  browser: safari
+  os: Mac
+
+SafariTP:
+  browser: safari
+  os: Mac
+  extra_config:
+    safari.options:
+      technologyPreview: true
+
+ChromeWindows:
+  browser: chrome
+  os: Windows
+
+FirefoxWindows:
+  browser: firefox
+  os: Windows
+
+Edge:
+  browser: msedge
+  os: Windows
+
+ChromeLinux:
+  browser: chrome
+  os: Linux
+
+FirefoxLinux:
+  browser: firefox
+  os: Linux
+```

package/docs/tutorials/welcome.md

@@ -35,11 +35,13 @@ To get the sources and compile the library, you will need:
     * _NOTE: A local web server is required because browsers place restrictions
       on applications from file:/// URLs._
 
+If you just want to compile for export to other projects, you might consider compiling through a docker container. (see compile instructions)
+
 To quickly install these prerequisites on Ubuntu or Debian, you can run this
 script:
 
 ```sh
-curl https://raw.githubusercontent.com/google/shaka-player/master/build/install-linux-prereqs.sh | bash
+curl https://raw.githubusercontent.com/shaka-project/shaka-player/main/build/install-linux-prereqs.sh | bash
 ```
 
 We do not provide detailed instructions or scripts for installing these
@@ -51,7 +53,7 @@ links above to download and install the prerequisites manually on any OS.
 #### Get the source
 
 ```sh
-git clone https://github.com/google/shaka-player.git
+git clone https://github.com/shaka-project/shaka-player.git
 cd shaka-player
 ```
 
@@ -62,6 +64,12 @@ cd shaka-player
 python build/all.py
 ```
 
+Alternatively you can use a docker container:
+```sh
+cd build/docker
+docker-compose run --rm shaka-compiler
+```
+
 The output is:
  * dist/shaka-player.compiled.js (compiled bundle)
  * dist/shaka-player.compiled.debug.js (debug bundle)

package/externs/shaka/text.js

@@ -349,6 +349,16 @@ shaka.extern.Cue = class {
      */
     this.nestedCues;
 
+    /**
+     * If true, this represents a container element that is "above" the main
+     * cues. For example, the <body> and <div> tags that contain the <p> tags
+     * in a TTML file. This controls the flow of the final cues; any nested cues
+     * within an "isContainer" cue will be laid out as separate lines.
+     * @type {boolean}
+     * @exportDoc
+     */
+    this.isContainer;
+
     /**
      * Whether or not the cue only acts as a line break between two nested cues.
      * Should only appear in nested cues.