This makes a large number of small typo fixes. It also rewords a
number of comments and JSDoc descriptions, and does some
formatting standardization.
This doesn't fix every single issue, but it fixes a lot. Notably,
there were some formatting issues I declined to standardize due to
ambivalence on what the proper standardization would be; for example,
when and where empty lines should show up in JSDoc.
Change-Id: I5904ec91b96417a9ac5e19cb4f7b07a084f26ac8
This makes a large number of small typo fixes. It also rewords a
number of comments and JSDoc descriptions, and does some
formatting standardization.
This doesn't fix every single issue, but it fixes a lot. Notably,
there were some formatting issues I declined to standardize due to
ambivalence on what the proper standardization would be; for example,
when and where empty lines should show up in JSDoc.
Change-Id: I048b430e4c0bea2ccb9aec572d5e9ec6b606a87a
This adds attach/detach methods to replace the media element in the
Player constructor. Now applications can take back control of the
media element or provide a reference later in the Player's life cycle.
This also allows applications to decide whether or not to set up
MediaSource in advance, through an optional argument on attach and
unload. The default will be to set up MediaSource in advance, which
maintains current behavior. This advanced setup of MediaSource can
improve load latency later.
This change also introduces async/await for the first time in the
project, which required changes to eslint config, Closure build
arguments, Babel & Babel-polyfill setup, and the esprima parser used
by our extern generator.
The use of async/await will improve readability in many places, and
these infrastructure changes to enable async/await should also unblock
issues #1336 and #1337.
Closes#1087
Change-Id: I0d6b4e0e2af27a6520a3d070fa92b7139b2cb8b0
- Translate uncaught Promise rejections into test failures
(Chrome only until the event is more widely implemented)
- Clean up uncaught Promise rejection caused by exceptions thrown
after destroy() in:
- CastProxy
- CastReceiver
- NetworkingEngine
- StreamingEngine
- Clean up uncaught Promise rejection caused by test cases in:
- CancelableChain unit tests
- DrmEngine unit tests
- StreamingEngine unit and integration tests
- Player unit and integration tests
- Speed up rejection in NetworkingEngine when we should not retry
- Add --delay-tests to test.py, to aid in debugging uncaught
Promise rejections and other types of async test pollution
Closes#1323
Change-Id: I5a8f5702a22430929babeb071bf6650c52c5ad17
This is an automated fix to be inline with Google style guides, this
was created with eslint's --fix option.
Change-Id: I860eecbc8152603e730aa17a1393f16d26b3b6fc
Google style guide requires adding curly braces to all block statements
even if it is only has one line. This fixes it by using eslint's
--fix flag followed by running clang-format to reformat the change.
Change-Id: Idc086c2aa8c02df5ef8b2140a11bfb9128eeb4bd
This is part of a change to convert all usages of 'var' with either
'let' or 'const'. This takes a conservative approach for 'const' where
it will only be used for aliases and storing the "original" values in
tests.
Change-Id: I8f857a24e4c1ad336177d23dfed4f4a29d3262d2
A follow-up fix changes all 'var' definitions to 'let'. This fixes
issues caused by it. One major change is adding brackets to case
statements. Each case statement is considered in the same scope, so
defining variables in them actually are the same variable. By adding
brackes to the cases, each case gets its own scope.
Change-Id: I99b1298223786f4df415594a2e64eb31d72b2053
When casting, the cast dialogue contains information about the current
media, including volume, time, and duration. These values are
synchronized by different messages. We were sending over the
MediaStatus messages that synchronize current time, but were not
including duration in our MediaInfo messages. This caused the cast
dialogue progress bar to not display correctly.
This change makes it so that our MediaInfo messages now include
duration, and we now send over MediaInfo messages in situations where
we did not previously.
Closes#1174
Change-Id: Ic585f3befec9e44ef4e9895d04ddfad6cc5473b3
Not all values need to be updated twice a second. This change modifies
the list of player getters so that each value also includes an update
frequency, and only updates that property once in that many updates.
This acts as a configurable way to ensure that some properties update
in different amounts, without having to have multiple update timers or
compose multiple update messages in the same timeframe.
Change-Id: I90e75e3e73f6c633d91b1799307ec2b15587327b
Removes a special case in serialization that is no longer relevant due
to a configuration interface that was removed for v2.3.
Change-Id: I87ed194f42c1c25d86ca45b7ac952d6a45119a26
getManifest() hugely increased the message size when casting, to the
point where we were having message size problems.
This CL stops that property from being proxied.
This also adds an integration test that makes sure update messages do not get
too large.
Closes#1128
Change-Id: I3c4bfabb4d35ee870a603c38f784cb226366a28b
This causes the cast receiver to ignore further proxy events after
the receiver has been destroyed. This is to prevent errors after
destroy.
This is a nearly inconsequential bug; destroy is only called when
the cast receiver app is about to be unloaded, after all.
However, this change is necessary for integration tests to work.
Change-Id: I7bd9cb0f815e8f0989838c7f205e0475eb1b729b
Adding an event right after the player parses the manifest, and before
initiating streaming, so that users can get the manifest information.
Adding manifest getter method in player so that customers can access
manifest information.
Closes#1043Closes#1074
Issue #1036
Change-Id: I0016c312bacdfa86299e5df68b586f90d565cfdc
Beforehand, we stripped out all objects variables in events when
serializing. This was intended to remove complicated DOM objects, and
prevent the error messages from containing large amounts of unnecessary
information. However, this also caused the cast receiver to strip away
the detail variable in error events, thus removing all useful
information from the error event.
This adds a special exception to serialize for the contents of the
'detail' variable.
Issue #1065
Change-Id: Ie291e317cc6e856af20af5df57ecf3b5c81ec8bd
The cast sender API doesn't seem to be able to re-use an existing session
unless you reload the page. This stores the old session, so that it can be
re-used without reloading the page.
In order to enable this, CastProxy.destroy no longer leaves the current session;
I figure if you want to leave the session, you'll call forceDisconnect.
That part I am not fully sure about; perhaps it would be better to have a
separate optional argument about whether or not to leave, or make it a part of
the forceDisconnect argument.
Issue #768
Change-Id: Ie648372cea4b106ff85df3d0dcc563fca5d10d8c
Beforehand, calling chrome.cast.session_.destroy() would typically cause an
error, as the message or update listener was called after the the CastSender
was destroyed.
This removes those listeners before destroying.
Issue #768
Change-Id: I7889adce7b829c3f24dac7a178c9be26e2fdc887
If you call chrome.cast.initialize a second time, it does not error but it
also does not fire off receiverStatusChanged in order to signal the
initial receiver status. This can result in problems if the CastProxy is
destroyed and then re-created; specifically, it will erroneously claim to be
unable to cast until the receiver status next changes.
This makes hasReceivers_ into a class variable, so that a new sender will use
the hasReceivers_ of previous ones.
The original bug report was kind of confusing, so I cannot say for sure if
this actually solves their problem or not. Hopefully it does.
Issue #768
Change-Id: I7839ed99a8c48c69567bbcaeb1f9b6728265d63b
Beforehand, the Chromecast would poll getPlayheadTimeAsDate and
getPresentationStartTimeAsDate for every update message, which are live-only
getters, even on VOD.
This would cause a lot of error messages in the debug output of the receiver;
we didn't notice this before because we mostly run the receiver in compiled
mode.
This also allowed users to poll those attributes for VODs without any error
messages when casting, since the results of the last update were cached.
This change adds a list of getters that require live; such getters are not added
to state update messages, and are set up with asserts in the sender.
This should solve the problem and slim down our update messages a bit at the
same time.
Change-Id: Ifc0b445def2d85b22fcb9af160dec2205d1faace
Previously, if you connected to a ChromeCast that is currently playing, the
local interface would continue to show play icons as though the video was
paused.
This makes it so that the cast proxy sends out synthetic play or pause events
after the first state update after joining an existing session.
Change-Id: I1eb4c23f7b58225d361d353aacf0743def2f576c
There was a bug in the cast_utils test that meant that the new members
on Player weren't being detected. The test should fail when we forget
to add a new member to the list in cast_utils.js. This updates the
test and adds the new members to the list.
Change-Id: I27c25d07b409b8350b5709c3ce26696d72a6a11d
The getTracks and selectTrack methods have been deprecated since v2.1
and scheduled for removal in v2.2.
Change-Id: I938b3015262d71683ac871c05a9f4c74c96acf50
This is part of adding a new conformance rule to add additional type
safety. This will disallow using properties of unknown types or using
unknown properties.
The first parts will be fixing errors caused by the new rule. These
are backwards compatible, so can be applied before the rule is enabled.
Once all the errors and bugs are fixed, the rule will be enabled.
Change-Id: Iefde089b2f62ddfdf43944cda5badab438577561
Media Playback messages are used by generic Chromecast controllers
(Google Home app and the likes). Supporting them is required by
the Chromecast SDK.
Closes#722.
Change-Id: I3c98fb9d63da81b59c2cc82a3e790332fc9bb56e
This adds a severity field to Error objects. This can be used to
detect whether an error is recoverable. All the same errors are still
reported so the field can be ignored.
There are two possible values:
* RECOVERABLE means that the Player will try to recover from the error
* CRITICAL means the Player will be unable to continue and must call
load() again
Closes#564
Change-Id: Ie2c5468340c13e7a288b99690ab65b7ecc0a6b29
This adds a method on Player to get the license expiration times for
the current EME sessions. This also adds the expiration times to the
stored content structure for offline content. This will update the
stored expiration while playing content (e.g. license duration changes
when playback starts).
Closes#727
Change-Id: I18770a79413423695bbb2ed5f31f6b19038a33d2
This add the groundwork for event regions that occur while playing.
When the playhead enters (or plays through) a specified region it will
fire enter/exit events for it. They are not fired when seeking over.
Issue #462
Change-Id: I9e280796bd012ad74d0319aa2056c6f6aa28890d
Add UI options to select current audio and text language.
Split selectTrack() into selectText() and selectVariant().
Stop automatically disabling ABR manager when a variant is selected.
Add a warning if selectVariant() is called while abr is enabled.
Issue #412.
Issue #626.
Change-Id: I15f1c3c4fdc6d6b641f708fbef19dbcf10cbcfc6
Using a special API available on the Chromecast, determine if we can
do 4k. If so, raise the hardware limit from 1080p to 4k.
Change-Id: I6e403cce5d9c43a22f1b76cf4d79661ac096dd82
The emsg, loading, and unloading events were present in v2.0.0.
The drmInfo, isInProgress, and keySystem method were also present in
v2.0.0. The getPlayheadTimeAsDate method was introduced in v2.0.1.
None of these were proxied to the cast device until now. All v2.0.x
events and methods are now being proxied.
Change-Id: I6fba60f4ca451053c1449cafcddd9c1006292ad9
Show 'stop casting' dialog on chromecast control click when casting.
If user chooses to stop, delegate disconnecting to Chrome.
Related to #261
Change-Id: I3072a3723e0d0d526039946fb45713e20349e54c
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
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