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
Example content protection tags parsed:
```xml
<ContentProtection schemeIdUri="urn:mpeg:dash:mp4protection:2011" value="cenc" cenc:default_KID="<default key id>" />
<ContentProtection value="ClearKey1.0" schemeIdUri="urn:uuid:e2719d58-a985-b3c9-781a-b030af78d30e">
<clearkey:Laurl Lic_type="EME-1.0">License Url</clearkey:Laurl>
```
The player parses the default key id and license url,
and sends a POST request to license url as per https://w3c.github.io/encrypted-media/#clear-key-request-format to retrieve the decryption key/s.
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)
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
Now we parse value of descriptor for urn:mpeg:mpegB:cicp:TransferCharacteristics in AdaptationSet to indicate hdr property on shaka.extern.Stream which seems equivalent to HLS definition given in VIDEO-RANGE attribute within EXT-X-STREAM-INF.
This is done by reading the supplemental / essential property in the parsing of AdaptationSet, then mutating the hdr property on shaka.extern.Stream if no hdr exists after parseRepresentation_.
The alternative considered was to parse all essential / supplemental properties on any shaka.dash.DashParser.InheritanceFrame and then carrying that through to the parseRepresentaiton_ function; this can be seen here. The problem with the alternative approach was that the essential property in the adaptation set would have had to have been "let through" on the assumption that we would parse it within the parseRepresentation_ method... But this to me seemed somewhat risky to change, and also looks messy with the empty else if condition, plus was a much larger change (with more calls to XmlUtils, though not familiar with how that is implemented, so not sure if there was any penalty because of that).
* Test expectation for HDR signalling via property
The test sets the expectation that we should be able to extract the
information of the TransferCharacteristics from the DASH
AdaptationSet. This should then get converted to the nomenclature
used in HLS for the VIDEO-RANGE attribute on EXT-X-STREAM-INF.
* Implement signalling of HDR capability through property descriptor
According to DASH-IF IOP v4.3 6.2.5.1. the transfer characteristics
can be declared at the AdaptationSet level via a supplemental or
essential property. In HLS the transfer characteristics are used to
determine the value of the VIDEO-RANGE attribute on the
EXT-X-STREAM-INF attribute, which is already used to indicate the
hdr property on the shaka.extern.Stream object. Therefore for
consistency we also add the same identification to the DASH parser.
* Added entry in AUTHORS and CONTRIBUTORS
Fixes#3726
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
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 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
This is for fixing a case in geo-redundant streams failover:
1. ShakaPlayer identifies DASH period based on period id
2. Period ids generated by two synchronized packager could be inconsistent temporarily in some negative scenarios
3. After the scenario the packagers resync at the live edge, but the inconsistency is preserved in the manifest for the length of the DVR window
4. When ShakaPlayer receives a new mpd with inconsistent period ids (i.e. jumping between mpds from two packagers), it might result in
- Wrong presentation time
- Wrong buffer ahead estimation
- Old segment references added into segment index
5. Consequently, playback gets stalled and requires end-user to refresh the player (i.e. VPF)
When caption languages are not present in the manifest (such as
"CC2=;CC3="), use "und", the language code for "undetermined".
Bug: 187442669
Change-Id: Ia129815efb2ae6b0ac6b655ac02398a7b1f70e68
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
Added support for efficient preprocessing of DASH manifest after they have been parsed into an XMLDocument
This is configured with the new manifest.dash.manifestPreprocessor setting.
This is need to efficiently repair manifests that are not compatible with Shaka Player.
Closes#3339
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
This was broken accidentally during MediaCapabilities refactoring.
This does not affect any release version.
The filtering step does two things: it applys the "restrictions"
config to the streams in the manifest, and it sends DRM init data to
DrmEngine for all streams in case new sessions need to be created.
For key rotation, it is critical to create new sessions in DrmEngine.
The init datas for new periods are added to existing streams when the
new period's streams are stitched onto the old ones.
The restrictions config should also be applied on manifest update,
since the update could have created some new streams with
characteristics outside of the current restrictions config.
Closes#3169
Change-Id: I716c2978c7394d7bb56227aa1854392a10eae058
In #3169, we discovered failing assertions for some multi-Period DASH
live streams. The failing assertion was meant to ensure that our
eviction logic was correct, and that our assumptions are maintained
properly.
Though the assertion failed, nothing was actually wrong with playback.
But the assertion itself should only fail if there is actually
something wrong.
With the choice between removing the assertion (since playback is
fine) or "fixing" the assertion (to avoid this false negative), I
chose to fix the assertion to retain the value of it to catch actual
bugs in our logic in the future.
The assertion specifies that you should not see evicted segments after
non-evicted segments. But eviction was only done when merging a
segment index with an old version of the same index (same
Representation and Period). When an update drops a Period from the
manifest, this means everything in that Period should be evicted. But
the eviction call wouldn't happen, because we had no new version of
the segment index to update the old one.
An extra call to evict() on each manifest update can fix the state
of the system so that our assertions pass.
The assertion message appeared identically in two different
assertions, so this change also rewrites the assertion messages to
differentiate them and to clarify their meanings.
Issue #3169
Change-Id: Ifeb7a1a8f48af704b028a22d987349209d7ee485
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
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',
}
}
});
Previously, we fill in the variants' drmInfos with the drm
configurations of |clearKeys|, |servers| and |advanced| during
initializing the DrmEngine, before we query the media keys.
Now we need to call |MediaCapabilities.decodingInfo()| to get the
mediaKeySystemAccess of the variants after the DrmEngine is
created and configured, and the drm values are filled in for the
variants, and before |DrmEngine.queryMediaKey_()|.
The steps would be:
0. StreamUtils.setDecodingInfo() should not be called before
DrmEngine is initialized and configured.
1. Create and configure DrmEngine.
2. Fill in drm values for the variants with configurations.
3. Call StreamUtils.setDecodingInfo() to get the decodingInfo of
the variants.
4. Use the decodingInfo results to set up the Drm mediaKeys in
DrmEngine.
5. When StreamUtils.filterManifest() is called, we can reuse the
decodingInfo results instead of calling decodingInfo again.
Previously we call filterManifest() when parsing the manifest, to
filter out the unsupported streams.
Now decodingInfo can tell us if a variant is supported and its
MediaKeys at once. When initializing the DrmEngine, we get the
decodingInfo results of the variants, and only use the supported
streams to set up the MediaKeys. After that, we filter the manifest
right after DrmEngine is initialized.
Thus, we can skip filterManifest() in manifest parsers.
Using decodingInfo to get media keys will be in the next CL.
Issue #1391
Change-Id: Ieb401a1e4dfbcc958f7a14fa96df546237b0f446
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
In DASH, a trick mode track can be associated with multiple regular tracks.
This fixes the parser to respect the whitespace-separated list of IDs instead of assuming just one ID.
Resolves#2978
Casey Occhialini
theodab
Álvaro Velad Galván
Joey Parrish
Gaetan Hervouet
Álvaro Velad Galván
sr90
Michelle Zhuo
theRealRobG
Aidan Ridley
Enson Choy
Joey Parrish
ismena
Vincent Valot
Jacob Trimble
Benjamin Wallberg
Dany L'Hébreux