Links to RealServer content use special formats that activate RealServer and tell the it how to deliver the requested material. This chapter describes the theory behind the different formats that RealServer uses.
This chapter explains how to construct the links to your content. Different methods use different formats, but they're all based on the same kind of structure.
This chapter covers generic link formats, as well as link formats that apply to all types of features (such as subdirectories in a link). For instructions on linking to content served with a particular delivery method, refer to that method's chapter. Also, Chapter A, "Summary of Link Formats" gives a quick review of all the various formats.
This chapter provides an in-depth discussion of link anatomy, including special directory structures. The background information provided may not be of interest to you if you aren't using any of RealServer's advanced functions.
Content subdirectory, you can use the link format described in "Linking to On-Demand Clips".
A typical link to media clips served by RealServer includes elements such as a port, a mount point, a path, and a file name.
The following illustration shows the parts of a more complex link.
All links to material served by RealServer use the same general format:
protocol://address:port/MountPoint/path/file
The protocol is the communication protocol that RealServer uses in sending the media clip.
RealServer uses two main protocols to communicate with clients:
RTSP is a client-server protocol designed specifically for serving multimedia presentations. It is an open standard, and very useful for large-scale broadcasting. Only RTSP can deliver SureStream™ files with their multiple bandwidth encoding. SMIL, RealText, and RealPix also require RTSP.
PNA is the proprietary client-server protocol designed and used by RealNetworks in RealSystem versions 5 and earlier. The ability to serve via PNA is supported in RealServer 8 for compatibility with older versions of RealPlayer.
RealServer also uses HTTP to stream HTML-based material, such as Ram files and RealSystem Administrator pages.
 |
Additional Information |
|---|
| Read "Protocols Used by RealServer". |
Links to media files streamed by RealServer can appear in four places, and use different protocols, as shown in the following table. The protocol you use depends on where you are placing the link, and what type of content it points to. Notice that Web pages require a slightly different link format than the other three venues.
The address is the IP address or the machine and fully qualified domain name where your RealServer is installed. You can use either. In this book, the example address is always realserver.example.com, rather than the equivalent IP address.
The port number is the number where RealServer is listening for the appropriate RTSP, PNA, or HTTP request.
Including the port number of the RealServer machine is optional when you use RealServer's default port settings. If you don't include a port number in the URL, the client (such as RealPlayer) will supply one on its own. It looks at the protocol, shown at the beginning of the URL, to decide which port number to use.
To check the port numbers in use on your RealServer, look in RealSystem Administrator. Click General Setup>Ports.
| Protocol | Port Number |
|---|---|
http |
8080 |
rtsp |
554 |
pnm |
7070 |
You might want to change the port numbers, using RealSystem Administrator, if multiple RealServers are using the same IP address, or if you want to segregate requests for different material.
If your RealServer and Web server are on the same machine, you may need to modify the HTTP Port setting. See "Running Web Servers and RealServer on the Same System" for information.
A mount point reference appears in every URL. It is a shortcut name that tells RealServer which feature (or file system plug-in) will be handling the request. Most of the delivery methods each have their own mount point.
Mount points are listed in RealSystem Administrator.
In the case of on-demand content, though, the mount point is usually defined as a single forward slash, and is therefore "invisible" in the mount point.
Some frequently used mount points are:
Content directory
To determine which mount point to use (if any), you must first decide which type of delivery method you are using. To find out the correct mount point to use, consult the table below. The table is based on the default configuration your RealServer was shipped with; if you have changed these values, you will need to use the new settings.
In addition, if the link will be used in a Web page, remember to also include the Ramgen mount point. (See "Ram Files and Ramgen" for more information.)
In some cases, a link will include more than one mount point. The Ramgen mount point is often used in addition to other mount points. The scalable multicast mount point is used at the same time as the live broadcasting mount point.
For multiple mount points not covered within these chapters, consult "Multiple Mount Points in Links" in Chapter A, "Summary of Link Formats".
Using different mount points that point to the same base path or using the same file system can be an effective way of providing conceptual organization of content. For example, if content on your RealServer is being supplied by different people, you may elect to establish a different mount point for each person's material, even though the material is stored on the same machine, though in separate locations.
RealServer looks through the list of mount points before it looks for virtual or actual directory names. Should a mount point or virtual directory have the same name as an actual directory, RealServer will ignore the actual directory.
There is one case in which you can use this to your advantage: displaying a message that says "Currently experiencing technical difficulties" when a live broadcast is interrupted. Live files are sent to a mount point that does not have a corresponding base path. Live files are streamed as they are created by an encoder, and they never exist in file form. Create an actual directory with the same name as the live mount point, and place a small file containing your message in this subdirectory. If a live stream fails to arrive at RealServer, RealServer will search for an actual directory that matches the URL. In this case, it will find the subdirectory with the error file in it.
|
|
Additional Information |
|---|
| See "Playing A "Please Stand By..." Message". |
The path value references the subdirectory (if any) where the clip is located.
Content. Include only the subdirectory names under Content; you don't include Content in the subdirectory.
If you have created an additional mount point for on-demand content, you can determine whether a path is necessary by looking at the new mount point and its base path. (The base path gives the actual location for files served by the mount point.) If the on-demand clips are located in a subdirectory of the base path, you need to include the subdirectory (or subdirectories) in the link.
livefile value, include the virtual path.
You can't determine which parts of a link refer to mount points and which parts refer to virtual directories just by looking at the link; you must examine the pages that list mount points to see which elements in a link are mount points.
Finally, you type the filename at the end of the link. The filename is either the name of the clip (in which case you must use the ramgen mount point-see the next section) or the name of a metafile.
You will need to give some information to the content creator so that she can create accurate links to the content she is creating. This information is summarized in the table below.
Metafiles are text files that you link to in Web pages. The metafiles contain the names of the actual links. Pointing to a metafile in a link, rather than to a media clip, enables RealPlayer to contact RealServer. There are two types of metafiles:
There are two ways to reference a clip in a link:
Many browsers are not configured to start RealPlayer when a user clicks on a link to RealServer content. Because of this fact, links to RealServer content point to small text files, also known as metafiles. Web browsers can be configured to recognize this single file type and start RealPlayer. The metafile contains the "true" address of the media files, and RealPlayer can recognize these.
These metafiles are called Ram files. They are small text files that list one or more clips in sequence. They are similar in function to SMIL files, but cannot do the sophisticated presentations that are possible with SMIL.
A user can save the Ram file (by right-clicking on the link in the Web page) and use it to connect later (by opening it with RealPlayer), and skip the step of downloading it from your RealServer.
Ram files are often used for backwards compatibility with earlier versions of RealServer.
|
|
Additional Information |
|---|
| To learn more about Ram files, including options for start times, see RealSystem Production Guide. To view this manual, click Resources under Help in RealSystem Administrator. |
A Ram file is simply a text file with the extension .ram. It can list the URL for a single clip, or it can give URLs for clips to be played in sequence:
|
One reason to use Ram files in RealSystem 6 software is that most content uses the RTSP protocol, which earlier clients could not read. A Ram file can list more than one presentation type.
A Ram file that lists two different protocols for the same clip uses the following format:
|
Newer clients, such as RealPlayer 6 and later, stop reading a Ram file when they reach the word --stop--. Older clients look for the pnm instruction.
As a shortcut to creating a Ram file for every single link you create, RealServer 8 is preconfigured with a mount point named Ramgen, which you can add to a link instead of creating a Ram file.
When RealServer receives a request that contains this mount point, it appears to create and send a Ram file automatically. RealServer simply converts the URL in the initial request to an URL within an HTTP message. The browser appears to download a file; the information is given to the client, which requests the correct links.
You must reference either a Ram file or Ramgen in a link. Some browsers are not configured to start the client when a SMIL or other streaming media file is requested, but all browsers launch the client when they receive Ram files.
Synchronized Multimedia Integration Language (SMIL) is a mark-up language, based on an open standard, that specifies how and when each clip in a file should be played. SMIL files can perform sophisticated layout and timing instructions.
For instructions on linking to SMIL files, see "SMIL Files".
If you are just getting started with RealServer, store your media clips in the Content subdirectory of the main RealServer directory. These clips can be streamed immediately.
However, if you have many clips, it makes sense to organize them into subdirectories or even to store them on different computers. Links for these files may become quite lengthy. Adding multiple mount points, with base paths that substitute for the lengthy paths, will shorten the links.
| Location of Clips | Remarks |
|---|---|
| Content directory | When your clips are stored in this directory, links are easy to create. See "Storing Clips in the Content Directory". |
| In a subdirectory of Content | Include the subdirectory name in the link. Refer to "Storing Clips in a Subdirectory of the Content Directory". |
| In a different directory than Content (not a subdirectory) | Add a mount point that references the directory. Consult "Storing Clips in a Different Directory". |
| On a completely different system | Configure your system to recognize the other location and add a corresponding mount point that references the other system and path. Reference "Creating Additional Mount Points" |
The Content directory is the main place to put clips. In the following example, the Content directory contains two clips (music.rm and music.rp) and two directories (Speeches and Concerts):
| Directory Structure |
(main directory) |
| Values |
Mount Point: / Base Path: C:\Program Files\Real\RealServer\Content (Windows), usr/RealServer/Content (UNIX) |
The file named music.rm would have the following Web page link:
http://realserver.example.com:8080/ramgen/music.rm
In a Ram file, use a similar format, with a different protocol and without the ramgen mount point:
rtsp://realserver.example.com:554/music.rm
Files in the Content directory can be streamed without any special changes. But if you have a lot of files, you will probably want to organize them into subdirectories of the Content directory. When you do, be sure to include the names of the subdirectories in the link to the files. Substitute the subdirectories for path in the URL.
| Directory Structure |
(main directory) |
| Values |
Mount Point: / Base Path: C:\Program Files\Real\RealServer\Content (Windows), usr/RealServer/Content (UNIX) |
To refer to the file debussy.rm, located in the Concerts/Classical subdirectories, include the subdirectories in the link:
http://realserver.example.com:8080/ramgen/Concerts/Classical/debussy.rm
In a Ram file, use a similar format, with a different protocol and without the ramgen mount point:
rtsp://realserver.example.com:554/Concerts/Classical/debussy.rm
 |
Tip |
|---|
| If you have many subdirectories within subdirectories, consider defining an additional mount point as a shortcut. See "Creating Additional Mount Points". |
If you are going to store files in a directory that is a not a subdirectory of the main base path, you will need to create a separate mount point for those files. The mount point functions as a shortcut for the path information. Use the new mount point in links to that content, in addition to any other appropriate mount points.
|
|
Tip |
|---|
| Choose a name for the mount point that reflects the type of content streamed from this location or its subdirectories. |
A generic mount point name appears in the Mount Points list and in the Edit Mount Point box.
When you create a link for the content in the new mount point's base path, use the new mount point. If the content is in a subdirectory of the mount point's base path, include the mount point and the subdirectory in the link.
Uses for additional mount points include:
In the following example, assume a mount point has been defined as /music/, and that it refers to the actual Concerts directory:
| Directory Structure |
(main directory) |
| Values |
Mount Points: /music/Base Path: C:\Program Files\Real\RealServer\Concerts (Windows), usr/RealServer/Concerts (UNIX) |
A file named debussy.rm, located in the Classical subdirectory, would have the following link in a Web page:
http://realserver.example.com:8080/ramgen/music/Classical/debussy.rm
It would use the following URL if typed directly in a Ram file, SMIL file, or in RealPlayer's Open Location dialog box:
rtsp://realserver.example.com:554/music/Classical/debussy.rm
The full path to the file is not included. Instead, only the portion relative to the base path is shown.
A generic mount point name appears in the Mount Points list and in the Edit Mount Point box.
When you create a link for the content in the new mount point's base path, use the new mount point. If the content is in a subdirectory of the base path, include the subdirectory in the link.
RealServer can stream files from any location that your operating system can recognize.
A generic mount point name appears in the Mount Points list and in the Edit Mount Point box.
G:, not G:\.)
When you create a link for the content in the new mount point's base path, use the new mount point. If the content is in a subdirectory of the base path, include the subdirectory in the link.
For files that will be authenticated (the user will be asked for a name and password-and possibly for other information- before being given access), the files must be placed in a completely different directory, one which is not a subdirectory of Content. It's necessary to isolate secure material so that the RealServer authentication feature can perform the security checks before granting access.
The directory or directories that contain the secure material must be at the same level as Content, or at a higher level, or on a different system.
| Directory Structure |
(main directory) |
| Values |
Mount Points: /secure/Base Path: C:\Program Files\RealRealServer\Secure (Windows), usr/RealServer/Secure (UNIX) |
For instructions on how to set up authentication and the appropriate directories and mount points, refer to Chapter 15, "Authenticating RealServer Users".
Live clips, created from a production tool such as an encoder, aren't physically stored anywhere, so their links don't usually include a path to an actual directory. The link to a live event may include a virtual path, as typed in the production tool. It may or may not correspond to any actual directories. For live material, the path always begins with the /encoder/ mount point. See "Virtual Paths" for an in-depth discussion.
| Directory Structure |
(main directory) |
| Values | Mount Points: /encoder/ |
For example, a content creator encodes a live event and names it Speeches/Famous/Lincoln.rm. The Speeches directory is an actual directory in this case, but it has no Famous subdirectory. The virtual directory is Famous.
In a Web page, the link to the live clip would use the following format:
http://realserver.example.com:8080/ramgen/encoder/Speeches/Famous/
Lincoln.rm
The link to the live clip would have the following format:
rtsp://realserver.example.com:554/encoder/Speeches/Famous/Lincoln.rm