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>
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
If server-side ad segments aren't aligned, AV could get out of sync by
accumulating errors in the timestampOffset of the SourceBuffers.
This improves the issue by tracking discontinuity boundaries and
resetting timestampOffset to theoretical segment start times when a
boundary is crossed.
Issue #4589
We now have an explicit fallback to sync on sequence numbers if
PROGRAM-DATE-TIME is explicitly ignored. This is more robust than
relying on whatever happens to be first in the various media
playlists.
This also refactors how PROGRAM-DATE-TIME is used. The date will now
be used to adjust segment reference start times, rather than
overriding the time used in StreamingEngine. (This was hard to
discover when reading the HLS parser.) Now all HLS sync logic is in
the HLS parser.
Closes#4287
Parse EXT-X-GAP HLS tag and add a status enum to shaka.media.SegmentReference.
shaka.media.SegmentReference.Status.AVAILABLE --> Normal behaviour
shaka.media.SegmentReference.Status. UNAVAILABLE --> Related to https://github.com/shaka-project/shaka-player/issues/2541
shaka.media.SegmentReference.Status. MISSING --> EXT-X-GAP in HLS
Note: only the parsing is added, but the functionality is not yet implemented.
Issue https://github.com/shaka-project/shaka-player/issues/1308
This makes the HLS parser read the EXT-X-PROGRAM-DATE-TIME value
on manifests, and use it to make sure that segments are inserted at
the correct place in the timeline, when in sequence mode.
Issue #2337
This makes the HLS parser honor more attributes for image tracks.
It also makes some changes to player.getImageTracks, so that the
returned track shows the size of a single thumbnail rather than the
entire sheet.
Closes#3840
Change-Id: I2ae096f455864201e08a85e29f0f02a3e06eb07f
Thumbnail segments may be structured for a certain grid size and
duration, but the segment references may have their duration truncated
due to the end of a period or the end of the presentation. This was
causing us to calculate the wrong duration for those individual
thumbnails, and therefore return the wrong
thumbnail.
We also did not have any way to indicate to an application how long a
thumbnail should be shown.
This fixes the duration calculation by retaining the original,
untruncated duration in SegmentReference. This also exposes startTime
and duration information on the Thumbnail object, so that applications
know when/where and how long to show a given thumbnail.
Closes#3517
Change-Id: I84aa7705a19691fc6ae68eee9944fecbd7067fe0
Previously, SegmentReference.getUris was listed as public field,
but not actually exported. For an object that does not have externs,
there is no way to ensure that a member variable is not renamed.
So, instead, this CL makes an exported public getUris method, that
wraps the getUrisInner member variable. This allows for the method
to be exported, without having to make an extern for the class.
Closes#3096
Change-Id: I847439c444021bcf6af2b210f7138a51ba164d71
LL-HLS hints a resource that is needed to playback in the upcoming
update. It's available for request, and may not be available for
download yet.
A preload hinted resource is either a partial segment, or an init
segment. If it's an init segment, treat it the same way as the Map tag
in ManifestTextParser.
A preload hinted segment contains no duration information, so its
start time and end time are the same. It will be replaced by a partial
segment in the next update.
We should fetch and append the preload hinted segment the same way as a
partial segment.
Issue #1525
Change-Id: I1e30f216ecdc843c3cd01681629a8886383d0b22
Changed SegmentIndex and SegmentIterator to iterate through regular and
Partial SegmentReferences.
SegmentIndex:
merge(): Find all the old segments after the first new segment's start
time, and replace the old ones with new segments.
SegmentIterator:
Use the currentPosition and currentPartialPosition pointers to iterate
through the two-layer arrays.
current(): Get the current SegmentReference, and get its current Partial
SegmentReference if it has a Partial Segment list. Move to the next
regular segment if we reached the end of the current segment's partial
list.
next():
If the regular segment has a partial list, go to the next Partial
Segment. If reached the end of the current partial list, move to the
next regular segment.
If the regular segment doesn't have a partial list, move to the next
regular segment.
Issue #1525
Change-Id: Icb7f49e50314f15ea40bf3a74d008191ed1a9a6c
If a segment has partial segment tags, create a SegmentReference for
each partial tag, and add the list of partial SegmentReferences to the
parent SegmentReference as an attribute.
If the parent segment contains the segment tag(EXTINF tag), use the
duration information from EXTINF tag to create the SegmentReference.
Otherwise, calculate the parent segment's duration based on the partial
segments' durations.
Issue #1525
Change-Id: I946cc007aad2ff911b69bf1c6a46df145452bfaa
This fixes all the license headers in the main library, which corrects
the appearance of the main license in the compiled output.
It seems that the `!` in the header forces the compiler to keep it in
the output. I believe older compiler releases did this purely based
on `@license`.
Issue #2638
Change-Id: I7f0e918caad10c9af689c9d07672b7fe9be7b2f3
Various issues with the nullability of number types led to various
fixes, including:
- defaulting a nullable number to 0 to avoid propagating a null value
through calculations
- adding an assertion or runtime check that something is not null
- moving an existing null check to before the calculation
- returning early on null during an iteration
- changing a nullable number to non-nullable
- defaulting to NaN instead of null
These issues were caught by a compiler upgrade.
Issue #2528
Change-Id: I86d516c74a42ee3624c33d7513d2d4c76d3ea589