What is the difference between a CDN and Phenix’s real-time streaming platform?

CDNs, or Content Delivery Networks, were built for file downloads over HTTP. Early ones like Akamai focused on images initially to speed up the delivery of web pages. As the web grew so too did CDNs and their capabilities to deliver all sorts of web content, HTML, CSS, images, etc.

Along came internet video, initially in the form of files that you could download and then playback locally. Then came progressive download video where you could begin the video playback before the entire file was downloaded.

Around this time, streaming platforms like Real Networks and Microsoft Windows Media Server came onto the scene for video streaming. These protocols were proprietary and utilized UDP to enable the streaming of video data vs. the download of video files.

Flash from Macromedia came onto the scene and started to dominate the world of online video streaming with its Real Time Media Protocol or RTMP. Around this time, CDNs like Akamai began to license technology from all three major streaming vendors, running their services within their networks to enable video. However, these licenses were not cheap, and the third-party proprietary software between the CDN and the user motivated the CDN to push forward a new solution that utilized the existing HTTP infrastructure investment. This was not a decision that was based on user experience or an analysis of the problem and choosing a better technology but borne out of cost reduction and existing investment re-use.

CDNs collaborated to standardize on HTTP based streaming, initially forcing Adobe to release HTTP Dynamic Streaming or HDS to allow the use of CDN infrastructure and ultimately when Apple released its HTTP Live Streaming or HLS specification the world adopted it because it was cheap, standards based and scalable.

With protocols like HLS and HDS the video stream is made up of many small file downloads played back one after the other. This approach was great for VOD and okay for live streaming at high latencies where large client-side buffers are not a problem. However, chunk/file based workflows are not great for low latency and impossible for real-time streaming.

Overall, CDN infrastructure was built for handling files, storing them, moving them, and serving them. None of it was built with the concept of time as being a critical variable for optimization.

Now here comes WebRTC or Real Time Communications for the web. A reboot of previous protocols like Real, WMS, RTP, RTSP, etc., but sponsored by the W3C and built into browsers.

Phenix built a global infrastructure based on WebRTC around the idea that the end-to end latency should be less than 1/2 second. To do this, you need a significantly different approach and a different fundamental architecture. Nothing can be written to disk; it takes too long. Everything must be ready to stream, and transcoding must be completed once prior to streaming out to end users; per user transcoding causes major issues in terms of resource utilization.

The other industry innovation that Phenix has taken full advantage of is dynamic resource allocation via Cloud Infrastructure providers. Every Phenix service can be provisioned in real-time to meet spontaneous demand, using only what is needed when it’s needed. This is new since the inception of CDNs and allows Phenix to start and grow with its customers without requiring an expensive infrastructure build out. Dynamic scaling also allows the licensed version of Phenix to be deployed within existing cloud environments to enable the creation and selling of profitable services on existing underutilized resource investments.