CHAPTER 9

Webcast Encoding

The encoding stage is where webcasting production separates from traditional broadcasting. Encoding is where the broadcast quality we have worked so hard to produce thus far is compromised. Unfortunately this comes with the territory: there simply is not enough bandwidth available on the Internet to stream broadcast quality video. Yet.

This may not always be the case. There are a number of initiatives in the works to deliver fiber connectivity to the home, which would offer upwards of 30 Megabytes per second downstream capacity. Also, webcasts destined for use on internal networks can take advantage of multicast, and deliver much higher bit rate streams. Regardless of the bit rate you are streaming, you have to use an encoder to convert the raw digital media into a format that can be streamed.

This chapter covers the entire encoding process including a discussion of advanced encoding techniques and explains what equipment and hardware is essential for a successful webcast. Included in the chapter are step-by-step examples of how to encode using Windows Media Encoder and RealProducer software. In order, the topics covered are:

•    Encoding Basics

•    Encoding Equipment

•    Webcast Encoding Techniques

•    Encoding Settings Examples

Encoding Basics

At their most basic, encoders take incoming audio and/or video and encode a streaming version according to the parameters you provide. Encoders use sophisticated mathematics and perceptual models to retain as much fidelity as possible. The fidelity of an encoded stream is directly related to the bit rate: the higher the bit rate, the higher the fidelity.

Modern audio and video codecs have improved dramatically in the last decade, and continue to do so. Combined with the increasing penetration of broadband, this has made webcasting a much more enjoyable and high quality experience. But not everyone has a broadband connection, and broadband streams use a lot of bandwidth. Therefore, the first thing you have to do when considering encoding settings is to consider your audience.

Consider Your Audience

When planning for a webcast, take a moment to consider who your target audience is, and what limitations that imposes on your webcast. If you’re webcasting on the public Internet, there are a number of things you need to consider. Although many people have broadband connections that are rated at a megabit per second or greater, this data rate isn’t sustainable across the public Internet for long periods of time.

The public Internet, as of 2005 and into 2006, is capable of sustaining streams in the 300-500 kbps range. Certainly there are networks capable of sustaining much higher data rates, but all it takes is one outdated router to cause a bottleneck for your entire webcast. Testing in advance can help here.

Another thing to consider is the aggregate bit rate you’ll be delivering simultaneously. A single 300 kbps stream isn’t much, but webcast to one thousand people simultaneously and you’re looking at 300 Mbps, which is considerable. Delivering that amount of data requires a serious streaming media infrastructure.

ALERT

image

You should also consider the aggregate total bandwidth delivered, as many streaming providers charge by this measure. Using the preceding example, one thousand viewers watching a 300 kbps stream for an hour consume approximately 128 Gigabytes of bandwidth. For most streaming media hosts this isn’t a considerable amount of bandwidth. However, if you’re being charged per gigabyte, you can tailor your stream bit rate to accommodate your budget.

Consider Your Programming

The other main concern is the type of programming you’re encoding. In the preceding chapter we learned that motion is difficult for video codecs. However, no matter how careful you are when producing the program, there is bound to be motion, and in some types of programming much more than others.

Sporting events, for example, are notoriously hard to encode. The nature of most sports is motion, and lots of it. There may be steps you can take in the production stage to minimize the motion, such as framing your shots a bit wider, and cutting to different camera angles Less often. However, you still need to consider the programming as a whole, and set your encoding parameters accordingly.

Encoding parameters are discussed a little later on in this chapter, in the “Webcast Encoding Techniques” section. Before we delve into the actual settings, let’s take a step back and talk about encoding equipment.

Encoding Equipment

Encoding equipment is simple: a computer with a sound card, video capture card, and encoding software. A modern processor with decent speed is all you need for most applications, though if you’re trying to do something fancy such as encoding multiple streams on a single computer, you’ll need a high-powered CPU.

Computer Hardware

For most applications you can work with the minimum amount of RAM the operating system requires, though additional RAM never hurts, particularly if you may be running other applications on the same computer at the same time. 512 Megabytes of RAM is probably the minimum you need. Hard drive space is the same—if you’re not archiving locally, then you don’t particularly need a lot of storage. However, if you’re planning on archiving your files locally, be sure to have enough drive space to store your archives (see Table 9-1).

Table 9-1
File sizes for different bit rates.

image

Bear in mind that you may be webcasting both dial-up and broadband versions of your webcast, and encoding multiple formats. In that case, you could be generating over a gigabyte an hour for your content. However, with 60 GB hard drives available as standard on most computers, storage is rarely a problem.

You need a sound card. Many computers come with sound cards, some of them built-in to the motherboard. Most computers sold today are aimed at consumer grade applications, with sound cards expected to perform mundane tasks such as playing back operating system sound effects. The quality of the components used is not particularly high, and consequently the built-in sound cards tend to be noisy. If you’re producing a high quality audio feed, the noise may not be apparent. Using a higher quality sound card or an external audio device is always a safer bet.

To capture your video signal, you’ll need a video capture card. Video capture cards come in a range of prices with a multitude of features. Most consumer capture cards today are targeted towards folks who want to watch TV on their computers and may want to record television programs. These cards tend to be lower quality and focused more on the TV tuner than the video quality.

Inside the Industry

image

What you’re looking for is a video capture card that accepts a composite or S-Video input. Some: capture cards include a FireWire input which can be used as both the audio and video source. However, as mentioned earlier in this book, encoding a DV signal requires the encoding computer to first decode the incoming DV signal before it can re-encode it to a streaming format. This is possible, but requires a fair amount of computing horsepower. Check with your software manufacturer for recommended minimum requirements.

Because of the way Windows and Mac operating systems deal with audio and video, you’ll most likely need an encoding computer for each stream you plan on offering. In addition, you’ll want to have at least one if not two backup encoding machines ready to go for redundancy purposes. The backup machines can also be used to monitor the streams, the servers, and to keep in touch with other people working on the webcast via instant messaging.

Computer Software

The software you need depends on what format you’re using for your webcast. At a minimum, you’ll need the encoding software offered by the manufacturer, such as the Windows Media Encoder or the RealProducer. Most modern computers are capable of encoding a webcast with plenty of CPU power to spare, though in general it’s best not to run other software on your encoding machines.

You should have at least one computer that is dedicated to administrative tasks, such as monitoring the streams locally, monitoring server activity, and possibly running instant messaging software. Obviously you’ll need media player and instant messaging software installed. You may also want other software tools, such as stream editors, or audio and video editing software. If you’re webcasting a number of events over the course of a few days, you can utilize down time to do some editing for archiving purposes.

Specialized Encoding Equipment

There are a number of encoding solutions available for webcasting. Some are designed to work around the operating system limitations that restrict an encoding machine to a single stream of output. Others are designed to combine streaming media with other assets such as PowerPoint slide presentations to create a unified presentation. Depending on your webcast and budget, one of these might be a worthwhile investment.

Multiple Stream/Format Solutions — There are a number of custom webcasting systems available that enable a single machine to encode multiple streams of output. High powered machines have more than enough horsepower to encode multiple streams, but are limited by the way the operating system handles resources such as sound cards and video cards. These systems work around these limitations to offer multiple streams from a single encoder.

ALERT

image

Multiple stream solutions are a double-edged sword. On one hand, it makes sense to utilize all the computational power that an encoder has to offer. On the other, you now have a single point of failure for a number of streams. If, for example, the network interface on the encoder fails, you don’t just lose a single stream—you lose all the streams that are being encoded.

That being said, multiple stream solutions are a great solution, provided you build enough redundancy into your encoding system. They’re also great because far less encoding hardware is required on site, which means a smaller footprint for the encoding station.

Inside the Industry

image

The following manufacturers offer multiple stream solutions as of Fall 2005:

•    Communitek Video (www.communitekvideo.com): offers the minicaster and Webcaster encoding stations

•    Digital Rapids (www.digitat-rapids.com): Offers the DRC-Stream™ line of hardware

•    Sunnyside Software (www.sunnysidesoft.com): Offers Raycaster Software which enables multiple streams of Windows Media.

•    Viewcast (www.viewcast.com): Offers SimulStream software that works with their Qsprey series of capture cards, and the Niagara Streaming Systems (see Figure 9-1).

•    Winnov (www.xstreamengine.com): Offers the XstreamEngine line of encoders

image

Figure 9-1
The Viewcast Niagara Power Stream Pro.

Presentation Solutions — One of the most common webcast formats is talking head video combined with some sort of presentation, such as PowerPoint slides. To produce a webcast of this type requires some fairly advanced authoring and production skills. A number of manufacturers have devised solutions that bundle this functionality into a single interface:

•    Accordent (www.accordent.com): Offers PresenterPlus, PresenterPro and Pre- senterOne software, as well as the Accordent Capture Station hardware solution.

•    Sonic Foundry (www.sonicfoundry.com): Offers mediasite™ hardware solutions.

•    Webcast in a box (www.webcastinabox.com): Offers an all-in-one webcasting appliance (see Figure 9-2).

image

Figure 9-2
The Webcast in a box encoding solution.

Production/Encoding Hybrids — Some encoding solutions combine audio and video production capabilities with encoding. These typically include multiple video and audio inputs, switching capabilities, as well as audio and video processing.

•    NewTek (www.newtek.com): Offers the TriCaster (see Figure 9-3), which bundles video capture, editing, live production, and Windows Media encoding.

•    Sony (www.sony.com): Offers the Anycast production and encoding system.

image

Figure 9-3
NewTek’s TriCaster.

Setting Up for Redundancy

The number of encoding machines you require depends on a number of things. First of all, you have to figure out how many different streams you’re planning on delivering, and how many streams you’re going to encode on each machine (if you’re using multiple encoding technologies). On top of that, you need at least one backup machine, preferably two.

For example, if you’re encoding Windows Media and Real streams, at broadband and dial- up rates, you’ll be encoding four separate streams, requiring four encoding machines. Add in two spares for redundancy, and you’re looking at six encoders. Don’t forget you’ll need enough audio, video, and network cabling to get everything set up (see Figure 9-4).

image

Figure 9-4
A typical redundant encoding setup.

 

Author’s Tip image

Most encoding software offers a way to save all the encoding settings to a file. Save settings files for all your streams, on the desktop. That way if an encoder fails, a replacement stream is only a click away.

When you set up your encoding equipment, label each machine according to the format and bit rate of stream it will be encoding. If a stream goes down, you’ll know immediately which encoding machine is down, and which cables to check. Another good tip is to copy the encoding settings for all streams to the backup machines.

Webcast Encoding Techniques

Encoding a webcast is no different than encoding any other streaming media file. All the same considerations apply. You have to consider the audience you’re trying to reach, and how much bandwidth they have. Your encoding settings follow from this, as with all other streaming media.

Bit Rate Considerations

The majority of all webcasts are now done at broadband bit rates. Some webcasts include a dial-up stream to cater to the widest possible audience, but this will not be the case for much longer. However, even though the audience will be predominantly on broadband connections, it’s worth considering what your broadband bit rate should be.

The public Internet is capable of sustaining approximately 300 kbps. This is a fairly safe bit rate to use. However, if you’re expecting a huge audience, you may want to scale this back to 200 kbps or even 150 kbps. Even though higher bit rate streams provide higher fidelity, it’s of no use if they cannot be delivered. The simple fact is that lower bit rate streams stand a better chance of successful delivery.

You should also consider if there are other aspects of the webcast, for instance slides that will be delivered along with the video. If so, be sure to leave some bandwidth for the other media assets. You also should leave some bandwidth for the audience to use email, chat, instant messaging, and all the other things that people use when they’re online.

 

Author’s Tip image

Remember, you can always contact the authors of this book for help on encoding techniques or anything else in the book. Email us at [email protected].

The other consideration may be budget. If you’re paying for your bandwidth, 150 kbps streams cost half as much as 300 kbps streams to deliver. For talking head content, 150 kbps should be sufficient to deliver adequate quality. Experiment with different settings during your testing to determine what your minimum bit rate should be.

Audio Considerations

There are a number of things to consider about your audio, the first being the bit rate. Obviously if it’s an audio-only webcast the entire bit rate will be audio. But if you’re webcasting video, you have to decide how much of the available bit rate to dedicate to the audio stream.

Table 9-2 lists suggested minimum audio bit rates and the quality you can expect for each. Note that the presets that come with most encoders often use lower audio bit rates, particularly for dial-up streams. This is not necessarily the best approach.

Table 9-2
Suggested minimum streaming audio bit rates and expected quality.

image

 

Author’s Tip image

Any broadcast engineer will tell you that people will watch substandard picture quality, provided it is accompanied by good quality audio. A perfect example is news coverage from dangerous areas that is sent back via video phone. This technology sends a video stream over a phone line. The picture is jerky and blocky, but the audio quality is always acceptable.

In addition to the bit rate, there are two other settings you can control. You can choose to use a voice or a music codec, and you can encode in either mono or stereo. It’s easy to decide which to use in both cases.

Most program content is mono. Even music that is recorded in stereo places the important elements in the center of the mix. At any given bit rate, mono codecs have higher fidelity than stereo codecs. Not only that, but stereo codecs sound pretty bad at bit rates less than 32 kbps. So unless your content truly requires stereo, encode in mono and your content will sound better. You should always encode in mono at bit rates under 32 kbps.

The choice between a voice codec and a music codec is a little trickier. Voice codecs take advantage of the limited frequency and dynamic ranges of speech, and use a different algorithm to encode a higher quality stream. The problem is that if you try to encode music using a voice codec, it sounds horrible.

ALERT

image

Only use a voice codec if you’re absolutely sure that your programming does not include music, or if the music is only used at a low level in the background.

Video Considerations

The total bit rate of your file constrains the video quality of your webcast. Recall that video codecs must render key frames followed by difference frames, and must stay within the budget that is determined by the total bit rate. Once you decide on a total bit rate for your stream (and the audio codec you’re using), there are really only three basic encoding settings you can control: the screen size, or resolution, the frame rate, and the frame quality setting.

Resolution — Let’s start with resolution. If you’re webcasting at dial-up rates, you simply are not going to be able to deliver a full-screen, full-motion experience. The crazy thing is that encoding software will let you try. You can set up an encoding profile with a resolution of 640 × 480 and a total bit rate of 34 kbps—but don’t expect the result to resemble anything other than mud.

So the thing to do is to choose a resolution that is appropriate to your total bit rate and the type of content you’re trying to encode. High motion content will require reduced resolutions to achieve acceptable results. Low motion content will encode well at slightly larger screen resolutions than high motion content. This is yet another area where testing before your event will be very helpful. Determine in advance what resolution is optimal for your bit rates. Table 9-3 lists some suggested resolutions for different types of content at varying bit rates.

Table 9-3
Suggested screen resolutions.

image

One important thing to notice about the suggested screen resolutions is that they’re a 4:3 aspect ratio. The aspect ratio is the ratio of the width to the height of the picture frame. You should always use a 4:3 aspect ratio when setting the resolution. Aspect ratios and screen resolutions are discussed in more detail later in the chapter in the “Cropping and Resizing” section.

Frame Rate — The second setting you can set is the frame rate. Standard video is shot at 30 frames per second (actually 29.97). Ideally we want our streaming video to encode at 30 frames per second. Unfortunately, when encoding at a low bit rate, there may not be enough bandwidth. One approach is to reduce the frame rate.

However, reducing the frame rate may be a false economy. For example, consider encoding at 15 frames per second instead of 30. To do this the encoder drops half the frames, and encodes every other frame (see Figure 9-5). Remember, however, the codec encodes based on the difference between frames. If there is a lot of motion in the programming, the difference between frames 1 and 3 will be greater than frames 1 and 2. So even though there are fewer frames to encode, the difference between frames may be more difficult to encode.

image

Figure 9-5
How encoders drop frames when encoding at reduced frame rates.

If your programming is low motion, decreasing the frame rate can help, because the difference between frames is minimal. If your programming is high motion, stick with the original frame rate and decrease your resolution until you achieve acceptable results.

When reducing the new frame rate be sure the new frame rate is a factor of the original frame rate. To see why, consider the examples in Figure 9-5. To get 15 frames per second, the encoder drops every other frame. For 10 frames, the encoder encodes a frame, then drops two, then encodes one, and drops two, etc. The key here is that the time interval between encoded frames is consistent.

If you specify 20 frames per second, the encoder encodes two, then drops one, encodes two, etc. The problem is that the resulting encoded file will appear jerky, because the difference between the first two frames is a single frame, but the difference between the second and third is two frames. The time interval between frames is inconsistent, and the result will be ugly.

ALERT

image

Interestingly enough, when you’re setting the frame rate, you’re setting a desired frame rate. If the codec can’t keep up with your desired frame rate given the other parameters you’ve set, it will do the best job it can, but drop frames from time to time or decrease the frame rate to strike a balance between frame rate and frame quality.

Frame Quality — The final setting you can affect is frame quality. This setting determines the overall quality of the video frames. The encoder uses the frame quality setting and the frame rate to determine how to encode your file. Setting the frame quality high means you’d prefer less frames per second, but higher quality. Setting the frame quality low means you’d prefer the encoder to provide the full frame rate, and compromise picture quality to achieve it.

In the Windows Media and QuickTime encoders, you set a frame quality between 1 and 100, with 100 being the highest frame quality. The RealProducer offers three settings, Sharpest Image, Normal, and Smoothest Motion. High action programming generally looks best when encoded with low quality frames, because the motion requires a full frame rate. Lower motion programming can often take advantage of a higher quality frame quality, and hence a lower frame rate.

Inside the Industry

image

Ben Waggoner, noted industry compressionist, feels most viewers prefer a stable frame rate with variable image quality to stable image quality with a variable frame rate. To achieve this, you should set your encoder’s frame quality Controls to minimum. Of course, the big exception is when image quality is at a premium, for example in a classroom where a whiteboard has to be legible.

He also feels that frame rates below 12fps aren’t a good idea. There is greater change between each frame (which needs to be encoded), and the user has more time to notice each artifact.

The solution? Use a lower screen resolution.

The best approach to encoding is to start with an existing encoding profile and to experiment with the settings. If your content is low motion, you can experiment with larger resolutions and higher frame quality. Higher action programming will by definition require reduced resolutions, and lower frame qualities.

Using Advanced Encoding Filters — In addition to the basic settings that you can control in your encoder, most encoding software also offers advanced filters to deal with special situations. Two of these are designed to deal specifically with issues that arise during the video transfer process, the third deals with poorly produced content.

Delnterlacing Filter — The resolution section touched on the fact that television and computer monitors display video differently. Another difference is that television monitors are interlaced displays, whereas computer monitors are progressive displays. Interlaced displays divide each frame of video into two fields, one that includes all the odd lines and the other all the even lines. Progressive displays don’t have fields, they just have a single frame (see Figure 9-6).

image

Figure 9-6
Interlaced vs. progressive displays.

To make a single frame of progressive video, the two fields of interlaced video must be combined. The problem arises because the fields are actually separated by a discrete interval of time, 1/60th of a second to be exact (1/50th of a second in Europe). If there’s a lot of motion in the frame, particularly horizontal motion, the combination of the two fields can cause problems (see Figure 9-7).

image

Figure 9-7
A progressive frame assembled from two interlaced fields.

The vehicle driving past the camera moved considerably between the first and second fields. Consequently, when the fields are combined into a single frame of progressive video, the result is that the vehicle is a mess. Deinterlacing filters attempt to remove interlacing artifacts from the video before it is encoded.

There are a number of different ways that interlacing can be mitigated. The details are complex and tedious—suffice it to say that most video content should be deinterlaced for maximum quality, with a couple of notable exceptions.

The first exception is when you’re encoding at a resolution of 320 × 240 or smaller. In that case, most encoders don’t use the second field, so interlacing artifacts never appear. The second is if you’re filming with a new video camera that supports progressive mode, in which case the programming isn’t interlaced to begin with.

Inverse Telecine Filter — The inverse telecine filter gets rid of the redundant frames that are created when film is transferred to video. The native frame rate of film is 24 frames per second. When film is transferred to video, an extra frame is inserted every four frames. This frame is “created” by combining fields from the frames surrounding it.

The extra frame isn’t noticeable when the video plays back, but it’s unnecessary. An inverse telecine filter senses the extra information and removes it, so that the codec doesn’t have to waste effort on encoding redundant information.

Noise Filter — The final filter, a noise filter, is useful only for poorly produced content. Low quality content is noisy, which is visible as grain or snow in the picture. This grain is seen as motion by the codec, and thereby seen as important.

A noise filter slightly blurs each video frame, thereby reducing the amount of detail. Reducing the amount of detail in the frame generally reduces the amount of motion seen in the frame, and thereby tricks the codec into ignoring the noise.

If you produce your video content to a high standard, you should never have to use a noise filter. However, for content that can’t be re-shot or otherwise fixed, a noise filter can help.

Cropping and Resizing — Virtually all streaming video has to be resized at some point. The limited data rates that we can encode at generally preclude any sort of full screen presentation, so we’re generally encoding at something less than 720 × 480. However, there’s another reason that streaming video has to be resized, due to the difference between television and computer displays.

Aspect Ratios and Square vs. Non-Square Pixels — Television screens have a 4:3 aspect ratio, which means the ratio of their width to height is always a perfect 4:3. However, television displays have 480 visible lines of resolution, each line having 720 pixels. If you do the math, you’ll see that this is not a 4:3 aspect ratio. A 4:3 aspect ratio would dictate 640 pixels per line.

When video is digitized at 720 × 480, and displayed on a computer screen, the image looks a bit squashed because of the difference in pixel geometry. To solve this problem, we have to resize the video to a 4:3 aspect ratio. When we resize a 720 × 480 digital video to a 640 × 480 or 320 × 240 resolution, we’re restoring the original aspect ratio that television pixels would otherwise provide.

Why It’s Tricky — First of all, resizing, by definition, changes the original signal, and it’s a very complex thing to do. If done incorrectly, it can introduce artifacts into your video signal. These artifacts will be amplified by the encoding process, and may result in a low quality video stream.

Cropping the image adds a level of complexity, because you have to be extra careful about maintaining your aspect ratio. Some instances where you might want to crop your video are:

•    You’re encoding from a very low quality source, which has noise around the edges or along the bottom.

•    You’re encoding widescreen content that has been “letterboxed” with black bars along the top and bottom of the screen.

These two cases require completely different approaches. In the first case, you want to stay at a standard 4:3 aspect ratio, but get rid of some noise along the edges. In the second case, you want to end up with a 16:9 widescreen aspect ratio (or some variation thereof).

The first thing you must determine is what the final aspect ratio of your video is, and choose a resolution accordingly. If it’s a standard 4:3 aspect ratio, then the usual 320 × 240, 240 × 180,192 × 144, and 160 x120 are what you should be targeting. If you want to end up with a widescreen format, then you should be targeting a 16:9 aspect ratio, like 320 × 180, 240 × 132, or 160 × 90.

Next, you must determine how much you want to crop your screen, and adjust it to maintain a 4:3 (or 16:9) aspect ratio. If you want to crop 5% of the bottom of your frame to get rid of noise, you’re going to have to also crop 5% from either the left or right sides to maintain your aspect ratio (see Figure 9-8).

image

Figure 9-8
Be sure to maintain your aspect ratio when cropping.

 

Author’s Tip image

Many codecs have limitations on the resolutions they will handle, caused by their minimum macro-block size. This is a fancy way of saying that the dimensions may have to be even multiples of 4, 8 or even 16.

Depending on what software you’re using, you have to determine in what order the resizing and cropping are done, so you can maintain the proper aspect ratio. Some of the cropping functionality offered by encoding applications can be downright confusing. Examples of cropping and resizing are provided later in the chapter.

Legacy Considerations

One very annoying consideration that you must bear in mind as a webcast producer is what version media player your audience has installed. This can be particularly relevant in the enterprise, where desktops may be locked down and users are not allowed to install software. Some of the latest codecs in encoding applications are not backwards compatible with older players.

For example, if you’re webcasting to a corporate audience that is standardized on a Windows 2000 platform, and they have not upgraded to Windows Media 9 Series, you cannot encode using the Windows Media 9 video codecs. The audio codecs are backwards compatible, but the video codecs are not. This is particularly frustrating because the Windows Media 9 Series video codecs represent a huge step forward in video quality. You may be forced to encode using Windows Media 7 codecs, which offer far less fidelity.

This situation is by no means limited to the Windows Media Platform. Real, QuickTime, and Flash all have the exact same problem. In an ideal world you’d always encode using the latest codecs for the highest possible quality. Depending on your audience, you may be limited to lower quality legacy codecs.

Multiple Bit Rate (MBR) Files

If you’re encoding a number of different bit rates and more than one encoding platform, you can quickly end up with a lot of files. Not only that, but instead of a single link to a webcast you may have to put four or more links (i.e., broadband and dial-up bit rates, in both Windows Media and RealMedia formats). To simplify this, both Windows Media and RealNetworks allow multiple streams to be embedded in a single file, known as a multiple bit rate (MBR) file.

MBR files offer a number of advantages. First, they allow you to use a single encoder to encode multiple streams, reducing the amount of equipment you need. Second, file management is simplified, with a single link to the content for all bit rates, and a single archive file to keep track of. Additionally, RealNetworks Helix servers have the ability to switch between streams contained within the same file. This feature is known as SureStream technology. This can be helpful if traffic conditions on the Internet change during a webcast.

ALERT

image

An audience member who initially connects at 300 kbps may no longer be capable of receiving a full 300 kbps stream. If available, the server can downshift seamlessly to a lower bit rate stream. Without this, servers and players “thin” streams by dropping frames.

The ability to switch to a lower bit rate stream made for a much improved experience for the audience when the technology came out. Connectivity on the Internet has improved a lot in the past five years, however, making this functionality largely unnecessary. While the improved file management is useful, the switching ability largely is not.

Not only that, but the resolution of all video streams in a SureStream file must be the same. This renders it practically useless, because different resolutions are appropriate for different bit rates. With SureStream, you end up either encoding at a small resolution, which is not an optimal experience for the broadband audience, or at a larger resolution, which dooms the dial-up stream to inferior quality.

Push vs. Pull

There are two basic methods used to get your stream to the server:

•    Push encoding: Using this method the encoder initiates the connection, and sends the stream directly to a server.

•    Pull encoding: Using this method, the server initiates the connection, requesting the stream from the encoder.

Push encoding can be advantageous because it enables you to encode from behind a firewall. The server doesn’t have to know anything about the encoder, however, to set up a push encode you must know the server name, port, and other information such as the publishing point, or a username and password combination. All this must be set up in advance on the server.

Pull encoding can be advantageous because it requires no knowledge on the encoding side. All you have to do is start up the encoder, and the server takes care of the rest. However, pull encoding requires that the encoding machine reside on a routable IP address. This means that either the encoding machine cannot be behind a firewall, or if it is, you’ll have to do some work on the firewall configuration to make sure the server can request packets from the encoding machine.

The encoding method you choose is highly dependent on how your distribution network is set up. Some content distribution networks (CDNs) only support pull encoding, others require push. It will also be dependent on the network connectivity on site and whether routable IP addresses are available. Be sure to test your encoding well in advance to avoid any surprises right before the broadcast.

Encoding Settings Examples

The techniques described in this chapter are for the most part available in all live streaming applications. The biggest challenge is figuring out where each platform hides the settings, and what the terminology used by each platform means.

The following sections illustrate how to set up encoders for the Windows Media and Real platforms. Both of these encoding applications are available for free, though the RealProducer Basic does not allow you to alter the default templates. It’s actually really simple to get around this limitation of the RealProducer. All audience templates are stored in the audiences folder, in a fairly simple to understand XML format. Open any of these files in a text editor, change the settings any way you like, and save the edited file. Presto!

For the purposes of this exercise, we’re going to assume that we’re catering to a broadband audience. Depending on your audience you may also want to encode a dial-up stream when you webcast. For Windows Media streams, you can simply choose another encoding template and use a multiple bit rate file. For Real streams it’s generally best to encode two separate streams and offer different screen resolutions for each. The following examples should familiarize you with the encoding applications enough to do what you need to do.

Windows Media Encoder

The Quick Start section of this book provided a step by step walkthrough the Windows Media Encoder using the wizard. Now that you’ve read most of this book, it’s time to start acting like a power user. Start up the Windows Media Encoder. If the New Session Wizard appears, de-select the check box in the lower right corner that says “Show this dialog box at start up,” and click cancel (see Figure 9-9).

image

Figure 9-9
Disabling the Windows Media New Session Wizard.

All you have to do now is click the Properties tab along the top of the Windows Media Encoder. This opens up the Session Properties window in the left side of the Windows Media Encoder. The window presents a tabbed interface to all the encoder settings. In fact, when you use the New Session Wizard, you’re essentially working your way through these very tabs. The first tab is where you set up your sources for the webcast (see Figure 9-10).

image

Figure 9-10
The first thing to do is set up sources for your webcast.

Selecting Sources — Choose an audio and a video source for your webcast. In most cases these will be from devices, but in some cases, for example if you’re using an intro and outro, you may want to define previously existing files to use. For each file, you’d set up a different source.

The Windows Media Encoder is very flexible when it comes to setting up sources. You can define a number of different sources, and define behaviors for each of them. For example, consider a webcast where you want to display a welcome slide for the 30 minutes preceding a broadcast, then webcast a live audio and video feed, and then finish off with a thank you slide for five minutes. In this case you would define three different sources.

The first source would use an image for the video, and perhaps live audio. Source two would be live audio and video, and source three would be another slide for the video, and perhaps with previously recorded audio. During the broadcast you could switch between these sources, manually, or have them switch automatically at certain times. This is an easy way to produce a relatively professional looking broadcast.

After your sources are set, it’s time to set up how you’re going to send your streams to the outside world. This is set up on the Output tab.

Select Your Output Method — Click on the output tab to set up how you’re sending the encoded stream to the server (see Figure 9-11).

 

Author’s Tip image

if you’re planning on using script commands during your live broadcast, be sure to click the Script checkbox. This ensures that the script commands panel is available during your webcast.

image

Figure 9-11
Next, set up your output method(s) on the Output tab.

If you’re using the push method, click the “Push to server” box, and enter the server name and publishing point. If you’re using the pull method, click the “Pull from encoder” box and make sure the port you’re using isn’t in use by any other applications on the machine. If you need to change to another point, be sure to tell your distribution partner the new port number—they’ll need to know that to set up the server correctly.

The last thing you can do on this tab is create an archive of your webcast. You can do this by checking the “Archive to file” box, and providing an appropriate file name. The archive can be limited by size or duration, if you’re worried about filling up your hard drive. In these days of 100+ gigabyte drives, this should not be too much of a concern. The next step is the heart of the encoder—the compression tab.

 

Author’s Tip image

You can use both methods of encoding at the same time, and each method could use a different server—which would provide you with a certain amount of redundancy. You can even have multiple servers pulling from the same encoder, again for redundancy.

Choose Your Encoding Settings — Click on the Compression tab to display the compression settings (see Figure 9-12). This is where you select the encoding profiles, which are determined by the bandwidth of your target audiences. These days, it’s fairly safe to assume there are two basic audiences, broadband and dial-up, with dial-up thankfully disappearing. Working under this assumption, you should be aiming to encode two streams, targeting bit rates around 300 kbps and 37 kbps.

image

Figure 9-12
The Compression tab is where the fun begins.

The Windows Media Encoder exposes different default profiles depending on which selections you make in the Destination, Video, and Audio drop down menus. Select “Windows Media Server (streaming),” “Multiple bit rates video (CBR),” and “Multiple bit rates audio (CBR).” Then select appropriate bit rates for your audience. To modify an existing profile, click the Edit button to bring up the Custom Encoding Settings window (see Figure 9-13).

image

Figure 9-13
Use the Custom Encoding Settings window to optimize your settings.

For example, the default streaming profiles provide a 340 kbps and a 43 kbps. You can modify each of these by clicking on the appropriate tab in this window. You can choose which audio codec to use, adjust the total bit rate by raising or lowering the video bit rate, and adjust the screen resolution. There are other advanced settings you can adjust, such as key frame interval, but you shouldn’t really mess with these unless you really know what you’re doing. In Figure 9-14, you can see that I’ve created a custom 300 kbps profile, with a 32 Kbps mono audio codec, and the video bit rate adjusted to 259k for a total of 300 kbps.

image

Figure 9-14
A custom 300 kbps profile with a modified audio codec and video bit rate.

If you put a decent amount of effort into creating a custom profile that works for your content, you should save it so that you don’t have to re-create it each time. After you have your parameters set just the way you want, click on the General tab, and type a name and a description of your profile. You can see in Figure 9-15 that the description leaves no doubt as to how the parameters have been set. This saves time later, as you don’t have to click through each and every screen to figure what settings are being used.

image

Figure 9-15
Save your custom profiles with sensible names and full descriptions.

Adjust the Video Size — Click on the video size window if you need to do any cropping of your video. But beware—cropping your video is not a trivial exercise. There is significant interplay between the settings on this page and the settings you specified on the Compression tab.

image

Figure 9-16
Try to avoid resizing your video if at all possible.

The Windows Media Encoder comes with a number of presets for cropping 4:3 content to a widescreen aspect ratio (see Figure 9-16). However, by default, Windows Media Encoder attempts to stretch the video to fit whatever resolution you set on the Compression tab. So if you’re trying to encode a widescreen aspect ratio, you must be sure to set the output size on the Compression tab appropriately.

For example, if you’re cropping letterboxed content for a target 16:9 aspect ratio, you should set your output size to 320 × 180 or any other 16:9 aspect ratio. Then, on the Video Size tab, you should select the 1.78:1 setting (which is the same as 16:9). The result will be a nice widescreen file.

The Windows Media cropping utility is clever in that it uses percentages instead of exact pixel numbers. The benefit is that if your input is a different size than you think, the encoder will crop the same percentage of the screen. It might sound tricky, but it works.

For example, assuming you’re working with a 4:3 aspect ratio, using a size of 320 × 240. To get to a 16:9 aspect ratio, you want to end up with 320 × 180, which means you have to crop 30 pixels off the top and bottom. Choosing the 1.78:1 preset does precisely that. The cool thing is that if your sources are actually 640 × 480, the encoder automatically changes the settings to crop the right percentage of the screen, so your output looks correct.

ALERT

image

The one drawback to the Windows Media Encoder cropping utility is that it doesn’t preview in real time. You must start the encoder to see the results of your settings. Be sure to run some tests to make sure you’re getting what you want.

If you’re cropping to get rid of noise at the edges of your video, you have to use the custom method of cropping. This is where you can get into trouble, because the controls for the amount of cropping on all four sides are independent. Furthermore, the default behavior of the Windows Media Encoder is to stretch the picture to fit the size specified in the Compression tab.

 

Author’s Tip image

You can shave off 5% of all four sides without any problem. This part of the screen is hidden by most television sets by the plastic surround, so cameramen and directors never put anything important at the extreme edge of the picture. For a 320 × 240 screen, this translates to 12 pixels off the top and bottom, and 16 pixels off the left and right.

The key is that for every three pixels you shave off the top or bottom, you have to shave four pixels off the left or right. As long as you keep this in mind, you should be okay. But be careful.

Fill in the Stream Information — Click on the Attributes tab to fill in title, author, copyright, rating and description information (see Figure 9-17). This information is optional, but highly recommended. If you don’t provide this information, the player defaults to displaying the name of the file in the title bar, which might be totally meaningless. It’s much better to display a meaningful title. Not only that, it’s incredibly helpful later if someone asks for a particular video, and the file name doesn’t include the name of the speaker. In that case, placing the name of the speaker in the title or author fields can be a lifesaver.

image

Figure 9-17
Use the title, author and copyright fields wisely.

Video Processing — Click the video processing tab to use the advanced filtering built in to the Windows Media Encoder (see Figure 9-18). This is where you can apply Inverse Telecine and Deinterlacing filters to your inputs. If you don’t know whether your content requires these filters, you can use the Detect button to have the Windows Media Encoder sample your input and recommend filters for you to use.

image

Figure 9-18
Use filters—but only if you need them.

Advanced Functionalities — There are a few more tabs available in the Properties window, but they offer advanced functionality that is not used very often, and specifically not covered in this book:

•    Plug-ins: The Plug-ins tab enables you to do audio and video processing in the Windows Media Encoder. No processing plug-ins are included with the basic Windows Media Encoder install, you have to find third-party plug-ins and install them.

•    Security: The Windows Media Encoder is capable of broadcasting files that are protected by digital rights management (DRM) schemes. This is a subject that warrants a book of its own.

•    Advanced: You can do some harmless things on this tab, such as change the Identification name of the encoder or include time code in your file, and some incredibly dangerous things such as altering the maximum packet size. Don’t touch it.

 

Author’s Tip image

If you’re using any kind of video input, chances are that the Windows Media Encoder is going to recommend that you use the Deinterlacing filter. However, if you’re encoding at resolutions of 320 × 240 and below, don’t bother. Streaming encoders discard one of the fields when the screen resolution is 320 × 240 or smaller, obviating the need for deinterlacing.

Apply Your Changes, Save the Session — Before you do anything, it’s very important to click the Apply button in the bottom right corner of the Properties window. This registers all your changes, and will adjust the Windows Media Encoder interface accordingly. For example, if you’re going to issue live script commands, a script panel will be displayed.

To save a session file, choose Save or Save As from the File Menu, and choose a location and file name for a session file. As always, using descriptive file names is a great idea.

 

Author’s Tip image

Another good practice is to save an Encoder Session file. This file combines all the info you entered into the various tabs of the Properties window into a text file that can be opened up by any Windows Media Player. That way, if catastrophic failure should occur, you don’t have to completely reconfigure your encoder—just double-click on the session file and go!

ALERT

image

If you’re using push encoding, copy all your session files onto the desktops of all your backup machines. That way if a machine goes down, you can bring up a backup in a matter of seconds. You can do the same D with pull encoding, but you have to make sure the backup machine is configured to use the same IP address.

Start Encoding — If you’re made it this far, there’s nothing left to do other than to click the Start Encoding button at the top of the Windows Media Encoder. If there’s enough room on your screen, the properties window will stay open, and your video inputs will be displayed, along with audio level meters. If there isn’t enough room, your Properties window will automatically be closed to make room for the other panels of the encoder (see Figure 9-19).

image

Figure 9-19
The Windows Media Encoder uses as much screen real estate as possible.

Test Your Stream — Just because your encoder is running doesn’t mean your job is done. You’ve got to test your stream to make sure it’s reaching the server and everything is working properly. The Windows Media server distributes live streams via publishing points. When you’re linking to a live stream, link straight to the publishing point, using the following syntax:

rtsp://your.server.com/name_of_your_publishing_point

You can also link directly to the Windows Media Encoder. The link is displayed in the monitor panel of the encoder when you begin encoding, on the connections tab. It will look something like this:

http://123.34.67.89:8080

Checking your streams is probably the most important part of the whole process. Not only does it verify that the streams are actually available on the servers, but it also gives you a chance to see exactly what your audience is seeing. If you don’t like what you’re seeing, neither will they. Testing gives you a chance to adjust your settings if needed.

RealProducer

The RealProducer interface is similar to the Windows Media Encoder. The input is on the left, the output is on the right (see Figure 9-20). The bottom of the interface lists all the jobs that are scheduled, if you’re using the encoder to do bulk encoding. To begin with, we need to set up our sources.

image

Figure 9-20
Most of the controls of the RealProducer are accessible from the main interface.

Selecting Sources — The RealProducer encodes from either files or devices. You can set up different sources for different jobs, and specify durations for jobs. You can’t switch manually between sources like you can with the Windows Media Encoder. Click the radio button next to the type of source you want, and choose the source from the drop-down menu or click the Browse button if you’re encoding from an archived file.

You should see your video source, and see audio level on the audio input meters. If you don’t, there is something wrong with your sources. If you don’t see your source listed in the drop-down menu, you may need to re-start the RealProducer, particularly if you’re using a FireWire source and connected it after you started the RealProducer.

The Settings buttons next to the audio and video sources provide easy access to the audio input levels as well as any video controls that may be available. These will vary depending on your source and the capture card manufacturer.

Setting Up Your Outputs — The RealProducer encodes directly to files or to servers. To set up a live encode to a file, click the small RealOne icon underneath the destination pane. This pops open a standard “Save As” dialog box, where you specify a filename and click OK.

To set up a server destination, click the small server icon underneath the destination pane. This opens the server destination window (see Figure 9-21). At the top of this window, enter a name for the destination, the name of the live file, and select the broadcast method you’ll be using.

image

Figure 9-21
Enter your server details in the Server Destination window.

 

Author’s Tip image

Saving templates is only possible with the RealProducer Plus. Another RealProducer Plus feature is sending to multiple servers simultaneously. You can specify multiple servers in the destinations pane, each with different server settings and connect methods if necessary. The RealProducer Basic is limited to a single server destination.

The RealProducer can do push and pull encoding, and supports a number of different account schemes. The one you choose will be dependent on the server setup and the onsite connectivity. Your distribution partner or IT department will provide you with the appropriate settings to use here. Be sure to save your settings as a template, as it makes setting up future webcasts easier.

Setting Up Audiences — The RealProducer calls a set of encoder settings an audience. Click on the Audiences button right above the destination pane to choose your encoding settings. This opens up the Audiences window (see Figure 9-22).

image

Figure 9-22
Choose your encoding settings in the Audiences window.

Starting from the top left, the first thing to choose is the type of audio codec to use. Use the voice codec only if you’re absolutely sure your programming will not include music. Next, select your desired video quality by choosing an option from the Video mode drop-down menu. Finally, you can choose how much backwards compatibility you want by selecting which RealVideo codec you want to use.

ALERT

image

Backwards compatibility is only available with the RealProducer Plus. The RealProducer basic forces you to use the latest RealVideo codecs.

The right hand side is where you set the size of your output video. Click the “Resize video to:” checkbox to activate the resizing functionality. But beware—immediately below the resizing dimension specifications, there’s a checkbox that means well but can get you into a whole lot of trouble.

The RealProducer defaults to having the “Maintain aspect ratio” check box checked when you enable the resize video functionality. In theory, this is a good thing. But in practice, it doesn’t always work, because it doesn’t take pixel geometry into account.

For example, if you’re encoding directly from FireWire, the RealProducer senses that your input is 720 × 480. If you try to resize it to 640 × 480 while leaving the “Maintain aspect ratio” checked, you won’t be able to. The box forces the mathematical ratio to remain constant; ignoring the fact that DV content uses different pixel geometry. The irony in this case is that the setting does exactly the opposite of what it is supposed to do.

However, it’s easy to correct. Deselect the “Maintain aspect ratio” check box, and then type in 640 × 480 or 320 × 240, or whatever size you decide to use.

The bottom of this window is divided in half. The left side shows all available audience templates; the right side shows the templates that will be used for this job. Click the audiences you want and click the arrow between the two areas. Highlight audiences and click the trash icon beneath the right side to get rid of audiences you don’t want.

 

Author’s Tip image

Remember, all audiences are forced to use the same screen resolution. If your audiences have radically different bandwidths available, it’s probably a better idea to send them individual streams rather than compromise one for the other.

If you want to edit an audience, click the pencil icon underneath the Audiences window. This opens up the Audience Properties window (see Figure 9-23).

image

Figure 9-23
You can edit templates with RealProducer Plus.

ALERT

image

If you don’t have RealProducer Plus, don’t bother trying, because this functionality is disabled in the free encoder. You can, however edit templates manually with a text editor.

You can change the total bit rate, the target frame rate, and the audio codecs used (depending on whether you specify music or voice on the Audiences page). There are also some additional settings available via the Advanced Video Options button, but unless you really know what you’re doing, you probably shouldn’t mess with these (see Figure 9-24).

image

Figure 9-24
Use Loss protection to make your streams more robust.

One notable exception is the Loss protection setting. This builds in a little more redundancy into the file in case a packet is dropped along the way. Loss protection can make your file hold up a little better in some cases, and should always be used if you’re encoding for the public Internet.

Of course, if you’ve made a number of changes it’s a good idea to save your work as a template for next time.

Video Processing — Click the video filters button to access the video processing capabilities of the RealProducer. This opens up the Video Filters window, which provides cropping and black level correction, as well as deinterlace, inverse telecine, and noise filters. This window also features a video preview window.

The cropping interface does not provide any presets. Instead there are left and top crop values, and total height and width values that can be entered manually or adjusted by dragging the yellow bars in the video preview window. The preview window is a nice touch, but being sure you’re maintaining a proper aspect ratio will involve some math.

Another interesting point is that the RealProducer does not stretch the cropped content to your specified resolution. If you need to crop your content and end up at a particular resolution, you have to start with a resolution that is larger than your target resolution, and crop accordingly.

For example, if you want to end up with a 320 × 240 resolution and want to crop off roughly five percent around the edges, then you’d have to set your resolution on the audiences page to 352 (320 plus ten percent) by 264 (240 plus ten percent). In the Video Processing window, you’d set the left parameter to 16, the top to 12, and the width and height to 320 and 240, respectively. Got it?

ALERT

image

Although the RealProducer will let you specify a larger output size than your input source, you cannot then crop this stretched video back down to your desired output size. The width and height settings on the cropping feature either override the settings on the Audiences page, or are ignored, depending on the order in which you set them.

The next processing feature available is black level correction. Black level correction makes the darkest areas of your screen black again. This helps restore the balance if you’ve adjusted your brightness, and also compensates for the difference between black on a television monitor and black on a computer monitor. Click the check box if you want to use this feature.

The final two (actually three) processing features available are deinterlacing/lnverse Telecine and Noise filtering. The Deinterlace/lnverse Telecine functionality is on by default—the RealProducer automatically uses it if it needs to. Finally, a noise filter is available if you have very low quality content.

Fill in Clip Information — Click the Clip Information button to fill in the title, author, and copyright information for your clip, (see Figure 9-25). As mentioned previously, this information is completely optional, but makes your webcast look far more professional. It also can be very helpful later on if you’re looking for a particular piece of programming amongst a number of files that have unhelpful names.

image

Figure 9-25
Fill in the clip information.

Save the Job File — Choose the Save Dob option from the File menu to save all the encoding information for your webcast. Provided you’re using a push encoding method, this job file can be copied to your backup machine(s) and used to fire up another encoder quickly if your main encoding machine suffers a catastrophic failure.

ALERT

image

Unfortunately, saving job files is yet another option that is only available in RealProducer Plus.

Start Encoding — Click the Encode button at the bottom of the interface to start the encoding process. If you’re using push encoding, it will take a few moments for the encoder to connect to the server and authenticate. If you’re using pull encoding, it may take a few moments for the server to begin pulling from the encoder.

If you’re using multiple audience templates, you can monitor the quality of each output by choosing the audience from the drop down menu above the output window. This is a handy feature that allows you to see what each of your audiences is seeing without having to open up a RealPlayer.

Test Your Stream — Don’t forget to test your stream. You can test it by opening up a RealPlayer, and opening a connection directly to the server. If your server is using the default mount point, using the following syntax:

rtsp://your.server.com/encoder/name_of_your_file.rm

If you’re running multiple servers, you may need to use slightly different syntax. Check with your system administrator to get the correct syntax. Be sure to check your streams on site. Not only is it important that the streams are available on the server, but also you’ll be able to check your stream quality, and adjust your settings if needed.

Redundant Encoding Techniques

There are a number of approaches you can use to build redundancy into your webcast. The first, and most obvious, is to have multiple encoding machines available in case of equipment failure. However, there are other types of failure, and other techniques available to try and mitigate them.

For example, you might suffer a catastrophic connectivity outage. Using multiple connectivity paths is required to combat this. This requires using multiple encoding machines on different networks, and likely twice the connectivity fees.

Even if you don’t use multiple connectivity paths, you can still send multiple feeds. If for some reason one of your encoders shuts down, the audience automatically rolls over to the backup feed, instead of being disconnected. This is a much better experience than having the audience wait until you restart the encoder or replace it with a backup machine.

Of course, to get this kind of behavior you need to provide access to the redundant streams using the redundancy features built in to your server platform or by using redundancy in your metafile. Server and metafile redundancy are covered in subsequent chapters.

Conclusion

Encoding involves some compromises in your stream quality, because the public Internet isn’t yet capable of sustaining bit rates required for that level of quality. Therefore, consider your audience and type of programming when choosing your encoding settings.

You’ll need powerful computers with good quality sound cards and capture cards or FireWire ports. Alternatively you can buy custom encoding solutions, or solutions dedicated to producing particular types of presentations.

Be sure to select the right audio codec, and allot a high enough audio bit rate to provide acceptable audio quality. Adjust your video resolution to optimize your video quality. Use video processing when you need it, being sure to always maintain the correct aspect ratio. After you’ve selected all your settings, save the templates or profiles, and the job file. Then, fire up your encoder and test your streams.

Finally, use as many redundant encoding techniques as you can afford to. The next chapter covers authoring, which is how you connect your audience to your content.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset