Broadcast Infrastructure Planning

When Contoso Movies Online first set up their contract with the CDN service that would also host their Web and Windows Media-based content, a process was established for how to set up broadcasts for the live channel. Each CDN or ISP will have a different process. However, there is some basic information that is common to all broadcast configurations that must be communicated. To understand what information is needed, let’s look at what happens to the live stream during a broadcast.

First, Windows Media Encoder compresses and encodes the audio and video into a stream that consists of a series of packets containing data. Then the stream is sent over a network as a live or broadcast stream. The stream can also be sent to a storage device where it is written to a file, or both written to a file and broadcast. Once on the network, the live stream from the encoder is most often received by a Windows Media server that then delivers the stream to multiple players.

You connect a server to the live stream from an encoder by using the URL of the encoder, which consists of the HTTP protocol, the IP address of the computer, and the port number assigned to the encoder session, such as http://EncodingComputer:8181. Multiple instances of the encoder can stream data from a single computer. For example, you could use three video capture cards to feed into three encoders. To differentiate the encoder instances, you assign different port numbers to each one. For example, the encoders could be assigned port numbers 8181, 8182, and 8183. You could also split the video stream from one capture card to two or more encoder instances, and configure each to encode at a different bit rate. For example, the Osprey video capture card can use SimulStream software to split the video. You could also encode an MBR stream with one encoder instance.

You can connect the Player directly to the encoder and receive the live data packets. In practice, however, you do not typically connect the Player directly to an encoder except for monitoring. Maintaining connections requires processing time, and you should reserve as much processor resources as possible for encoding. Besides, Windows Media Encoder is limited to five client connections. To distribute a live stream, you use a Windows Media server, which can handle hundreds (or even thousands) of connections.

Distributing a Live Stream

To distribute a live stream from a Windows Media server, you create a broadcast publishing point that sources from the encoder, using the encoder’s URL. Then users can connect to the server by entering the URL of the publishing point, such as rtsp://WMServer/LiveStream. Note that you connect to an encoder using the HTTP protocol, and to a server using the MMS or RTSP protocols. You can stream from a server using HTTP if the server is configured to do so.

To deliver a live stream to a hosting service or CDN, a connection is established, typically over the Internet. To do that, the encoding computer can be assigned a static IP address and configured with a high-speed connection to the Internet. The hosting service can then connect using the IP address. If the computer cannot be assigned a static address (for example, if the computer might be connecting through different ISPs), you can use a dynamic DNS service. The DNS service enables you to change the IP address associated with a fixed domain name. The Windows Media server publishing point can then refer to the fixed domain name, such as http://ContosoDynamicName01:8181. When the IP address of the encoding computer changes, you can use a utility provided by the DNS service to update the address associated with the fixed domain name. This is the system Contoso will use for the Ivanhoe event, because the DSL provider for the event is different from the provider used at the Contoso office.

To set up the connection for the event, therefore, the producer will supply the hosting service with the fixed domain name of the encoding computer, ContosoDynamicName. If they were to use a backup encoder, they would also need to supply a domain name for it. The Contoso producer would also inform the hosting service if she will be encoding multiple streams on an encoding computer.

To create a publishing point, a server administrator needs two basic pieces of information: a name for the publishing point (such as LiveEvent01) and a source (http://ContosoDynamicName01:8181). According to Contoso’s arrangement with the hosting service, the producer will supply the publishing point name and encoder domain name, and the hosting service will then configure the publishing point and send back the port number that a technician will add to the encoder configuration. If multiple publishing points are required for additional streams, the hosting service will provide port numbers for each one.

Setting up Encoder Rollover

Typically, a broadcast publishing point is configured to source directly from an encoder. However, it can instead point to a server-side playlist that contains a media element that sources from the encoder. The advantage of using a playlist is that a failover or rollover mechanism can be built into the publishing point. With rollover, you can configure two or more redundant encoding computers to automatically switch to a working encoder if the encoder that is live fails. The following playlist shows an example of a simple rollover.

<?wsx version="1.0" encoding="utf-8"?> <smil repeatCount="indefinite">     <media src="/books/2/544/1/html/2/http://Encoder01:8181"/>     <media src="/books/2/544/1/html/2/http://Encoder02:8182"/>     <media src="/books/2/544/1/html/2/C:\WMPub\WMRoot\Standby.jpg" dur="10s"/> </smil>

As mentioned in the previous chapter, elements contained in a smil element play sequentially from top to bottom. In this example, the playlist starts with Encoder01. As long as a stream is received from Encoder01, the playlist does not change to the next media element. If, on the other hand, a problem occurs and the stream stops, the server switches to the next media element, Encoder02. If neither encoder sends a stream, the playlist switches to an image that displays standby text, such as the image in figure 12.3.

Figure 12.3: Image displayed if previous elements in the playlist are not available.

The image plays for 10 seconds, and then the playlist loops to the top of the list. If one of the encoders starts streaming again, the server will resume streaming from that point in the playlist. If not, the playlist will repeat every 10 seconds until an encoder is started.