The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
First Published: May 26, 2015
Revised: November 5, 2015
This module contains information on configuring video and data sessions on the Cisco StadiumVision Mobile Streamer, and contains the following sections:
The Cisco StadiumVision Mobile (SVM) solution enables the reliable delivery of low-delay video and data streams to fans’ Wi-Fi devices at venues. Figure 1 illustrates a high-level view of the Cisco StadiumVision Mobile solution, which has the following attributes:
Figure 1 Cisco StadiumVision Mobile Architecture Overview
The Cisco StadiumVision Mobile Streamer is a critical component in the Cisco StadiumVision Mobile solution that provides the following benefits:
Table 2 lists key terms and concepts of the Cisco StadiumVision Mobile solution.
An important feature of the Cisco StadiumVision Mobile solution is to limit the consumption of
Cisco StadiumVision Mobile encoded content to authorized mobile applications. Consider the following situation:
Content Owner A (e.g., sports team) wishes to use the Cisco StadiumVision Mobile solution to deliver live camera feeds to fans throughout a venue during the team’s home games. Content Owner B (e.g., entertainment company) plans to host events at the same venue at a different time and also wishes to deliver live feeds to their fans. The two Content Owners each want to limit content consumption to their chosen and therefore authorized, Application Developer. The reasons for needing to limit content consumption to authorized mobile apps are many. For example, the app may need to be purchased or it may be sponsored by an advertiser. As a result, Cisco StadiumVision Mobile video and data streams configured for Content Owner A’s mobile app must not be consumed by Content Owner B’s mobile app and vice-versa.
The Cisco StadiumVision Mobile Streamer includes a (Venue/Content Owner/App Developer) Triplet in each announced video and data session. Only mobile apps with the identical Triplet will be able to discover Cisco StadiumVision Mobile sessions and consume the associated content. The Streamer may be configured to support multiple Content Owner and App Developer combinations, though only a single Triplet may be active at any one time.
Note The Stadium Operator is responsible for correctly configuring the Streamer and working with Content Owner/App Developer to enable content consumption.
The manner in which media sessions are associated with a specific Triplet is covered in the “Session Configuration” section.
The following sections provide instructions for using the Cisco StadiumVision Mobile Streamer. Each of the referenced windows and the associated fields are described in detail in the Accessing the Cisco StadiumVision Mobile Streamer UI section.
To access the Cisco StadiumVision Mobile Streamer, complete the following steps:
Step 1 Enter the following URL in a web browser:
Step 2 Specify the username and password.
Note The default username and password is:
admin / cisco!123
The Cisco StadiumVision Mobile UI provides the ability to view, configure, and analyze
Cisco StadiumVision Mobile sessions:
– To view periodic, real-time updates of specific session statistics, click Status on an active session.
– To configure individual session parameters, click on the name of the inactive session.
– View and download the System State Report
– Review the ISO list and log files from the Software Manager
Figure 2 shows the Cisco StadiumVision Mobile Streamer window that does not have an active session.
Figure 2 Streaming Sessions Summary Window
To set up the initial configuration of the Streamer, complete the following steps:
|
|
|
---|---|---|
Click Change Venue Name in the Default Configuration window. |
||
Modify defaults as needed in the Default Configuration window. |
||
Note The Content Owner/App Developer pairing must match the values hard coded into the specific SDK for the App Developer contracted for a particular venue.
The Default Configuration screen is used to view/modify the Venue name and Content Owner/App Developer pairs (all three together are called the triplet key). Figure 3 shows an example of the Default Configuration screen.
The Default Configuration screen is also used to view/modify the default settings to be applied when creating a session. Changing the default settings applies only to sessions to be created, and does not affect previously created sessions. Note that all sessions must be stopped before default setting changes may be applied.
The Venue, Content Owner, Application Developer (triplet key) settings are critical to enabling content consumption on mobile devices. The Streamer settings must match those used by the App Developer for content to be discovered and consumed by a mobile app. App Developers must be notified of a change in Venue name so that their app may be updated. Conversely, if the App Developer has already deployed the app, App Developers must also be notified if the associated Content Owner/App Developer setting on the Streamer is modified.
Figure 3 Default Configuration Window
The triplet key (Venue, Content Owner, and Application Developer) are configured in the Default Configuration screen. Figure 4 shows an example of the triplet key setting fields.
Note Stop running sessions before changing any default settings.
To modify the Triplet Key setting, complete the following:
|
|
---|---|
First delete the Content Owner/App Developer pair, and then click Add New to create a new pair. |
Note The Content Owner cannot be edited. The Content Owner/App Developer pair should be deleted if the Content Owner is modified.
Selecting the Add New button displays a dialog box that allows you to enter new Content Owner and App Developer names. Figure 5 shows an example of the Create the new Content Owner Dialog Box.
Figure 5 Create new Content Owner Dialog Box
This section describes how to create, configure, start, and stop streamer sessions.
The Create a New Session dialog box is displayed upon selecting the Create a new session button as shown in . The operator must enter all new session parameters to successfully create a new session. All other session attributes are inherited from the Default Configuration screen.
To create and start a session, complete the following steps:
Figure 6 Session Creation Window
Table 4 lists the Streaming Sessions field descriptions.
|
|
---|---|
Number associated with this session. Must be unique per Content Owner. |
|
Name associated with this session. Must be unique per Content Owner. |
|
Select the session type. Affects defaults to be applied to the created session.
Release 3.1 and Later Releases: Configuring Cisco StadiumVision Director for External Triggers |
|
|
|
IP multicast address for the session to be transmitted by the Streamer. Must be unique per Content Owner. Note that the port number is configured on the Default Configuration screen. |
Clicking on a session name on the Session Summary screen displays the associated Session Configuration screen. Displayed fields are dependent on the session type (video, audio, data, or file).
All modifications made on this screen are for the selected session only. Figure 7 shows a video session configuration window.
Figure 7 Video Session Configuration Window
Table 5 lists the video session configuration field descriptions for both input and output sources.
|
|
---|---|
Name of input data source. It may reflect the encoder name or the actual video source (e.g., EndZone, ESPN). |
|
IP multicast address on which the input video stream is received. |
|
Name of the session. Must be unique per Content Owner. Choose a descriptive name as this is the name that will be shown on the client. |
|
IP multicast address of the session to be transmitted by the Streamer. |
|
Number associated with this session. Must be unique per Content Owner. |
|
The Advanced Session fields are identical to those listed in the “Streamer Session Default Field Descriptions” section. |
Data sessions are generally assumed to complement the video streaming experience. The transmission of data session packets is consequently controlled to minimize Wi-Fi multicast congestion and ease client reception/recovery of data objects.
Two parameters play a critical role in controlling the data session transmission:
The product of the Session Bandwidth and Protection Window effectively specifies the maximum amount of source and repair data that may be sent for each object within a data session. It is therefore important to know the approximate size of objects to be sent over the network. The Stats Summary provides a quick view on the data session packet statistics.
Objects fetched for data sessions (e.g., out of town scores) are generally expected to small, e.g., 20-200 KB, and are further reduced when compressed by the Streamer for a typical delivered size of 2-50 KB.
Configuring the Session Bandwidth and Protection Window requires some trial and error since data objects typically vary in size and the compression achieved for each object can also vary. As noted on the previous page, the Stats Summary provides guidance on the size of the delivered object and appropriate configuration settings. Here is an example:
A three-second protection window would be required to extend the StadiumVision Mobile client’s reception window to match the Streamer transmission window. Table 6 contains the data session configuration field descriptions.
There are two types of data sessions:
|
|
---|---|
Name of input data source. It may reflect the encoder name or the actual video source (e.g., EndZone, ESPN). Note When creating a data-push session type, the Input URL and Polling Interval fields do not appear. The Input Name field is the only field that appears in the Input section for data-push session types. |
|
Input data source URL.This could be an RSS feed, for example: http://rss.cnn.com/rss/cnn_topstories.rss |
|
Polling Interval (s) |
Interval, in seconds, at which the Streamer polls the input URL. |
IP multicast address of the session to be transmitted by the Streamer. |
|
Number associated with this session. Must be unique per Content Owner. |
|
Maximum data rate per second to be allocated for sending the session. |
|
The Advanced Session fields are identical to those listed in the “Streamer Session Default Field Descriptions” section. |
Table 7 lists the audio session configuration field descriptions for both input and output sources.
|
|
---|---|
IP multicast address of the session to be transmitted by the Streamer. |
|
Number associated with this session. Must be unique per Content Owner. |
|
The Advanced Session fields are identical to those listed in the “Streamer Session Default Field Descriptions” section. |
File sessions are used exclusively for EVS C-Cast integration.
To configure C-Cast integration, complete the following steps:
Step 1 Configure a file session as described below in Table 8 that lists the file session configuration field descriptions for both input and output sources.
Step 2 Configure the C-Cast time via the Text Utility Interface (TUI), as described in the “External Systems” section in the Cisco StadiumVision Mobile Streamer Administration Guide.
|
|
---|---|
Source path to the folder of files. The default is set to “/opt/sv/servers/svm/txfiles” and should not be changed. |
|
Interval, in seconds, at which the Streamer polls the input URL. |
|
IP multicast address of the session to be transmitted by the Streamer. |
|
Number associated with this session. Must be unique per Content Owner. |
|
Maximum data rate per second to be allocated for sending the session. |
|
The Advanced Session fields are identical to those listed in the “Streamer Session Default Field Descriptions” section. |
To view the statistics gathered for each session, click Status beside the desired button in the streaming session window under Active sessions. Statistics can be viewed only for active sessions. Figure 9 shows an example of a Session Statistics screen.
To stop or delete a session, complete the following steps:
To view the session content owners, complete the following steps:
|
|
|
---|---|---|
Select the desired content owner in the content owner drop-down menu in the Streaming Sessions window. |
To view or modify the session configuration, complete the following steps:
|
|
|
---|---|---|
Select the desired content owner in the content owner drop-down menu in the Streaming Sessions window. |
Note Figure 7 shows an example of the session configuration window.
This section contains descriptions of the various fields used to configure the Cisco StadiumVision Mobile Streamer.
Table 9 lists the streamer session default fields and a description of each field.
|
|
---|---|
UDP stream that is sent from the encoder (it must match the configured encoder output stream). |
|
Port used for the UDP stream that is sent from the Streamer to the clients. |
|
Port used for the UDP repair stream that is sent from the Streamer to the clients. |
|
Forward Error Correction (FEC) algorithm to be used (Basic FEC or Enhanced FEC) for each session type from the drop-down menu. Enhanced FEC is superior to Basic FEC and should be used under normal circumstances. |
|
Window of time in milliseconds over which source stream packets and repair packets are associated. For video sessions, a smaller window (e.g., 250 ms) reduces the end-to-end delay at the expense of greater exposure to burst loss. Typical range for video sessions is 600-1000 ms. The valid range is 100-30000 ms. For audio sessions, the valid range is 100-30000 ms. Recommended values for both video and audio sessions are: For data sessions, the value must be large enough to allow the transmission of all data object source and repair packets. Typical range for data sessions is 1,000-2,000 ms, depending object size and data rate. The valid range is 100-30000 ms. |
|
Amount of repair data in percentage to be sent for each Protection Window. A greater Protection Amount value provides increased robustness to packet loss at the expense of increased Wi-Fi bandwidth. Video, audio, data, and file sessions have their own default values. The valid ranges for: |
|
Period of time over which lost packets in a Protection Window are recovered. A greater Recovery Duration reduces the mobile’s peak CPU load in recovery dropped packets at the expense of increased delay before the object is recovered and eventually displayed. Video, audio, data, and file sessions have their own default values. The valid range is 0-1000 ms. |
|
StadiumVision Mobile Reporter URL (http:// reporter-ip-address :8080/reporter/upload) to which clients will periodically upload their statistics. |
|
Note The settings in the Wi-Fi Config should be set to reflect the actual configuration in the Wi-Fi network. The Streamer uses these values to shape traffic so bursts that could cause AP buffer overruns are eliminated. |
|
Set this to match the multicast buffer setting on the Wi-Fi access points (AP). A common value for this field is 50, however this number should be confirmed with the local network administrator. |
|
Set this to match the beacon interval configured in the Wi-Fi network. This value is also known as the Delivery Traffic Indication Message (DTIM). |
|
This value is calculated by the Streamer based on the configured values for Multicast Buffers and Beacon Interval. It indicates the total Wi-Fi bandwidth available for Streamer sessions. |
|
Use this field to reserve a set amount of bandwidth for data sessions. |
|
This value is calculated by the Streamer by subtracting the Max Data Bandwidth from Max Available Bandwidth, and indicates the amount of bandwidth available for video sessions. |
Cisco StadiumVision Mobile can use data and file channels to deliver a venue-wide moment of exclusivity (MoE) to clients as shown in Figure 8.
Figure 8 Delivering a Moment of Exclusivity using Cisco StadiumVision
If the same content is destined to thousands of clients it can be sent by a Streamer multicast data or file channel to all clients at the same time and can be cached for future use by the client. This can be accomplished several ways:
Note The maximum message size to Streamer is ~150 KB, maximum outbound trigger action in SVM is 128 characters.
When using the bump data channel method there are data and file size limitations to consider as shown in Table 10 .
The following are examples of a pushed and bumped data channel with the Streamer IP: 10.194.173.99.
Note Web pages can use both the push and bump methods, however due to character limitations in Cisco StadiumVision Director, the bump method is recommended.
With the 4-data channel limit in the Streamer, ideally a single data channel would be used for all data transfers to mobile clients. You can also use JSON to construct the data object and filter on the client because the Streamer does not wrap data that is sent to it.
The JSON example below sends StadiumVision Director state change data to a StadiumVision Mobile Streamer data channel in order for the data to reach all of the clients:
Below is an example of the JSON portion of the message:
In order to implement the SDK on the client, it is recommended to create a filter in order to detect one data message from another.
Note For additional information refer to the Configuring Cisco StadiumVision Director for External Triggers Guide on Cisco.com.
Cisco Stadium Vision Mobile Streamer supports redundancy via a secondary warm standby Streamer. Failover is initiated manually by the operator when needed.
To configure the initial failover setup between the two Cisco StadiumVision Mobile Streamers, complete the following steps:
Step 1 Install two Cisco StadiumVision Mobile Streamers, referred to here as primary and secondary. Assign each Cisco StadiumVision Mobile Streamer its own unique IP address.
Step 2 Configure all streams and triplets on the primary Cisco StadiumVision Mobile Streamer only.
To perform a manual failover from one Cisco StadiumVision Mobile Streamer to the other, complete the following steps:
Step 1 Copy the primary Cisco StadiumVision Mobile Streamer configuration file to your laptop using the documented backup procedure (see the “Performing a Manual Backup or Restore” section).
Note If the reason for initiating a failover is that the primary server has failed, then you may not be able to retrieve the config file. Therefore it is recommended to perform a backup every time a config change is made to the primary.
Step 2 Copy the primary config file from your laptop to secondary Streamer using the documented restore procedure (see the “Performing a Manual Backup or Restore” section).
Step 3 To failover simply stop the SVM streaming service from the TUI (see the “Services Control” section), and start the same service on the secondary.
Note Never run SVM streaming service simultaneously on both the primary and secondary Cisco StadiumVision Mobile Streamers.
Step 4 Start the relevant streaming sessions from the web UI on the secondary streamer (see the “Working With Streamer Sessions” section).
https://www.ciscoet.com/resource/guide-deploying-stadiumvision-mobile-connected-stadium-wi-fi
Figure 9 Session Statistics Window
Table 11 lists the session statistic parameters and a brief description.