Below are the changelog entries for each deprecated feature removed by this commit.
-----
feat(config)!: `manifest.dash.defaultPresentationDelay` has been replaced by `manifest.defaultPresentationDelay` (deprecated in v3.0.0)
feat(config)!: Configuration of factories should be plain factory functions, not constructors; these will not be invoked with `new` (deprecated in v3.1.0)
feat(player)!: `shaka.Player.prototype.addTextTrack()` has been replaced by `addTextTrackAsync()`, which returns a `Promise` (deprecated in v3.1.0)
feat(ui)!: `shaka.ui.TrackLabelFormat` has been renamed to `shaka.ui.Overlay.TrackLabelFormat` (deprecated in v3.1.0)
feat(ui)!: `shaka.ui.FailReasonCode` has been renamed to `shaka.ui.Overlay.FailReasonCode` (deprecated in v3.1.0)
feat(offline)!: `shaka.offline.Storage.prototype.store()` returns `AbortableOperation` instead of `Promise` (deprecated in v3.0.0)
feat(offline)!: `shaka.offline.Storage.prototype.getStoreInProgress()` has been removed; concurrent operations are supported, so callers don't need to check this (deprecated in v3.0.0)
feat!: `shaka.util.Uint8ArrayUtils.equal` has been replaced by `shaka.util.BufferUtils.equal`, which can handle multiple types of buffers (deprecated in v3.0.0)
feat(manifest)!: `shaka.media.SegmentIndex.prototype.destroy()` has been replaced by `release()`, which is synchronous (deprecated in v3.0.0)
feat(manifest)!: `shaka.media.SegmentIterator.prototype.seek()`, which mutates the iterator, has been replaced by `shaka.media.SegmentIndex.getIteratorForTime()` (deprecated in v3.1.0)
feat(manifest)!: `shaka.media.SegmentIndex.prototype.merge()` has become private; use `mergeAndEvict()` instead (deprecated in v3.2.0)
feat(plugin)!: `AbrManager` plugins must implement the `playbackRateChanged()` method (deprecated in v3.0.0)
feat(plugin)!: `shaka.extern.Cue.prototype.spacer` has been replaced by the more clearly-named `lineBreak` (deprecated in v3.1.0)
feat(plugin)!: `IUIElement` plugins must have a `release()` method (not `destroy()`) (deprecated in v3.0.0)
This change fixes tests on Chromecast by loading tests later in the process. Test scripts are now dynamically inserted by boot.js, rather than loaded by Karma. The bootstrapping code then awaits the completion of that before starting the Karma frameworks (Jasmine) to run the tests.
This also removes the use of goog.provide/goog.require in tests and test utils. We don't need to load test utils or library sources dynamically in each test, and this gives us more explicit control over script loading and ordering.
Closes#4094
We filter out text streams that are duplicates, before persenting
them to the end user. A duplicate is detected by checking if
various values on the streams are the same.
However, we were not checking for bandwidth. This could lead to a
text stream being marked as a duplicate if it had the same language,
label, etc as another, even if they did not contain the same text.
This changes the utility to also check bandwidth.
Closes#3724
The tb (top bitrate) property should honor bitrate/size ABR constraints and only report the top playable bitrate.
The tb property should only report the bandwidth for that segments type (audio, video, muxed).
Fix incorrect top bitrate CMCD reporting by:
Honoring the player's current bitrate/size ABR constraints.
Only reporting the bandwidth for that segments type (audio, video, muxed).
Fixes#3851
Co-authored-by: Dan Sparacio <daniel.sparacio@cbsinteractive.com>
Revert "fix: Work around override of MediaCapabilities polyfill in Apple browsers (#3668)"
This reverts commit 31c0cd4b8c.
Fixes#3843 (usage of Shaka without polyfills)
Re-opens #3530 (MediaCapabilities polyfill not working on Safari)
Change-Id: Ib5aff1b38759e1a39200332f3f07d3d6bd3bd2e1
Fixes#3729
If the video variant stream contains information about `hdr`, then we now use that to provide a value for `transferFunction`, when constructing the [`VideoConfiguration`](https://w3c.github.io/media-capabilities/#videoconfiguration) object used to get decoding info from media capabilities API.
The following applies:
```js
switch (video.hdr) {
case 'SDR':
mediaDecodingConfig.video.transferFunction = 'srgb';
break;
case 'PQ':
mediaDecodingConfig.video.transferFunction = 'pq';
break;
case 'HLG':
mediaDecodingConfig.video.transferFunction = 'hlg';
break;
}
```
Add support for including Common Media Client Data (CMCD) in outgoing requests.
Fixes#3619
NOTE: The following fields have not been implemented: rtp, nrr, nor, dl
Co-authored-by: Dan Sparacio <daniel.sparacio@cbsinteractive.com>
When unboxing TKHD, the reader read int64 as trackId instead of int32. Thus unable to find matching timescale when doing TFHD unboxing. Therefore when parsing MDAT, the default timescale will be used which is 90000. All CC timestamps will then be incorrect.
This also fixes "Shaka Error MEDIA.VIDEO_ERROR (3,,PIPELINE_ERROR_DECODE: Failed to parse H.264 stream)" error when playing DASH MP4 H.264 streams with CEA-608 CC embedded. It's likely that the VDA bundled in Chromium-based browsers have already included EPB detection & prevention. If we let the player to remove the byte, VDA will complain about stream conformance.
Closes#3502
If it's srcEquals, the 'type' element of the input object when querying mediaCapabilities should be 'file'. Otherwise it should be 'media-source' .
Issue: #3530
When playing multiperiod content, we should not require thumbnails to
be present in every period. This fixes this case and adds a
regression test.
Closes#3383
Change-Id: I4403a1b8670cffcc46de32470e2d830dc199c9f4
We filter out duplicate streams for all other types, so we should do
this for images, as well.
This also updates all PeriodCombiner test cases to include the
imageStreams property.
Issue #3383
Change-Id: I63355f85d4e12bd25c1cadce29a040d17c4e7d61
Matching image streams across periods was not working correctly with
multiple streams per period. Matching was done on MIME type only,
meaning there was no way to differentiate multiple streams.
Resolution is a better signal, so this uses the same logic as for
video resolution in thumbnail resolution matching.
This also adds extra error logs that helped track down the issue, and
fixes some comment typos.
Issue #3383
Change-Id: I067de59c222a165d58926646f53fa61862853377
Currently a full chain comparison is done, but in video and audio codecs, you may want H.265/VP9 with no profile preference, with this change it is possible to do this.
Examples:
'hvc1' instead of 'hvc1.1.2.L123.80' and 'hvc1.1.2.L153.80'
'vp09' instead of 'vp09.00.40.08.00.02.02.02.00'
Adding the "preferredVideoCodecs" and "preferredAudioCodecs"
configuration, so that the application can set their own preferences
when choosing a codec.
Issue: #2179
Change-Id: Ib56aec10613dda9b7dce8e465c5f1d81540c34fd
We'll allow users to configure the decoding attributes they prefer when
choosing codecs through the configuration. The attributes include
'smooth', 'powerEfficient' and 'bandwidth'.
For example, if the user configures the field as ['smooth',
'powerEfficient'], we'll filter the variants and keep the smooth ones
first, and if we have more than one available variants, we'll filter and
keep the power efficient variants.
After that, we choose the codecs with lowest bandwidth if we have
multiple codecs available.
Issue #1391
Change-Id: Ief3f6d8ff98fabff5ec99bb0365cdc6a36d2ab2d
MediaCapabilities supports 'vp09...' codecs, but not 'vp9'. Translate
vp9 codec strings into 'vp09...', to allow such content to play with
mediaCapabilities enabled.
Change-Id: Iff7ddae379efb8a9f0766c89a62b85a325f81e93
According to the output documentation, |MultiMap.get| is supposed
to return null "if no such key exists".
However, in the case that an object is added to the map and then
removed, |MultiMap.get| will return an empty array instead of null.
This inconsistency could be relevant for code that tests based on
the truthiness of the output, so this CL changes the remove method
to delete the array for a given key if it becomes empty.
This also adds unit tests for MultiMap.
Change-Id: I049fece920883e1cb10c319a3f00156be4ee011b
In StreamUtils, add a MediaCapabilitiesKeySystemConfiguration
for each key system for the encrypted variant passed to the
decodingInfo API, to get the mediaKeySystemAccess as a part of
the decodingInfo results.
We create a list of mediaDecodingConfigurations for each variant,
and call decodingInfo() with each mediaDecodingConfiguration to
get the mediaKeySystemAccess.
Eventually, we'll use the mediaKeySystemAccess from the
decodingInfo results to replace the call of
navigator.requestMediaKeySystemAccess() in DrmEngine. That will be
in the next CL.
Also, adding MediaCapabilties polyfill with mediaKeysSystemAccess.
Issue #1391
Change-Id: Ied4a27dd8a1ade43209bcf07f21f0c9b31c2693c
If we have a multiplexd content with audio and video, we combine
the audio and video codecs in the manifest parser.
For example, a multiplexed stream would be with:
mimeType="video/mp4", codecs="avc1.64001e,mp4a.40.2".
When sending the request to MediaCapabilities.decodingInfo(), we
need to have the config for both audio and video to get the result
as "supported".
The video config would be:
contentType='video/mp4, codecs="avc1.64001e"'.
The audio config would be:
contentType='audio/mp4, codecs="mp4a.40.2"'.
Issue #1391
Change-Id: I74a8580c07228e9600dc40c611ebd5d34f8cd7ee
In StreamUtils, use MediaCapabilities.decodingInfo() instead of
MediaSource.isTypeSupported() to check if the stream is supported.
MediaCapabilities.decodingInfo() takes an
MediaDecodingConfiguration object as input, and returns a Promise
with a MediaCapabilitiesInfo object. The returned object tells us
whether decoding the media is supported, smooth, and
powerefficient.
Steps:
1. Create a MediaDecodingConfiguration object for each variant as
the input.
2. Query the decodingInfo API with the config.
3. Get the 'supported' info from the decodingInfo result, to know
whether the variant is supported.
Issue #1391
Change-Id: I8fc2d3ec6a9868f38269d550d35f45c298faae98
Before this change, our codec choice only worked when all codecs had the same resolutions available.
When one codec had a different set of resolutions available, we might end up choosing the wrong one. This is because our choice was based on the average bandwidth of all resolutions for that codec. So a "better" codec with higher resolutions available would also end up having a higher average bitrate, and would be avoided.
This fixes the issue by only considering the resolutions that all codecs have in common, then taking the average bitrate among those to choose a codec.
Compare the codecs of two audio/video streams to decide whether they
are duplicate streams.
b/174040424
Change-Id: Ifde2068ddf9088f653280c013a1f3247cb7d45ba
If two audio streams in two periods have no roles while other audio
streams have, combine those with no roles.
Fixes#2785
b/172605645
Change-Id: I8aa4189c3ddc50257e0dbd72cae4840ae1d446f1
One subtlety of the filterDescribe() helper in our tests is that it
does not stop the body of the describe() block from being executed.
It only suppresses the execution of the various "before/after" blocks
and the tests in it(). So the new functional unit tests on factory
functions failed on IE, since the various definitions being eval'd for
the tests were set in the describe() body. Now they are created in
beforeAll(), which is supressed on non-ES6 platforms.
Change-Id: Ia92c7aa33a89e0217bf9a0394b43753f120ec16d
In v3.0, we changed our plugin interfaces so that all are factories
that return objects. We no longer call those with "new" as we did in
v2.5.
We provided backward compatibility and a deprecation warning to alert
applications to update their usage of those interfaces. However, this
compatibility shim was broken for ES6 classes, which behaved
differently than ES5 constructor functions.
This fixes the shim and adds regression tests. The tests were tricky
because we use Babel to transpile our tests, but we needed raw,
untranspiled code to define a class to test these features. So we use
eval and some associated trickery to get exactly the different kinds
of plugin registrations we intend to support. These tests are skipped
on non-ES6 browsers.
Fixes#2958
Change-Id: Ife8b63c0d89f4ea0aff085d3a4c156c4eb657604
Previously, to decode UTF8 content, we used the browser's
decodeUriComponent method. This worked in most situations, but it
would stop and error the moment it found an invalid UTF8 character.
This meant that a single poorly-encoded character inside a text stream
would cause the entire closed captions to fail to display.
In this CL, we switch to using the newer TextDecoder API, which
will instead replace invalid characters with an "unknown character"
code point, and continue parsing. This should make our text parsers
more robust when faced with bad encoding.
Closes#2816
Change-Id: Ibf2887e143d24d15a127bbcf2961539669580eea
Our period flattening logic used to keep creating new streams and variants
when encountering a certain type of content (same main content and slightly differing
sequence of ads). In time, this led to a performance drain, where more and more time
was spent processing the variants, leading to all kinds of delays.
This is the last change in the series, addressing the way we set stream properties
when concatinating streams.
Fixes#2716.
Fixes#2736.
Change-Id: I98ae692797d19344601d7a0c51d1e343dfe55e01
This is an MP4 Parser which extracts CEA-708 packets from Fragmented MP4 streams.
The Closed Caption Parser (shaka.media.ClosedCaptionParser) will own this MP4 Parser, and will initialize it and call it as shown. As data comes in, the parser will parse this data, and the caption packets data then be returned in a callback (on708Data), as shown. Here, a theoretical decoder (future pull request, mentioned as a Todo comment) will decode and extract the parsed captions from these packets.
Issue #2648
The period-flattening algorithm is run even on single-period content
if the manifest is dynamic, because we don't know if another period
will be added later.
As a failsafe, we should create one output per input for single-period
content, and we can ensure that no streams are unused by marking an
input stream as the "best match" for an output if they share the same
ID. That way, even if all other characteristics for two inputs are
the same, the input-to-output mapping for single-period content will
always be sane.
That ID-based logic was missing for text streams. This change
corrects that.
Closes#2646
Change-Id: I28c6c63d92bcf710ae0072783911f9e66ed78228