This topic covers information that can help you to decide which option is best for your content delivery with Video Cloud.
One of the first things to decide after you create your Video Cloud publisher account is how you plan to deliver your video files. Video Cloud 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 (Content Delivery Network or Content Distribution Network), and so forth.
The content delivery options described in the topic are available only for Video Cloud Enterprise publishers. Video Cloud Pro and Express publishers must use Brightcove as their CDN.
In this topic, you will learn:
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 Video Cloud Pro or Express customer, Brightcove is your CDN solution. If you are a Video Cloud Enterprise customer, then you can choose to deliver your content using the Brightcove CDN or over any CDN that Video Cloud 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 set-up, please contact Brightcove Customer Support or your Account Manager.
There are several types of content delivery mechanisms:
When you deliver your content using 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 is downloaded to the viewer's computer or device and stored in a temporary directory. The video will begin to play when enough of the file has has been downloaded to the computer/device. If the viewer wants to fast forward or skip to another part of the video, he/she will only be able to do so if that part of the video has already been downloaded and stored. 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.
Progressive download is a perfect for hobbyists or websites that have low traffic requirements, don't mind if their content is cached on the viewer's computer/device, and if you 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 (several hundred or more 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.
Progressive download key points:
Streaming video on the other hand is delivered via a streaming server without the file ever being downloaded to the viewer’s computer/device. As soon as the viewer presses play, the video will start to play. If the user decides to forward or skip to some other part of the video, he/she can do it immediately and the video will continue to play from that point onwards. One of the advantages of streaming media is that bandwidth is only used for video that the viewer has watched, as only the watched portion of the video has been delivered. Nothing is kept on the client side; everything is on the server side and is delivered using Real Time Messaging Protocol (RTMP), which is a proprietary protocol developed by Adobe. RTMP was developed 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, read Adobe's Overview of streaming with Flash Media Server 3.
Streaming is useful in situations 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 Video Cloud 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 Flash Media Server (FMS) server infrastructure on the CDN. This was accomplished using a hashing algorithm and a Time To Live (TTL) for each stream.
Brightcove also worked closely with Adobe and our CDN partners to roll out support for RTMPE within the Video Cloud 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 have tried various ways to capture and archive video delivered to Adobe Flash. Today, very few of these "rippers" support RTMP which is the protocol used by Adobe Flash Media Server. Flash Media Server 3.0 and Adobe Flash Player 9.0.115 introduced the RTMPE protocol, a real-time encryption solution to help prevent stream ripping from Flash. More than 98% 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.
Apple iOS devices like the iPad, iPhone, and iPod Touch support only Apple HTTP Live Streaming (HLS) and HTTP (progressive download) for delivery of video files. FMS-based RTMP streams are not supported. You need to ensure either that your videos have one or more available renditions that that use the M2TS container or that your account is set up to permit HTTP based delivery. The iTunes App Store rules call for the use of Apple HTTP Live Streaming for long form video content (greater than 5 Mb or 10 minutes). For more information, see Delivering Videos with Apple HTTP Live Streaming.
Streaming key points:
In practice you will very rarely realize weather content has been streamed or progressively downloaded unless you look for some of the distinguished features as described above.
The Video Cloud universal delivery service (UDS) feature enables you to combine the advantages of streaming and progressive download. When UDS is enabled for your streaming account, your videos are delivered by streaming to your Video Cloud players, but can also be delivered by progressive download in situations where that's necessary, such as podcasts. UDS is not available for remote assets. Read more about Universal Delivery Service.
Regardless of whether you use streaming or progressive download for your video content, images delivered to end users in the Video Cloud player (thumbnails and video stills, for example) are delivered via HTTP download.
Video Cloud supports a few basic CDN configurations, depending on your CDN provider and setup. The choices are:
See Comparing Content Delivery Options for a table that summarizes the advantages and disadvantages of these CDN configurations.
You can choose to use The Brightcove CDN. Video Cloud leverages Akamai, 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 Video Cloud players using either Progressive Download (PD) or streaming mechanisms. If you choose BYO CDN, you can use the Video Cloud uploading tools to ingest content into your Video Cloud account, which then gets pushed to your CDN provider for delivery to end users through your Video Cloud 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 the Video Cloud uploading tools at all to add new content. You can use either the Video Cloud Media module, the FTP batch provisioning system, or the Media API to create videos in your Video Cloud account that point to the underlying video assets stored remotely by your CDN provider.
When you create videos with remote assets, you can use the Media module to manage your metadata, but you cannot preview the videos in the Media module. You cannot use the Media module image capture feature to create thumbnail or video still images from streaming videos with remote assets. 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 Video Cloud player, unless you are using RTMPE delivery.
Remote assets need to be set up as either streaming or progressive download; universal delivery service is not available for remote assets.
For RTMPE support with remote assets, you need to provide the complete URL, including the RTMPE protocol handler, when you add content to your Video Cloud media library.
Remote assets can also use HTTP re-directs. 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
For information about remote assets, read Creating Videos with Remote Video Files.
It is possible to configure a Video Cloud 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 uploading it again, and use BYO CDN for new uploads going forward. Contact us if you require this set-up. You may also be able to create multiple Video Cloud accounts, each with a different content delivery strategy.
Here are the main steps for getting set up with BYO CDN or remote assets:
Video Cloud 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 Video Cloud 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 Video Cloud reports for your "non-video" content, that is, for bandwidth usage incurred for Video Cloud player SWFs, images, etc.