Posted by: kurtsh | February 26, 2007

INFO: Why Web Servers are lousy for hosting Multimedia streams

I was reviewing an old Powerpoint that I did and I found an interesting list that I’d written on "Why Media Servers like Windows Media Services 9.1 are so much better at hosting Streaming Media than Web Servers".  Here’s the list:

    A Web Server sends as much data as quickly as possible.  This greatly reduces the ability of the server to serve great numbers of clients at the same time since bandwidth is saturated as a much faster rate.  Streaming Servers send data at predictable rates due to larger file sizes and concurrent demand for data.
    Media Servers intelligently regulate the rate at which data is being sent based on feedback from the player.  This allows players to always cache up just enough media to smoothly show video/audio and request "more content" if there was a hiccup and the cache is beginning to diminish.  This is balanced between the server’s desire to not use up the server’s available bandwidth to improve service scalability.
    Web servers do not support MBR video, which serves a specific bitrate media stream (depending on what’s requested from the client’s player based on the client’s available bandwidth) from a single file on the server that contains video streams for multiple bit rates.  A Streaming Server can store MBR video files which singularly serve any available video qualities to all bandwidth types, within a single file.
    Web servers are not designed to send data over UDP, which is the preferred method for media delivery because among other things, it is designed for low latency, forgiving applications.  TCP is a guaranteed, in-order protocol that must wait for lost packets that aren’t received – no matter how unnecessary the packet really is.  (One lost packet in a video stream is hardly the end of the world and most people won’t even know there was a hiccup if one got lost, however TCP must-must-must get that lost packet.)  Also UDP can use a single socket/port to transmit video from to multiple destinations, where as TCP must reserve a specific socket/port for each connection.
    Web servers do not support multicast streaming.  Multicast enables streaming servers to transmit a single media feed to an unlimited number of clients "listening", not unlike a broadcast radio station or an over-the-air TV station.  This provides a huge amount of scalability for servers that are in scenarios that can leverage multicasting.  Web servers must transmit content individually to each client connection, even if the content is the same for each client.
    Web servers do not provide the VCR type playback function a media server does.  A streaming server can fast-forward to specific location in an on-demand stream and immediately deliver the content at that timecode to the client.  A web server can not:  The client must wait until that component of the media stream has been downloaded before they can view it which is extremely unproductive for long recordings like seminars & recorded presentations that may be an hour long and have a lot of content to download.
    Web servers are not designed to capture rich client logging data that media servers can capture.  Streaming servers can not only tell "who" accessed a stream via IP address or actual credential, but how long they used the stream, how much data they downloaded, to what point they listened, what kind of bandwidth they had, the version of the player they used and it’s configuration, etc.  This information can be immensely valuable when delivering Distance Learning or Remote Education.


%d bloggers like this: