9/13/02 - Windows Media 9 Series Beta: Technical Review
New Server
The new Windows Media Services 9 has also received a thorough revision, with lots of new functionality added. First and foremost are the new Fast Streaming technologies, which include Fast Start, Fast Cache, and Fast Reconnect.
Fast Start seeks to minimize the buffering time before a streaming media file plays. The player must always buffer 3-5 seconds due to codec and packetization issues, but with Fast Start the data is sent much faster than the stream’s native bit rate. For instance, if a user is watching a 20kbps stream on a broadband connection, the data can be sent at 100 - 200kbps, which means the first 5 seconds can be buffered in less than one second.
In addition to minimizing the initial buffering time, data can be sent over and above the streaming data rate and cached to offer more protection from bandwidth shortages. This is known as Fast Caching. The player uses Internet Explorer’s cache, so any restrictions imposed by IE are inherited by the player.
Most interesting for live streaming media producers is Fast Reconnect, which attempts to reconnect any lost net connections. Using Fast Reconnect, a player that loses its connection to a server plays bits from its (Fast) cache while attempting to reconnect to the server. Fast Reconnect technology also works between the encoder and server. Obviously, in a live situation you can’t send bits faster than they’re being encoded, but having an encoder that proactively tries to re-establish a lost connection to the server is something that should have been available years ago. The demo shown at the conference was very impressive – I know I can’t wait to test this functionality out in the field.
One thing I must point out is that most of these new technologies, as well as RealNetworks TurboPlay, are based on the availability of additional bandwidth. This is not always the case for Internet streaming. Additionally, most streams are authored to make the most of the user’s connection. If a user connects at a broadband rate, chances are that they will be steered towards a broadband stream, leaving little or no extra bandwidth. In cases like these, these technologies may not make a noticeable difference. These technologies can be very attractive, however, when used on an Intranet, where there is generally excess bandwidth available.
The other two major announcements are server-side play lists and improved advertising support. The new server-side play lists are created through the server interface, and stored in a SMIL 2.0 file. They can be changed dynamically, personalized for individual users, and feature both live and on-demand content. Improved advertising support allows dynamic insertion and deletion, as well as cookie support. Previously ads were inserted via the ASX file; inserting them from the server side is more efficient and flexible.
Other miscellaneous server improvements have been made, such as improved packet recovery, better multiple bit rate (MBR) stream support that now allows multiple audio streams, and better bandwidth detection. One surprise announcement is support for the RTSP protocol. For the time being, the Windows Media Group is still recommending the MMS protocol for its rollover capabilities, but eventually MMS will be phased out.
Administering the Windows Media Services 9 can now be done via the traditional Microsoft management Console or via a web-based HTTP interface, which allows remote access across firewalls. Finally, this release includes code optimizations that allow greater numbers of streams to be served per server.
Page 5: Early Impressions >>