There's devices out there that are not compliant with the MSE spec. Such
as halting MSE when a secondary init segment is appended (webOS 3), or
failing to transition from a plain to encrypted init segment (Tizen
2017). While we initially prefer content workarounds, it's a time
consuming and trial & error process. For some devices it might not be
worth investing time into finding a proper workaround due to low usage.
We're giving people an alternative by resetting MSE when needed
(configurable). dash.js offers somewhat similar behavior
[here](https://github.com/Dash-Industry-Forum/dash.js/blob/a656ec709e7f92f76b392bf196ee9883da7928ce/src/streaming/controllers/StreamController.js#L672),
where MSE is reset before applying an encrypted init segment.
This PR introduces `crossBoundaryStrategy` in `StreamingConfiguration`.
It can be configured as following:
- KEEP - we're keeping MSE active, this is the default and the current
behavior.
- RESET - we'll always reset MSE when it crosses a boundary.
- RESET_TO_ENCRYPTED - we reset MSE when it crosses an encrypted
boundary, and we keep MSE afterwards. Additionally, we're not going to
reset when we're crossing a plain to plain boundary.
Each initSegmentReference now holds an `encrypted` and `boundaryEnd`
value. When configured with a different value than KEEP,
`StreamingEngine` will be instructed to fetch and append segment
references up until the boundary of the currently applied init segment.
We detect whether we're at a boundary in a few ways:
- Listening to the HTML5 MediaElement's `waiting` event, this'll
indicate that we do not have enough buffer to advance. If we're pretty
close to the boundary, we assume we're at the boundary.
- Due to subtle differences in the segment alignments, waiting wasn't
reliable. When close to a boundary, a timer is fired with the assumption
that "we'll reach the boundary at soon". I've set the threshold to 1
second, when playhead is further than the threshold, we'll skip checking
whether an MSE reset is due.
The implementation relies on the added properties in the init segment
reference, and the concept of a "Period" is avoided in StreamingEngine
to ensure it's compatible with HLS too.
---------
Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Co-authored-by: Wojciech Tyczyński <tykus160@gmail.com>
`TimelineSegmentIndex` `fitTimeline` doesn't check if `templateInfo` is
null. This means it errors in this case when it tries to access the
`timeline` property. It now exits early if it's null
Adds a replacement for removed JSDoc checks from ESLint v9.
Additionally fixes lots of issues found in the JSDoc, such as:
- missing `@param`/`@return` annotations
- bad formatting
- params order
- param name in the same line as type definition (tried to disable it,
but it was causing other issues and we didn't have lots of places with
such formatting)
Minor fixes in code found by Closure Compiler after fixing JSDoc are
also included.
`$Time$` in SegmentTemplate should not be adjusted for
presentationTimeOffset or Period start. It should always match the
segment's own media timestamp as it appears in the manifest.
This PR excludes the use of text segments when calculating the max
segment size.
This is due to Shaka using the max value between the buffer behind and
max segment size.
The max segment size of text segments can be a lot larger than video
segments.
This can cause the buffer behind to be extremely large and is a
particular problem for low
powered devices, which have memory constraints.
---------
Co-authored-by: Joey Parrish <joeyparrish@users.noreply.github.com>
fix(DASH): Live DASH allows segment overlap in the updated manifest for
first new segments to avoid creating GAP with ms inaccurate manifest vs
Segment duration and start time
Fixes https://github.com/shaka-project/shaka-player/issues/7397
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>
To provide feature parity with the `DOMParser.getAttribute` API which
would unescape html entities for free this PR unescapes url strings
which come from node attributes.
In a similar vain to
https://github.com/shaka-project/shaka-player/pull/6198 which unescapes
child strings.
When recalculations of period end are made, it is possible that we will not be able to find last segment from period on low precision platforms. To mitigate it, try to use cached value of `periodEnd_` whenever possible.
Issue observed on Xbox One & Xbox Series.
## 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.
- 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.
A recent change to allow for on-demand segment references (#5061) ended up causing a
regression with an older issue (#4717), where the presence of an image track overrides
`bufferBehind` behavior.
This fixes the segment template handler to properly account for image tracks, once again.
This is a performance optimization intended to reduce the Video Start
Time for DASH streams, both VOD and Live, by reducing the amount of
processing done during manifest parse time. This is especially effective
for long multi-period assets, assets with many variants, or on low end
devices in general. I've provided some measurements showing the
performance improvements at the conclusion of this PR.
Currently, during manifest parse time for a Segment Template, Shaka will
loop through the entire timeline and create segment references for each
timeline entry. For a long asset, or an asset with many tracks, this is
a significant amount of processing.
I've created a new entity called the Timeline Segment Index that extends
the SegmentIndex interface. The purpose of the Timeline Segment Index is
to ingest a timeline during construction, and then use that information
to build Segment References only on demand. This removes the need to
parse the entire timeline and create all of the Segment References
during parse time.
The effects of this change aren't quite as apparent on desktop web
browsers, given their speed and power. This improvement really shines on
lower end TVs on assets with a long timeline.
DASH parsing speed-ups in some cases can be as much as 40%.
Co-authored-by: Joey Parrish <joeyparrish@users.noreply.github.com>
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
Before, when using SegmentTemplate or SegmentList, we would tell
the presentation timeline about new segments only when we saw a
new period or representation. This meant that, in live streams,
if new content was being added to the SegmentTemplate or SegmentList,
the presentation timeline was not being kept abreast of the changes.
Thus, if that stream were to then transition to VOD, the presentation
timeline would suddenly start to report that the current time was
beyond the end of the seek range, which caused playback to stop.
Closes#3675
Change-Id: I77ef00c5a86de9ebcb86f18f792084ed70f94e8d
This is a step prior to the closeSegmentIndex implementation.
In the DashParser, use a map of context id to stream instead of
context id to segment index when parsing SegmentList.
For Dash live content, every time we parse a manifest update, we
create a new Stream object, leaving the old stream with its old
segment index.
If we close the segment index and create it later again, we need
update the stream's segment index.
Change-Id: I7a3af3666ddb4e26362c40eeb82c3d050fafe3ee
Matthias
Álvaro Velad Galván
David Pfister
Wojciech Tyczyński
Joey Parrish
has992
Iragne
theodab
Dave Nicholas
Cristian Atehortúa
Wojciech Tyczyński
Albin Larsson
Nick Crast
Casey Occhialini
Álvaro Velad Galván
Aidan Ridley
Michelle Zhuo