Cisco Stadium Vision Mobile Media Input Types

The Cisco StadiumVision Mobile solution can accept multiple forms of media content input (in-house video feed, IP video feed, and IP data feeds). The media is then routed through the appropriate encoder and into the Streamer. The Cisco StadiumVision Mobile Streamer is a critical component in the Cisco StadiumVision Mobile solution that aggregates video, audio, data, and file content streams and supports the following content types:

Channel Types Supported and Use Cases

Channel Type	Maximum Number of Channels	Example Use Cases
Streaming Video	4	Delivers live real-time venue game feed. Loops the most recent replays from the live in-venue game. Provide live out-of-venue game feed taking place at the same time.
Streaming Audio (Available in Android SDK only)	10	Provides the choice of commentary in multiple languages. Offers the choice to select between the home team and the away team commentators.
Data	4	Distributes data through push and pull channels to the client app. NOTE – The total number of data channels is 4.
Data Push		Triggers all mobile devices to display the same content at the same time, typically used for a sponsored moment of exclusivity.
Data Pull		Delivers real-time game statistics overlaid on the video pane.
File	1	Provides video replays, delivered by EVS C-Cast.

Streaming Video Channels

The figure below shows the video channel (SDI or IP) inputs in the Cisco StadiumVision Mobile solution. Streaming video can be real-time in-venue game feed, live out of the venue game taking place at the same venue, or loop the most recent replays from the live in-venue game.

Cisco StadiumVision Mobile Streaming Video

Streaming Audio Channels

The following figure shows how Cisco StadiumVision Mobile allows audio channels to compliment the live game experience. Audio channels consume less bandwidth than video channels, which allows for more room for channels.

Cisco StadiumVision Mobile Streaming Audio

Data Channels

The following figure shows how Cisco StadiumVision Mobile allows for the data push and pull channels to distribute data of any kind to the client app. The system integrator can decide what types of data is distributed and how it is used by the application. There are two types of data channels:

• Pull: Streamer polls an external web server at regular intervals (default 10 seconds). This channel can be used for data that changes periodically such statistics or thumbnails.
• Push: An external computer pushes data to the Cisco StadiumVision Streamer. This channel can be used for sending on-demand triggers to all mobile devices, for example when a goal is scored.

Cisco StadiumVision Mobile Data Channels

File Channels

The following figure shows how Cisco StadiumVision Mobile enables file channels as a way to distribute file-based (video, audio, and data) content to a large number of mobile clients over multicast.

Cisco StadiumVision Mobile Files Channels

File Channel Distribution

File channels are often used for replays to mobile devices at a live event where the bottleneck in a stadium is the Wi-Fi network that serves tens of thousands of fans with mobile devices. In order to scale, you can use Cisco StadiumVision Mobile Scalable File Distribution (SFD).

SFD uses multicast over Wi-Fi to scale distribution of the C-Cast video files. Multicast works much like over-the-air broadcast TV where your local TV station sends out a single signal that anyone in the area can receive with an antenna on the roof. From a load perspective it makes no difference to the TV broadcaster if ten subscribers or ten thousand subscribers are watching. Cisco StadiumVision Mobile SFD works in a similar way by sending the files as a single multicast transmission, and any number of mobile devices in the stadium can listen to that signal, receive the file and cache it in local storage for later use.

Generic Ingest

EVS C-Cast Integration

EVS C-Cast is the platform that Cisco StadiumVision Mobile uses for making replay video clips available to mobile clients over high density Wi-Fi networks. Read more about EVS C-Cast at:

http://www.evs.com/nala/product/c-cast

The traditional way of scaling C-Cast content delivery to a large number of clients is by using a Content Delivery Network (CDN). The CDN caches the content closer to the client, and thus avoids the need for every client to reach back and retrieve the content from the C-Cast Central server. This offloads the C-Cast Central server and reduces the amount of duplicate content that has to traverse the network.

However, the CDN approach does not help in a Wi-Fi environment where the bottleneck is the last 25 meters from an access point to a mobile device. SVM solves this problem by multicasting the C-Cast replays to mobile devices, and therefore avoids sending replays individually to each and every device.

Overview

In a traditional unicast C-Cast deployment (without SVM integration) the client app fetches an XML or JSON formatted C-Cast timeline via HTTP. The timeline describes the sequence of replays (C-Cast calls them events), and the camera angles available for each. Each camera angle consists of a thumbnail graphic and a MP4 video file.

From the perspective of the C-Cast mobile app there is very little difference between the traditional unicast and the Cisco StadiumVision Mobile multicast scenarios. In both cases, the exact same C-Cast timeline provides the app with the info it needs to make replays available to the user. And in both cases, the standard C-Cast media files are used. The only difference between the two scenarios is the transport mechanism used to the deliver the timeline and media files to the mobile devices. And this difference is largely, but not completely, hidden by the Cisco StadiumVision Mobile SDK. The C-Cast timeline is delivered via an SVM data channel and the corresponding media files are delivered via an SVM file channel.

Operation

When an SVM enabled C-Cast app is launched, it starts listening for the timeline on the SVM data channel. By default the timeline is repeated every 10 seconds, so the app may have to wait for up to 10 seconds to receive the latest timeline.

With the timeline in hand, the app extracts the media filenames for each replay and camera angle. The app then queries the SVM SDK to see if the file of interest has been received on the file channel and cached in local storage on the mobile device. If the file is available, the app proceeds to use it.

If a large number of replays and/or camera angles are being distributed, it can take several minutes for all media files to be received by the mobile device. It is therefore entirely possible that the app queries the SVM SDK for a specific file only to find that the file is not yet available. In order to provide a responsive user experience, the app should handle this situation by retrieving the missing file directly from C-Cast via unicast HTTP. The URL for this operation can be constructed from the timeline metadata. Consult the C-Cast API guide for instruction on how to create this URL.

This approach for managing files that are not yet available is referred to as hybrid unicast/multicast. By combining the two we are able to provide a solution that offers scalability and responsiveness.

To obtain the EVS C-Cast API, contact James Stellphlug (j.stellpflug@evs.com) stating that you are developing an app to consume C-Cast clips in a Cisco StadiumVision Mobile venue.