Cisco StadiumVision Mobile API for Apple iOS
First Published: May 26, 2015
Revised: November 2, 2015
This chapter describes the Cisco StadiumVision Mobile SDK Release 2.1.1 for Apple iOS, and contains the following sections:
- Introduction to Cisco StadiumVision Mobile SDK for iOS
- Restrictions for the Cisco StadiumVision Mobile SDK for iOS
- Cisco StadiumVision Mobile and iOS Developer Tools
- Download and Unpack the SDK
- Get Started with the iOS Sample App
- Cisco StadiumVision Mobile Methods and Functions for iOS
- Add Cisco StadiumVision Mobile Services to an iOS App—Code Structure and Samples
- Integrate EVS C-Cast
Introduction to Cisco StadiumVision Mobile SDK for iOS
The Cisco StadiumVision Mobile iOS SDK contains the following components bundled together:
- A set of static libraries, header files
- Sample app (with a complete Xcode project) and SDK video player
- API documentation (Doxygen build)
The API uses Objective-C classes and method calls to access the StadiumVision Mobile data distribution and video playback functionality within the StadiumVision Mobile iOS SDK library.
Mobile OS Support describes the mobile operating system versions supported by the Cisco StadiumVision Mobile SDK.
For additional information, refer to the Cisco StadiumVision Mobile Release Notes available from Cisco.com at:
http://www.cisco.com/c/en/us/support/video/stadiumvision/products-release-notes-list.html
Restrictions for the Cisco StadiumVision Mobile SDK for iOS
Before you begin using theCisco StadiumVision Mobile SDK for iOS, consider the following restrictions:
Cisco StadiumVision Mobile and iOS Developer Tools
Apple iOS Build Environment Requirements lists the various iOS SDK build environment requirements.
\
|
A Mac is required to build an iOS application which includes the StadiumVision Mobile iOS SDK. |
||
Note: Other Xcode versions might work but their compatibility cannot be assured. It is recommended you use Xcode 7.x or newer to support new and existing apps.
Prerequisites
- Download and install the Apple Xcode IDE.
- In order to build and run the project, you must join or be an existing member of the Apple iOS Developer Program.
- Latest Cisco StadiumVision Mobile SDK tar.bz2 file.
Note: Contact your Cisco account team for details about how to become part of the Cisco StadiumVision Mobile SDK partner program.
Download and Unpack the SDK
To download and unpack the SDK, complete the following steps:
If you do not have this file, contact your Cisco account team for details about how to become part of the Cisco StadiumVision Mobile SDK partner program.
- Extract the downloaded package into a directory. Cisco StadiumVision Mobile SDK File Content lists the extracted content and includes a brief description.
|
Contains Doxygen API documentation that is accessible by opening the index.html file in a web browser |
|
Note: Beginning in Cisco StadiumVision Mobile SDK for iOS Release 2.1, the SDK does not include "libvoCTS.a" and "voVidDec.dat." These files are no longer required.
Note: The clean.stream file that comes bundled with the SDK contains just one video channel. To provide app developers with additional ways to test multiple channels, an additional set of clean.stream files is available. For additional information refer to Testing Your Cisco StadiumVision Mobile App available on DevNet at:
https://developer.cisco.com/site/svm/learn/testing-your-cisco-stadiumvision-mobile-app/
Get Started with the iOS Sample App
The Cisco StadiumVision Mobile SDK provided to app developers includes the source code for a iOS Sample app. The purpose of the Sample app is to demonstrate what is possible and to enable a new app developer to quickly get a working app up and running. This section contains the following:
- Build the Sample App
- Customize the Sample App
- Embed the Cisco StadiumVision Mobile SDK in an Existing App
Note: Before creating a new app, review the Cisco StadiumVision Mobile SDK Best Practices at:
Build the Sample App
To build the Sample app, complete the following steps:
- Launch Xcode .
- Under File > Open > locate and select StadiumVisionMobileSample.xcodeproj from the extracted folder contents. Click Open .
- Disable bitcode in the Build Settings > Build Options by changing the Enable Bitcode value to No as shown in the Change the Enable Bitcode Setting to No.
- Select the active scheme (iPhone 5 for example) from the iOS Simulator list as shown in Xcode—Set and Run the Active Scheme (1). To run the Sample app from an external device, connect the device to your computer, then select the device from the iOS Simulator list.
- Click the Build and then run the current scheme arrow to build and run the Sample app with the selected scheme as shown in Xcode—Set and Run the Active Scheme (2).
Note: If the external device that you want to test on does not appear in the iOS Simulator list, add the device to the list of devices in the iOS Developer Program. While Cisco StadiumVision Mobile SDK Release 2.1 and later supports iOS 64-bit, the SVM SDK for iOS only supports the 32-bit simulator. The SVM SDK does not support the 64-bit simulator.
- If the build was successful, a message appears followed by the Sample app launching in a new iOS Simulator window or on the external device as shown in Xcode—Building the Sample App.
Customize the Sample App
There are many ways to customize the Cisco StadiumVision Mobile Sample app including customizing the Default-568h@2x.png graphic file to include a logo and specific colors.
Cisco Sample App Customized Video Player
The Sample app customized video player has the following properties:
- Implemented as "MyVideoViewController".
- Extends the "SVMVideoViewController" class.
- Handles all video overlays and gestures.
- Supports single-tap gesture and "Back", "Rewind"/"Live" overlay buttons.
- Supports two-finger double-tap gesture and stats overlay.
- Uses the "MyVideoViewController~iphone.xib" to layout the screen.
- Located in the "StadiumVisionMobileSample" Xcode project folder.
The video view shown in Interface Builder is connected to the "videoView" property and is of class type "MyVideoView".
Embed the Cisco StadiumVision Mobile SDK in an Existing App
The Cisco StadiumVision Mobile SDK can be embedded into an existing app. This section contains information and examples to assist you in embedding SVM capabilities into a custom application:
- Integration Checklist
- Configuration Files
- Field of Use Configuration
- Wi-Fi Access Point Configuration
Integration Checklist
The following checklist is useful when you want to embed the Cisco StadiumVision Mobile SDK into an existing app:
|
Note: The Cisco StadiumVision Mobile SDK for iOS Release 2.1 and later does not include "libvoCTS.a" and "voVidDec.dat." These files are no longer required. |
|
Xcode Other Linker Flags
The following figure shows the Xcode build settings that apply to both the project and target settings. Xcode Build Settings
|
|
|
Required iOS Libraries
- AudioToolbox.framework
- AVFoundation.framework
- CFNetwork.framework
- CoreGraphics.framework
- CoreMedia.framework
- CoreText.framework
- EventKit.framework
- ExternalAccessory.framework
- Foundation.framework
- libresolv.dylib
- libStadiumVisionMobile.a
- libStadiumVisionMobileSender.a
- libz.dylib
- MediaPlayer.framework
- MobileCoreServices.framework
- OpenGLES.framework
- QuartzCore.framework
- Security.framework
- SystemConfiguration.framework
- UIKit.framework
Configuration Files
There are two configuration files that must be bundled with any iOS app using the StadiumVision Mobile SDK, as listed in Configuration Files.
Note: The Cisco StadiumVision Mobile SDK for iOS does not include "voVidDec.dat" that was previously included. This file is no longer required as of Release 2.1.
Field of Use Configuration
There are three "field-of-use" (also known as the triplet key) properties in the "cisco_svm.cfg" configuration file that need to be configured for each StadiumVision Mobile application. These three fields must match the channel settings in the Cisco StadiumVision Mobile Streamer for the channels to be accessible by the application:
"contentOwner": "Multi-Tenant Team-B",
Wi-Fi Access Point Configuration
The "cisco_svm.cfg" configuration file can optionally include an array of Wi-Fi AP information that will be used by the StadiumVision Mobile SDK for statistics reporting if available. Below is an example Wi-Fi AP info entry in the "cisco_svm.cfg" configuration file:
Cisco StadiumVision Mobile Methods and Functions for iOS
This section provides detailed API return types, method names, and method descriptions:
- Cisco StadiumVision Mobile iOS API Summary
- Return Status Object
- Video Player Activity API Summary
- NS Notification Events
Note: Detailed API information is available in documentation Doxygen build that is downloaded with the SDK. Navigate to the extracted folder contents, open the html folder. Double-click index.html to launch the documentation in a web browser.
Cisco StadiumVision Mobile iOS API Summary
Cisco StadiumVision Mobile iOS API Summary summarizes the iOS API library.
Return Status Object
Each API call returns a SVMStatus object whenever applicable. SVMStatus class lists the SVMStatus object fields.
Stats API Hash Keys and Descriptions lists the hash keys and description for the Stats API.
Video Player Activity API Summary
The "SVMVideoVideoController" class can be extended and customized. Video View Controller API Summary lists the SVMVideoPlayerActivity API methods and descriptions. Additional API methods and details are listed in the Doxygen build.
NS Notification Events
The StadiumVision Mobile SDK broadcasts the following iOS NSNotification events for use by the client application (listed in NSNotification Event Properties).
The following source code registers to receive the Cisco video notifications:
#include "StadiumVisionMobile.h"
// register to handle the video buffering events
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(onVideoEvent:)
name:kSVMVideoEventNotification
The following source code handles the Cisco video notifications:
#include "StadiumVisionMobile.h"
// video event notification handler
(void)onVideoEvent:(NSNotification*)notification {
// get the passed "SVMEvent" object
SVMEvent *event = [notification object];
// determine the video event type
case kSVMEventTypeVideoBufferingActive:
// activate the UI "buffering" indicator
case kSVMEventTypeVideoBufferingInactive:
// deactivate the UI "buffering" indicator
The following example shows how to subscribe to receive the video player broadcast notifications:
// subscribe to receive video channel state change notifications
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(onVideoChannelStateChanged:)
name:kSVMVideoPlayerChannelStateChange
The following example shows how to parse the video player broadcast notifications for (1) the video channel name and (2) the video channel state:
// get the video channel state dictionary from the notification
NSDictionary *stateDict = [notify userInfo];
NSString *videoChannelName = [stateDict objectForKey:kSVMVideoPlayerChannelNameKey];
// get the video channel state
NSString *videoChannelState = [stateDict objectForKey:kSVMVideoPlayerChannelStateKey];
// determine the video channel state
if ([videoChannelState isEqualToString:kSVMVideoPlayState] == YES) {
// video player is now playing
NSLog(@"### VIDEO PLAYER: PLAYING");
} else if ([videoChannelState isEqualToString:kSVMVideoStopState] == YES) {
// video player is now stopped
NSLog(@"### VIDEO PLAYER: STOPPED");
Video Player State Flags
The SVM video player class ("SVMVideoViewController") provides a set of state flags that the inherited video player class (ie: "MyVideoViewController") can use to monitor the current video player state:
- BOOL isOpen;
- BOOL isPlaying;
- BOOL isAppActive;
- BOOL isVisible;
- BOOL isBackgroundPlaybackAllowed;
- BOOL isEventsRegistered;
- BOOL isEventHandlersRegistered
Video Player State Flags provides a description of each state flag provided by the StadiumVision Mobile video player ("SVMVideoViewController"):
Video Player Background Audio
Beginning in Cisco StadiumVision Mobile SDK Release 1.3, the SVM video player ("SVMVideoViewController") provides a mode that allows the video player to continue rendering the audio and video channels when the video player view has lost focus. This mode allows the audio to still be played even when the user navigates away from the video player screen (view controller) to a different app screen; causing the video player to be hidden.
The background audio mode is disabled in the "SVMVideoViewController" by default. The following example shows how to set the "SVMVideoViewController" mode that allows the video player to continue rendering audio and video when the "SVMVideoViewController" loses focus (is not visible):
// create the video view controller
self.videoViewController = [[MyVideoViewController alloc] init];
// allow the video player to continue playing when the video view disappears
[self.videoViewController allowPlaybackWhenViewDisappears:YES];
Video Player Channel Inactive Callback
To detect that a currently playing video channel has become invalid (due to Streamer server admin changes), the SVM video player ("SVMVideoViewController") provides a callback to tell the video player sub-class (ie: "MyVideoViewController") that the currently playing channel is no longer valid.
When a channel becomes invalid, playback of the video channel is automatically stopped.
To receive these callbacks, the "onCurrentChannelInvalid" method must be overridden by the 'SVMVideoViewController' sub-class (ie: "MyViewViewController"). The following example shows the method signature and implementation of this overridden callback method:
// OVERRIDDEN by the 'SVMVideoViewController' sub-class; indicates that the current channel is invalid
- (void)onCurrentChannelInvalid
NSLog(@"Current channel is no longer valid: dismissing video view controller");
Receiving Service Up and Down Notifications
Beginning in Release 2.0, Cisco StadiumVision Mobile SDK includes a mechanism to determine if the Cisco StadiumVision Mobile service is available or not. The SDK provides an indicator to the application indicating if the StadiumVision Mobile service is up or down. This indication should be used by the application to indicate to the user whether the StadiumVision Mobile service is available or not. Service is declared ‘down’ by the SDK when any of the following are true:
- The SVM SDK detects that the video quality is poor.
- The SVM SDK detects that no valid, licensed channels are available.
- The mobile device’s Wi-Fi interface is disabled.
Poor video quality can occur when the user is receiving a weak Wi-Fi signal causing data loss. There are two different ways that the iOS app can get the "Service State" from the SVM SDK:
- Register to receive the "Service Up/Down" notifications.
- Fetch the current service state from the SDK on-demand.
When the app receives the "Service Down" notification, the SDK will supply a bitmap containing the reasons why the service was declared as ‘down’ by the SDK. The ‘reasons’ bitmap is given in Service Down Reason Notification:
Note: For additional Service Down Notification details, refer to, review the Cisco StadiumVision Mobile SDK Best Practices at:
https://developer.cisco.com/site/svm/learn/best-practices/
Back to top of pageThe following example shows how to register to receive the "Service Up/Down" notifications from the StadiumVision Mobile SDK:
#import "StadiumVisionMobile.h"
// subscribe to receive service state up / down change notifications
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(onServiceStateChanged:)
name:kSVMServiceStateChangedNotification
// handle the received service state notifications
- (void)onServiceStateChanged:(NSNotification*)notify
// get the service state dictionary from the notification
NSDictionary *serviceStateDict = [notify userInfo];
// get the service state integer value
NSNumber *serviceStateNumber = [serviceStateDict objectForKey:kSVMServiceStateObjectKey];
NSUInteger serviceState = [serviceStateNumber unsignedIntegerValue];
// if the service state is down
if (serviceState == kSVMServiceStateDown) {
NSLog(@"*** SERVICE STATE: DOWN");
// get the service state down reasons bitmap
NSNumber *reasonsNumber = [serviceStateDict objectForKey:kSVMServiceStateChangeReasonsObjectKey];
NSUInteger reasonsBitmap = [reasonsNumber unsignedIntegerValue];
// determine the reason(s) why the service state went down
if (reasonsBitmap & kSVMServiceDownReasonSDKNotRunning) {
NSLog(@"SERVICE DOWN: SVM SDK was stopped");
} else if (reasonsBitmap & kSVMServiceDownReasonWiFiDown) {
NSLog(@"SERVICE DOWN: WiFi connection is down");
} else if (reasonsBitmap & kSVMServiceDownReasonNoChannels) {
NSLog(@"SERVICE DOWN: No valid licensed SVM channels available");
} else if (reasonsBitmap & kSVMServiceDownReasonPoorQuality) {
NSLog(@"SERVICE DOWN: Poor quality conditions detected");
// show the service down message
[self showServiceDownMessage];
} else if (serviceState == kSVMServiceStateUp) {
NSLog(@"*** SERVICE STATE: UP");
Getting the Current Service Up or Down State On Demand
The "getServiceState" API method can be used to fetch the current service state from the SDK. The method signature of the "getServiceState" API call is given below:
// api call to fetch the current svm 'service state' on-demand
- (SVMServiceState)getServiceState;
The following example show how to fetch the current service state from the SVM SDK using the "getServiceState" API call:
#import "StadiumVisionMobile.h"
StadiumVisionMobile *svm = [StadiumVisionMobile sharedInstance];
// get the current svm service state
SVMServiceState state = [svm getServiceState];
// determine the current service state
if (serviceState == kSVMServiceStateUp) {
NSLog(@"*** SERVICE STATE: UP");
} else if (serviceState == kSVMServiceStateDown) {
NSLog(@"*** SERVICE STATE: DOWN");
In-Venue Detection
Cisco StadiumVision Mobile SDK Release 1.3 provides a mechanism to detect whether the mobile device is connected within the SVM-enabled venue or not. There are two different ways that the iOS app can get this "In-Venue Detection" state from the SVM SDK:
Receiving In-Venue Detection Notifications
The following example shows how to register to receive the "Service Up/Down" notifications from the SVM SDK:
// subscribe to receive in-venue connection change notifications
[[NSNotificationCenter defaultCenter] addObserver:self
selector:@selector(onVenueConnectionChanged:)
name:kSVMVenueConnectionUpdateNotification
// handle the venue connection changed event
- (void)onVenueConnectionChanged:(NSNotification*)notify
// get the in-venue detection dictionary from the notification
NSDictionary *inVenueDetectionDict = [notify userInfo];
// get the in-venue detection value
NSNumber *inVenueDetectionNumber = [inVenueDetectionDict objectForKey:kSVMVenueConnectionStateObjectKey];
BOOL isConnectedToVenue = [inVenueDetectionNumber boolValue];
// log whether we are inside the venue
NSLog(@"###### Venue Connection Updated: %@", (isConnectedToVenue ? @"INSIDE" : @"OUTSIDE"));
Get the Current In-Venue State On-Demand
The "isConnectedToVenue" API method can be used to fetch the current in-venue state from the SDK. The method signature of the "isConnectedToVenue" API call is given below:
// returns whether the device is connected to the licensed SVM venue or not
The following example shows how to fetch the current service state from the SVM SDK using the "getServiceState" API call:
// get a reference to the svm api
StadiumVisionMobile *svm = [StadiumVisionMobile sharedInstance];
// get whether the device is currently connected to the SVM licensed venue
BOOL isConnectedToVenue = [svm isConnectedToVenue];
// log whether the device is currently connected to the SVM licensed venue
NSLog(@"###### Venue Connection State: %@", (isConnectedToVenue ? @"INSIDE" : @"OUTSIDE"));
Set the SDK Configuration at Run-Time
Previously, the Cisco StadiumVision Mobile SDK could only be configured by using a JSON-formatted config file ("cisco_svm.cfg") bundled within the iOS app. Beginning in Release 2.0, the application can set the SDK configuration at run-time through an API method. This allows the application to dynamically configure the SDK. For example, the application can fetch the SDK configuration information from a network connection, and then pass that configuration to the SDK.
Two different methods are provided for setting the SDK configuration at run-time:
The following example shows how to set the SDK configuration using the "setConfig" API method:
#import "StadiumVisionMobile.h"
// get the stadiumvision mobile api instance
StadiumVisionMobile *svmInstance = [StadiumVisionMobile sharedInstance];
// create the config dictionary with the set of licensing keys
NSMutableDictionary *configDict = [[[NSMutableDictionary alloc] init] autorelease];
NSMutableDictionary *licenseDict = [[[NSMutableDictionary alloc] init] autorelease];
[licenseDict setObject:@"MyVenueNameKey" forKey:@"venueName"];
[licenseDict setObject:@"MyContentOwnerKey" forKey:@"contentOwner"];
[licenseDict setObject:@"MyAppDeveloperKey" forKey:@"appDeveloper"];
[configDict setObject:licenseDict forKey:@"license"];
// update the stadiumvision mobile configuration
[svmInstance setConfig:configDict];
Scalable File Distribution
The Cisco StadiumVision Mobile SDK libraries will support file channels that are easily accessible to the mobile client application. Scalable File Distribution and Service API Summary lists the Cisco StadiumVision Mobile scalable file distribution API.
Data Channels
Data Distribution and Service API Summary lists the Cisco StadiumVision Mobile data channel APIs.
Add Cisco StadiumVision Mobile Services to an iOS App—Code Structure and Samples
This section describes the Cisco StadiumVision Mobile SDK workflow and contains the following sections:
- Cisco StadiumVision Mobile SDK Handled Events
- Starting the SDK
- Setting the Log Level
- Getting the SDK Version String
- Displaying the Device UUID
- Shutting Down the SDK
- Video Player View Controller Customization
- Video Channels
- Data Channels
Cisco StadiumVision Mobile SDK Handled Events
The Cisco StadiumVision Mobile SDK automatically handles the following events:
- Dynamic video channel discovery and notification
- Dynamic data channel discovery and notification
- Automatic SDK shutdown/restart in response to Wi-Fi up/down events
- Automatic SDK shutdown/restart in response to iOS life-cycle events
- Management of multicast network data threads
- On-demand management of video/audio decoding threads
- Automatic statistics reporting to the StadiumVision Mobile Reporter server
Starting the SDK
The StadiumVision Mobile SDK needs to be started at the application initialization by calling the "start" API method as in the following example:
#import "StadiumVisionMobile.h"
// get a reference to the StadiumVision Mobile API
StadiumVisionMobile *svm = [StadiumVisonMobile sharedInstance];
// start the StadiumVision Mobile SDK
Setting the Log Level
Sets the logging output level of the SDK, with the "DEBUG" level being more verbose than the "INFO" level. An example follows:
// start method sets logs to INFO by default
StadiumVisionMobile *svm = [StadiumVisionMobile sharedInstance];
[svm setLogLevel:SVM_API_LOG_DEBUG];
Getting the SDK Version String
The example below gets the StadiumVision Mobile SDK version string:
// get a reference to the api object
StadiumVisionMobile *svm = [StadiumVisonMobile sharedInstance];
NSString *sdkVersion = [svm version];
Displaying the Device UUID
The Cisco StadiumVision Mobile SDK is unable to include the MAC
address in the periodic stats that it sends to the Cisco StadiumVision Mobile Reporter
because Apple does not permit applications to access any device information that can be used
to identify that device or its owner. As a substitute for the MAC address, the SDK instead
includes a SVM Device UUID (universally unique identifier) that is unique for every device.
The UUID allows Reporter data to be correlated with a specific device. In order for the
correlation to work, the mobile app must display the UUID somewhere in its menu system (for
example on the About or Help tabs).
The app can retrieve the UUID from the SDK via the code sample below. The getDeviceUUID
method is documented in the iOS SVM header file.
StadiumVisionMobile *svm = [StadiumVisionMobile sharedInstance];
NSString *deviceUUID = [svm getDeviceUUID];
NSLog(@"Device UUID is %@", deviceUUID);
Note: The Cisco StadiumVision Mobile Device UUID should not be confused with the Unique Device Identifier (UDID) that is displayed in iTunes.
Shutting Down the SDK
The StadiumVision Mobile SDK automatically shuts-down and restarts based upon the iOS life-cycle notifications (NSNotifications). The client iOS application does not need to explicitly stop and restart the StadiumVision Mobile SDK. This ‘shutdown’ API is provided in case a customer use-case requires an explicit SDK shutdown.
// get a reference to the api object
StadiumVisionMobile *svm = [StadiumVisonMobile sharedInstance];
// shutdown the StadiumVision Mobile SDK
Video Player View Controller Customization
This section describes how to customize the video player, and contains the following sections:
- Default Cisco Video Player View Controller
- Customized Video Player
- Cisco Sample App Customized Video Player
Customized Video Player
To customize the video player, extend the "SVMVideoViewController" base class as in the following example:
#import "SVMVideoViewController.h";
@interface MyVideoViewController : SVMVideoViewController {
Video Player Customization
Video Channels
This section describes the Cisco StadiumVision Mobile SDK video channels and contains the following sections:
- Presenting the Video Channel List
- Playing a Video Channel
- Getting the Video Channel List
- Seeking Within the Video Buffer
- Video Player View Controller Customization
Presenting the Video Channel List
SVMChannel Object Properties lists the "SVMChannel" video channel objects containing all of the information needed to display the channel list to the user.
Playing a Video Channel
The example below demonstrates these actions:
- Selects a channel from the locally saved channel list.
- Presents the video view controller modally.
- Commands the video view controller to play the selected channel.
// get the user-selected video channel object
SVMChannel *selectedChannel = [videochannelList objectAtIndex:0];
NSLog(@"Selected Video Channel = %@", selectedChannel.name);
// create the video view controller
MyVideoViewController *myVC = [[MyVideoViewController alloc] init];
// present the modal video view controller
myVC.modalTransitionStyle = UIModalTransitionStyleCrossDissolve;
[self presentModalViewController:myVC animated:YES];
// play the selected video channel
[myVC playVideoChannel:selectedChannel];
Getting the Video Channel List
The client application registers to receive callback whenever the video channel list is updated, as in the following example:
// register to receive video channel list updates
StadiumVisionMobile *svm = [StadiumVisonMobile sharedInstance];
[svm addVideoChannelListDelegate:self];
The StadiumVision Mobile SDK will callback the client application with any video channel list updates.
#import "StadiumVisionMobile.h"
// implement the "SVMChannelListObserver" protocol
@interface MyViewController : UIViewController <SVMChannelListObserver>
// video channel handler (array of 'SVMChannel' objects)
-(void)onVideoChannelListUpdated:(NSArray*)channelList;
Seeking Within the Video Buffer
The last 30 seconds of played video is stored in the device RAM. The following example jumps backwards 20 seconds in the video buffer (instant replay).
// get a reference to the api object
StadiumVisionMobile *svm = [StadiumVisionMobile sharedInstance];
[svm rewindForDuration:-20000];
Back to top of page
The example below jumps back to the top of the video buffer ("live" video playback):
// get a reference to the api object
StadiumVisionMobile *svm = [StadiumVisionMobile sharedInstance];
// play at the "live" video offset
Data Channels
This section describes the Cisco StadiumVision Mobile SDK data channels and contains the following sections:
Getting the Data Channel List
In the following example, the client application registers to receive callback whenever the data channel list is updated.
// register to receive data channel list updates
StadiumVisionMobile *svm = [StadiumVisonMobile sharedInstance];
[svm addDataChannelListDelegate:self];
In this example, the StadiumVision Mobile SDK will callback the client application with any data channel list updates:
#import "StadiumVisionMobile.h"
// implement the "SVMChannelListObserver" protocol
@interface MyViewController : UIViewController <SVMChannelListObserver>
// data channel handler (array of 'SVMChannel' objects)
(void)onDataChannelListUpdated:(NSArray*)channelList;
Observing a Data Channel
In the following example, the registered class needs to implement the "SVMDataObserver" protocol:
@interface DataChannelViewController : UIViewController <SVMDataObserver>
In this example, the "onData:withChannelName" method is called to push the received data to the registered class:
-(void)onData:(NSData*)data withChannelName:(NSString *)channelName {
// convert the data bytes into a string
NSString *dataStr = [[NSString alloc] initWithBytes:[data bytes]
encoding:NSUTF8StringEncoding];
// display the data bytes and associated channel name
NSLog(@"ChannelListViewController: onData callback: "
"channelName = %@, data = %@", channelName, dataStr);
Integrate EVS C-Cast
Note: Cisco StadiumVision Mobile is supported with EVS C-Cast version 2.x only. EVS C-Cast version 3.x is not supported.
The steps below describe a high level workflow of how an Cisco StadiumVision Mobile powered C-Cast app gains access to the XML timeline and media files.
- Register a callback to be notified when a file channel becomes available, using addFileChannelDelegate
- Register to receive the channel notification using
[svm addFileChannelObserver:self forChannelName:@"something"] - (Optional) Listen for file channel list updates and
potentially register using
(void)onFileChannelListUpdated:(NSMutableDictionary *)fileChannelList {} - Handle the file reception (movies/thumbnails/timeline) using
(void)onFile:(NSData *)file withChannelName:(NSString *)channelName {} - Check if a file channel is already available, using getFileChannelListArray
- If a channel is already available or when a callback notification is received, register a file channel observer, using addFileChannelObserver
- Check if a file with the name ccast-timeline.xml is already available, using getFileDistributionLocalFilename
- If ccast-timeline.xml is not yet available wait for additional files to arrive, using onFile(). Each time onFile() is called do a corresponding check with getFileDistributionLocalFilename to see if the new file is ccast-timeline.xml.
- Once ccast-timeline.xml has been received, parse it using the steps in chapter 5 (How to build the media path) of the C-Cast API spec, then build the media path for all media files. Contact James Stellphlug (j.stellpflug@evs.com) to obtain the C-Cast API documentation.
- For each file media path, remove the path prefix so that
only the filename remains. For example:
http://www.mydomain.com/videos/abc/def/ghi/abcdefghijklmnopqrstuvwxyz123456_hls-ipad.m3u8
becomes
abcdefghijklmnopqrstuvwxyz123456_hls-ipad.m3u8 - For each filename cycle through onFile() and getFileDistributionLocalFilename until all files have been received.
- Be prepared for ccast-timeline.xml to change at any time. Repeat steps 7-9 whenever it changes.