This chapter describes how RealServer streams on-demand, or prerecorded, presentations.
RealServer is ready to stream content when you first install it, and will stream on-demand presentations and files that you place in the Content directory. When a user clicks a link to an on-demand presentation, RealServer streams the presentation from the beginning of the file. In live broadcasting, the streaming begins at a specified time, and anyone who clicks the link later than that misses the beginning.
On-demand streaming is suitable for any content that is not time-sensitive. The following are examples of good uses for on-demand streaming:
Use live broadcasting for events that you want to broadcast as they are encoded. Refer to Chapter 11, "Unicasting Live Presentations".
This section describes the ways in which on-demand streaming works together with other features.
Streaming and live broadcasting methods are mutually exclusive methods, with one exception: you can use the Simulated Live tool (G2SLTA) to broadcast on-demand files as if they were live. See "Creating a Live Source with G2SLTA" for detailed information on using the G2SLTA tool.
If you have used the live archiving feature to convert live streams to on-demand files, you can then create links to these individual files and deliver them via on-demand streaming.
You can also use the archived files to re-create a live presentation using the G2SLTA program.
RealServer is configured to automatically allow RealProxy to store all live and on-demand content streamed by your RealServer. To prevent certain on-demand files from being cached by RealProxy software, see the "To prevent RealProxy from caching material on your RealServer:" instructions .
As long as your RealServer is correctly located outside a firewall, it can deliver on-demand content to clients on the Internet. Refer to Chapter 9, "Firewalls and RealServer" for more information.
Any access control or authentication rules you set up for your RealServer are automatically used when users request on-demand content.
You can view which presentations are being streamed at any time with the Java Monitor. Click the Connections tab or the Files tab to see which files are in use.
All presentations streamed from your RealServer, whether on-demand or live, will be listed in the access log.
On-demand files are made by content creators. The administrator of RealServer and the content creator may be the same person, but they are discussed here as two separate people. The content creator may encode into RealAudio or RealVideo files, or assemble RealPix presentations, or create any other type of file that RealServer can stream.
Place clips in the RealServer Content subdirectory.
If you do not want to use the Content directory, do one of the following:
 |
Additional Information |
|---|
| See "Storing Clips in a Subdirectory of the Content Directory". |
Content) and create another mount point to use for this content.
|
|
Additional Information |
|---|
| Refer to "Storing Clips in a Different Directory". |
RealServer needs three things in order to stream on-demand clips:
When RealServer is installed, it is configured to stream content found in the Content subdirectory of the main RealServer directory. Subdirectories of Content may also contain content. RealServer is ready to stream your on-demand content when you first install it.
RealServer uses these settings to stream on-demand files:
/). To view this setting, click Mount Points under General Setup.
A link to an on-demand file has the following format:
http://address:HTTPPort/ramgen/path/file
| Component | Meaning |
|---|---|
http |
The protocol used to initiate streaming. Always use http in Web pages. |
address |
Machine and domain name of RealServer. IP address may be substituted. |
HTTPPort |
Port number where RealServer listens for requests sent via HTTP. This value is usually 80 or 8080; see "Port Numbers". |
ramgen |
Ram file generator mount point. |
path |
Optional; the virtual directory is any actual directory, relative to the base path of the mount point. If the file is located in the base path itself, omit path. |
filename |
The file name itself, including the extension. |
For example, a link to a file named video.rm, if placed in the Content directory, would look like this:
http://realserver.example.com:8080/ramgen/video.rm
To create a link for it in a Web page, use the anchor tags:
<a href="http://realserver.example.com:8080/ramgen/video.rm">Click here to watch the latest video.</a>
A link used in RealPlayer has a slightly different format:
rtsp://address:RTSPPort/path/file
rtsp://realserver.example.com:554/video.rm
Because of differences in software, equipment, and data transmission speeds, users will view your content at different bandwidth volumes. When a client requests a clip, it sends its bandwidth capabilities to the RealServer. RealAudio and RealVideo files encoded with the RealSystem encoding tools (versions 6 and later) record media at different rates, and store them in a single file, called a SureStream file. A RealServer that receives a request for a media file from a client will note the client's bandwidth, locate the correct portion of the file, and will stream the highest portion of the stream that matches the request. In this way, visitors to your site will receive the highest possible quality transmission, the person who encodes the file need encode only once, and you the administrator need keep track of only one file. In addition, as available bandwidth can vary over time, RealServer switches between streams automatically.
If the file does not contain an encoded portion that matches the client's requested bandwidth, RealServer sends a message to the client indicating that no matching bandwidth is available.
Bandwidth negotiation of RealAudio and RealVideo was handled in previous versions of RealNetworks products by creating one file for each compression algorithm, and putting all the files in a directory whose name ended with .rm. Files were named according to the compression algorithm with which they were encoded.
If you still have these files, you don't need to re-encode them. RealServer reads the old directory structure and can perform the bandwidth negotiation automatically. Bandwidth negotiation is always active; only in those directories ending with .rm will RealServer perform old-style bandwidth negotiation.
Audio and video data types are the only types that contain multiple compression rates within one files. If you are streaming another data type, such as text, bandwidth negotiation is handled via a SMIL file. Instructions on doing this are available in RealSystem Production Guide.