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
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
In DASH with SegmentTemplate and a fixed duration, indexes would
continue to grow so long as they had not ended. However, this was
based on a callback which captured an end time variable that could
become out-of-date in a multi-period live stream.
This prevents indexes from continuing to grow indefinitely by always
using the most up-to-date end time for the period.
This also fixes eviction of segments in the same scenario, which
fixes SegmentIterator access and related assertions later.
Issue #3354 (partial fix)
b/186457868
Change-Id: I2b34ee52dd12b59e1c1237258050b50e3189bee3
In live streams, we can evict segments outside the availability window
faster than they disappear from the manifest. If that happens, we used
to evict them several times (add them back in and then evict again).
This caused the eviction counter to increase beyond what it should be
and we had trouble finding segments afterwards.
Closes#3139.
Change-Id: Iafebfaf8e1e9ebb09a64cdf7e09a882115fd8eb6
When a Period has segments outside the Period, we evict them during
manifest parsing. However, this eviction shouldn't affect the position
of segments since these never existed.
Fixes#3230
Change-Id: I0494d9c38b51857967ed4b572475ddcc37f815a0
When a multi-period DASH manifest contains periods which are in the
future (described in the manifest, but with all segments past the
current end time of the segment availability window), the segments
generated for SegmentTemplate were invalid. Not all DASH multi-period
content describes unavailable future periods, so many providers using
DASH would not see this issue. This bug affected v3.0.0 - v3.0.7.
To fix this, we change the "next position" calculation for updates to
clamp to the minimum valid position. This avoids creating segment
references with negative position numbers for these future periods.
When the segment availability window moves to include this period, we
will then start generating segments for it (starting at position 0 or
whatever the startNumber attribute is for this period).
However, the contract for updateEvery() in SegmentIndex was such that
the timer would stop if the list of references was every empty. This
was meant to handle the case in which all segments were evicted, but
it could be triggered instantly on these "future" periods, for which
no segments exist yet in the availability window. To resolve this,
the contract was changed so that the updateEvery() callback must
explicitly signal a stop by returning null instead of an array of
segment references.
Bug: 179025415
Change-Id: I56a2826fd3aea3f69da7b8bf4fa7629562d63506
We found the issue within our app with the latest Chromecast CAF receiver update (November 22, 2020) that use Shaka 3.0.x. With our live stream containing 90 minutes of buffer, we notice high level of buffering issue with our customer.
It seems that the createUris callback was holding onto a parsing context in each reference.
Closes#3038
When Representations have different BaseURLs, segment URLs generated
for SegmentTimeline were always using the BaseURL of the last
Representation because the wrong parsing context was being used. This
fixes the issue and adds a regression test.
This only affected v3.0.0.
Closes#2650
Change-Id: I04df950b5d3205e102f9c74f52ece9773ce92282
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
This creates a new utility used by DashParser and old offline DB
formats to combine Streams across Periods. This allows multi-Period
DASH content to be played without period-specific structures in the
manifest format, StreamingEngine, or Player. This also makes the
Tracks stable across Periods.
Closes#1339 (flatten periods)
Closes#1698 (rapid period transitions issue)
Closes#856 (audio change causes bitrate change)
Change-Id: Icb04c8e47e36eacf7ac024a5063130d85a115e54
As part of Period-flattening, I'm trying to remove our dependence on
the "position" field of SegmentReference. With that eliminated, we
can more easily concatenate Arrays of SegmentReferences without
modifying them.
- Make SegmentIndex iterable
- Add specialized seek() and current() methods to SegmentIterator
- Remove position from SegmentReference
- Make positions in SegmentIndex API stable without field in
reference
- Remove brittle hard-coded positions in tests (except SegmentIndex
tests, where they would be hard to avoid in testing methods
separately)
- Use SegmentIterator in StreamingEngine to track the next segment
between switches
Issue #892 (refactor StreamingEngine)
Issue #1339 (period flattening)
Change-Id: I666cc21249c34ee6cbc138a59109d9f1159fa127
The recent DASH refactor broke the details of multi-period segment
references for SegmentTemplate+duration.
This change introduces a corrected universal model for generating
segment references for fixed-duration SegmentTemplate content. It has
been tested with a variety of streams from third-parties, most notably
the DASH-IF's live simulator.
Issue #1339 (flatten periods)
Issue #892 (refactor StreamingEngine)
Closes#2111
Bug: 28087927
Change-Id: Ife4e9ae2bb726e24e97dfe153882dabba4c03f2d
In an in-progress DASH stream (in which the content is static, but not
fully available yet), we will need to produce additional segment
references as time progresses. This was broken recently during
refactors for period flattening, when SegmentTemplate with a fixed
duration was changed to use a SegmentIndex instead of generating
references on-demand.
Issue #1339 (flatten periods)
Issue #892 (refactor StreamingEngine)
Change-Id: I0239335fa7c569063f06f4416982fc5ca7d5873d
This changes the eslint rule to enforce a strict pattern for the
argument comments. The comment must appear before the argument and
must be /* foo= */. This still ignores line comments.
Change-Id: I3afb01c65e1088eda13facb3aeeaa7595a2f5aee
This is a step along the way to flattening periods, and also
simplifies a few small things in StreamingEngine and tests.
Issue #1339 (flatten periods)
Issue #892 (refactor StreamingEngine)
Change-Id: Ie17cd5e15ed6ec9290a918c3a69c05c74581e0fc
SegmentReference used to have presentationTimeOffset, which,
subtracted from the period start time, was then _added_ to the
timestamps in the segment by MediaSource.
Now, SegmentReference has a timestampOffset field, which is exactly
what MediaSource's timestampOffset field is set to on the SourceBuffer
before this segment is appended. For DASH, this is periodStart minus
presentationTimeOffset.
This also adds append window start & end times to the
SegmentReference. Now segments can be appended to SourceBuffers
without reference to the period.
Note that start & end times of the SegmentReference in each segment
index are still relative to the period. This will change in a
follow-up.
Issue #1339 (flatten periods)
Issue #892 (refactor StreamingEngine)
Change-Id: I9d54eb2b529ec643c9475b8e9d218c3e2e826a26
Álvaro Velad Galván
Dave Nicholas
Cristian Atehortúa
theodab
Wojciech Tyczyński
Albin Larsson
Joey Parrish
Nick Crast
Casey Occhialini
Álvaro Velad Galván
Aidan Ridley
Michelle Zhuo
Joey Parrish
ismena
Jacob Trimble
Dany L'Hébreux