State of Play

The Legacy Distributed Model

Traditionally, Content Delivery Networks (CDNs) are designed using a distributed model. In this model, a user's files are stored on an origin server, while a large number of edge servers are responsible for the delivery of these files. Edge servers only have a minimal amount of disk space, so the majority of files are delivered from cache memory. Therefore, every time a download or streaming request is sent for a file which is not available in the cache of a particular edge server, it must be retrieved from the origin server before it can be delivered to the end-user.

ThThe Distributed CDN Modele design of the distributed model originates from the end of the 20th century, at which time the first global CDN's started to emerge. At that time and during the first years of the new millennium, a CDN's main challenge was to deliver website content from inside the points of presence (POPs) of an internet service provider (ISP). Every end-user who dialed into a POP would thus receive the content immediately, without the CDN first having to send the request over the -  still relatively slow - internet. Hence a distributed architecture, with edge servers being deployed inside the ISP networks to cache the content they pulled in from origin servers through big pipes put in place by the CDN. This way, the CDN could easily deliver popular content to a high number of internet users.


Multimedia Trends Leave the Distributed Model Exposed

However, with the explosive growth of internet bandwidth and connectivity, the advantages of these highly distributed architectures have decreased. For instance, Europe has a dense interconnectivity due to the combination of many public internet exchange points and peering agreements between private networks, and a majority of end-users who can dispose of fast internet access. In such environment, having an edge server inside each POP becomes less significant, while a CDN's capacities for scaling and load-balancing is of great importance.

Meanwhile, the evolution of online multimedia consumption has also revealed the limitations of the distributed model. The number of multimedia files that can be requested at any given time keeps increasing exponentially, a result of the growing number of streaming services, multimedia ads, user generated videos, online archives… Furthermore, each video must be kept available in multiple formats and resolutions for viewing on different kinds of devices and platforms. At the same time, the average file size of a video keeps growing due to the enhanced capabilities of playback devices and the high amount of bandwidth that is available to end-users. All these factors make it harder to deliver multimedia content from cache. To keep up with demand, an edge server with limited disk-space will constantly have to flush parts of its cache to make place for new files which first must be pulled in from an origin server. This results in lots of overhead for the distributed CDN: more and more edge servers are required to deliver the same amount of data, and huge volumes of internal traffic must be sent - from origin to edge servers - through bigger and bigger pipes. More important, this may result in a fluctuating latency and a lower Quality of Service (QoS) for the end user.

Rambla's Hybrid CDN: A Perfect Match For Multimedia Delivery

To avoid these issues, we decided to design our own hybrid CDN architecture when the Rambla CDN was built from the ground up in 2005. In this hybrid design, Rambla's Hybrid CDN Modelthere is no formal distinction between edge and origin servers, and all CDN servers are optimized to deliver their content from both cache and hard-disk. This allows the CDN to cope more easily with the new needs in terms of multimedia delivery, using a relatively small number of high-end servers.

In our hybrid architecture, each of the CDN servers can fulfill the tasks of an origin server: providing storage and distributing data to other CDN servers. Each CDN server also acts as an edge server, delivering frequently demanded content straight from its cache and less popular content from hard-disk - through a dedicated Storage Area Network (SAN). Thanks to the current internet infrastructure, our CDN servers no longer need to be deployed inside the network of every ISP. It suffices that all CDN servers have a fast, high-bandwidth connection to the main internet exchanges and ISPs (through peering agreements) in order to reach a European-wide penetration and ensure quick load times and a reliable connection for all end-users.

Since the launch of the Rambla CDN, we have kept refining this hybrid model using the latest technologies. Among others, this has resulted in the instant scalability of our CDN through the dynamic launch of integrated cloud instances, making it possible to extend the CDN's capacity both performance-wise and geographically.

One Step Beyond: Delivering Media with Optimal Quality of Service

Our latest research & development efforts, co-funded by IWT (Agency for Innovation through Science and Technology), are aimed at providing an optimal and constant Quality of Service (QoS). Beyond a certain level, QoS is hard to measure since it may vary with each stream or download. For example, the presence of a video file in the cache of an edge server may be of significant influence to the viewing experience of end users. Therefore, lots of CDNs simply focus on achieving a sufficient QoS, i.e. an acceptable degree of satisfaction by the majority of end users. While this approach may be enough to satisfy traditional online video platforms, it falls short of the mark for the latest generation of premium services such as the delivery of streaming audio and video to custom applications or set-top boxes, also known as over-the-top content (OTT).

Our hybrid Rambla CDN has been designed to supply premium QoS by delivering all content with equal high speed and reliability. This is where our new SkyWay software comes in. This distributed backend component streamlines all hard-disk access - directed towards a dedicated SAN - to make sure that random-read operations are completed at a much faster pace. Furthermore, it continuously monitors the CDN servers and their resources, and guarantees that sufficient resources are readily available for the optimal delivery of content from both cache and disk. In order to achieve this, SkyWay may dynamically postpone processes whose execution time is not critical, limit resource availability for other processes, distribute tasks to additional servers, free existing resources and establish new ones. This way, SkyWay assures that the Quality of Service of the CDN remains optimal under all circumstances.

This is an installment of our ongoing State of Play series, designed to offer insight into new evolutions and significant issues in the online video industry.

About a year ago, we wrote about video formats as part of an introduction to multimedia containers and codecs. Since then, the online video landscape has changed drastically by Google's acquisition of On2 and the subsequent launch of WebM as an open source video format. In this post, we'll try to shed some light on the ongoing 'WebM vs H.264' debate.

WebM / H264 Formats

WebM format

On May 9, 2010 Google released WebM as an open and royalty-free video compression format for the web. The WebM project defines a container format based on a subset of the Matroska media container, which is designed to hold VP8 video and Vorbis audio streams.

H.264 video

H.264 is a video codec standard developed by the ITU-T Video Coding Experts Group (as H.264) together with the ISO/IEC Moving Picture Experts Group (as MPEG-4 Part 10, Advanced Video Coding, or AVC). During the last couple of years, it has become the de-facto compression standard for online video. When used in Flash or HTML5 video, it is often being used together with the AAC audio codec and stored inside of an MPEG-4 container. Other possible container formats include .mov (QuickTime), .3gp and .3gp2 (mobile) and .f4v (Flash).

Openness and Licensing

A lot of attention has been drawn to the free and open nature of the WebM format, as opposed to H.264 which has a patent license administered by a private organization known as MPEG LA. On August 26, 2010 MPEG LA announced that H.264 encoded internet video will perpetually remain free for non-commercial use, which means that you will never have to pay royalties for distributing free internet video encoded via H.264. However, license fees are required for other types of usage such as subscription based content services and device manufacturers.

The WebM project, on the other hand, is offering its code under a standard BSD license. Google has irrevocably released all of its patents on VP8 as a royalty-free format, but provides no indemnification for costs incurred should a patent lawsuit arise. That means that anyone distributing WebM/VP8 could be on the hook for any patent-related fees that might come up.

MPEGLA logoOn February 11, 2011 MEPG LA announced that it is forming a patent pool and gathering claims from companies that believe they have patents essential to the VP8 codec, spurring uncertainty about a royalty-free future for WebM. The move resulted in an investigation by the US Justice Department to see whether MPEG LA is trying to stifle competition. Google reacted by launching a new community cross-licensing initiative, which was joined by consumer electronics manufacturers like Samsung, LG Electronics and Cisco.

There has also been some debate surrounding Google's assertion that it wants to 'enable open innovation'. There are now two viable branches of VP8, the one Google has retained in house, and another one expanded on by the open-source community. However, there's no third party entity that manages the evolution of the specification. And when it comes to important decisions like choosing the code to be used by hardware manufacturers for implementing silicon, Google will always have the final say - which is, incidentally, the same policy that Google is applying to other 'open source' projects/products like Android and Honeycomb.


H.264 is widely considered as today's most advanced video codec. By defining a set of encoding profiles and levels, the H.264 standard allows for playback on platforms with very divergent decoding capabilities. These profiles include a baseline profile (BP) aimed at applications with limited computing resources, a main profile (MP) intended as the mainstream consumer profile and a high profile (HiP) for HD and FullHD which requires lots of memory and processing power.

Quality seems to be the main point of criticism regarding WebM. Compression-wise, the standard is said to be comparable to the H.264 baseline profile. In reality, the encoder implementations are as important as the standard itself for evaluating quality. The Moscow State University’s Graphics and Media lab evaluated both the x264 decoder and the VP8 encoder and concluded that the latter shows “20-30% lower quality at average", while requiring slightly longer encoding times to reach the “normal” settings of x264 (baseline profile). However, WebM is judged to be performing significantly better than Theora or xvid. In contrast, a comparison by Streaming Media concluded that WebM is almost as good as H.264 "at most relevant data rates" for web video.

In terms of decoding speed, VP8 and H.264 seem to be relatively comparable. But H.264 already has a great deal of hardware support, which makes it decode faster in most real life circumstances. Particularly for portable devices, hardware acceleration is essential for video playback. In January 2011, the WebM project announced the availability of VP8 Hardware IP Designs and Chinese chip designer Rockchip announced the first processor with support for VP8. However, it will take time for WebM hardware acceleration to reach critical mass.


HTML5 browser support for the video tagThe new HTML5 standard supports embedded multimedia, including video, audio, and dynamic graphics. The new <video> tag allows browsers to natively playback video, without needing plugins like Flash, Silverlight or QuickTime. However, disagreements in the W3C standards group resulted in an omission of a codec specification for the <video> tag. This has led to a stalemate, which is not likely to be resolved very soon. All browser vendors agree that their software should support the HTML5 <video> tag, but they can't agree on the video codec that will allow it. As a result, different browsers have native support for different video codecs.

On January 11, 2011 Google decided to drop support for H.264 in the Chromium open source browser (from which Chrome is built), in favor of WebM. This led to the current situation, in which Microsoft (IE 9) and Apple (Safari 5) support H.264, while Google (Chrome 12), Mozilla (Firefox 5) and Opera (10) support VP8 and Theora.

Both Apple and Microsoft, determined not to give Google control over the future of web video, have declared to be fully behind H.264 as the codec for HTML5 video going forward. Microsoft has even gone a step further, releasing plugins for Firefox and Chrome which allow them to play H.264 on Windows. Google in its turn has released a WebM plugin for Internet Explorer.

This division has been a major obstacle for the progress of HTML5 video. The majority of web video is currently encoded in H.264 and being played using Adobe Flash Player. Since this is still a viable option for all major browsers and H.264 also remains dominant on devices (Google has added WebM support to Android, but didn't remove support for H.264), there's no real incentive for video content owners to switch to HTML5.

VIDEO IN A Two-codec world

Even though H.264 is still dominant - according to MeFeedia, H.264 now accounts for 69% of all HTML5 video - WebM is expected to gradually gain market share, which may result in a two-codec world for the coming years. If your online videos are designed to stick around, you may want to start encoding into both formats. To do this transparently, Rambla customers can use their default hotfolder: simply upload your video files and they will get automatically published in both formats on the CDN. Developers can use our API's instead. For more information, take a look at our user guides or contact us.

This is an installment of our ongoing State of Play series, designed to offer insight into new evolutions and significant issues in the online video industry.

In a previous article, we presented you with an overview of the main streaming protocols. In this edition, we take a closer look at the new technique of adaptive streaming (aka bitrate switching) for on-demand media. In a future edition, we will further examine support for live streaming and discover how a single broadcast can result in multiple simultaneously live streams, using different streaming protocols.


Adaptive streaming is a technology in which the bitrate of a stream is dynamically adapted to the user's needs. The technique consists in detecting the user's bandwidth and CPU capacity in real time and adjusting the quality of the video stream accordingly. If the viewer's bandwidth or CPU capacity drops, the player can automatically switch to a lower resolution without interrupting the viewing experience.

Basically, all adaptive bitrate streaming technologies work in the same way. In advance, the source video file (or live event) must be encoded to multiple resolutions and/or data rates. Before delivery, these encoded files are divided into segments - sometimes referred to as "chunks" - each representing two to ten seconds of video. When the client (= video player) first contacts the streaming server, it receives a table of URLs in which each URL points to a specific time interval (the columns) of a specific quality (the rows). A client then starts requesting segments from the Web server, downloading them via HTTP. As the segments are downloaded to the client, it plays back the segments in the order received. While playing, the client monitors playback-related indicators such as file download time, buffer levels, and CPU utilization. If desirable, the client can switch to a higher or lower quality stream, which should result in a seamless user experience.


One issue with Adaptive Streaming is that implementations were not born out of a widely accepted standard, but instead every vendor has defined its own proprietary protocol. Recently, the Motion Pictures Experts Group (MPEG) has started work on a common standard called DASH, but this still has a long way to go.

Currently, there are three main flavors of HTTP adaptive streaming - by Apple, Microsoft and Adobe - each targeting their own platform. All three specifications are codec agnostic in theory, but the current implementations are limited to certain video and audio codecs. The delivery mechanisms have a lot in common, but are nevertheless incompatible; for instance, each protocol provides the table of available URLs to the client in a different fashion.

Apple HTTP adaptive streamingApple HTTP Adaptive Streaming

  • Available on iPhone, iPad, and iPod touch (requires iOS version 3.0 or later) or any device with QuickTime X or later installed.
  • The current implementation requires H.264 video streams and AAC or MP3 audio streams which are stored inside a MPEG-2 Transport Stream (MPEG-2 TS) container.
  • The streaming server communicates the available streams and their URLs to the client by exposing an m3u playlist (.m3u8).

Microsoft Smooth StreamingMicrosoft Smooth Streaming

  • Supported by Microsoft's Silverlight framework, which is also included on Windows Phone 7.
  • The current Silverlight framework requires the H.264 or VC-1 video codec, and the AAC or WMA audio codec. The container format is “fragmented” MPEG-4, a variant of the ISO specification in which not all the data in a regular MP4 file is included.
  • The streaming server sends an XML-based .ismc manifest back to the client, which describes the available streams and their URLs.

Adobe HTTP dynamic streamingAdobe HTTP Dynamic Streaming

  • Supported by Flash Player 10.1 (or higher) and Adobe AIR 2.
  • The Flash player currently supports H.264 or VP6 video and AAC or MP3 audio. The container format can either be FLV or “fragmented” MPEG-4.
  • The streaming server sends an XML-based .F4M manifest back to the client, which describes the available streams and their URLs.

Adobe RTMP Dynamic Streaming

Before Adobe released their version of HTTP Dynamic Streaming, they had already included support in Flash Player (version 10 or higher) for adaptive streaming over RTMP. From the client's perspective, the bitrate switching mechanism is similar. The major difference is that RTMP is a stateful protocol with a persistent client-server connection. See our overview of streaming protocols for the benefits / drawbacks of using RTMP instead of HTTP.


Adaptive streaming is particularly well suited for internet devices, which have different requirements regarding memory and processing power. Connections may vary from high-end (e.g. broadband TV) to low-end (e.g. 3G networks) and are often fluctuating. Adaptive streaming allows these devices to dynamically choose a stream with a suitable resolution and bitrate.

To get a fast start-up time, clients will usually begin by downloading the lowest available quality. During this first download, the client is able to calculate the available network bandwidth. The client then uses this knowledge to switch to the highest available quality, considering the available network bandwidth and processing power. Clients should also be able to quickly jump to a different part of the video by calculating the time interval and requesting the corresponding segment.

From an end-user's point of view, HTTP adaptive streaming is fully transparent. The client just needs the URL that points to the playlist or manifest file (which will be different for each flavor of HTTP streaming). After making its initial request to this URL, the client retrieves all necessary data to dynamically stream the video.

For RTMP adaptive streaming, some additional client-side work is needed. This set of articles by 'Adobe Developer Connection' covers the details of how to achieve dynamic streaming in Flash. However, embeddable video players like JW Player and Flowplayer have already implemented the bulk of these mechanisms and only require some basic client-side configuration.

Should You Consider Adaptive streaming ?

As more and more internet devices appear on the market with greater capabilities for video browsing and playback, adaptive streaming is starting to become a mainstream technology. However, it is still a young technology and a lot of its (added) value depends on the intelligence that is built into client applications. Although some recent studies have shown that clients can react quite effectively to bandwidth variations, player implementations are also said to be "still at their infancy“, which in some cases may lead to heterogeneous user experiences.

In our own experience HTTP adaptive streaming generally works well, although there are some differences :

  • Apple's adaptive streaming looks very solid. It switches transparently from one bitrate to another and is capable of selecting the most suitable stream in different circumstances. Moreover, the Apple client devices can rely on hardware acceleration support when rendering video, which allows them to playback high-quality video's more easily.
  • Adobe's HTTP dynamic streaming still has some limitations. These are caused by the overhead of the Flash platform, and the lack of hardware acceleration support in some mobile devices (we'll elaborate on these issues in a future edition of 'state of play'). This makes it sometimes more difficult for the client to choose the most suitable stream. Another consequence is that a buffering delay may occur when the client has to switch back to a lower bitrate. This being said, the average Flash client performs well under sufficient bandwidth conditions and most modern devices are capable of rendering decent quality video.
  • The Microsoft Smooth Streaming player is quite effective under sufficient and/or stable bandwidth conditions. After having made a connection, it quickly tries to build a large playback buffer at the highest possible bitrate: this way, it can continue to play video at the same bitrate for quite some time after the connection has deteriorated. Once this buffer is exhausted however, the player may experience difficulties when switching back to a lower bitrate. This may result in buffering delay(s) or unnecessary bitrate reductions.

Anyhow, player implementations are rapidly getting better and - certainly as far as mobile devices are concerned - HTTP adaptive streaming seems to be the technology of the future. Should you decide to use it, Rambla takes care of the deployment issues for you. We have automated the whole workflow process of transcoding your files into multiple resolutions/bitrates and creating the necessary configuration files. All you have to do is upload your source file via FTP to a so-called 'hotfolder' and wait for the notification that provides you with your URL's for adaptive streaming. A default hotfolder is now available for every user account, free of charge. For developers, our RATS API includes the same functionality.

This is an installment of our ongoing State of Play series, designed to offer insight into new evolutions and significant issues in the online video industry.

In this post, we'll try to give you an overview of the main methods and protocols which are currently employed to stream online video (for instance, we are not covering Peer-to-Peer streaming since it is still being considered as experimental in a CDN context). In our next post, we will look into more detail at the advanced technique of adaptive bitrate streaming (a.k.a. bitrate switching) which is quickly gaining popularity.

HTTP Pseudostreaming

HTTP Pseudostreaming is not 'true streaming', but a form of progressive download that allows viewers to seek to not-yet downloaded parts of a video. The delivery protocol is regular HTTP, combined with a mechanism that allows the player to include a start time parameter in the HTTP request's query-string. Using this mechanism, the client can do random seeking to any part of the timeline at any time.

Pseudostreaming has some advantages over true streaming:

  • It leads to fewer hassles with firewalls and proxy servers (corporate environments).
  • The initial loading time is usually shorter.
  • It results in a better viewing experience if the local connection is below average.

There are also a number of drawbacks:

  • In contrast to 'true streaming', pseudostreaming results in your digital files being downloaded to the physical drive on the end user's device.
  • It leads to higher bandwidth consumption, since the client will try to download the file in its entirety (as opposed to true streaming where only the parts that you actually watch are being delivered).
  • When seeking in large video's (> 15 minutes), pseudostreaming causes relatively long wait times before play is being resumed.
  • For high-bandwidth videos, it may slow down (or even crash) a viewer's browser.
  • Progressive download results in less precise/detailed statistics, since not all downloaded data has necessarily been viewed.

Stateful Streaming

Stateful Streaming ProtocolsIn 'true streaming' protocols, the file is being sent to the end-user in a (more or less) constant stream and the user watches it as it arrives. For this purpose, traditional video streaming protocols maintain a persistent client-server connection that allows for real-time communication. The actual video and audio streams are being delivered via a dedicated streaming protocol built on top of TCP or UDP.

The main problem with this approach is that streams are frequently blocked by (mainly corporate) firewalls, since they are not being sent over HTTP (port 80). To circumvent this problem, protocols have been extended to allow for a stream to be encapsulated within HTTP requests. However, this technique - called 'tunneling' - comes at a performance cost and is therefore often only deployed as a fallback solution. Most of these protocols also have secure variants that use encryption algorithms to protect the stream.

Well known stateful streaming protocols include:

  • Real Time Streaming Protocol (RTSP) : developed by the IETF and published in 1998 as rfc 2326. Most RTSP servers use the Real-time Transport Protocol (RTP) for media stream delivery, which supports a range of multimedia formats (such as H.264, MPEG-4, MJPEG, MPEG, etc.). Client applications include QuickTime, Skype and Windows Media Player. Most smartphone platforms (e.g. Android, Blackberry, but not iOS) also include support for RTSP as part of the 3GPP standard.
  • Real Time Messaging Protocol (RTMP) : developed by Adobe Systems, which has recently released the specification for public use. RTMP is primarily used to stream audio and video over the internet to Adobe's Flash Player client. Due to the success of Flash Player, the bulk of streaming videos on the internet is currently delivered via RTMP or one of its variants (RTMPT, RTMPS, RTMPE, ...).
  • MPEG transport stream (MPEG-TS) : a mechanism, defined in the MPEG-2 protocol, which controls the transmission and storage of audio, video, and data. It is mainly used in broadcast systems such as DVB and ATSC and enables connectivity with many of the conventional IPTV set-top boxes.

HTTP Streaming

HTTP streaming is a recent technology which is still maturing and would benefit from a widely accepted standard. Currently, separate solutions have been instituted by different vendors, which all use the same mechanism but are incompatible. From a client perspective, they all require the vendor's own software or platform:

  • HTTP Streaming ProtocolsApple HTTP Adaptive Streaming : an HTTP-based media streaming communications protocol implemented by Apple Inc. as part of their QuickTime X framework and iOS 3.0 system. Apple has submitted its solution to the IETF for consideration as an Internet standard.
  • Microsoft Smooth Streaming : an IIS Media Services extension that enables adaptive streaming of media to clients over HTTP. Microsoft provides Smooth Streaming Client software development kits for Silverlight and Windows Phone 7.
  • Adobe's HTTP Dynamic Streaming : Adobe released their own version of HTTP streaming (requires Flash Player 10.1) in June 2010 and is now trying to catch up with Apple and Microsoft. Since Flash Player is the main client platform targeted, this is also being referred to as HTTP Flash Streaming.

Streaming over HTTP works by breaking the overall stream up into a sequence of small HTTP-based file downloads, each download loading one short chunk of an overall potentially unbounded transport stream. By using HTTP as the stream transfer protocol, firewall issues are generally avoided. Downsides of this approach are a lesser (default) security and the absence of metadata, which makes it harder to ensure quality of service.

All flavors of HTTP streaming include support for adaptive streaming (a.k.a. bitrate switching) which allows clients to dynamically switch between different streams of varying quality and size during playback, in order to adapt to changing bandwidth conditions and available CPU resources. While mainly associated with HTTP streaming, Adobe has also included support for adaptive streaming into the RTMP protocol.

Another would-be advantage of HTTP streaming is that it allows the HTTP chunks to be cached within ISPs or corporations, in contrast to video streamed via RTMP. This would reduce the overall bandwidth required to deliver HTTP streams. However, research by Streaming Media concluded that "practically speaking, it appears that the benefit of cache servers is so unquantifiable that it is irrelevant".

Recently, the Motion Pictures Experts Group (MPEG) has started work on a specification for Dynamic Adaptive Streaming over HTTP (DASH) in an effort to standardize video streaming over HTTP. However, lots of preliminary issues still need to be resolved - including legal ones (patent claims) - before DASH can become a widely used standard.

A Client Perspective

Whereas most clients allow video's to play via (progressive) download, support for streaming protocols varies strongly depending on your choice of player, device and/or platform.

  • iOS 3.0+ devices (iPhone, iPad, iPod touch) support Apple HTTP Adaptive Streaming.
  • Windows Phone 7 client libraries support Microsoft Smooth Streaming.
  • Most smartphones (3GPP) support RTSP.
  • Flash Player supports RTMP and, starting with version 10.1, also Adobe's HTTP Dynamic Streaming
  • QuickTime supports RTSP, QuickTime X (OS X 10.6) also supports Apple HTTP Adaptive Streaming.
  • Silverlight player (3.0 or later) supports Microsoft Smooth Streaming
  • ...

This fragmentation has to be taken into account when streaming to multiple platforms (e.g. in case of a live-stream, where it is impossible to fall back to progressive download). As a Rambla customer, you can opt for a mix of different techniques to reach your target audience. Our CDN supports all streaming methods described in this post, both for on-demand and live-streaming. Moreover, it suffices to publish a single .mp4 file (H.264/AAC) on the CDN to make it accessible to all players and devices mentioned here. For more details, see our documentation or contact us.

Syndicate content