These patches and IPR support in general will be revisited when we
have a better model for how this should work.
Closes#463
Change-Id: I2c5fe372986a9af232b052c67f8e5c3ba6585cee
Duplicate language information from StreamSet to Stream.
This will simplify the task of determining when a configuration
change triggers a language change.
Working toward a solution for #435
Change-Id: I461f7e8974f1e09b0b6f38edfab901b3f89eb3bc
This allows us to support manifests where AdaptationSet does not
specify an explicit contentType of 'text' for Representations
containing 'application/mp4; codecs="..."' text streams.
Also makes the demo app more resilient against unexpected track types.
Change-Id: Iec46f49d1b7726bec1b8d24bd6cc6f3fd2101ab4
If a key status is 'output-restricted', treat the key as unusable.
In many cases it is, and we have no way of differentiating when it is
or is not. So our treatment of this status should be conservative,
and we should treat the key as unusable. This will prevent
HDCP-related failures that may be caused by adapting to a stream whose
output restrictions may not be met. The hasOutputRestrictions flag on
streams and tracks is now gone.
The caveat to this change is that if content is encoded with the same
key for SD and HD, and HD streams have HDCP restrictions that cannot
be met, we will now consider both the SD and HD streams to be
unplayable, even though we could still play the SD streams. Because
we can't separate the status of the two streams, we don't know for
sure if the SD streams can be played.
We will no longer support such content due to the complexity of doing
so, and due to the risk of playback failures on adaptation to
restricted streams. Streams with different security requirements
should always be encrypted with different keys. Content which does
not follow this best practice will no longer be playable in Shaka
without modifying the player.
Change-Id: Ia29db8efa0b6f83c0376199dea5210c9b468bc40
- Restore ClearKey as a recognized key system in the DASH parser
- Query key systems with configured license servers first, so that
we can continue to differentiate between unavailable key systems
and under-configured key systems.
- Add a new ClearKey license server test asset.
- Update tests.
Closes#403
Change-Id: Id5ef46d2d35a0217d313f03d403058c5c279e878
Instead of filling the URI templates when parsing the manifest,
wait until the request is made to fill it. This reduces the time
it takes to parse the manifest.
This was tested using a stream with a 24-hour timeShiftBufferDepth.
Using a Chromebook pixel running Chrome 51. The average manifest
parse time was about 1 second before, now it is about 200ms.
Issue #405
Change-Id: I89f36085441f6c6b7d6281b24b671dc668f23fe5
Before, we did not use suggestedPresentationDelay in the seek range.
This meant that seeking to the live edge would usually lead to a
buffering state because the seek range is the same as the availability
window. Now the seek range is handled differently from the
availability window.
b/28938315
Change-Id: Iacfffe30778f7c63734fe24eeb95634611da86be
Otherwise, we fail to play manifests containing TTML. Without a TTML
parser, TTML streams should be ignored and not cause failures.
Issue #111
Change-Id: I982ad04083e40a3f5c5023f0059fa4ae1604ab07
Now the Storage class can store protected content and play it back.
When deleting it, the offline EME sessions will be removed. Also
now offline support appears in Player.support().
Closes#343
Change-Id: Ic5b5a0e0854d80f7821e04e751275abf40ee6eb6
Before, the same error was used for no available configurations or
key systems and for missing key system URI. Now there are two
different errors. Also elaborated on the error in the documentation.
Closes#371
Change-Id: I9b72daa0a99b4761714a74c3ceba60c873c89a77
Representations without Segment* elements or which do not
specify "text" as their type are now ignored instead of causing
failure.
Issue #368
Change-Id: Ica6490442dc38c7fdbc778eb0650dd7909d764c5
If a key is output-restricted it may still be usable.
So, instead of disabling these tracks, indicate that they
may be playable.
Issue #199
Change-Id: Ic13a02d97ccc21533118f17aa907c16d1cda05ce
Applications which cannot control their manifests may need to specify
a default clock sync URI for use when UTCTiming elements are missing.
Closes#290
Change-Id: I5704b25d2d3199ceb932f8102490a9b3e8a27dac
Hitting UTCTiming sources over and over could be considered abusive
behavior at scale, so we will only sync the clock once on startup.
The change to update clock sync on manifest update was added for #345,
but it seems that this was not part of the fix, since the content in
that issue had no UTCTiming element at all.
Change-Id: I32f4fc0a40fc92feeb54191e5fe869e0aaa9b54c
Without a UTCTiming element in the manifest, a client cannot
synchronize its clock. This can easily lead to playback failures,
so we warn application developers when we detect this.
Issue #290
Change-Id: Idcb395f5ece67bf2c7d0d984ad277f552d030eb8
Some browsers, such as Edge 13, do not report capabilities at all.
Not all encrypted streams have known key IDs, so we should not
use that as a predicate for the encrypted content type filter.
Since not all content has both audio and video, the requested and
reported capabilities may not have both either. So we should
default capabilities to empty lists if missing.
This also adds an encrypted audio-only asset so that audio-only is
covered by our integration tests.
Closes#342Closes#360
Change-Id: If5973c4ddea358d96ab305700e027021b1a7b65a
* Permit non-zero presentation start times for VOD: some
presentations have segments which start too far from 0 to
allow the video element to begin playback; now the player will
start VOD presentations from the start of the first segment.
However, segments of the 2nd, 3rd, 4th, etc., Period of a
multi-Period presentation must still start close to 0 (the
player will not jump any gaps in the presentation).
* Prohibit seeking to regions at the beginning of the segment
availability window if segment information is missing from
that region: sometimes live manifests do not contain all the
segments in the segment availability window; now the player
will prohibit seeking to these regions.
* Update definition of live in DashParser to match Player and
Playhead.
* Simplify PresentationTimeline's constructor by just using setter
functions.
Issue #341Closes#348
Issue #357
Change-Id: I96c22774448476bea89ff4014f03b87bdb51ba07
* Support minimumUpdatePeriod="PT0S".
* Fix comparisons with very large timestamps.
* Assign default Period ID if not given.
* Increase suggestedPresentationDelay.
Closes#331Closes#339
Change-Id: I091cb7ab3e2a1cdb38e4161fe139a96a10de3807
Now the application can restrict the kinds of tracks that the Player
will play. This is done through player.configure(). This also
allows restricting the playable tracks based on the EME key status.
Closes#326Closes#327
Change-Id: I88210ece6fd1db886c49d4599fbe5814d394132d
Without @namespace annotations, static classes do not show up in the
generated API docs. Although I stumbled over one instance while
writing tutorials, the rest were discovered programmatically by:
for x in $(find lib/ -name '*.js'); do
grep -Eq '@(constructor|interface|namespace)' $x || echo $x
done
Change-Id: I97dd2bb4bf3faad5ac8d952a28837fa1f594deb9
The live-edge calculation in PresentationTimeline needs to take into
account the duration of the current segment since the current segment
is not available until it has ended.
To do this we use MPD@maxSegmentDuration when available, and compute our
own maxSegmentDuration when it's not (as specified by the DASH spec).
Change-Id: Ic5b8478dbbff8eac93cf123a00a8b02db140cf15
Multi-period live streams have no presentation duration and have no duration
on the final period.
In this case, we were setting the timeline duration to the start time of the
final period, based on end = start + duration with duration == null.
This fixes the situation so that timeline duration is infinite.
Relates to #310
Change-Id: I8592318e3d4c5643fa1fcc03b34624957a2e974c
When updating a DASH manifest, we can key off of Period and
Representation only. The spec says that Representation IDs are unique
within the Period, and that Period IDs are unique within the
presentation. Therefore we do not need an AdaptationSet ID to merge
on update.
Relates to #310
Change-Id: I12b9f83c2bfda958a14e9ee31d459c04da8722e6
This also changes DrmEngine to reject key systems that do not have
any license servers, this causes init() to fail.
Change-Id: I10148c2caa2ffc57bf6c5f16421ed0600d98be95
This ensures that small gaps from the start of the Period or from the
end of the Period are not interpreted as missing SegmentReferences.
Change-Id: I7492faef8e44067494e3daf3ff73742fa914d1e3
Our new interpretation of whether a stream is live is if there is
no duration. This removes the old check for type='dynamic' from
the Dash parser.
Change-Id: I58aa1a785c7e949be7b48ab5b3b409cbf8e828a6
Joey Parrish
Sandra Lokshina
Joey Parrish
Seth Madison
Andy Hochhaus
Jacob Trimble
Timothy Drews
Costel Madalin Grecu
Costel G