Streaming Digital Media for E-Learning 2: Delivering Content via a Web Server
Deploying streaming media content with the web server approach is very similar to the download-and-play model I described in yesterday’s post: it’s a pull technology.
Using this paradigm, the initial request for data originates from the client, and then is responded to by the server. When using digital media, uncompressed audio and video is first compressed into a single, muxed (multiplexed) media file for delivery over the Internet 
or a network at a specific bit rate. The media file is then placed on a regular web server. A web page containing the media file’s URL is also created and placed on the same web server. When the link on the web page is clicked on, a client-side player (such a Windows Media Player or QuickTime Player) downloads and plays the requested media file.
In the context of e-learning, it’s pretty standard for a video demo (for example) to be stored and progressively streamed from a Moodle LMS running on an Apache such as Apache server (see Figure 1)
Figure 1. Demonstration: Uploading a WMV file to Moodle, and playback
via HTTP streaming in Windows Media Player
[Click to play the demo]
From a user’s perspective, this process looks and feels identical a download-and-play case use case. From a technical point of view, the difference lies in how the client functions.
Unlike the download-and-play model, the client player starts actually starts playing the streamed digital media file while it’s being 
downloaded. This is possible because the content is cached: a process of collecting the first part of a media file before playing. This small ‘buffer’ of information allows the content to continue playing even during periods of high network congestion. With this delivery method, the client retrieves data as fast as the Web server, network and client will allow, regardless of the quality of the 
compressed stream. Only certain media file formats support this type of progressive playback including Microsoft’s Windows Media format (WMV) and Apple’s QuickTime (MOV).
Web server streaming uses the Hyper Text Transport Protocol (HTTP), the standard Web protocol used by all Web servers and Web browsers for communication between the server and the client. HTTP operates on top of the Transmission Control Protocol (TCP), which handles all the data transfers.
It’s useful to remember that HTTP/TCP is optimized for asynchronous, static applications, such as displaying static Web pages, and file transfer; this can affect the distribution and delivery of motion-based, asynchronous (‘on-demand’) content. Users may experience interruptions, ‘glitches,’ and temporary loss of playback because to the limitations of the HTTP and TCP protocols when handling multimedia content.
More…
–
July 09 2009 04:31 pm | e-learning
A Podcast Service for the E-Learning Curve Blog | E-learning Curve Blog at Edublogs on 21 Jul 2009 at 3:56 pm #
[...] content delivery is what differentiates podcasts from other ways of accessing files, such as simple download or streaming. Special client software applications called RSS aggregators (also known colloquially [...]
A Podcast Service for the E-Learning Curve Blog | E-Learning Curve Blog on 21 Jul 2009 at 3:57 pm #
[...] content delivery is what differentiates podcasts from other ways of accessing files, such as simple download or streaming. Special client software applications called RSS aggregators (also known colloquially [...]