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
For content without a clear lead, the order of 'waitingforkey' and
'keystatuseschange' is inconsistent and causes false positives for the
WRONG_KEYS error. Without an obvious inverse for 'waitingforkey', we
will have to drop the WRONG_KEYS diagnostic error.
See also: w3c/encrypted-media#284
Change-Id: Icc1c420ff5d177a0329db244a6b28e99820a5221
Before, when we adapt we tell StreamingEngine we are in an unbuffered
state. This causes it to download segments at the playhead, even
though we have some buffered. Normally this does not cause problems,
but on Edge, it can cause skipping. So now, StreamingEngine will
use buffer end to determine which segments to download.
Issue #446
Change-Id: Ib1f4cd3a1627efa957825eb0445c99f753f31e7b
Empty WebVTT cues are valid, and should still be considered buffered.
By using a cues object with 0 length as a proxy to the init segment,
we lose valid empty WebVTT segments. Instead, use existence of start/end
as a proxy to init segments.
This regression was introduced in ab64c76ee9
* Suppress WRONG_KEYS errors when output is restricted. This is a
false alarm in these cases anyway.
* Throw a restriction error when the ABR manager fails to choose
streams for some content types.
* Rename ALL_STREAMS_RESTRICTED to RESTRICTIONS_CANNOT_BE_MET to
reflect the way restrictions actually work. We cannot play if all
streams of any one type are restricted, not just all streams in the
period. (e.g., all video restricted is a failure, even if audio is
still playable.)
b/30290503
Change-Id: I6de48950d33f241b7df1161052d60b89f962649f
* Drop unnecessary type alternation in SegmentIndex unit tests
* Drop unnecessary bind in StreamingEngine unit tests
* Drop unnecessary expose annotations in Pssh
* Add comments about quoted access in cast unit tests
* Move afterAll() position in cast unit tests
* Make return type for PublicPromise constructor more specific
* Define a type for Util.eventLoop return value
Related to PR #421
Change-Id: I092a8ff366b4ac4ea868dd3f4fbe4e3d63a2167f
Newer closure compilers do not seem to recognize the MediaKeys
polyfill classes namespaces because they don't follow normal
conventions. This leads to errors about missing requires.
This renames the classes as follows:
PatchedMediaKeys.nop => PatchedMediaKeysNop
PatchedMediaKeys.v01b => PatchedMediaKeysWebkit
PatchedMediaKeys.v20140218 => PatchedMediaKeysMs
The new names follow normal conventions and refer to the polyfills by
the prefix of the old API rather than by the version number.
This should help us upgrade to a newer compiler.
Closes#456
Change-Id: I5491ecb9a61e2b456ba8fa81a6adb6c110c96817
* Instead of filtering the output of AbrManager, ask AbrManager only
to choose streams for certain types. This keeps AbrManager's info
synced with reality.
* Simplify the way we apply config changes, restrictions, and new
text tracks to one method. Detect which types need updates and
only ask for those streams from AbrManager.
Issue #435
Change-Id: Ie10ddd2805cd45e97594838520e677de628a9f4c
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 will allow us to pass only audio stream sets when a language
changes, which will remove the need to filter the output of
chooseStreams in Player.applyConfig_.
Working toward a solution for #435
Change-Id: I893d13882809ef461b16c6c9426c8e9e33604c02
Calling chooseStreams does not disable AbrManager.
Further, we must explicitly disable it when switching periods.
Cleanup for issue #435
Change-Id: Ib5c75ddabb342929aef31eb185860b08d5c27cdc
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
* removes an assertion which is no longer valid
* corrects the registration of the VTT in MP4 parser
* fixes some type issues in TextEngine
Change-Id: I0b7f41f01e5d7be2932c86a56f3cdfd6a53d04cb
Wait to send a WRONG_KEYS error until key statuses have propagated.
Also, check for expired keys and fire the EXPIRED error from the key
status handler, not from 'waitingforkeys', which is not yet available
everywhere. The EXPIRED error will suppress any WRONG_KEYS error that
might otherwise fire when 'waitingforkeys' happens.
Finally, do not trigger track restrictions based on expired keys. This
means EXPIRED will never be followed by ALL_TRACKS_RESTRICTED.
This provides more deterministic behavior in tests and clearer
diagnostic signals for app developers.
Change-Id: Idd0f91fdd6442125661b9593ecaad0b57b81625c
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
When storing multiple tracks with the same type/kind/language, issue
a warning, since adaptation does not make much sense when playing
stored content.
Change-Id: I75d1625b2de680ae06728862d27b50272b951b7f
SimpleAbrManager will now leave 5s of video ahead of the playhead and
clear the rest when upgrading to a higher resolution.
Also smooths transitions for overlapping segments by scheduling an
abort() call to reset MediaSource internals after removing content or
changing the append window.
Related to issue #435
Change-Id: Ie036515388e1e7e4b3b8f3ab9922e3d5e7ed2627
This allows integration tests to test Player and offline with "real"
manifests and segments that are generated using ManifestGenerator and
StreamGenerator. The networking scheme can also be used with an
unmodified Player.
b/29883614
Change-Id: I77aa5385ecaaac43ba713687befa2f064654375a
Based on pull request by @baconz. Before, when appending segments,
TextEngine was given the segment times and then added the timestamp
offset to get the real time. However, this is incorrect as we want
the time relative to the presentation timeline. So we should only be
adding the period start time (the timestamp offset also includes PTO).
Closes#411
Change-Id: I92582d1cda034daef5e8ce2d7b79deafa0ddf828
This simplifies the logic for idle state, fixes some buggy idle state
transitions, and moves the idle logic into CastReceiver (with a little
support from Player).
Issue #261
Change-Id: Ic2729a4235c746ad46353bdf5dc7b605ab31f3ef
The sender is always polling video.buffered in the controls. Before
the first update from the receiver, the sender should see local values
for video.buffered. However, the receiver was updating volume events
before the first full update, leading the sender to try to access
remote values for video.buffered before they existed. This caused
uncaught TypeErrors in the controls.
Issue #261
Change-Id: I3836315d136be4584c1140842720919bca5d57e2
Original Chromecast devices can output a max of 1080p, and may have
issues digesting higher resolution content. Since higher resolution
content would be downscaled for display anyway, limit Chromecast to
1080p to avoid both decoder issues and wasted bandwidth.
Some Cast devices may support UHD content, but the max res for
Chromecast is currently hard-coded until we have a way to detect a
device's capabilities at runtime.
Issue #261
Change-Id: I3dd093b07f9a964116f81422f3c298dfbf7e2e52
The second argument is meant to be the number of decimal places to
which the value must match, not the maximum difference. So using
"0.1 decimal places" meant the maximum difference was actually 1.25.
You must pass "1" to get a maximum difference of "0.1".
This also adjusts some of the expectations to fix affected tests.
Change-Id: Ibc1223297011063e3e4f3fff0ba64fde06292128
- 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
This introduces Chromecast support directly in the v2 library, as well
as in the demo app.
See the included design doc for details.
Issue #261
Change-Id: I26a707e7fa6bd829c3ebc70e4c9345ec25eed000
Also involves some cleanup:
- Differentiate between WRONG_KEYS and EXPIRED.
- Fix session expiration detection for CDMs without sub-second
time resolution.
- Export accumulated key status over all active sessions.
- Update DrmEngine workarounds with bug links.
b/29919059
Change-Id: Ia4f12657285b0d431ed7a0c22ee4312375fdd40e
Joey Parrish
Jacob Trimble
Sandra Lokshina
Joey Parrish
Seth Madison
Andy Hochhaus
Timothy Drews