What does streaming mean?


"Streaming" is a generic term. It basically means that the data being transferred can be used immediately, without having to download the "thing" in it's entirety before it can be used.

Streaming audio or video will be decoded and played back immediately -- or once enough data has been transferred in order to start playback.

There are basically two types of streaming:

1. Progressive Download

When a media file is located on a traditional web server, it is "served" like other web-based files such as images, HTML and so on.

Wimpy will play as soon as enough data has been downloaded to initiate playback. However, the end result is that the file will be delivered in it's entirety to the "client" (your browser/PC) and saved in the browser's cache.

If the same file is requested, the browser/PC will use the file in the cache rather than re-downloading the entire file again -- unless of course the browser's cache is cleared.

Said Another Way:

When a request is made for a file, the web server prepares to send the entire file, and includes some basic information about the file (aka the "header") such as how big the file is and what kind of file it is prior to sending the actual "data" that constitutes the file.

The browser then receives the basic information, and prepares to store the file on the local PC in it's entirety (aka "cache" the file). Some file types, such as images and media files, do not need to be fully downloaded before they can be presented to the user.

For Example:
Have you ever viewed a very large photo and watched how the image slowly draws on the screen? This is a visual representation of how progressive downloading operates -- as the image data arrives, the browser draws whatever is available to the screen.

But if you refresh the same page with a large photo on it, you'll notice that the image loads much faster, perhaps the entire image will appear immediately.

The same thing happens with audio and video media files. But since media is played back at a constant rate according to time, you won't hear the audio "go faster" as more and more data arrive -- the remaining un-played data is simply compiled to a file on your local PC waiting to be played in due time.

Stuttering? One thing you may notice when either your internet connection or the web server's connection is slow (or if there is a lot of network traffic) is that audio may "stutter". This happens because not enough data is available for playback -- there simply isn't enough data to play back, so the track stops and starts intermittently as new data arrives. Most browser's are smart enough to calculate the connection speed and "buffer" enough data to prevent stuttering. While you may have to wait a few extra seconds before playback starts, it's worth it to prevent any kind of stuttering.


2. "True" Streaming

"True" streaming actually means that the data is played, then discarded immediately after it is played. Rather than delivering an entire file, streaming servers deliver mini-chunks of the source media.

On the client side (your browser or media player) takes these little chunks of data and collects them so that, perhaps, 20 seconds of the media files can playback. This is referred to as "buffering". Once the part has been viewed (or listened to) the client immediately discards the data -- the data is not stored locally (e.g. not "cached").

This is nice because the client doesn't have to negotiate large files, nor does it need a large hard drive to store massive HD media files.

Services like youtube.com and vimeo.com have special servers designed for delivering small chunks of data at a high rate of speed. 

Unlike traditional web servers that use the "http" protocol to deliver entire files "real" streaming servers do not deliver files in their entirety, and the overall "file" is generally no stored by the client (your media player/browser/PC).

If the same file is requested, the client will restart the stream "from scratch" -- meaning that the entire process begins a-new.

Generally speaking, "real" streaming servers (aka media servers) do not use the HTTP protocol, they use various other protocols that are more efficient and dedicated to streaming media data such as RTSP, RTP, MMS, MSS, HDS, some of which are proprietary (aka $$$).

Wimpy Uses Progressive Download

This is because Wimpy is designed for use with standard web sites. It also means you don't need to deal with maintaining a separate server, purchasing and installing server-based streaming software or paying extra for streaming-fees.

Using the "progressive download " method is the least expensive way to present audio/video on a website. Like "true" streaming, Wimpy's "progressive download " method allows a file to begin playing before it is fully downloaded.

A bit is a bit

Whether a bit is served through a "traditional" streaming server (e.g. Icecast, Shoutcast, Windows Media Systems, RealNetworks, Flash Media Server etc.) or served by a "standard" web server... the same bits are being transferred.

"True" streaming servers and "standard" web servers just uses a different transport methods. Shoutcast and other "true" streaming servers do not necessarily transfer bits better than a "standard" web servers, they just transfer them differently.

Granted, "traditional" streaming servers are geared specifically for media, whereas "standard" web servers are geared toward serving a variety of other "things".  Streaming servers may be a little more efficient, but they are still transferring the same volume of bits.

Click here for a more in-depth explanation or the differences between a "traditional" streaming server and a "standard" web server.

A Note About "Chunked Transfer Encoding"

Web servers can be configured to send data using Chunked Transfer Encoding. When a web server is set up to deliver files this way, traditional (and important) data is not delivered that allows the browser (and Wimpy) to determine the tracks overall duration (in seconds).

Hence, the timeline (scrubber) may not work when the "duration" is unknown.

In a nut-shell, the server does not issue "content-length" information as well as the "duration" meta that browsers require for media files. Chunked Transfer Encoding is used by some hosting companies to mimic "true" streaming over the HTTP protocol and sends small chunks of data as without traditional "header" information. In adddition, chunked transfer encoding never issues the "file done loading" signal, so Wimpy will continue to monitor the file loading progress for the duration of the track.

As a result, Wimpy will not display the timeline scrubber properly and users will not be able to "scrub" to different parts of a track. Without the "duration" there is no way for wimpy to know when the track ends so attempting to utilize the scrubber is pointless because if the scrubber were to move to the 50% point... 50% of what duration???

Check with your hosting provider to see if they can disable "chunked transfer encoding" for media files (The tech support folks at your hosting company should know what this means).