Our network was built for rich media - we'll deliver it better than anyone else - live or on-demand.

Flash media can be streamed through our network using any of the following methods:

Method	Platform	Description
Live StreamCast	Flash Media Streaming	Feature overview: Stream a live event. Uses Flash Media Communication Protocol (Real Time Messaging Protocol or RTMP). Leverages security features.
On-Demand Streaming	Flash Media Streaming	Feature overview: Stream on-demand content. Uses Flash Media Communication Protocol (Real Time Messaging Protocol or RTMP). Leverages security features.
HTTP Progressive Download	HTTP Large	Feature overview: Stream on-demand content. Easy to implement. Uses standard HTTP protocol which is widely supported through firewalls. Leverages a resilient infrastructure.

Live StreamCast

Live StreamCast provides the capability to efficiently stream live content to the customer’s users. The following diagram demonstrates the process through which a live stream is transmitted to users.



4 different steps take place when streaming live content to users.

1. An encoder encodes an audio/video feed and makes it available to a publishing point.
2. The server associated with 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 from the POP to the user through his/her ISP.

Encoding Media

The first step for serving a live stream occurs when the customer’s encoder encodes live content and makes it available to a publishing point. It is recommended that the customer chooses the publishing point closest to the computer hosting his encoder. This will ensure optimal data transfer speed between his encoder and our network.

Live Stream Broadcast

Once the encoded content 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 the customer’s live streams to immediately take advantage of our worldwide network. And, this ensures optimal data transfer speed between the publishing point and our POPs.

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 the customer’s users. When a user requests a live stream, the POP closest to him will retrieve the stream from the designated publishing point. By sending the stream through our network and bypassing traditional Internet communication routes, we can ensure the efficient transmission of the customer’s stream and reduced bandwidth load on his network.

Live Stream Delivery

It is required that the user’s ISP delivers the live stream from our POP. Each the customer’s users will then use a Flash player to enjoy uninterrupted live streaming. When a user requests a live stream, a check is performed to find out whether another user in the same region is currently viewing it. If it is currently being viewed in the same region, then that user will instantly be able to take advantage of the live stream.


On-Demand Streaming (RTMP)

Our on-demand capabilities allow the customer to stream Flash media, including previously archived live streams, as his users request them. The following diagram demonstrates the process through which an on-demand Flash stream is transmitted to the customer’s users.


3 different steps take place when streaming on-demand content to the customer’s users.

1. A Flash media file must be stored on a CDN or customer origin server. The first time that this Flash content is requested by a user it is retrieved from that origin server.
2. It is then served to the user that requested it and cached on the POP closest to that user.
3. Subsequent requests for cached content can be served directly from the POP.

Storing and Retrieving Flash Media

Before the customer’s on-demand content can be served to his users, 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 the customer’s on-demand content to be streamed across our worldwide network.
On-demand content is streamed to the customer’s users as they request them. This process involves streaming the content from the origin server to our worldwide network.

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 user requesting the content. Once the entire file has been served to a POP, it will be cached there. Sending Flash media through our network and bypassing traditional Internet communication routes ensures the efficient transmission of the customer’s Flash media and reduced bandwidth load on his network.

Flash Media Delivery

At last the user’s ISP is required to deliver the Flash media stream from our POP. Once on-demand content has been cached on a POP, all future requests for that content can bypass retrieval from the origin server. When a user 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 the customer’s user. If it is already there, then the on-demand content is immediately served up to that user.

Flash media can be retrieved 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 the customer’s needs. Additionally, they have direct access to our CDN servers, which allows them to deliver the customer’s media files quickly. A customer origin server refers to any computer external to our network to which the customer has sufficient access to store and retrieve files. If the customer chooses to store media files on his own server, then he will need to ensure that his customer origin server can communicate with our CDN network.

Loading On-Demand Content

By default, our edge servers don’t cache files until they are requested by a user. This means that the first user 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 user to request a particular file will take slightly longer to retrieve that file than all other subsequent user. If the customer has 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 his Flash media content on our edge servers.
The customer is provided with an API that he can use to automatically load assets to all of our POPs.

Purging On-Demand Content

Purging an asset deletes the cached version of the asset from all of our edge servers. This prevents an old version of an asset from being delivered to the customer’s users. This is useful when the customer would like to ensure the delivery of a new version of the asset in question.
The customer is provided with a Web Services REST API that he can use to automatically purge content and/or folders from all of our POPs.


Dynamic Streaming

The amount of bandwidth that can be used by a user to view streaming content is variable due to many factors, such as their current network (e.g., home vs. office vs. coffee shop) and playback device (e.g., smart phone vs. desktop). As a result, the customer may wish to provide varying quality levels of the same video to his users. 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 video feed, since switching to a different quality level would require the user to restart that video.

Multi-bit rate functionality changes the customer’s users’ viewing experience by switching 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.


Securing Flash Media

There are three different methods through which the customer can secure his Flash media against unauthorized viewing, which are tokens, SWF verification, and RTMPE.

The customer’s Flash media can be protected according to the following criteria: expiration date, country, URL, IP address, and referrers. This information is stored as tokens in an encryption key. A media player will be denied access to Flash content secured in this manner when the appropriate token is not provided and the encrypted requirements of that token are not met.

Also the customer can configure our servers to limit connections to his streams to users that use a predefined SWF file. Only users that use the same build of that SWF file will be allowed to play content streamed through the Flash Media Streaming platform. This concept is known as SWF Verification.

The purpose of this form of security is to force users to view the customer’s streaming content using his SWF file. It is most useful when the customer has created a custom SWF file that promotes his brand (e.g., logo, tag line, colors, etc.). This would prevent a malicious entity from streaming the customer’s content through a custom SWF file that hides his brand presence.

Flash Media Server offers the option to encrypt the customer’s Flash media stream through Real Time Messaging Protocol Encryption (RTMPE). RTMPE is a protocol offered by Adobe to encrypt the customer’s Flash stream and protect it from copyright infringements. RTMPE is the encrypted version of RTMP. In order for RTMPE to be most effective against copyright infringement, the customer should disable RTMP. This will ensure that only RTMPE can be used to stream his Flash media.

Live Authentication prevents unauthorized users from publishing a live stream to the customer’s account by requiring that the encoder authenticate to the publishing server through a Live Authentication key.