The content delivery options described in the topic are available only for Brightcove Pro or Enterprise publishers. Brightcove Express publishers must use Brightcove as their CDN.
One of the first things you should decide after you create your Brightcove publisher account is how you plan to deliver your video files. Brightcove offers many choices that have a variety of advantages and limitations. The delivery method you choose depends on how protected you want your video files to be, how you would like to reach your audience, your preferred method of upload, whether or not your video assets are already stored on another CDN, etc. Read this topic for information that can help you to decide among your options for content delivery with Brightcove.
Publishers use CDNs to distribute their media widely to viewers online. Wikipedia defines a CDN as:
A content delivery network or content distribution network (CDN) is a system of computers networked together across the Internet that cooperate transparently to deliver content most often for the purpose of improving performance, scalability, and cost efficiency, to end users.
There are many commercially available CDNs. If you are a Brightcove Express customer, then Brightcove is your CDN solution. If you are a Brightcove Pro or Enterprise customer, then you can choose to deliver your content over any CDN that Brightcove supports.
If you are expecting low volumes of traffic or have complete control over traffic to your videos you may not need a CDN to serve your videos. For example, some customers want to distribute their content on an internal wiki or private network. It is possible that your system can handle delivery of media without requiring an external CDN. If you would like more information on how Brightcove can support this setup, please contact us.
There are 2 basics types of content delivery mechanisms:
When you deliver your content by progressive download, the file is served from a standard web server through an HTTP request, just like a normal web page or any other downloadable document. When the video is played, the video file first begins to download to the viewer's hard drive, then playback starts. The video will begin to play when enough of it has downloaded to the viewer's hard drive. In comparison to streaming video, there's really only one consistent benefit to progressive download—you don't need a streaming server to deliver the video. Progressive download video can be served from any normal web server.
While this can be convenient and potentially cost-effective, the following potential issues should be noted:
Progressive download is a perfect use for hobbyists or websites that have low traffic requirements, don't mind if their content is cached on the viewer's computer, and only need to deliver shorter length videos (under 10 minutes). Customers who need advanced features and control over their video delivery, and/or those who need to display video to larger audiences (e.g. several hundred simultaneous viewers), need to track and report usage or viewing statistics for the video, or want to offer the best interactive playback experience, will need to stream their video. Streaming delivery also consumes less bandwidth than progressive delivery, because only the portion of the video that is watched is actually delivered.
Streaming media is multimedia that is constantly received by, and normally presented to, an end-user while it is being delivered by a streaming provider.
Real Time Messaging Protocol (RTMP) is a proprietary protocol developed by Adobe Systems for streaming audio, video, and data over the Internet, between a Flash player and a server. In the case of streaming video, each client opens a persistent connection to the streaming server, and the server streams the video bits to the client. Those bits are displayed by the viewer and then immediately discarded. For more information, see this Adobe overview.
Streaming should be used in any situation where you want or need to do the following:
Brightcove has enhanced RTMP delivery by employing a time-to-live (TTL) token for each video file delivered in a Brightcove player. Time to live (sometimes abbreviated TTL) is a limit on the period of time or number of iterations or transmissions in computer and computer network technology that a unit of data (for example, a packet) can experience before it should be discarded. Through Flash Media Server, Brightcove has implemented a customized approach that provides additional security into the FMS server infrastructure on the CDN. We do this using a hashing algorithm and a Time To Live (TTL) for each stream.
We also worked closely with Adobe and our CDN partners to roll out the support of RTMPE within the Brightcove player. RTMPE is an enhanced and encrypted version of RTMP developed by Adobe systems for securing the stream data between flash client and server. RTMPE is faster than SSL and does not require certificate management as SSL does.
Stream capture software providers are trying many ways to capture and archive video delivered to Adobe Flash. Today, very few of these "rippers" support RTMP (Real-Time Messaging Protocol), the protocol used by Adobe Flash Media Server (FMS). Flash Media Server 3.0 and Adobe Flash Player 9.0.115 introduced the new RTMPE protocol, a real-time encryption solution to help prevent stream ripping from Flash. Over 86% of internet-connected computers have now adopted Adobe Flash Player 9.0.115 or later, and Flash Media Server 3 is supported by all CDNs.
Regardless of whether you use streaming or progressive download for your video content, images delivered to end users in the Brightcove player (thumbnails and video stills, for example) are delivered via HTTP download.
Brightcove supports three basic CDN configurations, depending on your CDN provider and setup. The three choices are:
See Comparing Content Delivery Options for a table that summarizes the advantages and disadvantages of these three CDN configurations.
You can choose to use Brightcove's CDN. Brightcove leverages Limelight and other Tier 1 CDNs to offer your choice of progressive download or streaming hosting for your video content. With careful consideration of the delivery types outlined above, and depending on your video needs, you can use Brightcove to host your video and deliver it through our players seamlessly with download or streaming delivery.
You can also choose to use your own choice of CDN (BYO CDN or "bring your own bandwidth"). In this case, depending on the agreement with your CDN provider, your videos will be delivered seamlessly through Brightcove's players using either PD or streaming mechanisms. If you choose BYO CDN, you can use Brightcove's uploading tools to ingest content into your Brightcove account, which then gets pushed to your CDN provider for delivery to end users through your Brightcove players.
For RTMPE support with BYO CDN, 100% of your video assets must be delivered through RTMPE.
The final choice is remote assets. In this case, you may already have your video files stored on your CDN and you do not want to use Brightcove's uploading tools at all to add new content. You have to use Brightcove's FTP batch provisioning system or the Brightcove Media API to point Videos in your Brightcove account to the underlying video assets stored remotely by your CDN provider. In this case, you can not use Brightcove's UI tools (such as the Media module) to upload content into Brightcove, although you still can use the Media module to manage your metadata. With remote assets, you also lose the protection scheme we have employed through our TTL scheme for streaming assets, so RTMP streams can more easily be hijacked and played outside a Brightcove player, unless you are using RTMPE delivery.
For RTMPE support with remote assets, you need to provide the complete URL, including RTMPE protocol handler, when you add content to your Brightcove media library using FTP batch provisioning.
Remote assets can also use HTTP re-directs. Formerly, a remote asset had to be defined with the exact URL of the remote asset file. Now, you can use a URL that re-directs to the location of the remote file. For example, suppose your remote file's URL is http://video.example.com/MyMovie.flv. Formerly, the value of the remote-url attribute of the remote-asset element for this video would have to have been http://video.example.com/MyMovie.flv. Now, instead, the remote-url attribute can use a URL that re-directs to the location of the video, such as http://host.example.com/servlet.jsp?id=12345.
It is possible to configure a Brightcove account to use both BYO CDN and Remote Assets. For example, if some of your video content is already available on your CDN, you may want to use remote assets for your existing content, to avoid needing to upload it again, and use BYO CDN for new uploads going forward. Please contact us if you require this set-up.
Here are the main steps for getting set up with BYO CDN or Remote Assets:
Brightcove supports the following major CDNs for BYOB CDN content delivery:
If you use BYO CDN or remote assets, your gigabytes downloaded and minutes will not appear in the Brightcove Studio Reports page for any videos or players, since we are not integrated with your CDN. You should be getting these reports directly from your CDN provider. You may still see gigabytes downloaded in the Brightcove reports for your 'non-video' content, that is, for bandwidth usage incurred for Brightcove player SWFs, images, etc.