Chapter 12: Splitting Live Presentations

Splitting is a method of sending live broadcasts to other RealServers, rather than to clients. These other RealServers, configured as receivers, re-broadcast the streams to clients. By replicating streams close to users, clients receive high quality content, bandwidth usage is minimized, and audience size is maximized.

Overview

The RealServer where the live content originates, called the transmitter, makes its live broadcasts available to other RealServers, called receivers. Links on Web pages point to the receiver, rather than to the transmitter. When a user clicks the link, the receiver recognizes the special URL and relays the stream from the transmitter to the client.

As soon as the transmitter begins streaming a live source, it sends the broadcasts to all receivers. When a client requests a broadcast from the receiver, a connection has already been established between the receiver and the transmitter, and the broadcast is delivered to the client immediately.

	Note
	There is another type of splitting in which live events are only sent at the request of receivers. Read about this method in "Pull Splitting".

For example, a concert from Japan can be broadcast over the Internet to RealServers in Australia and North America. Users in those cities connect to the closest RealServer, thereby getting better media quality and using less network bandwidth.

While serving content that originated on another computer, a RealServer-whether a transmitter or a receiver-can still stream its own content. And because it's no longer serving to all the clients, it has more connections available for streaming its own content.

Example Splitting Scenario

Throughout this chapter, we'll use the example of a transmitter located in Japan that is broadcasting to receivers in Australia and North America.

Illustration of Splitting

Web pages listing the event have different links for different locations:

Sample Web Page, Linked to a Push Split Broadcast

Splitting Used with Other Features

This section describes the ways in which splitting works together with other features.

On-Demand Streaming and Splitting

Neither splitting method works with on-demand streaming; splitting only delivers live broadcasts. You can use G2SLTA to convert on-demand clips to live broadcasts. See "G2SLTA and Splitting" later in this section.

Live Unicasting and Splitting

Unicasting can happen automatically from a transmitter or a receiver-when you create a link that points directly to the stream on the receiver, you're using unicasting. In the diagram titled "Illustration of Splitting", the three clients shown in the upper right are receiving unicasts from the transmitter in Japan.

Multicasting and Splitting

There are two ways you can use these features together to make the most efficient use of bandwidth.

• For multicast communications between transmitter and receiver, use multicast for the protocol. Select this option as shown in "Step 1: Setting Up the Transmitter".

• For multicast communications between receiver and clients, see "Splitting and Multicasting" for information and an illustration.

Live Archiving and Splitting

Both transmitters and receivers can archive live streams.

G2SLTA and Splitting

The transmitter can broadcast either a live event from an encoder or an on-demand clip broadcast by G2SLTA. Using G2SLTA can be a good way to test your receiver configurations before you broadcast the real event.

RealProxy and Splitting

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.

Firewalls and Splitting

In their default configuration, the transmitter and the receiver use UDP for fast, efficient distribution, but some firewalls are not configured to permit UDP traffic to traverse network segments. If this is the case with your firewall, modify your firewall to allow UDP traffic between the transmitter and the receiver. You can customize the port numbers that the transmitter and receiver use to communicate, and match them to port numbers on your firewall.

The TCP option from the Protocol list is not recommended unless the network is highly reliable and resend requests are unlikely. The TCP transport should not be used in lieu of properly enabling UDP routes between transmitters and receivers.

	Additional Information
	Firewalls, and the best arrangements of transmitters and receivers, are described in "Communicating with Receivers".

Access Control and Splitting

If you use the access control feature to block access to your transmitter, receivers can still obtain split broadcasts, but they cannot make resend requests, regardless of whether the Honor Resend Requests feature is enabled on the transmitter. Furthermore, receivers using the pull splitting feature will not receive any content at all.

Authentication and Splitting

If you are sending a stream to a RealServer that is acting as a receiver, you must put copies of all the databases that store authentication information on the receiver. This distributes the authentication load.

Calculating Latency and Bandwidth

Stream Acquisition Latency

To determine how long it will take a receiver to acquire a live split stream from a transmitter, consider the following:

• The degree of network latency that exists between the transmitter and receiver

• The configurable interval used to send session announcements.

The receiver does not begin processing the incoming data until it receives the session description from the transmitter. If the session announcement-forwarding interval is set to say, 30 seconds, the receiver will require a maximum of 30 seconds before being able to begin processing live broadcast packets. This time delay does not include any network latency that may exist between the transmitter and the receiver.

As soon as the live distribution stream arrives at the receiver, the receiver constructs a local buffer before streaming data to the connected clients. This introduced receiver latency occurs only if a client connects to the receiver before the session announcement information arrives.

In cases where a pull splitting request is initiated by the receiver, the receiver stores only a 3-second buffer before sending the stream to the client.

Bandwidth Considerations

Calculating the bandwidth used by a particular presentation depends on whether the broadcast is single-rate or SureStream.

Single-rate broadcasts consume bandwidth according to:

• The encoded bit rate of the live stream.

• The percentage of overhead (approximately 10 percent) for session announcement information and TCP/IP headers.

• The percentage of overhead for the configurable error correction rate.

  	Additional Information
  	Instructions on setting the error correction rate can be found in "Optional Transmitter Features".

For example, a single-rate 100-Kbps stream with an error correction rate set to 10 percent will consume approximately 120 Kbps of bandwidth.

Determining the encoding bit rates for SureStream broadcasts is a bit more complex. As a rule, the bandwidth consumed by a SureStream broadcast equals the combined bit rates of all the audiences plus the overhead percentages mentioned a few paragraphs earlier.

Compatibility with Earlier Versions of RealServer

Because of the numerous changes to the splitting feature, both the transmitter and the receiver must be running RealServer 8.

Links use a different format than in previous versions of RealServer.

Earlier versions of RealProxy can still receive pull splitting from RealServer.

If you used splitting in earlier versions of RealServer, you'll want to note two areas of changes.

One is a change in terminology; what used to be called push splitting is now called simply splitting. Pull splitting is called out as a separate case, as shown in "Pull Splitting". A source is now called a transmitter, and a splitter is now called a receiver.

Technical changes consist of the following differences:

• The transmitter and receiver can now communicate via multicast, thus saving bandwidth. For more information on the multicast option, see "Step 1: Setting Up the Transmitter".

• Splitting is now a "connectionless" broadcast method; it only requires a one-way connection from transmitter to receiver. Unless the receiver is configured to request resends, the transmitter doesn't hear from the receiver. For more information on requesting resends, see "Optional Receiver Features".

• Data that was previously transmitted via the "back-channel" of the two-way communication is now sent in the data stream using the Error Correction and Metadata options. For more information on these options, see "Optional Transmitter Features".

• Splitting now uses a password and security method to render data unusable to any RealServer that does not have the correct password. For additional information, see "Step 1: Setting Up the Transmitter"

• There are now only two pages in RealSystem Administrator for setting up this feature.

• All variables used in configuration files are completely different than in earlier versions. For more information, see Appendix C, "Configuration File Contents".

Setting Up Splitting

There are three main steps to setting up splitting; the settings you use on the transmitter must match those used on the receiver.

1. Configure the transmitter. Use the steps in "Step 1: Setting Up the Transmitter"

2. Configure the receiver. Follow the steps in "Step 2: Setting Up the Receiver"

3. Create the links. Use the format described in "Step 3: Linking to Split Content".

Step 1: Setting Up the Transmitter

When you install RealServer, the setup program automatically supplies some information to the splitting feature, based on information it detects on your system. Assuming these settings are correct, you need configure only a few areas, as described in the steps below. To determine whether the supplied values are correct, look at "Optional Transmitter Features" for information.

To configure the transmitter:

1. In RealSystem Administrator, click Splitting. Click Transmitter.

2. In the Source Name box, type a name to use in the links to the split broadcast. Use only letters and numbers; do not use spaces. For the examples in this chapter, we'll use Japan.

3. In the Broadcast Receivers area, click Add New.

   A generic receiver name appears in the Edit Receiver Name box.

4. In the Edit Receiver Name box, type a name or description for the receiver RealServer to which this live content will be broadcast.

5. Click Edit.

6. In the Receiver IP Address or Hostname box, type the address of a receiver that is allowed to receive this content.

7. From the Transport list, select the type of transportation method to use in transmitter-to-receiver communications. You must choose the same transportation setting on both the transmitter and the receiver. The options, listed in order of recommended use, are:

   • UDP/Unicast-The option most commonly selected.

   • UDP/Multicast-The most bandwidth efficient option, this requires a multicast-enabled network between the transmitter and the receiver.

     If you select this option, you must also type an appropriate class D multicast address in the Receiver IP or Hostname box, and type a number in the Multicast Time to Live (TTL) box. For a list of possible TTL values, refer to the "Time to Live (TTL) Values" table.

   • TCP-Use this option if you are splitting over a very reliable network connection. This choice will produce a connection that can be broken, disturbing the broadcast; it also takes more overhead.

     	Note
     	If you select the TCP transport option, you should also use an additional method. Refer to "Broadcasting Over Multiple Network Paths".

8. Either accept the supplied values in the Port Range box, or type your own. This is the set of ports on receivers to which this broadcast will be sent. If the default ports will not work with your system, be sure to specify a range of at least 20 ports. Be sure that the ports are not in use for any other purpose.

9. To secure these transmissions, select Basic from the Security Type list, and type a password in the Password box. The receiver will pass this word to verify the identity of the transmitter as it receives broadcasts. To turn off security, choose None from the Security Type list.

10. Accept the settings for all the other values, or use the information in "Optional Transmitter Features".

11. Click Apply.

12. Repeat the previous steps to add more receivers.

13. The person who will be setting up the receiver will need to know the values you chose in these steps, so that she can make the same selections (or enter the correct values in RealSystem Administrator). Specifically, the receiver administrator needs to know:

    Source Name	Port Range
    Transmitter Address	Security Type and Password
    Transport	Receiver IP or Hostname

Optional Transmitter Features

This section describes the additional settings that you may customize for your transmitter.

• Error Correction Rate-The percent of corrective packets sent. A higher number results in more reliable delivery of data, but consumes more network bandwidth. The default value for use over the Internet is 20. If you're using splitting within a local-area network, you can set this value to a lower value or to zero, since you are less likely to need error correction.

• Metadata Transmit Rate-The frequency (in seconds) at which special packets are sent from the transmitter to the receiver. These special packets describe the stream being split, and are required for the receiver to process the incoming stream.

  A lower number may result in lower startup latency on a new receiver, but consumes more network bandwidth. Use a number from 1 to 60. See "Calculating Latency and Bandwidth" for more information.

• Honor Resend Requests-To improve quality of service, you can choose to have receivers re-request packets that arrived in poor quality or not at all. Select Yes to turn on this feature. However, this option requires a back-channel from the receiver to the transmitter, produces a small increase in bandwidth to support the resend request traffic.

Step 2: Setting Up the Receiver

When you install RealServer, the setup program automatically supplies some information to the splitting feature, based on information it detects on your system. Assuming these settings are correct, you need configure only a few areas, as described in the steps below. To determine whether the supplied values are correct, look at "Optional Receiver Features" for information.

Using the information you received from the administrator of the transmitter (see Step 13), use the steps below to set up the receiver.

To configure the receiver:

1. In RealSystem Administrator, click Splitting. Click Receiver.

2. In the Mount Point box, confirm the name of the mount point. This is the name you will use in the links.

3. In the Broadcast Transmitters area, click Add New.

   A generic transmitter name appears in the Edit Transmitter Name box.

4. In the Edit Transmitter Name box, type a name for the transmitter (or set of transmitters) where the live broadcast originates.

5. In the Transmitter Address Space box, type the host name, IP address, or IP address range of the transmitter. To indicate a range of addresses, type the netmask in the Transmitter Netmask.

6. In the Protocol box, select the same option that's in use on the transmitter.

   If you selected udp/multicast, you must also add the Multicast Address field with the class D multicast address.

   	Note
   	If you are using udp/multicast, the address you type in the Multicast Address field must match the value in the Receiver IP or Hostname box on the transmitter.

7. Accept the settings for all the other values, or use the information in "Optional Receiver Features"in the next section.

8. Click Apply.

Optional Receiver Features

This section describes the additional settings that you may customize for your receiver.

• Resend Requests-To re-request packets that did not arrive at the receiver, select Yes. This option provides greater quality, but may take up more network bandwidth. It can also add latency as the receiver waits for the resent data to arrive.

  	Note
  	If you chose Yes for Resend Request, the administrator of the transmitter will need to set Honor Resend Requests to Yes. If she does not make this change, the transmitter will not re-transmit any lost data even though your receiver is requesting it.

• Port Range-Choose the same option that's in use on the transmitter.

• Security Type and Password-Choose the same options that are in use on the transmitter.

Step 3: Linking to Split Content

This section describes the format of links to split content.

To create the Web page URL:

The link to the split content looks like this:

http://Receiver:HTTPPort/ramgen/broadcast/TransmitterSourceName/encoder/
path/file

Notice that the first part of the link refers to settings on the receiver, and the second part refers to settings on the transmitter.

To create the direct link URL:

The link that you would type directly in the Open Location dialog box of RealPlayer has the following format. 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.

rtsp://Receiver:RTSPPort/broadcast/TransmitterSourceName/encoder/path/file

Example Links

Consider the example shown at the beginning of this chapter, in which a transmitter in Japan sends its broadcasts to receivers in Australia and North America.

	Note
	The direct link to the Japan RealServer uses a regular live broadcast link, rather than the splitting format used in the other links.

This example shows the text you would place in a Web page.

...we hope you enjoy the concert! Choose the link nearest you:

<a href="http://Japan.example.com.jp:8080/ramgen/encoder/concert.rm">
Japan<a>
<a href="http://Australia.example.com.au:8080/ramgen/broadcast/Japan/encoder/concert.rm">Australia</a>
<a href="http://NorthAmerica.example.com:8080/ramgen/broadcast/Japan/encoder/concert.rm">North America</a>

The same links, when typed directly in the Open Location dialog box of RealPlayer, would have the following formats:

rtsp://Australia.example.com.au:554/broadcast/Japan/encoder/concert.rm
rtsp://NorthAmerica.example.com:554/broadcast/Japan/encoder/concert.rm

Optional Configurations

This section describes some ways in which you can use splitting to create more sophisticated delivery of live broadcasts.

• Broadcasting Over Multiple Network Paths

• Using Receivers as Transmitters

• Using Backup Transmitters

• Chaining Receivers

• Pull Splitting

Broadcasting Over Multiple Network Paths

For broadcasting over sophisticated networks, you can combine RealServer splitting features to provide even more robust delivery of data between transmitter and receiver.

By setting up multiple delivery methods for each broadcast, data is sent over different network paths; the receiver re-assembles packets in order, regardless of the transport. For instance, if a packet is late or missing from the data sent via UDP/Unicast, the receiver may get the right packet from those arriving via UDP/Multicast.

To broadcast over multiple network paths:

1. Use the instructions in "Step 1: Setting Up the Transmitter" to set up a rule for this broadcast.

   • In the Edit Transmitter Name box, you might identify that this is one of three delivery methods, with a name such as JapanUDP.

   • From the Protocol list, select UDP/Unicast.

2. Create a second rule that uses multicast.

   • In the Edit Transmitter Name box, you might identify that this is one of three delivery methods, with a name such as "Japan Concert (Multicast)".

   • From the Protocol list, select Multicast.

     Remember, for multicast you must also add the multicast address to the Transmitter Address box.

3. On the receiver, create matching Broadcast Transmitter names. Again, give them similar names to those in the previous steps. Match the protocols to the transmitter settings.

Using Receivers as Transmitters

While serving as a receiver for material originating on a transmitter, a receiver can also serve its own content, using the standard broadcasting and on-demand streaming methods. To set up a receiver to also act as a transmitter, first set up the receiver portion, using the steps in "Step 2: Setting Up the Receiver". Then set it up as a transmitter, using the instructions in "Step 1: Setting Up the Transmitter".

You may also be interested in the daisy-chaining feature, in which each receiver acts as both receiver and transmitter for the same material. Refer to "Chaining Receivers" for information.

Using Backup Transmitters

If you are broadcasting a live event that is being served from several transmitters, you can create a special link so that if one transmitter becomes unavailable, clients will still be able to connect the event using the single link.

The link to this type of broadcast uses an asterisk (*) instead of the source transmitter's name; this has the added advantage of obscuring the source of the broadcast, since the link does not include the name of the source.

Should the transmitter become unavailable, the receiver will automatically choose the next available transmitter for new connections.

Backup Transmitters

For example, a client connects to the Receiver, which receives the broadcast from Transmitter A. If Transmitter A goes down, the client receives an error message. Meanwhile, the Receiver switches to Transmitter B. The user can re-click the link in the Web page or click the Play button in RealPlayer, and will receive live.rm again.

Using Backup Transmitters versus Redundant Sources

The backup transmitters feature provides parallel stream sources to a given receiver. The redundant sources feature delivers parallel sources to a transmitter. Use can use both methods at the same time for the greatest reliability. For information about redundant sources, see "Working with Redundant Sources".

To set up backup transmitters:

1. Add the receiver information to each transmitter's Broadcast Receivers list.

2. Configure the receiver to get broadcasts from each transmitter, by adding all transmitters to the receiver's Broadcast Transmitters list.

3. Create the special URL for this broadcast: instead of typing the TransmitterHostName in the URL, type an asterisk (*).

Linking to Backup Transmitters

To create the link that will allow the stream to come from multiple RealServers, use the same format as for splitting (refer to "Step 3: Linking to Split Content"), but substitute an asterisk (*) for the TransmitterHostName value.

The following uses the example in the illustration above:

<a href="http://receiver.example.com:8080/ramgen/broadcast/*/live.rm">

Within RealPlayer, this link appears as the following:

rtsp://receiver.example.com:554/broadcast/*/live.rm

	Tip
	You can use the asterisk in an URL even when backup transmitters are not in use. This link format allows you to change the name of the RealServer shown in TransmitterHostName without having to also update all the links that reference it.

Chaining Receivers

A receiver can act as a transmitter for another receiver. Clients connecting to the second receiver receive the broadcasts originating at the transmitter.

In the illustration below, a stream that originates at the transmitter is passed to Receiver A, then to Receiver B, and finally to Receiver C. A client can receive the live stream from any receiver.

Advantages to this method include the option to use different settings at each connection for error correction, metadata, and passwords.

	Tip
	If your network is multicast-enabled, consider using UDP/Multicast to transmit the stream instead of using chaining. Multicast has the same reliability provides greater reliability and scalability than chaining.

Daisy-Chain Splitting

In addition to being configured as a receiver, each receiver in the chain (except the last one) is also configured as a transmitter.

The configuration on each receiver points to the previous receiver in the chain. Each RealServer only knows about the RealServer on either side in the chain; it doesn't know about the entire chain.

Setting Up Chain Splitting

To set up this feature, you configure each RealServer in the chain, and then create the appropriate links.

To set up chained splitting:

1. Configure the first RealServer:

   1. Set up this RealServer as a transmitter.

   2. Add Receiver A to the Broadcast Receivers list.

   3. From the Relay Live Broadcasts list, select No.

2. Configure Receiver A:

   1. Configure this RealServer as a receiver, and add the first Transmitter to the Broadcast Transmitters list.

   2. From the Relay Live Broadcasts list, select Yes.

   3. Configure this RealServer as a transmitter, and add Receiver B to the Broadcast Receivers list.

   4. In the Source Path box on the Transmitter page, change the default value from /encoder/ to /broadcast/ (to match the transmitter).

3. Configure Receiver B:

   1. Configure this RealServer as a receiver, and add Receiver A to the Broadcast Transmitters list.

   2. From the Relay Live Broadcasts list, select Yes.

   3. Configure this RealServer as a transmitter, and add Receiver C to the Broadcast Receivers list.

   4. In the Source Path box on the Transmitter page, change the default value from /encoder/ to /broadcast/ (to match the transmitter).

4. Configure Receiver C:

   1. Configure this RealServer as a receiver, and add Receiver B to the Broadcast Transmitters list.

To create the links for chained push splitting:

The link for each receiver reference the receiver and the previous receiver in the chain, as shown in the following table. Notice that each link starts with the name of the RealServer that appears to be hosting the content, and also references the transmitter where the material originates.

A link typed within a Player, Ram file, or SMIL file would appear the same, but would use rtsp for the protocol and would omit ramgen.

Pull Splitting

In this type of splitting, the transmitter doesn't transmit any streams to the receiver until the first client makes a request.

In contrast to the constant communication in regular splitting, the connection between the transmitter and receiver in pull splitting stays quiet until a client makes a request. When the receiver gets a request for the live broadcast, it requests a pull splitting session. The transmitter RealServer sends the broadcast to the receiver, which in turn sends it to the client.

Using Push Splitting and Pull Splitting Together

You can combine these methods to make the best use of your bandwidth. For example, divide your use of splitting methods according to time zones. Use push splitting to send an event to receivers in the same or nearby time zones, and make pull splitting links available to users in time zones on the other side of the world, where potential viewers are likely to be asleep.

Setting Up the Transmitter for Pull Splitting

When you install RealServer, the setup program automatically supplies some information to the splitting feature, based on information it detects on your system. Assuming these settings are correct, you need configure only a few areas, as described in the steps below.

To configure the transmitter for pull splitting:

1. In RealSystem Administrator, click Splitting. Click Transmitter.

2. In the Pull Splitting Sources area, click Add New.

   A generic receiver name appears in the Edit Source Name box.

3. In the Edit Source Name box, type a name for the stream.

4. Click Edit.

5. In the Source Path box, type a name of a path through which live streams are being sent, typically /encoder or /redundant.

6. Type a password in the Password box. The receiver will use this word to verify the identity of the transmitter as it receives broadcasts. To turn off this feature, choose None from the Security list.

7. In the Listen Port box, type a port number on which this transmitter should listen for pull splitting requests. If you leave this field blank, RealServer uses the value 2030. Type here to override.

8. Click Apply.

9. The administrator of the receiver will need to know the values you chose for the following settings:

   Transport	Security Type and Password
   Listen Port

Setting Up the Receiver for Pull Splitting

When you install RealServer, the setup program automatically supplies some information to the splitting feature, based on information it detects on your system.

To set up the receiver for pull splitting:

1. In RealSystem Administrator, click Splitting. Click Receiver.

2. In the Mount Point box, confirm the name of the mount point. This is the name you will use in the links.

3. In the Broadcast Transmitters area, click Add New.

   A generic transmitter name appears in the Edit Transmitter Name box.

4. In the Edit Transmitter Name box, type a name for the transmitter.

5. In the Transmitter Address Space box, type the host name, IP address, or IP address range of the transmitter. To indicate a range of addresses, type the netmask in the Transmitter Netmask.

6. In the Port Ranges boxes, type the range of ports that will receive the transmission. Be sure that the ports are not in use for any other purpose. If the default ports will not work with your system, be sure to specify a range of at least 20 ports.

7. From the Enable Pull Splitting Requests list, select Yes.

8. In the Pull Splitting Source Path box, type a value to identify this pull splitting stream in the URL. In the examples in this chapter, we'll use /pull/.

9. Accept the settings for all the other values, or use the information in "Optional Pull Splitting Receiver Features" in the next section.

10. Click Apply.

Optional Pull Splitting Receiver Features

This section describes the additional settings that you may customize for your receiver.

• Error Correction Rate-The amount of corrective packets sent. The number shown here is the percent of error-correcting packets sent. A higher number results in better quality, but consumes more network bandwidth.

• Metadata Transmit Rate-The rate at which packets describing the session are sent. A higher number results in better quality, higher startup latency on the receiver, but consumes less network bandwidth. Use a number from 1 to 60. The default value is 30, which sends the metadata once every 30 seconds, adding 30 seconds of latency to the transmission.

• Use TCP for Pull Splitting Backchannel-Use this option if you are splitting over a very reliable network connection. This choice will produce a connection that can be broken, disturbing the broadcast; it also takes more overhead.

Linking to Pull Split Content

This section describes the format of the link to pull split broadcasts.

To link to pull split content from a Web page:

The link to the split content looks like this:

http://Receiver:HTTPPort/ramgen/broadcast/SourcePath/Transmitter:ListenPort
/encoder/path/file

Notice that the first part of the link refers to settings on the receiver, and the second part refers to settings on the transmitter.

To create the direct link URL for pull splitting:

The link to the split content, as created by the transmitter or as typed directly in the Open Location dialog box of RealPlayer, has the following format. 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.

rtsp://Receiver:RTSPPort/broadcast/SourcePath/Transmitter:PullListenPort/encoder
/file

Example Pull Splitting Link

Consider the example shown at the beginning of this chapter, in which a transmitter in Japan sends its broadcasts to receivers in Australia and North America.

Note that the direct link to the Japan RealServer uses a regular live broadcast link (rather than the special pull splitting format).

The links used in the Web page have the following format:

...we hope you enjoy the concert! Choose the link nearest you:

<a href="http://Japan.example.com.jp:8080/ramgen/encoder/concert.rm">
Japan</a>

<a href="http://Australia.example.com.au:8080/ramgen/broadcast/pull
/Japan.example.com.jp:2030/encoder/concert.rm">Australia</a>

<a href="http://NorthAmerica.example.com:8080/ramgen/broadcast/pull
/Japan.example.com.jp:2030/encoder/concert.rm">North America</a>

Links typed in RealPlayer, or used in SMIL or Ram files, have the following format:

rtsp://Japan.example.com.jp:554/encoder/concert.rm

rtsp://Australia.example.com.au:554/broadcast/pull/Japan.example.com.jp:2030
/encoderconcert.rm

rtsp://NorthAmerica.example.com:554/broadcast/pull/Japan.example.com.jp:2030
/encoder/concert.rm

Copyright © 2000 RealNetworks
For information on RealNetworks' technical support, click here.
Comments on this document? Click here.
This file last updated on 11/28/00 at 17:34:57.