Demo Cast Receiver app: compatibility with Media Playback Messages

[alex-schwartzman]

I'm now reading the code, and at the same time studying Google Cast requirements.

One of the requirements - is that the receiver should emit Media Playback Messages using the namespace "urn:x-cast:com.google.cast.media", see https://developers.google.com/cast/docs/reference/messages.

However, in the demo/receiver_app.js I cannot find any mention of that required messaging.

Can you, please, clarify if the demo receiver is "just a non-compliant receiver" or, instead, all Media Playback Messages are emitted by some part of Shaka player which I did not spot yet?

[joeyparrish]

I was not aware of those requirements, so it would appear Shaka Player's receiver is non-compliant at the moment. I'm not certain, but I would guess this part of the SDK docs show why these requirements exist:

Commands from sender to receiver

These commands control the media player. ... This will allow generic remote control apps to work properly.

I'm not familiar with generic remote control apps, but it seems that these com.google.cast.media-namespaced commands would be important for that.

We'll take it on as an enhancement to support these commands as well as our custom ones. We will also see if we can find a generic remote control app for testing.

For now, I think you can expect your Shaka-based sender to work with your Shaka-based receiver, but that other senders would be unable to send a pause, seek, or volume command to your receiver app. If this is acceptable to you for the time being, you can always upgrade your receiver to a new release of Shaka Player after we implement these generic commands.

I don't have a timeline for implementation and release right now, but I will try to schedule it soon. Thanks!

[alex-schwartzman]

Thanks, @joeyparrish .

I could help you with the testing if you wish. :)

Besides, one might find the generic remote control in the Google's Cast Sender SDK, which is already available for Chrome, Android, and iOS. Samples which use that SDK are available as well:
https://github.com/googlecast/CastVideos-android
https://github.com/googlecast/CastVideos-iOS
https://github.com/googlecast/CastVideos-chrome

I am a mobile developer, and being able to control playback using generic Cast SDK is very important for me because in order to comply with Cast UX Guidelines user should have a chance to control the playback even when the application is already terminated. As soon as the receiver is compatible with generic playback control messages, Android will do that for me, no need to keep the application alive.

Therefore, when I build the Chromecast-enabled Android application with the custom receiver based Shaka player, it would help me a lot if it already supports generic playback control messages.

[joeyparrish]

I see. Thanks for the tips!

I've added this optimistically to the v2.1 milestone. If we finish this before we finish HLS, it will appear in v2.1. As soon as HLS is done, this will slip to the next milestone. Thanks!

[alex-schwartzman]

Just a small update: there are rumors that we don't need to emit those playback control messages by ourselves, but, instead, MediaManager will do that for us. That's a good news - we just need to implement cast.receiver.media.Player interface, and pass the implementation to the MediaManager's constructor.

Here I have posted the working sample of the player implementation https://github.com/googlecast/CastReferencePlayer/issues/26

[ismena]

I just tried controlling the playback from a Google Home app on my phone and it worked, so I'm cautiously optimistic that this is something that works "from the box".

@alex-schwartzman Let me see if I can get additional confirmation from another source before we call it a day.

[ismena]

Okay, the bad news is there is some work to be done to make this happen after all.
The good news is I think I know how to test this now :)

Will look into the implementation!

[ismena]

Actually @alex-schwartzman, do you mind syncing up with me on how you're testing this and what the expected result would be?
Is there a remote control app you use? Or do you make use of a possibility to control Chromecast with a TV remote?
I thought I would rely on the remote control dialog that appears on my Android phone when Chromecast is used, but it dawned on me that this might not be what you had in mind.
If you could describe a use case I can use to verify that the implementation works it would be perfect.

[alex-schwartzman]

Thanks for stepping in to that challenge.

@ismena there is a set of use-cases, which are expected to be handled when the application claims itself as Chromecast-compatible. They all boil down to Chromecast UX Guidelines : https://developers.google.com/cast/docs/design_checklist/

What is important for me as a developer, is that the receiver is capable of answering to the generic playback commands. When the answer contains all the information needed by the user - it's even better.

What is important for me as a user - is that when I kick off playback of my favorite show using my mobile, I can see the tile of the show, it's title, and some controls in chrome://cast/#devices when I use chrome, or in Google Home application (available for Android and iOS : https://support.google.com/chromecast/answer/7071794?hl=en) when I use my tablet for playback control. When I say "playback control" it means play, stop, skip to next, pause, adjust volume, kill cast session.

All those features described above are implemented already in MediaManager on the receiver side, and in Cast SDK v3 on the sender side. The only missing part in the puzzle is to let MediaManager know how pass playback control commands to Shaka. That's why it accepts
cast.receiver.media.Player in it's constructor. (see https://developers.google.com/cast/docs/reference/receiver/cast.receiver.media.Player)

[joeyparrish]

Okay, it looks like we have some work to do, then. Here's a quick design for how these required commands will map to Shaka Player:

Required messages from sender to receiver

Load
The autoplay and currentTime fields will be directly supported.

The message contains a content ID inside the MediaInformation structure. We will invoke a callback to the receiver app to translate this into a manifest URI, and in the absence of that callback, we will assume the content ID field contains a manifest URI. This seems to be allowed by the cast SDK docs.

The customData field of the Load message will be given to shaka.util.CastReceiver's opt_appDataCallbackopt.

Pause
Will call video.pause().

Seek
Will set video.currentTime, and will honor resumeState, if set.

Stop
Will call player.unload().

Play
Will call video.play().

Get Status
Will respond with a Media Status message to the requesting sender.

SetVolume
According to SDK docs, this should set video.volume, unlike other volume commands, which set system volume.

Required messages from receiver to sender

Error: Load Failed
Sent when a Load command fails. Will be tied to player.load().catch(...).

Error: Load Cancelled
Sent when a Load command fails with LOAD_INTERRUPTED.

Media Status
Sent when a Get Status command is received.

[ismena]

Hey Alex, we just pushed the implementation for this.
Please let us know how it works for you and reach out if we need to do any adjustments.