The State of Media Servers 2015

It might seem like 2014 was the year that the media server died.

At least that’s the conclusion that could be drawn by the demise of at least one well-known media server solution—the Helix Media delivery platform by RealNetworks—and the lack of updates by other big name media server companies such as Adobe, Apple, and Microsoft.

Chris Knowlton, vice president and streaming industry evangelist at Wowza Media Systems, says that the past year has been an “interesting” one when it comes to the media server landscape.

“RealNetworks, after breathing new life into Helix Media Server for a few years, suddenly declared that Helix Media Delivery Platform was end-of-life this past October,” he says, adding that other well-known streaming media server products have faded away in recent years.

Apple’s QuickTime Streaming Server stopped shipping several years ago, although there is a version focused on podcasts that still ships with the OS X Server app that Apple sells in its Apple App Store. Microsoft, for its part, does not appear to be shipping any new media server updates and is instead focusing its energy on Azure and Azure Media Services.

“Adobe seems to be less intent on general-purpose media technologies,” Knowlton says, “and appears to be refocusing its media development efforts on Primetime, its TV Everywhere offering.”

Perhaps this is to be expected. The commoditization of media servers—along with the advent of open source media servers, as well as the intrinsic downward pricing pressure that comes along with open source and lower-priced commercial media server alternatives—had the potential to force larger, more well-known competitors out of the market.

Knowlton, though, thinks there’s another reason why these larger companies seem to be moving away from media server products.

“One commonality among them is that media servers are either no longer, or were never, one of their primary businesses,” he says. “Delivery of streaming to any screen isn’t a side project for us, it’s our only focus.”

This is especially true in Apple’s case, as it championed the H.264 video codec and the AAC audio codec as a way to standardize its QuickTime movie trailers. Once those two codecs were widely adopted as the common denominator for audio and video streaming delivery, Apple then turned its attention to move beyond progressive downloads to delivering premium movie and television content in a segmented (or fragmented) streaming format.

The result of its effort was Apple’s contribution to the adaptive bitrate (ABR) over HTTP streaming effort: HTTP Live Streaming (HLS), which consists of thousands of small files of interleaved audio and video served over TCP via a plain vanilla HTTP web server or a specialized media server. When more than one resolution or bitrate of HLS content is available for the end user to view, the small segmented files can be sent at varying bitrates, depending on current network conditions.

“As HTTP adaptive streaming has become the preferred means of delivery,” Knowlton says, “a number of other cost-effective multiscreen media delivery options have become available for most customers. This, in turn, allows Apple et al. to move away from general-purpose media server software and focus on other aspects of their businesses.”

Media Servers vs. HTTP Servers

With this move toward commoditization and standardized codecs—and the promise of standardized ABR technologies, whether in de facto (HLS) or a true standards-based technology (MPEG-DASH)—questions about the need to continue to use commercial media servers instead of free or low-cost HTTP servers follow naturally.

Jaron Vietor, CTO of DDVTech, which makes MistServer, says that there still seem to be four major differences between HTTP servers and media servers.

HTTP Servers Fail When Streaming Live Content

Vietor says the strength of an HTTP web server, serving up files, is also its Achilles heel when it comes to delivering live content. “Web servers can stream a file from it with full seeking support,” Vietor says, “because when the client/browser says, ‘give me the file, starting at byte position 346455,’ the web server can simply go to that position in the file and begin to serve content.”

By contrast, he says, a proper streaming server can be used to stream individual virtual files for both live and on-demand content, instead.

“Plain HTTP servers can only serve whole files,” Vietor says. “So if you want to run a live stream, you’re going to have to segment the content. The problem lies in the

fact that, when you’re working with live and/or multiple formats, creating files on disk becomes either cumbersome or impossible.”

To solve this issue, a media server such as MistServer is used to generate a “fake” file in memory for each connected client, which means the client browser thinks it is  receiving an entire file. But instead of looking up a specified byte position, the media server calculates the proper current byte range, in the form of a millisecond position in the stream buffer, and offers that back to the client browser.

HTTP Servers Struggle With New Technologies and Protocols

Adaptive bitrate content, once segmented, can be served by a standard HTTP server, but Vietor says that new technologies, such as WebRTC, need more than a simple webserver.

“WebRTC has much better performance and less latency when used with a streaming server,” says Vietor. “Even for videoconferencing and such, including direct communication between clients, there is still a need for network address translation (NAT) traversal, which cannot be a simple web server.”

In addition, to save bandwidth, some form of a media server is also used for video conferencing between more than two parties.

Web Servers Require Scripting

The current batch of HTML5-based streaming servers, especially those used in live streaming solutions, relies on scripting at the player to properly execute playback.

“All current HTML5 live streaming solutions require client-side scripts,” Vietor says, “but a proper media server can work without those.”

For Apple devices, such as the iPad, iPhone, or Macintosh computer, HLS works without scripting. For other, non-Apple devices, playback of HLS content requires fairly intensive client-side scripting. As such, if the non-Apple device can receive another form of ABR or streaming delivery, a media server bridges the gap between needing to use a single streaming type for all devices versus using the best streaming type for a specific device type.