Streaming Media - August/September 2007 - (Page 16)

letters to the editor networks.com/products/security/index.html); (http://en.wikipedia.org/wiki/Windows_Media_DRM). 4. While both progressive download and streaming servers can start with the same hardware, streaming server software typically requires higher-cost servers to scale while progressive download typically scales with lower-cost commodity web servers. Flash Media, RealNetworks, Windows Media Services (Windows Server License), and QuickTime Streaming Server (Mac OS X Server License) are additional costs. 5. Progressive download start time is a function of the web server response time, content delivery network, and player’s buffer-to-start setting. Streaming can start more quickly since its player buffer-to-start time is much smaller. However, it’s been proven by YouTube and other progressive download sites that any latency imposed by progressive downloading is not an inhibitor to viral traffic generation and content popularity. 6. Time will tell. As you state, P2P can be a viable option, with the operative word being “can.” Its wide variance in performance and DRM issues rule it out for “most” commercial applications “at this time.” 7. This is true for early progressive download, but progressive download is evolving with web servers that allow random seeking and delivery throttling. 8. Social networking and viral sharing of content have quickly become major factors in the distribution of rich media. Today’s social networking sites have eclipsed the promises made by other distribution systems that attempted to clone network television/affiliate or cable television distribution models. But, as you point out, there are inherent risks and challenges associated with this model. The critical issue is that each content owner must first determine his business goals, then evaluate and choose those technologies that best support those business objectives. Now, Really Regarding “Streaming vs. Progressive Download” in the June/July 2007 Streaming Media, I wish to set the record straight. The authors failed to mention that Real Time Streaming Protocol (RTSP) using a true media server is the more efficient method for media delivery, whereas Hyper Text Transfer Protocol (HTTP) is designed more for delivery of web pages and browsing. Sending down a very short video under five minutes served by a web server under a light or medium load may begin playing fast enough for some, but just try launching a media video file of longer than five minutes 16 STREAMING MEDIA August/September 2007 via HTTP In this case, clients may require more than just . a “little patience” and may balk. Is it worth it? That depends upon the value of your content. Let’s assume we have “valuable” content to deliver. If the server is loaded or the client is connected to a congested network, RTSP-served streams begin playing faster regardless of the length. There will also be fewer interruptions once the video starts. Fewer resources are required, and less patience is necessary. That is because RTSP requires less data to deliver the same video file. If the video file is being served from a very popular source, the RTSP-configured media server will scale up the best, meaning a media server will deliver the more streams simultaneously, with the least re-buffering under the same loaded web server, all things being the same. “Progressive downloading” using HTTP may be configured to begin playing after the file completely downloads, which may take several minutes. HTTP may also be configured to begin playing as the media file downloads—which is technically streaming. In the latter case, the rebuffering issue will occur more frequently than if the same media file was streaming using RTSP from a true media server. So, the HTTP-based client will either wait longer to begin or is more likely to experience hiccups during the replay. One reason for this is because RTSP delivery requires less bandwidth to send down the same video file, and another reason is the way the two handle lost packets. HTTP will stop the download while it resends any lost packets until every single bit is accounted, which is necessary for web pages. But in heavy congestion, this may cause a mass packet collision for a media stream, and may halt the media file download without proper notification. With HTTP it’s all or nothing. , Under the very same conditions streaming with a media serving, RTSP will ignore any lost packets, and continue downloading the good packets. If necessary, the RTSP client sends the media server instruction to slow down the data rate for just the users affected by heavy congestion. The slower media stream has a better chance to play at least the audio uninterrupted. The user may not notice a few missing video frames, and is likely to prefer missing frames to a complete stop. When the network recovers, the media server will sense this and restore the data stream to the full frame rate as encoded. As the network load increases, the benefits to the client for streaming using a media server via RTSP trump the progressive downloading method using HTTP from a web server, particularly when considering longplay or very popular content over near-loaded networks. http://www.realnetworks.com/products/security/index.html http://en.wikipedia.org/wiki/Windows_Media_DRM

Table of Contents Feed for the Digital Edition of Streaming Media - August/September 2007

Table of Contents Sweet Sixteen Letters to the Editor Technology and Business Trends IBM Takes Webcasting to the Desktop ROI in the EDU Bank Serves Espresso, Enterprise Video Online Video Advertising: Hit or Miss MLB’s Foul Bawl A Crash Course in Flash Video Newspapers in Multimedia Metamorphosis Webcasting Large Entertainment Events: Seeing Through the Hype Webcasting With Windows Media Can’t Start A Fire . . . A WiMAX Primer Mobile Video at Last Telestream Episode Pro Grass Valley ProCoder 3 Silverlight Is No Flash Killer

Streaming Media - August/September 2007

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.