A previous PR, #5950, added support for variants that contain multiple
different codecs.
It was supposed to also add support for variants with multiple
mimeTypes, but that part didn't work correctly. This reworks a lot of
#5950 and #6047, to change how they handle such complicated variants.
This has the side-effect of allowing the stream utils to differentiate
between content that has multiple codecs because of type changes, and
content that has multiple codecs because of being muxed video+audio.
Fixes#6010
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
The state engine mechanism, designed for the player class, was
over-engineered. The structure of the class makes debugging player
errors unnecessarily annoying, by obfuscating the code-path the error
followed, and in general
has created a significant amount of technical debt.
This changes the player to use an async-await setup for the top-level
operations, laying things out much more cleanly
and linearly.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Shaka in most of places normalizes tracks' language code to be compliant with ISO 639-1 when possible. However, it does not do that all the time (i.e. normalization is missing in MSS parser) and there is no way to get value that has been explicitly set in a manifest. Moreover, documentation is misleading, as it claims that value is taken directly from a manifest.
Normalization should take place, specifically to easify PeriodCombiner algorithm and also to not break existing applications.
However, original value can be desired for some implementations.
This PR introduces new field to get original language value from the manifest.
Now that DRM info is only parsed after playback has begun, the manifest
parser needs to communicate back to the other components that new DRM
info is available after lazy-loading a playlist.
Closes#4622
fix: Fix HLS dynamic to static transition
- Keep maxSegmentEndTime_ updated in PresentationTimeline by calling
notifySegments on each HLS playlist update, so that the seek range
doesn't revert to the original playlist size when it becomes
static.
- Wait to change the presentation type to VOD until after _all_
active playlists have an ENDLIST tag, to avoid missing the final
segments in one type or the other.
- Stop updating the playlists after transition to VOD.
- Update the MSE duration at exactly the same time as we transition
to VOD, to avoid a loophole where the UI knows it's VOD, but
doesn't have any way to get the correct duration. Previously, this
state would persist until the final segments were appended.
Closes#4431
If a storage operation is aborted (via API, not via closing the page),
this will now be cleaned up from the database. More work is needed to
find and remove orphaned segments in the database.
Related to #4166 and follow-up to PR #4176.
By waiting for all segment data to be written to the database before updating the manifest, we can speed up offline storage in the foreground by ~87%.
Closes#4166
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 adds code to allow Shaka Player to play media in sequence
mode, an alternate playback mode that makes the browser ignore
media timestamps, when playing HLS media.
This is important for containerless media formats, as they do not
contain such timestamps.
Changing HLS to not require timestamps also means that we no
longer need to fetch media segments in order to get the start
time, which should lower bandwidth usage and startup delay.
In initial tests, on a simulated 3G network, load latency went down
from an average 3.16s to 2.61s on the HLS version of "Big Buck Bunny:
the Dark Truths of a Video Dev Cartoon"; an improvement of about 17%.
Issue #2337
Change-Id: I507898d74ae30ddfb1bddf8dce643780949fbd9b
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>
This refactors the storage mechanism so that the method that
attaches a segment to the manifest is be a stateless async method,
and no longer needs to be in the same session as the method that
stored the manifest.
This is the end of phase one of the work towards allowing Shaka
Player to use background fetch to store assets offline.
This change will allow a service worker to store the segments as
they are downloaded, without having to keep the Shaka Player
instance alive.
Issue #879
Change-Id: I6a3545c57bacaf7229fe8c32669e88c6cc4e4138
It is unlikely that we will be able to load DRM sessions inside
the service worker for BG fetch. However, sometimes we have to get
the DRM keys from the init segments.
This changes Storage.downloadSegments_ to download the init segments
first if it looks like they will contain needed init data to create
license requests.
This also fixes a typo that was preventing us from getting init data
from segments, and adds a test that would catch that issue.
Issue #879
Change-Id: Ide859ed0eb2d9208150787f14d915135df681d96
This changes the order that things happen when the offline storage
mechanism stores a manifest, so that the manifest is made and the
segments are downloaded in separate steps.
This is in preparation for adding background fetch support.
Issue #879
Change-Id: I4451db839b654f6134f06a58c240a9ca98d31a4e
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
When we use decodingInfo() with the drmInfo of the variants to get media
keys, the decodingInfo result can tell us whether the variant's DRM is
supported by the platform. Thus, filterManifestByDrm_() is no longer
needed with MediaCapabilities enabled.
Issue #1391Closes#3334
Change-Id: I34fbb3e11877f02cae1d435e9dbf274ce0e691dc
In DrmEngine, previously we created MediaKeySystemConfiguration for the
variants, and called navigator.requestMediaKeySystemAccess() to get the
mediaKeySystemAccess, and set up MediaKeys.
Now we can use the mediaKeySystemAccess from the decodingInfo results of
the variants directly to set up MediaKeys.
Issue #1391
Change-Id: Id93a5e2fed7f6827317ae11644967185fc0cffbd
Make the DASH keySystems configurable, so that any developer could chose to opt-in for recommendation based on DASH DRM UUID.
Example:
player.configure({
dash: {
keySystemsByURI: {
'urn:uuid:9a04f079-9840-4286-ab92-e65be0885f95': 'com.microsoft.playready.recommendation',
}
}
});
Álvaro Velad Galván
ncocaign
Wojciech Tyczyński
theodab
Casey Occhialini
Joey Parrish
Álvaro Velad Galván
Michelle Zhuo
Vincent Valot