Video Streaming: from the native Android player to uncoventional devices

Editor's Notes

• #16: android:screenOrientation can’t be portrait, reversePortrait, sensorPortrait, userPortrait or reverseLandscape.
• #17: No touchescreen– TV control comes with DPAD. TouchScreen must not to be required since Google Play won’t filter.
• #18: Limit Sensor– Make optional every uses features which are for not crucial operation.
• #27: Before starting to develop the Android client application is important to have in mind which are the basic requirements. First of all there are few library dependencies and constraints you’ll need to care about. Number one: the minimum SDK version supported by Goole Cast technology is the 9 that is Gingerbread Number two: the Goole Cast client APIs are packaged into the android.support.v7.media package of Android Support Library revision 19 o later Number three: you’ll need to setup the Google Play Services library revision 4.2 or later Number four: you must import the AppCompat which provides basic UI elements like the MediaButton, useful for establish a connection to the Chromecast device
• #28: Now let me show you what is the typical sender application flow because it’s also important to understand which are the steps the client runs in order to start and control a receiver application. During the development phase you’ll have to interact with several Java objects. So first of all: the sender application uses the MediaRouter object to discover all the cast-device available inside the local WiFi network. through its callback, the MediaRouter informs the sender application which of the available. From the RouteInfo object the sender application extracts the instance of the CastDevice object: the most important object inside the development lifecycle. This is the object which represents the hardware specification of the cast-ready device Once the sender application knows the cast device the user selected it makes use of Google Play Services APIs in order to launch the receiver application and to establish a communication channel where several messages are exhanged Only at the end of these steps you’ll be able to play any kind of content using the RemoteMediaPlayer object
• #29: Now I would like to give you more details about the discovery phase. It’s important because, inside the same local WiFi network, many cast-ready devices could be connected, everyone with different capabilities. So the sender app must make a choice in order to select the capailities it needs for. The Google Cast SDK provides three main categories that the Chromecast is able to manage: REMOTE PLAYBACK LIVE AUDIO LIVE VIDEO REMOTE PLAYBACK category idendifies all the routes which present a remote media by playing content from URI. These routes take the responsability for fetching and rendering content on their own. The application doesn’t display any content on the screen of the device. Different are the cases of the LIVE AUDIO and LIVE VIDEO where the routes support live audio and live video streaming respectively from device to the destination. Theses routes are the easiest to use because the application renders the content locally on the screen of the device and the system streams it automatically to the destination. A destination that could be a local display or wireless display with support for mirroring or Android presentation. Further, in this slide you can see how it’s easy to set the requested capabilities for the Android client application, using the MediaRouteSelector object.
• #31: On the other side we have the receiver application. What a mistery? What a mistery just because I’ve experienced a lot of questions and curiosity from many collegues of mine. They couldn’t imagine what the receiver application is and how it works. I realized it was often confusing and frustrating for Android developers to find out that the receiver application is just an HTML5 and Javascript web application. Exactly. Inside the Chromecast device what’s running is a custom version of Chrome web browser. This decision is the reason why the Chromecast became a successful product. Having a widespread and consolidated technology like Chrome web browser playing the role of the media player allowed the many developers to solve most of the known problem about video streaming and to mantain client and server technology respectively decoupled. So what does it do? First of all it displays the media content on the TV and further it provides an handler for the management of the messages exchanged between the client application and the recevier device. As we’ll see later there is a strong presence of messages flow starting from the client towards the receiver and vice versa. If you’ll start develpoing a Chromecast application you would choose one of the three available media receiver: a default media receiver, a styled media receiver and finally a custom media receiver. The Chromecast Receiver API provides different solutions based on what are your needs. And now i’m showing you them.
• #32: The default media receiver is the simplest and easy to use. It’s a prebuilt reciever application, hosted into the Google Cloud Factory, and it’s designed for the streaming of audio and video contents. It doesn’t provide any UI customization as Styled and Custom one permits and further it doesn’t require any kind of registration as Styled and Custom needs to.
• #33: The Styled Media Receiver, instead, represents the right choice if you need a ready-made application receiver for media playing with the possibility to customise some little UI elements. By publishing a simple CSS file, with specific CSS class names, it’s possible change the logo image, the progress bar logo, the title style and so no. Differenty from the previous Media Receiver, the default one, the styled media receiver requires the user to register the receiver application by simply fullfil a web form. This registration calls for a name and a URL referring to host where the CSS file is remoted.