## Background:
The native DOM Parser can perform poorly on some older devices, this
approach is faster on newer devices but is considerably better on older
devices.
This PR replaces the usage of the DOM Parser for DASH, MSS, VTT and
TTML.
The draw back of this approach that it does not include any validation
at the cost of better performance.
In our streams we have guarantee that every track will have a single
match in every period. This change allows `PeriodCombiner` to take
benefit of this knowledge.
I was testing `PeriodCombiner.combinePeriods()` performance of mentioned
changes on Tizen 2021 on 2 streams and I've got following results:
| content | upstream | proposed changes |
| - | -: | -: |
| stream 1 | 17 ms | 12 ms |
| stream 2 | 191 ms | 98 ms |
Both streams are VOD.
Stream 1 has 18 periods with 6 video & audio tracks in each.
Stream 2 has 18 periods with 6 video tracks & 36 audio tracks in each.
Summary of changes:
- create dummy streams during preparing arrays of input streams
- use hash map to quickly find perfect stream matches across periods
- hash map also automatically removes duplicates, so remove previous
logic for finding them
- check earlier are we trying to create output stream from dummy stream
- 2 changes from above also gives us a possibility to simplify
`areCompatible()` & `isBetterMatch()` methods
- reduce creation of spare collections when concatenating streams
- reduce conditional logic when possible
I was testing `PeriodCombiner.combinePeriods()` performance of mentioned
changes on Tizen 2021 on 2 streams and I've got following results:
| content | upstream | proposed changes |
| - | -: | -: |
| stream 1 | 23 ms | 17 ms |
| stream 2 | 484 ms | 191 ms |
Both streams are VOD.
Stream 1 has 18 periods with 6 video & audio tracks in each.
Stream 2 has 18 periods with 6 video tracks & 36 audio tracks in each.
With the addition of the changeType API for MediaSource, it is theoretically possible for a variant to change between multiple codecs for a given buffer, over the course of playback.
This adds support for the DASH player to stitch together periods which have such multi-codec variants, but only as a last resort. For example, if one period only has audio in aac, and another period only has opus audio, the player will now stitch those periods together as one, but if there is a throughline that does not involve changing codecs it will go for that instead.
Closes#5961
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>
This change reduces the amount of loops in dash parser, and improves
code readability, as checking config and creating an array of sets is in
a separate method now.
---------
Co-authored-by: Ivan Kohut <ivan.kohut@lamin.ar>
When we exported `PeriodCombiner` in
https://github.com/shaka-project/shaka-player/pull/5324 we added an
`@export` to `PeriodCombiner.Period`, and since then we've been testing
in our dogfood builds using shaka-player.compiled.debug, because we like
to get logs from dogfood. Everything was working great.
When we went to switch over to the production build, we realized that
`@export` on a `typedef` doesn't really work because the type gets
minified internally!!
This moves `Period` over to `extern` so that it does not get minified
and can be used externally.
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.
Add ColourPrimaries and MatrixCoefficients schemes as specified by
https://dashif.org/docs/DASH-IF-IOP-v4.3.pdf.
In particular, `ColourPrimaries` and `MatrixCoefficients` schemes were
considered "unrecognizedEssentialProperty", causing some
streams with valid manifests to discard the video track.
- Move TimeRange from shaka.dash.MpdUtils to
shaka.media.PresentationTimeline
- Move AccessibilityPurpose from shaka.dash.DashParser to
shaka.media.ManifestParser
With these changes, core Shaka Player can be built without the dash
module.
We (Sky/Peacock) required the ability to try a different ad stitched
manifest upon a manifest request update failure.
After the initial retry parameters (timeouts and retries) have been
exhausted, error immediately and not continue to retry with the same
manifest.
Fixes an issue where `createSegmentIndex()` creates a reference in
cached Stream and not on a new Stream. Now cached value is reused in
period flattening.
Updated assertion in Period Combiner to catch potential issues within
old approach.
Without this fix I've noticed problems around seeking on multiperiod
content after variant change.
This adds an optional parameter to request and response filters, of a
new enum called AdvancedRequestType.
This enum describes request types that are subtypes of the basic types.
For example, INIT_SEGMENT is a type of SEGMENT.
This gives users more information about the type of the request, while
maintaining backwards compatibility.
Closes#4966
When DAI adds ad segments faster than real-time, the availability
windows gets messed up, and some assertions in SegmentIndex break.
This locks down the presentation start time after the initial manifest
is parsed, so that the availability window is stable throughout
playback.
b/233075535
EventStreams in DASH generate TimelineRegionInfo objects, which are
then stored in the RegionTimeline and RegionObserver classes. But
DashParser would add all regions to RegionTimeline, even if they would
be quickly removed again, and RegionObserver would cache some regions
from the timeline without ever removing them.
This fixes the issue from both of those directions. DashParser will
now ignore regions that are outside the DVR window (and therefore
would soon be removed from RegionTimeline), and RegionObserver listens
to an event on RegionTimeline to clean up its own storage when regions
fall outside the DVR window during playback.
Closes#3949 (memory leak in DASH live streams with inband EventStream)