## Overview

Our goal is always to offer our customers a solution that is flexible enough so it can be perfectly adjusted to their use case. This applies to the integrated Chromecast support of our player SDKs for Web, iOS, and Android as well. The latter can be achieved either via CAF (Casting Application Framework) or Google Cast V2, which while still work in Bitmovin’s old player versions but not on Bitmovin V3 for iOS and Android, has been deprecated by Google.

Besides simply enabling this feature, you can also customize the look&feel of the player UI used on Chromecast, as well as leverage your own application by providing your own app-id and messaging namespace, and you can push additional metadata upon initialization to configure your app or share other details needed by it.

## Basic Concepts

**Receiver app**

It is basically a HTML app that is hosted on a server to the Internet. It can include any desired behaviour (e.g. by including JavaScript). When the app is launched on a Cast device the associated HTML file is fetched and interpreted in its browser. An overview of CAF Receiver app can be found [here](🔗). Bitmovin offers a basic example of a receiver app, containing a basic HTML page with the video element and reference to Bitmovin SDK. You can check out the [example on GitHub](🔗) The receiver App for CAF version 3 integrates [Shaka Player](🔗) as default player, and it is not possible to replace it with any third party player, including Bitmovin. The capabilities and features support of the receiver are dependent on the ones available in Shaka Player. Moreover, it is worth noting that the version of Shaka Player used in CAF receiver does not go on par with the mainstream Shaka, generally being the CAF version slightly behind.

**Sender app**

A Sender app is used to launch and control the Receiver app. You can think of a Custom Receiver like a remote-controlled web browser. For some uses cases e.g. media players there are APIs provided by Google. It is also possible to exchange string messages between Sender and Receiver. The communication relies on Web Sockets and is abstracted by the Google Cast Sender APIs.

Bitmovin player contains sender functionality available for Web, Android and iOS SDKs. Customer applications can use them to implement different cast use cases (see details below on this guide).

**How to launch the app?**

Every app has a unique ID which can be found in the [Google Cast SDK Developer Console](🔗). This ID is needed to launch the app with Google Cast Sender APIs for Chrome/Android/iOS. For Instructions on how to register your app to Google Cast SDK developer console, please visit [Google Cast Registration](🔗).

## Requirements

In order to cast content to a Chromecast device, the following prerequisites must be met:

  • If the sender device is a Desktop browser, it must be Chrome based, such as Chrome, Edge, etc.

  • The receiver device must be a certified Chromecast receiver, either a hardware dongle or a TV with build-in Chromecast support.

  • The sender & receiver must be on the same local network

  • The sender and receiver need internet access

  • The sender must include the cast SDK

  • A valid cast receiver applicationID (Obtained from [Google Cast SDK Developer Console](🔗))

## Supported Features

The following table summarises the supported features for CAF on the different Bitmovin SDKs:

Casting DASH streams
Casting HLS streams
Send messages from sender to receiver (addMetadata)
Send side loaded subtitles to receiver
Basic playback
DRM configuration
Using custom receiver
Cookie/credentials support

Supported DRM systems are Playready (SL 2000), Widevine (Level 1) and Clearkey DRM. Supported subtitle formats are TTML, WebVTT, CEA-608/708. The codec and HDR support is dependent on the receiver hardware, and a full compatibility list can be found in the [media documentation](🔗). Besides that, Bitmovin supports the following features of CAF SDK:

  • ABR

  • Multiple audio and subtitle tracks

  • Subtitle styling

  • Styling of receiver UI elements

  • Display custom DOM elements (with custom receiver)

  • Live streams

  • Transmuxing

## Web Setup

For Web Player SDK, it is required to setup the [Remote Control configuration](🔗), the following configuration shows the most basic setup:

The **receiverApplicationId** is an optional parameter, in the case you are configuring your own Receiver app. When this parameter is omitted Bitmovin player will us a default receiver App.

The **receiverVersion** parameter must be setup to '**v3**' in order to use Google CAF version 3 (latest version). Using version 2 is also possible, however this version is already deprecated by Google and it is not recommended to be used.

## iOS Setup

For iOS Player SDK, please refer to the [BitmovinCastManagerOptions](🔗) for the configuration options available for the Sender app. The following code shows a basic setup:

The **BitmovinCastManagerOptions** include the applicationId, which is optional. In the case there is no custom Receiver App it is not necessary to pass **options** as a parameter for **BitmovinCastManager.initializeCasting()**.

A complete example for iOS and CAF can be found on our [GitHub repository](🔗).

## Android Setup

For Android Player SDK, please refer to the [Bitmovin CastManager](🔗) documentation. A basic configuration is shown below:

The applicationId is passed optionally as part of the **BitmovinCastManager.initialize()** .

A complete example for Android and CAF can be found on our [GitHub repository](🔗).