EdgeCast Networks Inc. Flash Media Streaming Administration Guide

Transcription

1 EdgeCast Networks Inc. Flash Media Streaming Administration Guide

2 Disclaimer Care was taken in the creation of this guide. However, EdgeCast Networks Inc. cannot accept any responsibility for errors or omissions. There are no warranties, expressed or implied, including the warranty of merchantability or fitness for a particular purpose, accompanying this product. Copyright Information EdgeCast is a registered trademark of EdgeCast Networks Inc. Adobe, Flash Media Live Encoder, and Flash are registered trademarks of Adobe Systems Incorporated. JW Player is a registered trademark of LongTail Video. Flowplayer is a registered trademark of Flowplayer Ltd. About This Guide Flash Media Streaming Administration Guide Version /12/ EdgeCast Networks Inc. All rights reserved.

3 Table of Contents Flash Media Streaming... 1 Overview... 1 Types of Flash Media Streaming... 1 Live StreamCast... 2 Overview... 2 Live StreamCast Requirements... 4 Setting Up a Basic Live StreamCast... 4 Sample Flash Player Code... 7 Archiving Your Stream... 7 Digital Video Recording (DVR)... 8 Setting up DVR Functionality... 9 Testing Your Live StreamCast On-Demand Streaming (RTMP) Overview On-Demand Requirements Setting Up Video On-Demand Sample Flash Player Code Dynamic Stream Switching Setting Up Multi-bit Rate On-Demand Content Loading On-Demand Content Purging On-Demand Content Automated Purging Through Content Expiration Manually Purging Files Masking the URL of a CDN Origin Server (CNAME) Testing Video On-Demand Securing Your Flash Media Table of Contents EdgeCast Page i

4 Overview Preventing the Unauthorized Viewing of Your Flash Media Using Tokens to Secure Flash Media Authenticating Your SWF File Encrypting Your Stream (RTMPE) Preventing the Unauthorized Publishing of Flash Media Appendix Migrating from Live Streaming to Live StreamCast Updating your Encoder's Configuration Publishing Point URL Stream Name Updating your Flash Player Implementation Updating HTTP Client Links to your Stream Announcing your Stream to our Servers Glossary Table of Contents EdgeCast Page ii

5 Flash Media Streaming Overview Flash media can be streamed either through Flash Media Communication Protocol (RTMP) or HTTP protocol. This chapter will explain the differences between these two methods and the different types of stream configurations that you can employ. Additionally, we will provide detailed instructions on how to secure and archive your Flash media. Types of Flash Media Streaming We offer three different methods through which you can stream your Flash media, which are Live StreamCast, On-Demand, and HTTP Progressive Download. Live StreamCast and On- Demand use Flash Media Communication Protocol (Real Time Messaging Protocol or RTMP) to stream Flash media to your clients. HTTP Progressive Download uses standard HTTP protocol to stream flash media. The main advantages that RTMP brings to streaming Flash media is that it is more secure and it supports live streaming. The main advantage of HTTP Progressive Download is that it is easy to implement, the HTTP protocol is more widely supported through firewalls, and it has a more resilient infrastructure. Note: A fourth method for streaming Flash media is Live Streaming (Legacy), which also uses RTMP. However, this feature will shortly undergo an end-of-life transition. Therefore, we strongly encourage you to use Live StreamCast instead. However, if you still want to use Live Streaming (Legacy), then you should follow the instructions set forth for Live StreamCast unless information specific to Live Streaming (Legacy) is provided. For example, an FCSubscribe call should not be used for Live Streaming (Legacy). Note: If you are currently using Live Streaming (Legacy) and you would like information on how to migrate to Live StreamCast, please refer to the Appendix. Note: For more information on HTTP Progressive Download, please refer to the HTTP Large Object Administration Guide. Flash Media Streaming EdgeCast Page 1

6 Live StreamCast Overview Live StreamCast provides the capability to efficiently stream live video to your clients. The following diagram demonstrates the process through which a live video stream is transmitted to your clients. Note: For the purpose of simplifying this example, only the North American portion of our world-wide network is displayed. How Live Video Streams to Your Client The above diagram demonstrates four different steps that take place when streaming live video to your clients. These steps are: 1. An encoder encodes a video and makes it available to a publishing point. 2. The publishing point broadcasts the live stream so that it can be pulled from any of our worldwide Points of Presence (POPs). 3. When requested by a user, the stream is pulled from the publishing point to the POP closest to each request. 4. All requests for that live stream from a particular region are served by a single POP. The live stream is delivered to the client through his/her ISP. Flash Media Streaming EdgeCast Page 2

7 Encoding Video The first step for serving a live stream occurs when your encoder encodes your live video and makes it available to a publishing point. We recommend that you choose the publishing point closest to the computer hosting your encoder. This will ensure optimal data transfer speed between your encoder and our network. In the above diagram, the closest publishing point to the encoder is North America, West Coast United States. Live Stream Broadcast Once the encoded video has been pushed to our publishing point, it is ready to be broadcast as a live stream by our ingest server. Our publishing points have been strategically placed in very close proximity to our POPs. This allows your live streams to immediately take advantage of our worldwide network. In turn, this ensures optimal data transfer speed between the publishing point and our POPs. In the above diagram, the closest POP to the publishing point is located in Los Angeles. Pulling the Live Stream Once a live stream is being broadcast, it is ready to be distributed throughout our worldwide network upon the request of one of your clients. The North American portion of our worldwide network is represented by orange lines in the above diagram. When a client requests a live stream, the POP closest to your client will retrieve the stream from the designated publishing point. In the above diagram, there are four clients trying to view the live stream. These clients are located close to Seattle and Atlanta. The Seattle and Atlanta clients will receive the live stream through the Seattle POP and Atlanta POP, respectively. By sending the stream through our network and bypassing traditional Internet communication routes, we can ensure the efficient transmission of your stream and reduced bandwidth load on your network. Live Stream Delivery The last leg involved in the delivery of your live stream requires that your client s ISP to deliver the live stream from our POP. This is indicated by a purple line in the above diagram. Each of your clients will then use a Flash player to enjoy uninterrupted live streaming. When a client requests a live video stream, a check is performed to find out whether another client in the same region is currently viewing it. If it is currently being viewed in the same region, then that client will instantly be able to take advantage of the live stream. Securing Live Streams This is the basic setup for streaming a live video feed through our worldwide network. In addition to simply improving the performance of your live video feeds, you can protect them in many different ways. The protection that we offer prevents the illegal modification or viewing of your video feeds. For more information on how you can protect your live streams, please refer to the Securing Your Flash Media chapter. Flash Media Streaming EdgeCast Page 3

8 Live StreamCast Requirements Live StreamCast requires an encoder, access to the content delivery network, and a Flash player. The requirements for each of these items are listed below. System Requirements: Encoder: We require that you use Adobe Flash Media Live Encoder 3.0 or higher. The system requirements for this computer are determined by your encoder and the number of stream instances it will broadcast. For more information on system requirements or the configuration of your encoder, please refer to Adobe s web site. Content Delivery Network: We provide publishing servers that will ingest your live stream and transmit it to all necessary edge servers for delivery to your end-users. Flash Player: Our service is compatible with any Flash player that supports the FCSubscribe call and can handle a stream encoded by Flash Media Live Encoder 3.0 or higher. Note: To find out whether a Flash player supports the FCSubscribe call, please contact the software manufacturer of your desired player. Note: Our testing indicates that the following versions of JW Player work with Live StreamCast: versions 4.6, 5.1, 5.2, and 5.3. However, it is important to note that we do not provide Flash player support. If you experience issues with your Flash player implementation, please contact that player's software manufacturer for technical support. Note: If you would like to use Adobe Flash Media Live Encoder 2.5, then you will not be able to take advantage of Server-side archiving or DVR functionality. Additionally, you will have to use Live Streaming (Legacy). For setup information, please refer to the Setting Up a Basic Live StreamCast section below. Setting Up a Basic Live StreamCast There are two main elements to a basic configuration of Live StreamCast. These elements are an encoder and the Flash client. We will discuss each one of these elements below. Encoder Live StreamCast requires that you set up a computer where the feed will be encoded with Flash Media Live Encoder (FMLE) 3.0 or higher. As a part of this configuration, you will need to indicate where to publish your live stream. You should specify the location of the publishing point closest to your encoder. The following table provides the URLs for our publishing points. Flash Media Streaming EdgeCast Page 4

9 Publishing Point North America: East Coast U.S. North America: West Coast U.S. Europe Australia URL rtmp://fso.dca.xxxx.edgecastcdn.net/20xxxx/path rtmp://fso.lax.xxxx.edgecastcdn.net/20xxxx/path rtmp://fso.ams.xxxx.edgecastcdn.net/20xxxx/path rtmp://fso.syd.xxxx.edgecastcdn.net/20xxxx/path Tip: The publishing point URL should not end with a forward slash (/). Tip: You may also view the base URL for the publishing point (FMS URL) closest to your encoder from the Flash Streaming page on the Flash tab of the MCC. Tip: We support the use of a backup publishing point. If one publishing point should experience technical issues, a backup publishing point would take over the task of publishing the stream. In Adobe Flash Media Live Encoder 3.1, this option can be set through the Backup URL option. Note: You should replace xxxx with your CDN account number. Your CDN account number can be found in the upper-right hand corner of the MCC. You should also replace Path with the path to the folder where you would like to publish your stream. Note: If you are using Live Streaming (Legacy), then you should not use the above URLs. You should refer to the URLs listed on the Flash Streaming page, which can be found on the Flash tab of the MCC. The folder where you will publish your live stream is important for two reasons. The first reason has to do with Server-side archiving and DVR features. Both of these features allow you to store a live feed on a CDN origin server. If you do not publish to the root folder, the specified publishing point determines where the file will be archived. The second reason involves our reporting features. One of our reports allows you to view bandwidth and client usage by folder. If you publish certain types of streams to different folders, then you can view statistics by stream type. Note: If the publishing point URL points to the root folder, then archived streams will be stored in the _definst_ folder. This folder can be found directly off the root folder of the CDN origin server. Tip: The publishing point can point to a path that does not already exist. Your live stream will publish and the reporting feature will log information correctly, regardless of whether the path already exists. However, the folder will not be created on our CDN origin server unless you have enabled the Server-side archiving feature. Another important thing to keep in mind when pointing the encoder to the publishing point is that you will need to specify a Live Authentication key as a part of the stream name. A Live Authentication key ensures that only you can create or publish streams from your account. The proper format for the stream name when specifying the publishing point is: StreamName? LiveAuthenticationKey Flash Media Streaming EdgeCast Page 5

10 For example, if you decide that you would like to call your stream MyStream and your global Live Authentication key is MyPrivateKey, then your actual stream name would be MyStream?MyPrivateKey. If a Live Authentication key is not included when specifying the publishing point on your encoder, then you will not be able to stream your video. Note: For more information on how Live Authentication keys work, please refer to the Preventing the Unauthorized Publishing of Flash Media section below. Note: If the Server-side archiving feature is currently enabled, then the stream name determines the base name of the file that will be stored on the server and the video format that will be used. For more information, please refer to the Archiving Your Stream section. Note: If you would like to use Flash Media Live Encoder 2.5, you will have to use a different delimiter when specifying the Live Authentication key. Instead of using a question mark, you will have to use a forward slash (i.e. StreamName/LiveAuthenticationKey). Additionally, you will have to use Live Streaming (Legacy). Keep in mind that Server-side archiving and DVR features are not supported when a forward slash is used as a token delimiter. Flash Player Live StreamCast requires that you specify three different elements when implementing your Flash player. These elements are a Player URL, a stream name, and FCSubscribe. Player URL: The Player URL is the path to the stream on our CDN server. The notation for this path is provided below. Please remember to replace xxxx with your CDN account number. You should also replace Path with the path to the folder to which your encoder is publishing. rtmp://fml.xxxx.edgecastcdn.net/20xxxx/path Stream Name: The stream name is the name of the stream, as defined in the encoder. Make sure that you do not include the Live Authentication key. You should also not include a question mark as a part of the stream name unless you are taking advantage of Token-Based Authentication. Token-Based Authentication: If you have enabled Token-Based Authentication for Flash media streaming, then you will need to append a question mark (?) followed by the token generated from the primary encryption key. For example, if your stream name is WebCam01 and the token corresponding to your primary encryption key is a4fbc3710fd3449a7c99984d1b86603c22be1006d830b, then you would specify WebCam01?a4fbc3710fd3449a7c99984d1b86603c22be1006d830b as your stream name. For detailed information, please refer to the Token-Based Authentication User Guide, which is available from the Media Control Center (MCC). Flash Media Streaming EdgeCast Page 6

11 FCSubscribe: FCSubscribe is a call used to determine when a connection starts or stops. You will need to set FCSubscribe to true when implementing your Flash player. The manner in which you can set this method varies according to the Flash player that you are using. To find out whether a Flash player supports FCSubscribe or how to set it, please contact the software manufacturer of your desired player. Tip: The Player URL path can also be found on the Flash Streaming page of the Flash tab in the MCC. Reminder: The default port used for the RTMP and RTMPE protocols is If your client s Flash player does not allow communication through port 1935 and you have enabled tunneling, then you will be able to send your stream through the HTTP protocol using port 80. Sample Flash Player Code Sample code can be viewed from our Knowledge Base for the following video players: Live StreamCast: JW Player 5.3 Live StreamCast: Flowplayer 3.2 Live Streaming (Legacy): JW Player 5.1 Live Streaming (Legacy): Flowplayer 3.2 Archiving Your Stream A Flash stream can be recorded on a CDN origin server as it is being streamed. One use of this feature is to provide on-demand capabilities for Flash content that was originally streamed live. Note: Live streams are archived on a CDN origin server to a path that replicates the origin path specified in the publishing point URL. For example, if your publishing point is rtmp://fso.lax.xxxx.edgecastcdn.net/00xxxx/videos/july/2010, then the relative path on the CDN origin server would be Videos/July/2010. By default, Flash streams are saved as FLV files. However, you have the option to save them using either the H.264 F4V or MP4 file format. If you prefer to use a different file format, then you will need to use the following format when setting the stream name in your preferred encoder: mp4:streamname.f4v?liveauthenticationkey mp4:streamname.mp4?liveauthenticationkey When archiving your streaming media, you have the option to either append or overwrite your previously recorded files when your stream is interrupted. This capability is controlled by the Enable Appending option from the Advanced Settings Server Side Archiving page of the Flash tab in the MCC. By default, the name for your archived file will be one of the following: Flash Media Streaming EdgeCast Page 7

12 Appending: StreamName.append.ext Overwriting: StreamName.ext Note: If the specified ingest server is unable to resume encoding your video after a stream interruption, then a new archived file will be created using this format: StreamName.#.ext (e.g. Demo.1.flv) or StreamName.append.#.ext (e.g. Demo.append.1.flv). The term ext refers to the file name extension that will be assigned to your archived file. This can either be FLV, F4V, or MP4, depending on the type of file format used to archive your Flash media. Note: Another way to archive a live stream is through our DVR feature. However, the Serverside archiving and DVR features cannot be enabled simultaneously. By default, the Server-side archiving feature is enabled on your account. If you would like to disable it and enable the DVR feature, please contact your CDN account manager. Digital Video Recording (DVR) Important: We are currently providing early access to DVR playback functionality. This means that the feature set and configuration provided for this feature may change upon release. Note: DVR functionality is only available for Live StreamCast. DVR functionality can be enabled for a live Flash stream. This means that if your customers are using a DVR-enabled player, then they will be able to pause, rewind, and fast forward a live video stream. Additionally, once your live stream ends, it will be archived as a FLV, F4V, or MP4 file. You can choose the desired file format when setting the stream name in your preferred encoder: StreamName?LiveAuthenticationKey mp4:streamname.f4v?liveauthenticationkey mp4:streamname.mp4?liveauthenticationkey Note: If an extension is not specified (as shown in the first item in the list), then the file will be archived using the default FLV file format. The default format for the name of the archived file is: StreamName.ext (e.g. Demo.flv). Typically, our ingest server will append to an existing archived file when a stream is interrupted. However, if the original ingest server is unable to resume encoding your video after a stream interruption, then a new archived file will be created using this format: StreamName.#.ext (e.g. Demo.1.flv, Demo.2.flv, and Demo.3.flv). Live streams are archived on a CDN origin server to a path that replicates the origin path specified in the publishing point URL. For example, if your publishing point is rtmp://fso.lax.xxxx.edgecastcdn.net/00xxxx/videos/july/2010, then the relative path on the Flash Media Streaming EdgeCast Page 8

13 CDN origin server would be Videos/July/2010. The exception to this rule is when your publishing point is set to the root folder. This type of configuration will cause your files to be archived to a folder called "_definst_." Note: There is approximately a 20 minute delay between the end of a live stream and when it will be archived on a CDN origin server. Setting up DVR Functionality Before you can take advantage of the DVR feature, you will need to contact your CDN account manager to disable Server-side archiving and enable the DVR functionality. Once the DVR feature has been enabled for your account, no further CDN configuration is required. However, you will need to configure your encoder to support DVR functionality and you will need to create a custom video player. Important: DVR functionality will not be available until the following two requirements are met: Server-side archiving feature is disabled and the DVR feature is enabled. Configuring Your Encoder Each live stream must be configured to support DVR functionality before it is published by your encoder. This can be performed in Flash Media Live Encoder 3.1 by making sure that the DVR Auto Record option is marked. You may also start or pause your DVR recording session after you have already started encoding your video. This can be accomplished through the Record and Pause options that are available from the bottom right-hand corner of Flash Media Live Encoder 3.1. Warning: If DVR has been enabled on your CDN account, then you will need to ensure that your encoder is configured to record your stream. Otherwise, your clients will be unable to connect to your stream. Configuring Your Media Player DVR functionality can be implemented by creating or customizing a media player. One method of creating a media player is through the ActionScript 3 FLVPlayback 2.5 component. When creating your media player, you will need to inform our servers that a DVR-enabled video is being requested. The FLVPlayback component allows you to do so by calling DVRSubscribe and passing the name of the stream being requested. If you do not wish to create your own media player, then you will need to customize a packaged media player. However, you will need to make sure that the desired media player supports the ability to make a call to enable DVR. If you plan on using JW Player 5.3, then you can make this call using the following code excerpt: 'rtmp.dvr':'true' Note: For more information on how to call DVRSubscribe, please refer to your software manufacturer s documentation. Flash Media Streaming EdgeCast Page 9

14 In addition to calling DVRSubscribe, you will also need to change the player URL that is used to identify the location where you published your live event. The origin identifier in that URL must be changed from 20 to 30. Sample Live StreamCast (without DVR playback) Streamer: so.addvariable('streamer','rtmp://fml.xxxx.edgecastcdn.net/20xxxx/path/'); Sample Live StreamCast (with DVR playback) Streamer: so.addvariable('streamer','rtmp://fml.xxxx.edgecastcdn.net/30xxxx/path/'); FCSubscribe Live StreamCast requires that you inform our servers that a live stream is being requested. Typically, this can be accomplished through the FCSubscribe call. However, the DVRSubscribe call, which is necessary for DVR playback, also relays this information to our servers. If a media player relays this message multiple times to our servers, it may cause an issue with your stream. As a result, it is recommended that FCSubscribe is not called from your custom media player when taking advantage of DVR functionality. Testing Your Live StreamCast A live stream can be viewed without having to embed a video player onto a web page. This allows you to quickly verify that your live stream has been configured properly. Before you can test out your live stream, you will need to meet the following requirements: Make sure that your encoder is properly pushing encoded video to a publishing point. This involves verifying the publishing point location and the live authentication key. Download the latest version of JW Player. Upload Player.swf to a CDN or customer origin server. Once you have met the above requirements, then you should simply type the following URL in your browser s address bar: You will need to replace the following items in the URL: xxxx: This should be replaced with your CDN account number. Your CDN account number can be found in the upper-right hand corner of the MCC. PlayerPath: This term should be replaced by the path to the folder where Player.swf is stored. Flash Media Streaming EdgeCast Page 10

15 CDN URL: If you are not using an edge CNAME, then this path should start with the content access point (i.e. yyxxxx/path). The variable yy should be replaced with the appropriate origin identifier. If you are using a CDN origin server, then yy should be set to 00. If you are using a customer origin server, then it should be set to 80. Edge CNAME URL: This path should start with the name assigned to the appropriate edge CNAME followed by the path to the Flash player folder. It should not include the content access point. StreamPath: This term should be replaced by the path to the publishing point location. Make sure that this path does not end with a forward slash (/). StreamName: This term should be replaced by the name assigned to the stream by your encoder. Important: CDN and edge CNAME URLs are case-sensitive. Note: The above sample URL uses the HTTP Large Object platform for the SWF file. Alternatively, you may make the Flash player available through the HTTP Small Object platform. You can do so by replacing wpc with wac in the above sample URL. Note: If you are using Live Streaming (Legacy), then you should replace the portion of the URL that appears after streamer= with one of the player URLs listed on the Flash Streaming page, which can be found on the Flash tab of the MCC. Flash Media Streaming EdgeCast Page 11

16 On-Demand Streaming (RTMP) Overview Our on-demand capabilities allow you to stream Flash media, including previously archived live streams, as your clients request them. The following diagram demonstrates the process through which an on-demand Flash stream is transmitted to your clients. Note: An alternative way to stream Flash content on-demand is HTTP Progressive Download. For more information, please refer to the HTTP Progressive Download chapter in the HTTP Large Object Administration Guide. Note: For the purpose of simplifying this example, only the North American portion of our worldwide network is displayed. How On-Demand Content Streams to Your Client The above diagram demonstrates three different steps that take place when streaming video on-demand to your clients. These steps are: 1. A Flash media file must be stored on a CDN or customer origin server. When requested by a user, the requested Flash content is retrieved from either a CDN or customer origin server. 2. For each request, the Flash content is served to and cached on the POP closest to the client. 3. The on-demand stream is delivered from a POP to all clients in that region. Flash Media Streaming EdgeCast Page 12

17 Storing and Retrieving Flash Media Before your on-demand content can be served to your clients, it must first be stored on a CDN or customer origin server. This step is essential since it allows the on-demand content to be requested through a CDN or edge CNAME URL. This type of URL allows your on-demand content to be streamed across our worldwide network. On-demand content is streamed to your customers as they request them. This process involves streaming the content from the origin server to our worldwide network. In the above example, this step is represented by a blue line that goes from the origin server to a POP in Los Angeles. Routing and Caching Flash Media Once the requested Flash media is in our network, the next step involves sending the Flash media to the POP closest to the client requesting the content. Once the entire file has been served to a POP, it will be cached there. In the above diagram, there are four clients requesting on-demand content. These clients are located close to Seattle and Atlanta. The Seattle and Atlanta clients will receive the Flash media through the Seattle POP and Atlanta POP, respectively. This is represented by orange lines in the diagram. Sending Flash media through our network and bypassing traditional Internet communication routes ensures the efficient transmission of your Flash media and reduced bandwidth load on your network. Flash Media Delivery The last leg involved in the delivery of your on-demand content requires your client s ISP to deliver the Flash media stream from our POP. This is indicated by a purple line in the above diagram. Keep in mind that the caching of your on-demand content allows a client to bypass the retrieval of on-demand content from the origin server. When a client requests on-demand content, a check is performed to find out whether the requested Flash media has already been cached at the POP closest to your client. If it is already there, then the on-demand content is immediately served up to that client. In the above diagram, the dashed purple lines indicate the clients that will be able to enjoy even faster on-demand streaming. On-Demand Requirements On-Demand streaming requires an origin server, our content delivery network, and a Flash client. The requirements for each of these items are listed below. System Requirements: Origin server: You can choose to store your flash media files on either your own server (customer origin) or on our storage server (CDN origin). If you choose to store your media files on your own server, then you will need to ensure that your server has sufficient bandwidth and storage space to handle all of your streaming needs. On the Flash Media Streaming EdgeCast Page 13

18 other hand, if you take advantage of our CDN origin servers, then you can rest assured that your files will stream from a server that has top of the line bandwidth and storage space. Content Delivery Network: We provide servers that transmit your on-demand content to all necessary edge servers for delivery to your end-users. Flash Player: Our service is compatible with any Flash player that can handle a stream encoded by Flash Media Live Encoder 2.5 or higher. Important: Your player URL should not point to the root folder of an origin server. You must store your Flash content in another folder and specify the path to that folder when setting the player URL. Reminder: The default port used for the RTMP and RTMPE protocols is If your client s Flash player does not allow communication through port 1935 and you have enabled tunneling, then you will be able to send your stream through the HTTP protocol using port 80. Setting Up Video On-Demand The capability to stream Flash media as your clients request them requires that you configure the storage location for your Flash media and upload the desired file(s). After which, you will need to implement your Flash player and point it to the desired Flash media file. We will discuss each of these items below. Storage Location We can retrieve Flash media from two different sources, which are CDN origin and customer origin servers. CDN origin refers to our set of storage servers. These servers have sufficient storage capacity to exceed your needs. Additionally, they have direct access to our CDN servers, which allows them to deliver your media files quickly. A customer origin server refers to any computer external to our network to which you have sufficient access to store and retrieve files. If you choose to store media files on your own server, then you will need to ensure that your customer origin server can communicate with our CDN network. This can be accomplished by allowing the IP addresses associated with our CDN servers access to your customer origin server through the HTTP protocol. For a complete list of IP blocks that should have access to your storage server, please refer to the Customer Origin page on the Flash tab of the MCC. Note: Do not store Flash media in the root folder of your origin server. This type of configuration is not supported. To configure and store Flash media on a customer origin server 1. Using your preferred FTP client, upload the desired Flash media files to your server. 2. Navigate to the Customer Origin page on the Flash tab of the MCC. Flash Media Streaming EdgeCast Page 14

19 3. If your desired server has already been assigned a CDN URL, then proceed to the next step. Otherwise, in the Hostname or IP Address option, type the URL to the folder on your server where your Flash media files are stored. Make sure to include the when specifying the URL. You should also include the port through which TCP communication can occur. 4. Make sure that all of the IP addresses listed on the Customer Origin page can access your server. Note: If you have not previously assigned a CDN URL to your server, then you should allow up to an hour for your changes to take effect. To store Flash media on a CDN Origin Perform one of the following: FTP Client: Find out the name of the FTP server by viewing the FTP page on the Media Manager tab of the MCC. Once you know the FTP server name, use your preferred FTP client to log in to that server using your MCC log in information. Navigate to the desired path and then upload the desired Flash media files. MCC: From the File Management page on the Media Manager tab of the MCC, upload the desired Flash media file to the desired path on the origin server. Flash Player Once your Flash media files are hosted on a customer or CDN origin server, you are ready to set up your Flash player to stream on-demand. On-Demand streaming requires that you specify a Player URL (stream) and the file name of the Flash media that you would like to stream. Player URL: The Player URL is the URL to the folder on either the customer origin or CDN origin server where your Flash media file is stored. This path can be found on the Flash Streaming page of the Flash tab in the MCC. File Name: In your embedded code, specify the file name including the extension (e.g. MyFlash.flv). Token-Based Authentication: If you have enabled Token-Based Authentication for Flash media streaming, then you will need to append a question mark (?) followed by the token generated from the primary encryption key. For example, if your stream name is WebCam01 and the token corresponding to your primary encryption key is a4fbc3710fd3449a7c99984d1b86603c22be1006d830b, then you would specify WebCam01?a4fbc3710fd3449a7c99984d1b86603c22be1006d830b as your stream name. For detailed information, please refer to the Token-Based Authentication User Guide, which is available from the Media Control Center (MCC). Flash Media Streaming EdgeCast Page 15

20 Tip: If you do not wish to expose the CDN path to your clients, you may choose to create a mask for the URL of the CDN origin server using a CNAME. For more information, please refer to the Masking the URL of a CDN Origin Server (CNAME) section below. Sample Flash Player Code Sample code can be viewed from our Knowledge Base for the following video players: JW Player 5.3 Flowplayer 3.2 Dynamic Stream Switching When providing on-demand content, you may wish to provide varying quality levels of the same video to your clients. Typically, this would be performed by creating several links to the desired content and then allowing a user to select the video quality that will produce the best viewing results. A major drawback of this type of configuration is that it effectively locks a user into the selected on-demand video, since switching to a different quality level would require the user to restart that video. Using multi-bit rate functionality to provide on-demand content changes the viewing experience for your users. It switches the burden of choosing an appropriate video quality from the user to the Flash player. It allows the Flash player to automatically adjust the quality of the video being displayed according to current network conditions and CPU usage. It is able to do this by continually monitoring a client s environment, assessing the best bit rate for each client, and requesting a higher or lower bit rate Flash video according to the information provided in a configuration file. Note: Switching between Flash videos that use different bit rates usually involves a delay of a few seconds. This delay is due to the fact that a player can only switch to a different Flash video between key frames. Note: Whether a Flash player supports multi-bit rate streams and the criteria that it uses to determine the stream quality that will be requested depends on that player s manufacturer. Setting Up Multi-bit Rate On-Demand Content Multi-bit rate functionality can be implemented in much the same manner as on-demand content. The major configuration differences are listed below. Multiple video files with varying bit rate levels will be provided instead of a single video file. Flash Media Streaming EdgeCast Page 16

21 The available video files must be listed in a multi-bit rate configuration file. This file can either take advantage of SMIL or RSS syntax. The syntax that should be used depends on your Flash player. A Flash player will need to point to a multi-bit rate configuration file instead of directly to the video file. Tip: It is recommended that you encode your videos with a high frequency of key frames. Key frames are a crucial factor in determining when a Flash player can switch to a different quality stream. Using a small key frame interval (e.g. 2 to 4 seconds) reduces the chance that a player will buffer video or be affected by playback stutter. Choosing Bit Rate Levels The most important step for adding multi-bit rate functionality to your on-demand content is to determine how many and the quality of the video files that you will make available to your clients. Some general guidelines on how to choose bit rate quality are provided below. Low quality: This type of video file should not require much in terms of bandwidth or CPU usage. All of your clients should be able to view this type of stream without experiencing delays due to buffering, disconnects, or playback stutter. Balance between quality and bandwidth/cpu requirements: This type of video file will cater to most of your users, since it will be the highest quality video that they can view with their limited bandwidth or hardware. Most of your video files should fall under this category. High quality: This type of video file should provide an optimal viewing experience to demanding clients that expect higher quality due to their available bandwidth and computer hardware. Note: Video files of varying quality can be either be created when streaming a live event or from an existing video file. When configuring your encoder, you will need to select the desired bit rate and the resolution or output size of the video. The steps required to accomplish this depends on your encoder. For more information, please refer to the documentation provided with your encoder. Note: Adobe Flash Media Live Encoder 3.1 provides the capability to create up to three bit rate streams from a live event. This capability requires that you enable each desired bit rate stream by marking the checkbox that appears to the left of the corresponding bit rate settings. Creating a Multi-bit Rate Configuration File Once you have generated the desired bit rate video files, you are ready to create a multi-bit rate configuration file. This file provides a listing of video files and the minimum bit rate level required before a Flash player can switch to it. Flash Media Streaming EdgeCast Page 17

22 The standard multi-bit rate configuration file is a SMIL document. However, the type of configuration file that you should create depends on your Flash player. For example, JW Player only supports multi-bit rate configuration through an RSS document. Sample code can be viewed from our Knowledge Base for the following documents: Multi-bit Rate Configuration: Standard (SMIL) Multi-bit Rate Configuration: JW Player 5.1 Configuring Your Flash Player The final step that you will need to take is to point your Flash player to a multi-bit rate configuration file instead of a single video file. This can be accomplished through the file variable. Sample code can be viewed from the following article in our Knowledge Base: JW Player (Multi-bit Rate) 5.1 Loading On-Demand Content By default, our edge servers don t cache files until they are requested by a client. This means that the first customer in a particular region to request a file will cause the corresponding edge server to request the file from the origin server. After which, the file will remain cached on that edge server until it is automatically or manually purged. Therefore, the first customer to request a particular file will take slightly longer to retrieve that file than all other subsequent customers. If you have a large event or content that becomes simultaneously available to a large volume of end-users (e.g. a new movie release), then it might be helpful to load your Flash media files on our edge servers. Note: A file can be automatically or manually purged. For more information on purging ondemand content, please refer to the Purging On-Demand Content section below. Note: The optional load feature only needs to be implemented a single time. The file will be cached regardless of the CNAME used to reach it; provided that those CNAME records point to the same location. To load your on-demand Flash media to our edge servers 1. Navigate to the My Edge page, which can be found on the Flash tab of the MCC. 2. From the Load URL option, select the CDN URL for the server where your Flash media content can be found. 3. To the right of the Load URL option, type the full path to the desired Flash file that will be loaded. Make sure that this path starts with a forward slash. You should also include the FLV or F4V extension when specifying the filename. Flash Media Streaming EdgeCast Page 18

23 4. Click Load. Note: Each load request needs to be processed. Therefore, your request will be placed in a queue. The My Edge page provides a means to keep track of when a request was made and when it was completed. Purging On-Demand Content Content that has been cached on an edge server can be purged at anytime. A typical reason for why you would want to purge on-demand content is that you have a newer version of a file. In such a case, the old version of the file will continue to be served out by our edge server until it either checks for a new version, the content of that file expires, or it is purged. Tip: If you need to automate a purge task, then you can either do so through Content Expiration Headers or by taking advantage of our XML API. Important: Purging is not the same thing as deleting the file from the origin server. Purging a file will not delete the source file. It will simply remove the cached instance of that file from all of our edge servers. If you would like to remove the original file, then you will need to delete it through the File Management page of the Media Manager tab in the MCC or through your preferred FTP client. Automated Purging Through Content Expiration You can specify Content Expiration Headers from your web server. This will automatically tell our edge servers how often to check for content freshness, and will automatically purge content that is no longer needed. For example, setting the header on your web server to cache-control: max-age=86400 would cause our edge server to check for a new file every seconds (i.e. on a daily basis). Note: The expiration time will automatically get updated with every new request, and the cache will expire after the amount of time specified in the last successful request. Please refer to your web server s documentation for more information on how to configure these settings. Manually Purging Files Cached Flash media files can be purged from our edge servers through the My Edge page, which can be found on the Flash tab of the MCC. When purging files, keep in mind that you may purge files individually, by folder, or recursively. Note: A file only needs to be purged a single time per location. The file will be purged regardless of the CNAME used to reach it; provided that those CNAME records point to the same location. Tip: If you have files that are updated frequently, then you should consider using a naming convention that assigns unique names to your new files. This will ensure that future requests will go to the new files without the need for purging the old files. Flash Media Streaming EdgeCast Page 19

24 To manually purge files 1. Navigate to the My Edge page, which can be found on the Flash tab of the MCC. 2. Under the Purge From Edge section, select the location of the file(s) that you would like to purge from the Purge URL option. 3. To the right of the Purge URL option, type the path to the folder containing the file(s) that you would like to purge. Make sure that the path starts with a forward slash (/). 4. Perform one of the following: 5. Click Purge. To purge an individual file: Type the name of the file that you would like to purge. If you would like to purge files based on query strings, please refer to the Purging Query String Variations of a Cached File section below. To purge a folder s cached default file: Make sure that the path points to the folder whose cached default file you would like to purge and that a forward slash (/) follows the name of the desired folder. You may also choose to use query string notation to purge specific variations of the default cached file. To recursively purge a folder s content: Make sure that the path points to the folder whose contents you would like to purge and that a forward slash and an asterisk (/*) follow the name of the desired folder. Note: Each purge request needs to be processed. Therefore, your request will be placed in a queue. The My Edge page provides a means to keep track of when a request was made and when it was completed. Purging by Folder When specifying which file(s) will be purged from our edge servers, you may do so by specifying a folder. There are two ways in which a folder purge can be handled. It can either purge the default file that was cached for that folder or it can purge a folder recursively. The syntax that should be used for each purge method is described below. Syntax /Folder Path/* /Folder Path/ /Folder Path/? Description An asterisk indicates that the specified folder will be purged recursively. This means that the contents of the specified folder and all of its subfolders will be purged from our edge servers. Simply specifying the desired folder will purge the default file that was cached for that folder. It will also purge all query string variations of that file. A question mark indicates that only the default file that was cached for that folder will be purged. Query string variations of that file will not be purged. Flash Media Streaming EdgeCast Page 20

25 Syntax /Folder Path/?SampleQuery Description A question mark followed by a specific query string will only purge the default cached file matching the specified query string. Note: An asterisk can only be used as specified above. It cannot be used as a wildcard. Note: When purging the default file cached for a particular folder, keep in mind that there are certain conditions that may cause a file other than the default file for that folder to be purged. For example, specifying /Folder/ may not be the same as specifying /folder/index.html even if index.html is the default file for that folder. A couple of situations under which this would occur are when the specified URL is redirected or if URL rewriting is used. Purging Query String Variations of a Cached File If your file naming structure is based on query strings, you can customize how query string variations of that file are handled. Please refer to the following table for a detailed explanation on how you can handle query string variations of a file. Syntax /Folder Path/File Name /Folder Path/File Name? /Folder Path/File Name?SampleQuery Description Simply specifying a file name will purge the original file and all of its query string variations. A file name followed by a question mark (?) indicates that only the specified file will be purged. All query string variations of that file will not be purged. A file name followed by a question mark and a query string (?SampleQuery) indicates that only the specified file with that particular query string will be purged. The original file and all other query string variations of that file will not be purged. Masking the URL of a CDN Origin Server (CNAME) The URL to the location on a CDN origin server where your Flash media file resides can be masked through the use of an edge CNAME. There is a CDN and a DNS aspect to an edge CNAME. The CDN aspect is an edge CNAME configuration that allows our servers to identify a contact access point. In addition to this configuration, a DNS server must be configured to recognize the alias for the CDN URL. The alias set on the DNS server should match the domain (e.g. fms.xxxx.edgecastcdn.net) associated with the edge CNAME configuration. If a directory path has been specified, then our servers will rewrite the URL to point to the appropriate folder. Important: Informing our edge servers that you would like to use a CNAME record will not update or set that CNAME record on your DNS server. Before you can take advantage of the desired CNAME, you will need to set the record on your DNS server. Flash Media Streaming EdgeCast Page 21