Concerts, presentations, speeches, can all be encoded and broadcast to clients almost instantaneously. Live presentations can be archived for later reference or later broadcast. For example, you can archive an event that happens in one time zone and then play it later for viewers in a later time zone with the G2SLTA tool.
In live broadcasting, a content creator sets up a device, such as RealProducer Plus or RealProducer Pro, to capture a real-time event, that will create the digital media for RealServer to stream. A Web page includes a link to the live event, and everyone who clicks that link sees or hears the same event at the same time.
Visitors who click a link to a live broadcast join the event as it happens, and everyone sees the same content at the same time.
Streaming live content is much the same as streaming static content, with the following differences:
 |
Tip |
|---|
| If you don't want to broadcast live events yourself, RealBroadcast Network™ (RBN) provides full services for encoding and broadcasting events to a few or a few thousand viewers. See http://www.realnetworks.com/rbn for details. |
The following are factors in deciding whether to use this feature:
Live unicasting is typically used for audiences of light-to-medium volume live events. Splitting and multicasting may be more appropriate for events with a larger number of viewers.
Live unicasts are often used for such events as:
Live broadcasting works with all other RealServer features. There are a few special considerations for each feature, however.
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.
The live archiving feature can create on-demand files of any live broadcast. These files can be used for historical purposes or for later rebroadcast.
The simulated live tool (G2SLTA) is a command-line tool that creates a live presentation from an on-demand file.
Unicasting and splitting (both push and pull splitting) are often used together, without any special configuration. This happens when your RealServer is configured as a source RealServer, and there are links that allow clients to connect directly to your RealServer.
In the figure titled "Illustration of Splitting", the RealServer in Japan is acting as a source to the receivers in Australia and North America, and is also unicasting to the three RealPlayers at the right.
Unicasting and back-channel multicasting are also often used together; links to back-channel multicasts do not require that the client be multicast-enabled, so if the client is not able to connect in multicast mode, it will be able to receive the stream via unicast instead.
Scalable multicasting includes a feature that enables a client to receive a broadcast via unicast if the special multicast presentation is not available for some reason.
RealProxy cannot cache live broadcasts, because there is no actual file to cache. But RealProxy includes an ability to "share" live streams among clients, and thus reduce the bandwidth required from a transmitter. They communicate through pull splitting; RealServer is pre-configured to act as a transmitter, and RealProxy is automatically set up to act as a receiver.
Standard protocols are used in delivering live broadcasts. These are covered in Chapter 9, "Firewalls and RealServer".
Before any client is allowed to receive any broadcast, RealServer checks the client's IP address to see whether the client is allowed to receive a broadcast. If the address is acceptable, RealServer looks at the location of the file to see if it is in a secure location. If so, RealServer challenges the user (or Player) for identification. Once the client passes the tests, RealServer connects the client to the live broadcast.
RealServer's ISP hosting feature can host on-demand content only; it does not host any live content.
All streams and connections to broadcasts currently in use can be viewed by using the Java Monitor in RealSystem Administrator.
All client connections to live broadcasts are recorded in the access log file. Any errors encountered by clients are recorded in the error log.
Setting up RealServer to broadcast live events consists of three steps:
RealServer is ready to stream live events when you first install it. This section describes the settings that RealServer uses in live unicasting.
If the encoder is a RealSystem version 6 encoder, such as RealProducer Plus 6, RealServer uses the settings on the Encoder page (located by clicking Broadcasting in the left-hand frame of RealSystem Administrator):
/encoder/. All links to live material will include this mount point.
4040. If you change this value, be sure to give the new port number to content creators so they can direct their encoded feeds to the right RealServer port.
EncoderRealm. Select None if you do not want to require user names and passwords from encoders.
 |
Additional Information |
|---|
| Realms and authentication are described in Chapter 15, "Authenticating RealServer Users". |
View these settings by clicking Broadcasting>Pre-G2 Encoder.
/live/ for links to material created by encoding software that was released prior to RealSystem G2, such as RealEncoder. All links to live material will include this mount point.
5050. If you change this value, be sure to give the new port number to content creators so that their encoders can still connect to RealServer.
Links to live events are similar to links for on-demand clips, with the addition of the encoder mount point.
Use the format of linking to an individual file, and use the live file mount point, usually /encoder/ (if the material is arriving from a version 6 or later encoder).
The link to a live file has the following format:
http://address:HTTPPort/ramgen/encoder/path/file
| Component | Meaning |
|---|---|
http |
The protocol used to initiate streaming. Always use http in Web pages. |
realserver.example.com |
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. |
encoder |
Live events encoded with version 6 and later software use /encoder/ as their mount point. If the live event is created using a pre-G2 encoder, use the /live/ mount point instead. |
path |
Optional; any actual directory, relative to the base path of the main mount point. If you typed any subdirectory in the source software (other than the /encoder/ mount point), include it here. |
file |
The file name itself, including the extension. |
For example, a link to a live event being encoded as concert.rm would look like this:
http://realserver.example.com:8080/ramgen/encoder/concert.rm
Links typed directly in RealPlayer or used in a Ram or SMIL file use the following format:
rtsp://address:RTSPPort/encoder/path/file
The format is nearly the same as the link used in the Web page; the protocol is different, the port number (if any) matches the protocol, and Ramgen is omitted.
With live unicasting, the following optional features are available:
If a live unicast is interrupted, you can still send information to clients, displaying a message that says "Currently experiencing technical difficulties" when a live broadcast is interrupted. This is possible by making a file that contains the message you want to display, and placing it in a subdirectory with the same name as the live mount point.
encoder), and place it under the main base path (usually Content).
If you are working with pre-G2 encoders, use live instead (or use both encoder and live).
Your directory structure will now look something like this:
RealServer
Content
encoder
encoder 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 and will stream the error file.
You can save (or archive) a live broadcast for historical purposes or for later playback. For information on playing saved files as if they were live, see "Creating a Live Source with G2SLTA".
RealNetworks' encoding products include an option to save a copy of a file while encoding. This setting is different from, and independent of the archiving feature in RealServer. Typically, there is more storage space on the RealServer system than there is on the content creator's computer.
For each live broadcast that you want to save, you can choose to create one large file that contains everything in the original broadcast or several small files. These small files can be based on length of recording or file size. For example, RealServer can archive a continuous live feed into files each containing thirty minutes of the broadcast, or can start a new archive file each time a certain size is met.
Large files are appropriate when you want to save an entire event in one file. If RealServer archives a live broadcast with the same destination path and file name as an existing file, RealServer automatically renames the file by appending a unique number to the end. For example, if RealServer encountered a file named concert.rm in the archive directory, it would rename it as concert.rm.86400. The new file gets the concert.rm name. The number that RealServer chooses is related to a timestamp; larger numbers indicate newer files. In this way, one directory can be used to store the latest version of a broadcast and the previous versions as well.
Reusing the same output file name can simplify Web page maintenance, because the links for a recurring event remain the same.
Small files based on elapsed time are saved with the following method: as soon as the initial value indicated in the configuration file is reached, the archived file will be named filename0.rm. When the second archived file maximum size is reached, it is named filename1.rm where filename is the name of the live file stream.
File names for files based on size are named with the same method as for files archived according to elapsed time.
If RealServer tries to archive a stream for which an archived file already exists, it uses the same method as described in "Large Files".
Because several bit rates are present in SureStream files, RealServer creates several temporary files as it archives the streams. When the desired file time or size is reached, RealServer merges the temporary files into the final SureStream format.
The time required to merge the files is usually as long as or longer than the presentation itself. Thus a one-hour clip takes a little more than an hour to merge.
 |
Warning |
|---|
| Do not stop RealServer before it merges the temporary files, or it will not create the archive file. |
Live archiving works with all other RealServer live broadcasting features. There are a few special considerations for each feature, however.
Although you can use the Simulated Live tool (G2SLTA) to broadcast on-demand files as if they were live, and then archive them, it does not make much sense to archive an existing file.
Both transmitters and receivers can archive broadcasts.
When you set up live archiving, you create settings that apply to all live broadcasts performed by your RealServer, or indicate that only broadcasts associated with certain source paths will be archived. In both cases, you can specify any location for the resulting archived files.
The instructions given here will archive a live broadcast into a single large file. If the resulting file will be too large, or if you want to divide the archived file into smaller files automatically, see "Creating Small Files Limited by Size or Time".
 |
Note |
|---|
| These instructions describe only the steps required to set up this feature. For more options, see "Optional Live Archiving Features". |
*) in the Source Paths list. This archives all live streams broadcast by this RealServer.
|
|
Additional Information |
|---|
| Instead of archiving all live streams, you can be selective. See "Archiving Only Certain Streams". |
Enabled.
Archive subdirectory of the RealServer Content directory.
To turn off live file archiving, select the virtual directory for which you want to turn off live archiving. Select Disabled from the Archiving list.
An archived file is a live broadcast that has been converted to an on-demand file. Links to archived files use the on-demand style; the default location is the Archive subdirectory of the Content directory, so include that in the URL.
The actual file name which the link will reference depends on the archiving method you used:
Links in a Web page use this format:
http://address:HTTPPort/ramgen/Archive/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. |
Archive |
The virtual directory of the archived files. |
file |
The file name itself, including the extension. |
For example, a link to a single large file would look like:
http://realserver.example.com:8080/ramgen/Archive/concert.rm
If the same event were archived by file time, a link to an individual small file would look like:
http://realserver.example.com:8080/ramgen/Archive/concert42.rm
Live archiving has these additional features:
You can choose to archive a limited number of broadcasts, or to archive all but a few broadcasts.
*) in the Source Paths list.
Disabled.
This step disables archiving for all broadcasts. The next steps will turn on archiving for specific streams.
Enabled.
*) in the Source Paths list.
Enabled.
This step turns on archiving for all broadcasts. The next steps will disable archiving for specific streams.
Disabled.
Limiting by file size is shown in "Choosing the Size of the Archived Files".
If you give values in both the Limit Archive Files By Size or Limit Archive Files By Time boxes, RealServer will use the first, or lower, limit.
To save entire broadcasts without limiting the file size (create a large file), omit values for both areas.
If the machine on which RealServer is installed does not have enough disk space for archiving, you can set up a mount point for another machine.
These instructions apply to archiving all streams to one location, but you can combine the instructions in "Archiving Only Certain Streams" with the instructions in this section to direct individual streams to separate archive storage locations.
A generic mount point name appears in the Edit Mount Point box.
*).
Enabled.
/filestorage/.
RealServer will now archive live broadcasts in the new location.
If RealServer 5-style bandwidth is in use, select On from the Bandwidth Negotiation list. When this option is set to On, and RealServer receives streams from encoders with the .rm extension, RealServer creates a directory named after the filename, including the extension. All streamed files are created in this subdirectory. For more information on version 5-style bandwidth negotiation, see "Files Created with Previous Encoder Versions".