Chromecast support in v2 #261
Comments
|
The current demo app does not support that yet. You may notice that those controls are disabled as soon as you cast. Please note that casting is done completely outside the library and in the application. So you can already use the full range of Shaka features with the Chromecast in your own application, even though you can't see it in the demo. With Shaka 2, we will organize the demo app in a way that shows all functionality both locally and on the Chromecast. |
joeyparrish
changed the title
|
In addition to showing Cast support in the demo app, we've decided to bring Cast support in-library for v2. We hope this makes it easier for users to build Cast receiver apps. |
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
It makes no sense to refer to the Cast-proxied Player for offline storage, so explicitly refer to the local Player instead. Issue #261 Change-Id: I6b4e0cb828489724d334362d6e15da3d3ea12719
Issue #261 Change-Id: If6dd1c06a51dfd77bea62fc757718d0e59c324d8
Issue #261 Change-Id: Ia91178810c5ad4d353b9c96e396fda2ba4bfcff2
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 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
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
|
This is mostly done. What we have so far will be in v2.0.0-beta3. What's not done yet, which we hope to finish in the final v2.0.0:
|
|
Split the CSS3 animation performance issue to #505, which will be deferred until after v2.0.0. |
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
To recreate:
Load demo Angel One w/ Subtitles.
Enable Subs, View/test on browser player. (WebVTT is included in manifest)
Choose various audio languages, perhaps cycle tracks
Cast to Chromecast, there are no subtitles and the audio will only be the default 'en' track.
The text was updated successfully, but these errors were encountered: