Streaming TRV900 Footage

by Dave Millman (dave at tactics com)
June 28, 2001

We tried several tools and techniques on the way to getting good quality streaming video. In the end, we identified four objectives:

    1. We would try to accommodate users on all connection speeds
    2. We would devote as much encoding time as necessary to get good results
    3. We would deliver via RealVideo, then add Windows Media if required
    4. We would outsource hosting with a streaming provider

Objectives 1 & 2 drove evaluation of several tools, and the eventual purchase of Media Cleaner 5. This amazing product gives a patient user the tools to create stunning quality streaming video.

Objective 2 helped drive the purchase of a new 1.3GHz P4 dedicated to video editing and encoding. The P4 with its 400MHz memory bus only beats a similarly-clocked PIII in a few areas, but video processing is one of them. We're seeing substantially greater speed-up factors between this machine and its predecessor (a 550 MHz PIII) than the 2.5x clock rate increase would indicate.

Setting Objective 3 was easy. I asked 12 people who would be our typical viewers what video format they preferred on the web. Four said video didn't work too well for them, seven said RealVideo, one said Windows Media.

Objective 4 was a simple matter of mathematics. If our in-house servers are connected to the Internet via a 384 Kbps link, that says we can host a maximum of one 300 Kbps stream, or a couple of simultaneous 100 Kbps streams, assuming no other demands on the server or the network. We wanted to be able to conduct presentations with 3-5 simultaneous remote locations, regardless of their connection speed. So we host with Playstream.com.

Some of the technical details:

Streaming video requires you to think about and allocate total available bandwidth among your audio and video. If you are creating a 300 Kbps stream for a 384Mbps DSL user, you can allocate 32 Kbps to audio and have plenty of bandwidth left for video. But if you are targeting a 25 Kbps stream for a 33 Kbps modem user, then you need to scale back.

We toyed around with 120x90 and 240x180 images. But we discovered that if we used Cleaner to its fullest capability, we could deliver 320x240 even to modem users. The fact that our material is talking-heads interviews helps-this type of material compresses very well.

The RealVideo SureStream format allows the encoding of up to 8 streams in one file. You choose the audio and video bandwidth for each stream. We chose these settings, closely following the program's recommendations:

For 28,8Kbps modems: 12Kbps total, 6.5Kpbs audio
For 56Kbps modem: 31 Kbps total, 8.5 Kpbs audio
For single ISDN: 34Kbps total, 8.5Kpbs audio
For dual ISDN: 58 Kbps total, 16Kpbs audio
For low broadband: 68 Kbps total, 15Kpbs audio
For mid broadband: 236 Kbps total, 32Kpbs audio
For high broadband: 404Kbps total, 32Kpbs audio

Note that we always dedicated more than its fair share of total bandwidth to the audio, since that's where all the information is in a talking head. All audio tracks are mono.

After reading the Cleaner manual (which is the best primer on video encoding I've found anywhere), we realized the advantages of their Static Mask feature. This allows you to indicate an area which does not change throughout the video, and thus does not need to be continuously encoded. All the bandwidth which would have been wasted encoding this non-changing area is redirected to your important audio and video. Even if your material is more dynamic than a talking head, if you can mask off 10% of the image as static, you can allocate all that extra bandwidth to audio or subtly improve the rest of the video.

Finally, we tested various combinations of these features, which take extra processing time but each improve the final result:

* Automatic, adaptive deinterlacing (not necessary if you shoot progressive scan)
* Adaptive (video) noise reduction with temporal processing:
  this looks for random bits changing, and changes them back if it thinks they
  are noise rather than data. CPU intensive magic.
* Audio dynamic range limiter

In practice, a 30-second DV clip takes about 10 minutes to encode on the P4 with the settings above. We tested Variable Bit Rate encoding, which takes almost twice as long to run two passes through the video to identify more compression possibilities, but did not see any higher quality on our material. Your mileage may vary.

Finally, PlayStream (http://www.playstream.com) seemed to be focused on customers just like us: low volume business streaming sites. Their rates are quite reasonable, and their performance seems to be good. But we have only had one month of service so far, and have only streamed a few hundred megabytes of data. They offer a pay-per-view option that I'd love to figure out how to make some money with, but nobody's going to pay 5 cents to see what we're showing now!

That's what we've learned to date. Comments welcomed.

Back to main DV page.