Using MS Windows NT Server NetShow Services
Using MS Windows NT ® Server NetShow™ Services
Abstract
For the uninitiated, planning for and successfully executing a live webcast can seem a daunting undertaking. Every event is different, and each poses unique implementation issues and challenges. This guide is an overview of the many variables to consider when planning for and producing live webcast events.
On This Page
.gif){kind=icon}
Introduction
Basic Terms and Concepts
The Basics of NetShow Services
The Live Event: An Overview
How Video Compression Works
All About the NetShow Encoder
At the Event: Interfacing with A/V, Configuring the Encoder, Connectivity to the Server
Configuring the NetShow Encoder
The MSBD Connection: Connectivity Between the NetShow Encoder and NetShow Server components
A Bit About The NetShow Server components
Summary
Appendix: Additional Resources
Introduction
For the uninitiated, planning for and successfully executing a live webcast can seem a daunting undertaking. Every event is different, and each poses unique implementation issues and challenges. This guide is an overview of the many variables to consider when planning for and producing live webcast events.
This document describes the most difficult webcasting scenario of all: producing a live event from a location remote from the point of network service, encoding for both video and audio on site, and distributing to the Internet at associated (low) bandwidths. On the technical side, we have included hardware and connectivity recommendations as guidelines that provide the best assurance in deploying a successful webcast. The target audience for this document is producers or managers engaging in this practice for the first time, who need an understanding of the broader requirements and procedures involved in planning a webcast.
Microsoft® Windows NT® Server NetShow™ Services enable Internet Providers and organizations to deliver the highest-quality audio and video at every bandwidth across the Internet or enterprise networks. NetShow Services consist of server and tools components for delivering audio, video, illustrated audio, animations, and other media types over networks. Users play Windows Media content with the new Windows Media Player, a universal player that plays the most local and streamed media file types. NetShow Services empower companies to deliver rich content to sell goods and services, provide news and entertainment, conduct training, and deliver corporate communications.
For more detailed information on specific NetShow Services (such as how exactly to configure the NetShow Encoder), please consult the NetShow Services Product Documentation and the NetShow Services Content Creation Guide that install with your tools, as well as additional documentation found in Microsoft TechNet or on the NetShow Services Web site at https://www.microsoft.com/NTServer/techresources/streaming/default.asp/.
Basic Terms and Concepts
ISP: Internet Service Provider, supplying NetShow Services hosting services. In webcast, the ISP is most concerned with server configuration and connectivity with the Encoder.
CODEC: Central to the concept of streaming media. Short for Compressor/Decompressor. Codecs are used on the content creation side (in this case, at the NetShow Encoder) to compress the audio and video data to target data rates; and they are used on the client to decompress that data for playing.
MSBD: The protocol for streaming data internally before it's served to the public, such as between the live NetShow Encoder or between servers. NetShow Services now also support HTTP distribution between these components.
ASF: Advanced Streaming Format is a file format of Windows Media content. An ASF stream from a NetShow Encoder can be transmitted live over a network, written to file for later playback, or both simultaneously.
NetShow Server Components: Offer multiple configuration options, providing services for unicast, multicast, live, and stored content management, as well as sophisticated controls for developing programming scenarios based on broadcast station metaphors. Considering the range of configuration options, configuring for live unicast distribution for a signal from a NetShow Encoder is the easiest of all.
ISDN: Integrated Services Digital Network. Fast digital phone lines for the passing of MSBD or HTTP distribution data between your remote NetShow Encoder and your point of network service.
NTSC: The rules dictating the format of the video signals used throughout the United States and many other countries. PAL and SECAM are two other common formats used outside the United States.
NetShow Encoder: The workhorse at the heart of live webcasting. It can either write ASF data to a file, distribute to a server, or both.
The Basics of NetShow Services
The topography of a typical live webcast is shown in Figure 1, below. To summarize, a computer running a NetShow Encoder at the event has audio and video source feeds connected to the respective inputs on an audio/video capture card(s). The encoding machine in live mode digitizes the A/V signals, and the NetShow Encoder software compresses the data in real time for distribution through a network to a computer with Windows NT Server NetShow Services installed. Networked client machines equipped with the Windows Media Player request the data streams directly from the server through a virtual publishing point to which the stream has been assigned. The server provides numerous client management controls and reporting functions.
The majority of webcasts today are transmitted over the Internet through unicast. With unicast, the server produces an individual data stream for each player requesting the data. This is in contrast to multicast, where the data stream is transmitted only to network routers that show current requests for the data. The net result is that in a multicast scenario, only one stream leaves the Encoder, and that stream is replicated at the router level for distribution to each client so requesting—thus eliminating bottlenecks at the point of network service. While little of the actual Internet is multicast-enabled at this point, most Internet webcasts are done today through unicast. Multicast, however, is being widely adopted within closed corporate networks at a very fast pace, and it will become a real factor on the Internet in the foreseeable future.
.gif)
Figure 1:
The Live Event: An Overview
The following is a detailed account of the planning and preparation activity for one particular webcast that includes the use of Microsoft PowerPoint® presentation graphics program slides called dynamically through the stream (URL "flip"). These priorities are provided as a suggestion of the range of considerations and advance planning necessary to produce a successful webcast. You'll need to modify these steps to suit your particular schedule and needs, but allowing time for suitable preparation (particularly your first time out), system verification, and unknown circumstances is central to protecting your investment in your webcast.
High Priorities (Optimal About Six Weeks Before the Show)
Design the webcast system, indicating which machines to employ, connectivity plans, and so on.
Plan the media production itself; determine the look of the show.
Determine success factors (know ahead of time what will make this event successful and how you will measure that success—for example, through the number of hits, products sold, leads generated, and other objectives).
Assess the budget and make compromises where necessary.
Line up a company to provide Internet hosting services for the event—an ISP.
Estimate expected load on servers and infrastructure (bandwidth, communication lines, and number of hits) and either plan to restrict access to users beyond that threshold or increase capacity to accommodate traffic.
Order necessary communication lines four to six weeks in advance. The more lead time the better. Make sure to tell the phone company what you're doing so they won't schedule testing or routine maintenance during your event. Insist on clean lines. The company will need to provide all the data necessary to access the lines (SPIDS, IP addresses, phone numbers). Expect ISDN services to make a major impact on your budget. It's a good idea to order the following lines:
One dual ISDN line to carry the feed from the NetShow Encoder back to your servers.
One dual ISDN line to test with and act as a backup in case the other line goes down.
One analog line and computer to test what the feed actually looks like to your customers.
One analog phone line (or cell phone) so you can call back to your computer room in case something goes wrong.
If you are transmitting the A/V feed to NetShow Encoders at a location remote from the event, there are options to ISDN lines: satellite feeds, Vyvx lines, and (if you are just transmitting low data rate audio) plain old phone lines.
Priorities (Optimal About Four Weeks Before the Show)
Document the proposed configuration, your requirements, success factors, open items, questions, and other details.
Acquire equipment and software as necessary.
Order audio/visual services, equipment, and crew. Basically, for your NetShow Encoder you will need a line-level audio feed and a composite or S-VHS video feed. If within your budget, hire a professional crew with live broadcast and webcasting experience. Good lighting and sets will enhance the quality of the webcast images. Also, arrange to have the crew record the presentation to videotape (so you can create on-demand content later).
Plan how the Windows Media content will be accessed—through HTML pages, ASX invitations, and so on. Start designing and creating HTML pages.
If you want to use PowerPoint presentations, make design recommendations to those people creating slides. Use large fonts (prefer no more than six bullets per slide, six words or fewer per bullet) and make sure text and diagrams really stand out from the background.
If you plan on having pretaped content to show during the live broadcast, begin gathering and creating elements now: graphics, art, edited demos and promos, open segment, credits, and so on. If cutting from the live event to pretaped elements, be sure to have enough tape decks to play the material, as well as a switcher to cut from camera to tape and back. Test all feeds on-site.
Schedule a day for a dry run with your support team. This should take place approximately one week prior to the event, but it's a good idea to schedule now.
Schedule the on-site Encoder team to actually run the event. Commonly, on-site crews consist of two people. Both crew members set up before the event. During the event, one monitors the system and the other monitors the system and can act on any problems that are encountered. If URL flips and other programming is to be added to the stream, one of the crew can do it while they are monitoring the system.
Complete plans for channels and programs and how you will set up and schedule them.
Notify relevant press of your upcoming event so that they can help promote it.
Put together a list of e-mail addresses for customers, suppliers, surfers, and so on who will want to see the event. You will use this list later to invite them to "attend."
Closer to the Event (Within One to Two Weeks)
Get the PowerPoint presentations from speakers and convert to HTML pages. This will allow you to insert URL flips into the stream to make the user's browser automatically flip to these slides.
Set up, run, fully test, and verify the complete system at your shop.
Verify the NetShow server components.
Get HTML pages hosted and ready to carry Windows Media content. Be sure these pages include the PowerPoint slides you've converted to HTML.
Put codebase for preloading HTML pages of PowerPoint slides into your HTML pages.
Do a dry run with the your support team (scheduled approximately one month prior to the event). This dry run should include as much of the final system as possible (video/audio feeds, phone lines, actual NetShow Encoder machines servers, HTML pages, and so on). Evaluate performance, diagnose trouble and make suggestions to improve performance or quality levels.
Send e-mailed invitations to customers, suppliers, surfers, and so on telling them about the event and where it will be located. If needed, also tell them to connect one hour before the event so the PowerPoint slides (now HTML) can be preloaded to their system for quicker playback.
Day Before the Event
On-site crew sets up the encoding system and gets it running smoothly.
HTML pages are hosted and tested.
Communications links are tested.
Day of the Event
Ensure the audio/visual system is up and running and connected to your Encoder. If possible, set up the A/V system the day before for testing as well as prelight.
Ensure the communications lines between the Encoder and the server are tested and running smoothly.
Verify that test feeds are successfully broadcast, and that they are operating by testing over the Internet.
One Hour Prior to the Event
Have users dial into HTML page where the event will be, and start either an IP multicast to download slides to their computer, or use Pre-Load Microsoft ActiveX® controls to have it happen automatically.
Test the ISDN and communications lines again to make sure they are functioning.
If you have a tape deck and switcher, you can run a pretaped "coming up" hour loop to test the connection.
During the Event
Use a computer on the Internet to monitor what customers actually see.
Have one person monitoring the system and another person monitoring the system while inserting URL flips and programming into the stream.
Post-Event
Take video from the event and capture as an AVI.
Convert AVI files to compressed ASFs or illustrated audio presentation.
Write up a postmortem of the event to identify where things went right or wrong so next time it can run even more smoothly.
How Video Compression Works
Great video feeds don't always make the best low-bandwidth feeds for the Internet. A great deal of movement and certain effects like zooms, pans, fades, and some transitions challenge compression algorithms. A little understanding of how video compression actually works will help you shape your production for optimal results. (Also, see the section on Creating the Best Picture below.)
There are two types of compression taking place during the process: Intraframe compression and Interframe compression. Intraframe compression effects the data within a single frame, and can be compared to JPEG image compression where fields of similar colors are averaged, resulting in less data to describe the image.
Interframe compression has to do with methods of temporal compression, that is, how data is compressed across a series of frames. During the compression process, the codec generates two types of image frames: I-frames (index) and delta frames. I-frames (also known as key frames) are fully rendered representations of an image, and are generated at an interval set at the NetShow Encoder (typically one I-frame every eight seconds). However, the NetShow Encoder automatically generates data-intensive I-frames whenever it detects more than a 30 percent change in the pixels between any two frames. In Figure 2, there are at least seven scene changes in about seven seconds. So seven key frames—or complete redraws of the frame—are required to render the short sequence. This taxes the encoding algorithms, particularly when encoding to low data rates, and the net result is a sacrifice in frame rate and the accompanying smoothness of motion.
.gif)
Figure 2:
Conversely, Delta frames, which describe only the changes between the previous key frame and the new frame, are inherently less data-intensive. When less than 30 percent of the pixels in a frame change, P frames are drawn instead of having to redraw the entire frame. With less data in a P frame, they are smaller than key frames and more easily rendered by the Encoder at the intended rate. In Figure 3, the changes between the frames are slight. So in a similar time frame, only two key frames would be required instead of seven above, and we would therefore be able to reproduce the existing movement in the image more convincingly.
.gif)
Figure 3:
What does this mean to you? By adhering to certain guidelines during the shoot (see below), you can take some measure in shooting your event to provide for source signals that are of a quality that is much more suitable to low data rate compression.
Creating the Best Picture
In most scenarios today, webcasts are driven by the events they cover (rather than events being staged specifically for webcast). So you could be confronted with any number of circumstances when planning for A/V services. You may be budgeted to supply A/V services specifically to webcast the event, in which case you would be in a position to exercise a certain amount of influence over the style of shooting. Or you simply may be piggybacking on an existing A/V service that has been contracted to video the event for tape or broadcast. In this latter case, you may have zero influence to determine the appropriateness of the video shoot for your purposes. It would still be wise to attempt to convey the following recommendations to the director and A/V crew since making great live video doesn't always translate into making great compressed presentations on the Internet.
Creating Simple Video
Because of the degree of interframe change associated with certain transitions, long fades, zooms, and pans can make compressing more difficult to low-bandwidth data rates. Also, the quick cutting and manic camera movements typical in music videos are entirely inappropriate for streaming on the Internet. Understand that this is a common shooting style and communicating your needs for discreet camera movement and other recommendations to the director may contradict his or her creative intentions for the shoot. If you have the input, seek a compromise.
Minimize Camera Movement
Always try to mount the camera on a tripod. Shooting the camera in hand-held style always creates slight movement that makes each pixel in the shot change, increasing the key frames. The result is fewer frames per second and lower resolution images.
Framing Video Images with Still Backgrounds
It's imperative to minimize movement in your shots. For example, trees rustling in the background may make beautiful video, but will create change in the video when compressed, resulting in more key frames or bigger P frames, and lower resolution and frame rates. While intricate nonmoving backgrounds translate well, solid backgrounds improve the actual picture quality. Darker colors and black compress the best for low-bandwidth data rates.
Separating the Subject from the Background
Separation needs to be greatly exaggerated. It's easy to lose the talent in the background with improper lighting (see below). Flesh tones in the background also tend to muddy up the look of the picture. As far as attire, solids are best for optimal picture quality. Avoid patterns, white, red, orange, and colors similar to the background color.
Stress Good Lighting
Use bold lighting that emphasizes contrasts between dark and light elements in the picture. After compression, higher-contrast content just looks better. Many video directors have determined that when shooting for webcast, they can shoot with the apertures on their cameras open overly wide. This provides the NetShow Encoder with an overly bright picture that can encode optimally when the scene is not brightly enough lit. For example, faces hitting 80 IRE and even up to 90 IRE look good (0 IRE is black/100 IRE is white). Anything lower than 80 IRE appeared murky when encoded. With background lighting, low lighting and high levels look good, while medium levels display higher amounts of dithering.
If Using Graphic Elements, Make Them Big
There are any number of ways to deliver text and graphics through the ASF stream: as a URL calls to html pages rendered to a frame in the page, or as text data sent synchronously within the stream itself, it is rendered into the page through dynamic html. NetShow Services also work closely with PowerPoint to allow you great options in presenting those presentations both live and on-demand. However, if you must use graphic elements directly in a low data rate video image itself, make sure that logos, credits, names, keys, and graphics are big and blocky and fill enough of the screen to be legible.
Avoid Extreme Close-Up Shots when Videotaping People
If the face fills most of the shot, movement will occur effecting the entire frame even when the person simply speaks changes expressions or moves his or her head even slightly. Thus, more key frames or bigger P frames are required, lowering quality and frame rate. If possible, frame the person's head and shoulders from about waist-up, where the principle subject assumes approximately 50 percent of the frame area. You will be much more successful in creating smooth motion; in shots such as these, this pays off in a tight synchronization of speech and mouth movement.
Work with Your Video Crew to Produce the Best Signal
If possible, show the video crew the signal being produced by your NetShow Encoder during setup. If the shoot is for Internet streaming only, this allows a video crew to reference the encoded image when setting lighting, exposure, white points, and so on for optimal webcast picture quality. If the crew is also shooting for tape or broadcast that will be otherwise distributed, they will need to calibrate their pictures while referencing an NTSC video monitor, this being an ideal representation of the ultimate delivery mechanism. But if you are shooting expressly for video, use an encoded signal as reference when setting up your shots.
The above issues concerning producing video specifically for Web delivery creates an opportunity for Internet Service Providers to shape new service packages around new pricing structures. For basic webcast events, current transmission bandwidths may minimize the need for the more costly services of traditional video companies (skilled lighting design, digital cameras, high-quality switchers, direction and camera work, fully conforming broadcast-quality video, and so on). While quality should always be stressed, many ISPs may be able to provide their own audio and video services specifically tailored for webcast. There are instances in which a single camera focused on a well-lit, interesting subject can itself constitute compelling Web content. Reasonably priced, good-quality webcasts are possible with recent industry developments: the release of digital three-chip video cameras producing extraordinarily high-quality signals; the developments of IEEE Standard 1394; and the extremely low prices of small, portable video switchers and audio mixers. It becomes a very real proposition that two people (or even one very savvy specialist) with a trunk load of gear can arrive at a site and produce and deliver content for webcast delivery at a fraction of the cost of a broadcast-style video crew. Carefully consider what you need when contracting A/V services specifically for webcast.
This is not to diminish the importance of broadcast-quality, professional A/V services. For complex or highly invested webcasts, the experience and equipment of traditional A/V services may be more appropriate and provide certain assurances you might not otherwise be able to provide—while containing costs.
All About the NetShow Encoder
The NetShow Encoder is installed on the machine that takes the audio and video signals, digitizes and compresses them, and provides them to the NetShow server for distribution. The Encoder is the main workhorse of the NetShow tools. Compressing live audio and video in real time is an extraordinarily processor-intensive task. The NetShow Encoder should be on your beefiest machine, and should be solely configured and dedicated to this task. No unnecessary services or programs should be running while this machine is operating. If you're running your NetShow Encoder on the Microsoft Windows NT® operating system, you should keep a close eye on your CPU usage. The Encoder will react to a maxxed-out CPU by dropping video data and producing less-than-optimal signals.
Keep in mind that the higher the encoding data rate, the higher the processor requirements. So, if you're encoding video targeted for 56-Kbps ISDN consumption or higher, you should take the following recommendations quite seriously. Well before the event, thoroughly test and verify whatever machine you use for reliable encoding capabilities to your target data type and data rate. Summarized below are the baseline NetShow Encoder configuration requirements for various encoding duties for the NetShow Encoder:
Live, Single stream, 28.8 Kbps video:
Pentium 200 MHz
Live, Scalable Video, 28.8Kbps, 56Kbps:
Minimum: Pentium II 266 MHz; Recommended: Dual Pentium II 233 MHz or DEC Alpha 533 MHz
Live, high data rate; 320 x 240 pixels, 15 frames per second (fps), 100Kbps – 1 Mbps
Dual Pentium II 233+ MHz, DEC Alpha 533 MHz
Note how the requirements scale upwards as the processing data rate climbs. Note also the demands required to create scaled video. The following provides information on the components:
CPU
The NetShow Encoder software takes particular advantage of Intel MMX technology. If you can't dedicate a dual-processor machine with the muscle described here, at least attempt to configure a NetShow Encoder with a Pentium MMX chip. Another point on a dual processor machine is that the often-recommended MPEG 4 v.2 video codec is multithreaded and can take advantage of the multiple processors. The result is higher-quality encoding for your webcast.
64 MB of RAM
The Encoder is not memory-intensive if the CPU is performing well, so you can get by with 64 MB of RAM or go to 128 MB of RAM for more demanding applications.
Audio/Video Capture Card
Refer to the list of compatible audio/video capture cards that work with NetShow tools listed on our Web site: https://www.microsoft.com/NTServer/techresources/streaming/default.asp. In most cases, we highly recommend a merged audio/video card. We also strongly recommend disabling the on-board card and configuring a machine with the stand-alone audio/video card. We have found success using the Osprey 100 and Winnov Videum. The ATI All-In-Wonder and Intel Smart Video Recorder 3 are great video-only cards.
Microsoft Windows® 98 or 95 OSR2 or Windows NT Workstation 4.0
Both of operating systems are stable platforms for encoding Windows Media content. However, you'll need to run Windows NT to use the dual processor capabilities. For the Encoder, the selection depends on your preference and audio/video capture card choice. (Not all capture cards provide drives for both platforms.
NetShow Encoder Software
Download the latest version of NetShow Streaming Media Services at https://www.microsoft.com/NTServer/techresources/streaming/default.asp
Communications Device Back to the Server
For example, you need an ISDN modem (like Digi DataFile-U, the Motorola BitSurfer, or US Robotics Sportster) or router to connect back to the NetShow server services over an ISDN line, or a suitable network adapter for connection over a LAN. This selection will more than likely be based upon the needs of your ISP. We cannot overemphasize the importance of verifying the integrity of your connection to your server, particularly if you are connecting over ISDN. All the preparation in the world is useless if your Encoder and server fail to connect.
At the Event: Interfacing with A/V, Configuring the Encoder, Connectivity to the Server
Assuming you do not have access to broadcast-style satellite transmission and uplink facilities (and who does but broadcasters), you'll be schlepping at least one computer to your event location and encoding your webcast on-site. When planning for your event, realize that the NetShow Services and your task of encoding the video and audio signals represent only the nucleus of your broader concerns. While we have discussed the importance of working out details with your A/V provider, this section will discuss the physical aspect of that interface. We'll also look at the vital matter of server connectivity.
Nuts and Bolts: Setting up and Interfacing with A/V Services
You'll need two media feeds from your A/V service: the audio and video signals delivered over separate cables. Set your encoding station up anywhere in or around the facility—even outside in a tent, say, if that's your best access. But you must be in a location where the A/V crew can cable you these two signals. You also need to be accessible to your ISDN service terminus. Ideally, however, you should attempt to set up your station at or near the location of the video switcher and audio mixer to put you in voice-communications proximity with these services.
It's important to arrive early at the venue and to come into contact with the A/V provider as soon as possible. Just as they will be testing and tweaking their signal and setting their levels, you too should spend this time in verifying the integrity of your feeds. Do not assume the video crew has ever dealt with this webcast interface before. Because of this, it's vital for you to bring the proper connectors to plug into the audio and video inputs on your cards since the crew may not have these connectors.
Plugging In: Video
Even the lowest-end video cards provide at least two types of video inputs: composite video (an RCA input, probably yellow) and an S-Video input (a round input with multiple pins). S-Video is usually regarded as preferred but it's more likely you'll be presented with a composite video jack as your source. This is fine for our purposes. Since you've assumed the video crew has never interfaced with a computer before, you've arrived at the venue with the appropriate cable adapters for video: a BNC to RCA adapter. This adapts the familiar coaxial cable you'll likely be presented with to the composite video input on your video card. Very expensive productions have been shut down during preparations while a tech runs to an electrical store for lack of this two-bit little chunk of metal.
After plugging in, verify the video signal presence at the input on your card by launching any capture program or similar device that installs with your video card drivers. Simply launching the capture application should automatically display the video image present at the input (in the case of the Winnov Videum card, this is the Videum Capture utility). If you are not seeing the image, select Video Source from the Capture menu (or similar control), which provokes a dialog (see Figure 4).
.gif)
Figure 4: Video Source Settings Dialog Box
Ensure the Video Source is selected appropriately (composite or S-Video). This dialog also appears in the NetShow Encoder (Edit>Video). If you're not seeing your signal, you probably have the wrong source. If you're still not seeing your video, ask the A/V crew to test the feed through one of their monitors to verify its presence to the cable.
Take note that when you're viewing your image in this capture utility (or similar application), what you see is as it appears at your video input. This is the data the NetShow Encoder will be compressing. Take this opportunity to evaluate the image quality being supplied by your A/V service compared to the image shown on the A/V crew's monitors. Your image should be similar in sharpness, color integrity, brightness, and contrast. If not, there's an extreme likelihood you're receiving a bad video feed. Bring this to the attention of the A/V crew. The image they supply should be as clean and full fidelity as the image recording to tape. Don't expect the motion in your preview to be as fluid as that in the monitors since your machine probably can't reproduce similar motion at these preview data rates. However, the quality of the image itself should be similarly sharp and crisp. To view the compressed video after you have configured the NetShow Encoder, you can verify the signal by using the video preview button on the front panel of the NetShow Encoder. Again, this encoded signal makes an excellent reference when setting up your staging, lighting, and camera positions for the webcast.
Plugging In: Audio
Unlikely as it seems, audio presents more variables than video when connecting to a computer. While connecting video, the signal's presence and integrity are your main issues. With audio, you must deal with the variable of levels (loudness of the signal) to optimize the quality of your webcast signal.
One important variable often overlooked when interfacing your NetShow Encoder with traditional A/V equipment is how a computer reads audio levels. The audio level regarded as a peak zero level (the loudest a signal should be allowed to get) in professional A/V equipment is substantially higher than the level the audio input on your computer regards as a peak zero level. Audio intensity is measured in dB (decibels), measured on a negative scale with zero at the top representing full saturation. Signals peaking above this value will distort the signal, sometimes called clipping. A zero peak reading on a professional audio board is an actual electrical energy level of +4 dB, while your soundcard input regards a peak zero signal as having an intensity level of -10 dB. More useful knowledge is that professional audio is carried on a circuit comprised of three connectors (negative and positive signal wires plus a grounded shield) called a balanced circuit. The audio signals on the computer's soundcard input are of the unbalanced variety, where the signal is carried over just two connectors.
What this means is that on location, you must be equipped with a means to "step-down" and adapt the audio signal coming from the sound board to your sound card with a simple external hardware devise as described below. A second important note is that you should not expect the A/V crew to come prepared with the cable adapters to accommodate the input at your sound card. This input requires a stereo, 1/8" mini-jack in most cards. As common as this connector may be for you, it's never used in professional A/V equipment.
While not necessarily the simplest way, the best possible practice in this scenario is to come prepared with a small audio mixing board to handle the interface between the A/V equipment and your Encoder. The Mackie model 1202 is a startlingly affordable, extremely compact, remarkably versatile piece of equipment that provides you with all the control over your audio signal you'll need. Gain controls (volume) at the input allow you to attenuate the signal to your needs, and unbalanced outputs can be sent to the soundcard. The trim pots also provide level meters and a hardware means to control your audio level to the computer, which is highly preferred to the less-than-convenient software controls. This also eliminates your reliance on the A/V crew to provide you signals at a fairly consistent level.
Alternatively, you may use any of a number of inexpensive attenuation devices (available at Radio Shack and elsewhere) made solely to match audio levels between +4 dB and -10 dB devices. Typically these will have a female three-pin XLR input on one end for the signal from the audio board (the A/V crew certainly should be able to provide this connection) and an unbalanced output. Arrive at the venue with at least this simple step-down device and a cable adapted to run from its output to the input on your sound card in case the A/V crew cannot provide these essentials.
Setting Audio Levels: Worth Getting Right
Use an accurate software audio meter to get the best reading of the audio level coming into your computer. A small audio meter installs into the Windows Recording Control panel with the drivers for some audio devices. However, this meter is not scored and is imprecise and inadequate for accurate level control. The drivers installed with some media cards provide levels modules with better meters. The "Vidium Configure" control device installs with the Winnov cards in one such device. Good audio meters can also be found in audio editing applications like Sonic Foundry Sound Forge and CoolEdit.
Whatever audio meter device you use, your levels need to be set sufficiently high—but not so high as to introduce clipping in your signal. In other words, set your levels to disallow signals peaking to or above zero dB on your audio meter. One good idea is to synchronize audio levels with the A/V audio board source by requesting that a tone be sent through the line at a -3 dB level. You can then set your level controls to show this same -3 dB reading to this tone on the audio meter. To some degree, you can then allow the A/V sound operator to handle audio levels (if you trust him to ride his level accurately). Similarly, if you brought your own audio board, you could synchronize all of the audio devices in the signal path.
You also should talk to the sound engineer about how he's processing the sound. For instance, he may have installed a limiter in the signal path that attenuates a signal level above a certain peak. This is good situation because it allows you to set your recording level sufficiently high without the fear of confronting unexpected peaks in the input level. Also, he may have introduced a low frequency equalization roll-off, attenuating the lowest tones below 75 Hz. This is a good practice, especially when producing audio for low-bandwidth compression. This feature—available on the Mackie board discussed above—should be used as a matter of practice. One more point: if the audio engineer has applied a "reverb" effect to the audio signal for a PA system, ask for a "dry" signal that shows none of this effect. These types of effects do not compress well to the lowest data rates.
This discussion further illustrates the importance of developing an early, cooperative relationship with the A/V crew, and the importance of arriving early at the venue to run your setup and verification procedures in conjunction with the A/V crew. We also have emphasized being prepared. Become familiar with your equipment well in advance, particularly the Play and Record Control dialog boxes in Windows. Don't find yourself stymied by one issue or another at the venue, especially when a little advanced practice and verification of your systems may save you the grief of not having complete control over your systems as showtime approaches.
Configuring the NetShow Encoder
.gif)
Figure 6:
Configuring your NetShow Encoder is central to setting up your webcast. (See Appendix 1 for Encoder Setup Overview.) Based on the content you'll be encoding at the event, you should know well before arriving at the event exactly how you'll configure your Encoder. Use the sufficient documentation on how to configure the Encoder both in the Encoder help files and in the NetShow Services Product Documentation that installs with the NetShow tools; or download it from the Windows NT Server Web site: https://www.microsoft.com/NTServer/techresources/streaming/default.asp. Many concerns in setting up your Encoder are the same as those for creating on-demand content, including choice of codecs, frame rate, image size, and so on. In addition to setting your compression parameters, you'll need to select the source of your audio and video signals (the audio and video cards) and the software port destination of the encoded stream.
Your choice of compression parameters and codecs is contingent upon the type of material you're encoding. For instance, your choice of audio codecs is different if you're encoding spoken words than if your content contains music. Music has an inherently more complex aural structure and does not convey as well as voice alone to the low data rate codecs. Also, the video encoding parameters and codec you select are contingent upon the amount of movement or action you'll expect in your frames.
Audio and video codecs also need to be considered in tandem. For example, voice-only audio converts quite well to some lower-rate audio codecs like the ACELP.net 5kb/s codec, which consumes only 5 Kbps of your target data rate. Using these limited data rate codecs for voice-only material actually provides for a better video image because less of the combined bandwidth is consumed by the audio content, allowing the Encoder to encode video data to a higher percentage of your aggregate stream. The result: richer video. For encoding music to Windows Media content, the codec choice is easy. The Voxware Metasound codec encodes music content exceptionally well to as low as 6kb/s. ACELP.net is best for voice to the lowest data rates, and either if these plus the MPEG Layer 3 audio codec encode most type of content quite well at audio data rates from 16kb/s and up. Use your personal preference. For practically all video applications up to 1Mb/s, the MPEG 4 v.2 codec, newly improved for streaming media services, is the default choice.
For more information on the codecs and their various characteristics, see the very thorough discussion contained in the NetShow Services Content Creation Guide on the Windows NT Server Web site. For further help in configuring the Encoder, see the NetShow Product Documentation in the NetShow Services program group.
The NetShow Encoder provides for extremely easy setup from pretailored presets. For easy Encoder setup, select Quick Start after selecting File>New from the main Encoder panel to see a dialog box with a list of factory presents and simple descriptions of each, shown below.
.gif)
Figure 7:
In this mode, the NetShow Encoder automatically selects your default capture devices, and assigns a live stream to a default port, which is displayed on the front panel when running. You also can select a template with I/O options or choose custom settings to expose all configuration options. Whichever option you select, the object here is to load the appropriate settings into the Encoder so it will input from your capture card, compress a stream optimally to the correct bandwidth, use the audio and video codecs you want, and output the media to the right file or network address. You can save your settings (if not using one of the presets) when the Encoder is off by selecting File>Save to store your settings to an .asd file. Double-clicking this file will then launch the Encoder again, preconfigured to your specification.
One Last Tweak: Verifying and Fine-Tuning the Video Signal from the Encoder
Once you've established connectivity to your video and audio sources and configured your NetShow Encoder, take a look at the final Encoder, verify its integrity, and take an opportunity to possibly add one more level of improvement to the encoded signal. To view the encoded signal from the Encoder itself, launch the video preview window from the button on the front Encoder panel.
This brings up the encoded image in the NetShow Encoder preview window as it's coming from the Encoder, and provides an excellent end user reference signal.
It's useful to assess your image quality at this point. For instance, under some circumstances such as shooting low-contrast images or insufficiently lit subjects, you can tweak the brightness and contrast settings to your video card to improve your final encoded output. A typical dialog for doing this is shown in Plugging In: Video. (See Figure 4.) Access this dialog from the Encoder by selecting Encode>Video Capture Settings from the Encoder front panel. Note that this dialog cannot be accessed while your Encoder is running.
Brightness and contrast correction is kind of a half-blind process: view and assess the encoded image, stop the Encoder, open the control, make brightness and contrast adjustment (of only a few points in any direction), close the control, reinitiate encoding, view the image in the Windows Media Player, and assess and readjust as necessary. Be aware that you can do as much harm as good with these controls. If, for instance, the brightness control was set unusually low at your encoding monitor, compensation to produce what you regard as a suitable signal may indeed transmit to your viewers inordinately bright. So only consider using these controls if you are confident with their functionality and correction is clearly warranted.
In a final step, after initiating your stream to your server (covered in the next section), it's useful to verify your signal on the Web from a separate machine with network access. This, of course, is to verify that your server is delivering as expected, and to view your final content as your viewers will see it. This seems an obvious point, but if you don't take the opportunity to see it, you won't really know that it's out there. This process reveals potential errors or problems stemming, say, from an error in configuring the server, and should be accomplished in plenty of time to provide for correction. This also implies the need for access to a Plain Old Telephone (POTS) and an activated account with an ISP. Provision of a line explicitly for this purpose should be part of your overall preparedness plan.
The MSBD Connection: Connectivity Between the NetShow Encoder and NetShow Server components
With regard to the connectivity of your remote Encoder with your point of service (a LAN or Web-enabled server running NetShow Services), there are several potential scenarios. The most opportune and easiest is live webcasting through your corporate intranet. For our purposes, however, we'll continue with our Internet scenario focused on deploying a live webcast and interfacing from a remote to an Internet Service Provider. In this case, the most common solution for reliable connection to your Network Services is through ISDN.
ISDN stands for Integrated Services Digital Network. Following are straightforward recommendations on your remote Encoder's connection to its point of service. Nowhere in the production chain we've described is a connection more sacrosanct, yet fraught with inconsistencies and potential for failure. If this hookup goes down or data is stalled or interrupted in transit, all your other expense and preparation is for naught.
If you have any serious investment in the staging and promotion of your live Web event, the nature of this connection can only be of one type: a point-to point, dedicated bandwidth, Dial-Up AMI (Alternate Mark Inversion) or BRI (Basic Rate Interface), 128 Kbps and 112 Kbps respectively, dual-channel ISDN connection. If you're planning an event from an oversight level and don't know what that means, find someone who does. In summary: It's a big phone call that will definitely appear in your project budget.
For computer systems folks just coming online with ISDN, welcome to the club. Few computer systems engineers have come into enough practical contact with ISDN to develop any real expertise. A confident understanding and command of the parameters of ISDN add substantially to the assurance of success for any webcast, and would be a requirement on any highly leveraged webcast project.
ISDN modems—as set up and addressed through Dial-Up Networking—are not inherently difficult. What are difficult are the variables in service provision from LEC to LEC (Local Exchange Carriers). Variance in service provisions creates potential for misunderstanding and difficulties in establishing connectivity.
Use of SPID syntax (Service Provider Identifications) is inconsistent between providers. Temporary service, as typically employed in webcasting, is often installed or provisioned incorrectly.
Because of these variables and inconsistencies of ISDN service, we recommend planning and testing your connectivity on a clearly planned schedule, as mentioned in The Live Event: An Overview. The basic rule is this: Order ISDN installation both to the venue as well as at your point of Internet service in plenty of time to provide for a thorough testing opportunity. The testing must be scheduled in time to provide for problem resolution, which may involve your ISP. We are aware that this is an ideal scenario, so have a plan to control the variables if these recommendations cannot be met.
There are objections to this strident insistence for dedicated bandwidth between the NetShow Encoder and the NetShow server, because of the particular expense involved. Clearly if you have existing Web servers running, all sitting on the World Wide Web with plenty of pipe to spare, why invest in more bandwidth? Well, the MSBD stream between your Encoder and your server is your "master" signal, the signal from which all other duplicates will be derived. You may assume the risk of commingling your MSBD data with Internet TCP traffic to whatever level you'd like. But it's inherently a bad idea to mix up streaming media distribution traffic with "bursty" TCP traffic since you cannot necessarily expect them to coexist in absolute harmony in unpredictable or oversubscribed traffic conditions. Any potential for the introduction of latency into the MSBD stream needs to be avoided: In a worst-case scenario, extraordinary data latency in the MSBD stream can result in timeout errors on the server side—not pretty.
Two scenarios exist where running the MSBD stream over the Internet might be acceptable. Service providers have described trunk-level connectivity paths that provide them adequate assurance of MSBD stream integrity. You may well be in a position to accurately assess the connectivity path for the MSBD signal and arrive at a similar conclusion, provided you have an assumption of the balance of risk. The nature of and investment in the webcast production also come into play. You can establish an MSBD stream between two 28.8-Kbps modems running on the Internet, and if you're insistent about just plain getting live content up on the Internet, then use what you've got and get your material live! Also, if the intention of your first live webcast is experimental in nature, or if the purpose is to establish a "proof of concept," then exercising cost containment is certainly in your interest. But if you've invested to any degree in your webcast, weigh carefully the decision on the integrity of your MSBD distribution connection against the consequences of failure.
A Bit About The NetShow Server components
Concerning connecting from Encoder to server, the connection is established between the two computers using Windows Dial-Up Networking. Therefore Remote Access Service (RAS) must be running and configured correctly at the server running NetShow Services. The dial-up connection is initiated from the Encoder side. Once the connection is open, the MSBD request is made from the server to the Encoder. The server is asking for the Encoder's output as the data source from which to service multicast or unicast client requests made to the server for the streaming media content. Server configuration is discussed in detail in the Product Documentation for NetShow Services.
A variety of server configuration and distribution scenarios exist to provide for various service capabilities, including multicast and unicast. Since our discussion is focused on delivery of live Windows Media content over the Internet, your primary concerns for server configuration pertain to unicast.
Server configuration becomes particularly straightforward if you're not distributing service any further than this one machine. And you can service a substantial number of concurrent streams from one well-equipped server, well over 1,000 on some configurations. When calculating your service requirements, your most pertinent questions pertain specifically toward anticipated aggregate bandwidth requirements.
Calculating Estimated Capacity Requirements
We all hope for wildly successful and popular webcast events. But when planning live events, many people are actually afraid their events will be too successful. So, start early in planning by estimating the number of people who will access your site and its streaming media content at any given time. These numbers are related to how much effort and investment have gone on in advance of your webcast, as well as associated linkages you have arranged to your event. Some numbers to keep in mind:
Type of Connection |
Total Bandwidth |
Maximum Number of Concurrent 28.8 Kbps Streams |
|---|---|---|
T-1 |
1.5 Mbps |
52 |
T-3 or DS-3 |
45 Mbps |
1,562 |
You can derive from these numbers that if you expect a successful event with several hundred concurrent streams, you will require bandwidth equal to multiple T-1 lines for adequate service. If you expect your event will be a real chart-topper with several thousand concurrent viewers, your service requirements will be equivalent to multiple T-3 lines. You probably don't have that kind of connectivity lying about in your supply room. Rest assured, a growing number of dedicated specialty Internet Service Providers, who are experts in providing streaming media services, are able to provide you with all the streaming media bandwidth you need—for a price, of course. Refer to the list of experienced, qualified NetShow Service Providers at: https://www.microsoft.com/ntserver/partners/becomepart/certpart/PartnerSolutions.asp.
Another useful point when thinking about bandwidth requirements for a webcast is that it's typical for people to overestimate the number of concurrent connections they may expect. Internet users are an extremely fickle bunch with relatively short attention spans. Depending upon the event, server logs from webcasts typically show a substantial divergence between the total number of views to an event and the peak aggregate viewers present at any one time. It's this last number you should consider when calculating your bandwidth needs.
Optimizing the Distribution System for Worldwide and Internal Intranet Performance
One of great things about the NetShow Services is the way it accommodates any level of service options and distribution configurations. If you expect a huge amount of traffic to your webcast, you can add additional servers to load-balance the NetShow Services. Similarly, if you anticipate a large audience within a company with firewalls, to ease bandwidth controls you can place a server running NetShow Services within that company and redistribute the streaming data company-wide using multicast. This is becoming a rather common scenario, used within corporations for the internal viewing of important company functions or announcements.
Summary
In reading this document, hopefully you have concluded that successful live webcast events are rooted in precise planning, preparation, systems testing and verification, and an overall understanding of the many variables involved.
Few ambitions could be described as more interdisciplinary than live webcasting. Of course, that can be said of many pursuits in Web content development. Yet nowhere else do the principles of broadcast production and engineering, telephony, and computer systems and network administration become so interrelational. Few individuals hold levels of expertise across such a diverse range of disciplines, so webcasting inherently is a team effort. Input and expertise come from a number of players from your organization.
Conversely, if this document has convinced you that live webcasting is just too big and expensive an effort, then we've failed to a large degree. To cover all the bases, we've stitched our story around the steps to plan and execute what might be regarded as a full-blown commercial Internet webcast event. However, Webcasting with Windows NT Server NetShow Services in is nothing if not enabling. Any individual's capability to point a camera on a subject, encode a stream, and spin that stream off to an Internet server with NetShow Services installed, is based upon his or her ability to comprehend and execute the steps we've described in this document. Good luck.
Appendix: Additional Resources
NetShow Content Creation Authoring Guide
In Microsoft TechNet or at https://msdn.microsoft.com/workshop/imedia/windowsmedia/default.asp
NetShow Services FAQ
Check to see if your issue is answered in the frequently asked questions guide at https://msdn.microsoft.com/workshop/imedia/windowsmedia/default.asp
Newsgroup
Microsoft.Public.NetShow
A discussion group for all versions of NetShow Streaming Media Services
ASF Information
For more details on the Advanced Streaming Format, go to https://www.microsoft.com/asf
Calendar of Events and Samples
For the schedule of live events, live and ongoing audio/video, on-demand events/content and samples that use NetShow Services, go to https://www.microsoft.com/windows/windowsmedia/press.aspx.
Mailing List (Listserv)
To subscribe to the NetShow Mailing List, follow the appropriate instructions:
To Subscribe |
To Unsubscribe |
|---|---|
E-mail to: Listserv@listserv.msn.com |
E-mail to: Listserv@listserv.msn.com |
Note: Users of MSN™, The Microsoft Network, will need to send their e-mails to Listserv@Microsoft.ease.lsoft.com instead of the standard address. |
|
For More Information
For the latest information on NetShow Streaming Media Services, check out Microsoft TechNet or our World Wide Web site at https://www.microsoft.com/NTServer/techresources/streaming/default.asp.