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
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>
Only create the segment index for a stream when the stream is chosen.
When switching to another stream, release the segment index of the
original stream, and create the segment index of the new stream during
the next update.
Change-Id: I4d8a64e0e52d3e7edb71d402a97ab1dcd7f561dd
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)
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
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
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
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
The new eslint found many style errors which have now been corrected.
It also complains a lot about atomic update issues that do not seem to
exist, so that rule has been disabled.
This upgrade will allow us to adopt eslint's "id-denylist" instead of
the older "id-blacklist" rule, the name of which violates new Google
guidelines about respectful language.
Bug: 178203011
Change-Id: Ia65581b96e4dd1331f720fa396183dca020b9caf
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
With "lowLatencyMode" enabled, "rebufferingGoal" is set to 0.001, and inaccurateManifestTolerance is set to 0 by default. However, in some cases longer rebufferingGoal helps to avoid new rebuffering.
Besides "lowLatencyMode", this code change adds the "autoLowLatencyMode" config. When "lowLatencyMode" config is disabled and "autoLowLatencyMode" config is enabled, and the manifest provides low latency features, we automatically activate the lowLatencyMode.
If "lowLatencyMode" is enabled, "autoLowLatencyMode" has no effect.
Issue #1525
This pertains to #2648 (although this is a new feature, not a replacement) and #1404. A CEA-708 decoder that follows the CEA-708-E standard, decodes closed caption data from User Data Registered by Rec. ITU-T T.35 SEI messages, and returns them as cues in Shaka's internal cue format. Furthermore, this pull request fixes and cements some of the logic surrounding CEA-608 and CEA-708 tag parsing on the Dash Manifest Parser.
Format:
Similar to the CEA-608 decoder, cues are emitted in Shaka's internal format (lib/text/cue.js). This decoder makes use of nested cues. The top level cue is always a blank cue with no text, and each nested cue inside it contains text, as well as a specific style, or linebreak cues to facilitate line breaks. This also allows for inline style (color, italics, underline) changes.
Details:
- ASCII (G0), Latin-1 (G1), and CEA-708 specific charsets (G2 and G3) all supported.
- Underlines, colors, and Italics supported, set as a property on each nested cue.
- Positioning of text is supported. (Exception: In CEA-708 the default positioning is left, in this decoder it is centered.)
- Positioning of windows not supported, but relevant fields that could be used to support this are extracted and left as a TODO.
Previously, on manifest updates, embedded captions would vanish in
single-period live DASH streams. The problem was based on the
specific point in the load order that we added dummy text streams
to indicate the presence of embedded captions.
This modifies the PlayerInterface for manifest parsers to add a
new method passed in, makeTextStreamsForClosedCaptions, which
must be called by manifest parsers for new video streams.
This also completes an unfinished feature, where new video streams
which add new closed captions would not get corresponding
text streams.
Closes#2811
Change-Id: Iee7499ec950b363cf6839765cc2bd2d01743467d
1. Move the config field from ManifestConfiguration to StreamingConfiguration, since StreamingEngine will need it.
2. In manifest parsers, we get the value of lowLatencyMode config from the StreamingConfiguration.
Issue #1525
Change-Id: Iaa961b4e6799ecc1fcf3147b2fb992e86d4b043d
availabilityTimeOffset indicates that a segment is available for
download earlier than its availability start time.
1. This attribute can be on Period, Adaptation set, and Representation
level. The availabilityTimeOffset value of a segment should be the sum
of the values on different levels that apply to the segment.
2. We pick the minimum of the availabilityTimeOffset value among the
representations, reduce the distance from live edge by this value.
3. The availability window should be:
timeShiftBufferDepth + availabilityTimeOffset.
Doc: https://dashif-documents.azurewebsites.net/Guidelines-TimingModel/master/Guidelines-TimingModel.html
Tested with demo page, and the live latency got reduced by the availabilityTimeOffset value.
Issue #1525
Change-Id: Ibe87b0293b31e594f38f98c7caa9f5aeb134e40b
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 corrects/normalizes license headers in misc. files, such as
config files, docs, build tools, tests, and externs. This does not
affect the compiled output, and is only done for consistency.
Issue #2638
Change-Id: I9d8da2de55243b08d7df2b743aac73c6f15e858a
The usage of SegmentIndex in tests was correct, but the latest Closure
Compiler is more strict about nullability. We need to add assertions
and refactor to avoid nullable numbers where a non-nullable number is
required. We also need to add assertions for the nullability of
Stream.segmentIndex after createSegmentIndex() is called.
This was caught by a compiler upgrade.
Issue #2528
Change-Id: I5615ffa27b878f86739d507f993c2b66ae8eb61a
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
In these tests, SegmentBase referred to init segments that did not
exist. In period-flattening, we will be fetching segment indexes in
advance during parsing, so these bogus init segments would be fetched
and cause an exception. Using SegmentTemplate avoids this for tests
are not concerned with SegmentBase specifically.
Issue #1339
Change-Id: I54990e95480dfbb59154fca72f12d277eca25701
When period-flattening combines Streams, key ID arrays would get very
long with duplicates.
This changes keyIds in the manifest and offline structures from Array
to Set.
Issue #1339
Change-Id: I003d23e567efafa771ecd2ad597900181604ad18
Period-flattening will concatenate Stream objects, so this information
should be available per-Stream instead of at the Variant level.
Issue #1339
Change-Id: I96195fea48cab1e4a349b2ab0b16064a443e928a
This removes periods from the internal manifest structure and cleans
up code and tests accordingly. This leaves us unable to play
multi-period DASH & offline streams until the main period-flattening
algorithm is completed in shaka.util.Periods.
Three test cases have been disabled for the moment.
Multi-period playback will be restored in a smaller, more focused
follow-up commit, with disabled tests re-enabled.
Issue #1339 (flatten periods)
Issue #1698 (rapid period transitions issue)
Issue #856 (audio change causes bitrate change)
Closes#892 (refactor StreamingEngine)
Change-Id: I0cbf3b56bfdb51add15229df323b902f0b2e643a
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
This reverts commit 235e4e11ad.
The effort to remove SegmentReference's position field will be handled
in a different way.
Issue #892 (refactor StreamingEngine)
Issue #1339 (period flattening)
Change-Id: I62b115137abc89f498b30467e574b0401dcad05d
This removes the tests added by #2412 since they didn't test what
was wanted. This also fixes our existing tests to ensure they work
with autoCorrectDrift. Lastly this adds a new test to ensure the
UTCTiming is ignored when autoCorrectDrift is true.
Change-Id: If511fca5d3f360cdf373229961b2a01fdbda31bb