HTTP streaming is an alternative approach to serving RealAudio and RealVideo files on the Web without the added management requirements and expense of server-side streaming software. Although this technique is not well-suited for high-volume sites serving numerous simultaneous streams, many smaller Web sites can benefit tremendously from this simple and inexpensive approach.

Actually, it's better than inexpensive, it's free.

That's because it relies on HTTP (HyperText Transfer Protocol) which is already used by all Web servers to store and transmit ordinary text and graphics files on the Web. And from the producer's point of view, there's no added effort because RealAudio and RealVideo files prepared for use on an HTTP server are identical to those used with a streaming media server.

There are some important differences however, between the capabilities of HTTP and specialized server software such as RealNetworks' RealSystem Server.

For example, you can't automatically detect the user's modem speed using HTTP. Instead, files optimized for each of the various connection speeds must be made available for users to select themselves. Links must say something like "High Bandwidth" and "Low Bandwidth". Also, the HTTP-based approach does not allow for live streaming audio or video presentations because complete files must be stored on the Web server before they can be accessed. Finally, HTTP does not make efficient use of server resources, and as a result doesn't perform well under heavy server loads.

But for sites serving no more than a handful of simultaneous streams at any given time, this is a great way to add streaming audio and video features to your Web site without incurring extra costs.

The only requirement for HTTP streaming is that your host server must recognize the .ra, .ram, .rm and .rpm mime types, which are standardized file classifications. Many servers already do. If not, it's a relatively simple process to configure your host server for these mime types and you can request that your service provider add this feature for you.

RealMedia Mime Types:

audio/x-pn-realaudio	(files with .ra, .rm and .ram file extensions)
audio/x-pn-realaudio-plugin	(files with the .rpm file extension)

 

Here are instructions for preparing RealAudio or RealVideo files for use on the Web:

1. Encode your media files with RealSystem Producer to .ra or .rm formats.
   
   
2. Copy your encoded files (files with the .ra, .rm or .rpm extension) to your World Wide Web server.
   
   
3. Use a text editor (such as Notepad or SimpleText) to create a metafile containing a URL to your file.

   For example, the contents of your metafile (also referred to as a Ram file) should be in the following form:

   http://hostname/path

   where hostname is the name of your World Wide Web server. For example: www.real.com.
   
   You should not include any HTML or SMIL tags in this metafile, it simply consists of link(s).
   
   
4. Save your metafile as a text using a .ram file extension.
   
   
5. In your HTML document, reference the metafile in a hyperlink. For example:
   
   <A HREF="filename.ram">
   
   
   You can use relative or complete paths. If you use complete paths, you must include both the hostname and the complete path. For example:
   
   
   <A HREF="http://www.real.com/home/filename.ram">
   
   
6. When a user clicks on the link, the streaming file(s) begin to download. The RealOne Player begins playing after a few seconds; it does not need to wait for the entire file to be downloaded.
   
   

With HTTP streaming and the right encoding and optimization tools, any Web developer has the ability to create and serve on-demand real-time audio and video.

 

Disadvantages of Streaming via HTTP

Because Web servers are not designed to manage bandwidth or keep multiple clips synchronized, streaming clips delivered by a Web server are more likely to stall than clips streamed by RealServer. To ensure that a presentation hosted by a Web server plays as smoothly as possible, observe the following points.

No SureStream Clips Encoded for Multiple Bandwidths

A Web server cannot send just one stream from a SureStream clip encoded for several bandwidths. Instead, it downloads the entire clip, causing a very high preroll. You must therefore encode each RealAudio or RealVideo clip for just one bandwidth. When using RealSystem Producer, select the option for Web server playback and choose your target audience. To support multiple bandwidths, encode separate clips for various bandwidths and use SMIL to let RealOne Player choose which clip to play.

No Secure RealAudio and RealVideo Clips

When you encode RealAudio and RealVideo clips with RealSystem Producer, you have an option to prevent RealOne Player users from recording the streamed clips to their computers. This feature works only when RealServer streams the clips. When a Web server delivers the clips, users still cannot record the clips through RealOne Player, but their Web browsers will cache the clips. Additionally, any user can click on your Web page hypertext link and perform a "Save As" function to download a clip from the Web server.

Limited Ability to Keep Parallel Clips Synchronized

A Web server does not consider clip timelines when downloading data. Nor does it receive
feedback from RealOne Player about the presentation's progress. Web server playback therefore makes it harder for RealOne Player to keep clips synchronized. A presentation that plays large clips in parallel may stall when the RealOne Player connection has little bandwidth to spare.

RealPix Presentations Buffer Longer

When delivered by RealServer, images in a RealPix presentation stream at different times depending on their place in the RealPix timeline. This lets you structure a RealPix presentation to keep it flowing smoothly. When delivered by a Web server, however, all RealPix images begin to download as soon as presentation playback begins. This causes a higher preroll.

SMIL File Optional

When delivering a single clip or a few clips played in sequence, you do not need a SMIL file. You can simply list the clips in order when writing your Ram file as described in "Creating a Ram File Manually". However, you can also have your Ram file specify a SMIL file that lists the clip locations, creates a layout, times the presentation, and so on.

SMIL Internal Timing Commands do not Work

Although you can use SMIL to lay out and time your presentation, you should not use the
clip-begin and clip-end attributes. A Web server cannot begin to download a clip at a certain point in its timeline. With clip-begin="5min", for example, RealOne Player must wait until it has received the first five minutes of clip data before it can play the clip. This creates an unacceptably long wait.

No Ad Insertion

The RealSystem ad insertion feature does not work with Web servers. Only
RealServer can replace <RealAdInsert.../> tags in SMIL files with URLs to ad clips.

No RealPlayer Seeking

Because a Web server cannot jump to a new position in a clip timeline, the RealOne Player position slider cannot fast-forward the clip. If the user moves the slider forward, playback pauses as the clip continues to download at its normal rate. RealOne Player resumes playback once the clip data reaches the requested timeline position.

No RTSP URLs

Because Web servers do not support RTSP, all URLs in presentations hosted by a Web server should begin with http://. This includes all URLs in a SMIL file or Ram file.

No Live Broadcast

Live broadcast is not possible because Web servers can download only clips stored on disk
Communication like this is not possible through HTTP.

Back to top

Back to RealSystem Overview