Shooting video for the web

Dear CML'ers:

I've got a video shoot coming up -with my D-30 shooting Beta SP - a sort of behind the scenes on a national show that will end up on their web site. We are going to be shooting on their sets with control of their lighting, so I don't think level will be a problem. Do I need to have any special concerns since the footage is destined for the Web? I usually like to kill the set washes when I'm shooting on a network set since this slightly increases the ratio. However if I gain contrast on the way to the Internet, perhaps I shouldn't do this. Thanks in advance for any advice.

Marty Mullin

Los Angeles

>Do I need to have any special concerns since the footage is destined for the Web?

Most video for the web goes through the cuisinart of outrageous compression and color degradation. Expect that pretty much all subtleties will disappear.

If the client has anything up on the web currently, study that and ask them if they plan on using the same methods for your footage.

Try to get in contact with whomever will be processing your footage, and see what they have to say, and see if they have any samples of their methods available online.

Bob Kertesz

BlueScreen LLC

For details, visit > http://www.bluescreen.com

As a reference you might want to go to a site like www.ifilm.com and see what things look like delivered via the Web. One of the things I've had to remind people of when we shoot for CD/Web delivery is that your video *will* be compressed (ick) and you don't have a very large viewing area so small details can get lost in big wide shots. I tend to keep it fairly tight for the stuff that I shoot.

--Thaddeus O. Cooper

Sr. Computer Scientist/Software Developer | Beginning Camera Op.| Ex-IATSE Local636 | General

I would suggest keeping both camera and subject movement to a minimum. Most compression schemes for readying video to stream on the web seem to like static shots that introduce little new information. Less is more!

Barnaby Kerr

Madison, WI

If you use something like Media Cleaner, it can be used to pump up the contrast and sharpness as it compresses. I would say the only thing that can hose you is the fact that you will be dropping down to 12-15 fps (to save on size)... that means any shaky-cam will could manifest itself in highly-pixelated web movies. The more stable the shot, the more flat the backgrounds, the better the compression. In fact the web is the ONE place where "talking heads" are preferred, just for the sake of clean compression.

Also, if you can, try to use Sorenson as the codec. It will restrict compatibility to those with QuickTime 4 or 5, but it looks the best.

Jason Ahles

Bob's advice is good. I would just add that you want to keep the movement to a minimum so avoid camera shakes, zooms, etc, as much as you can. The more frame changes there are the harder it is to stream the video - unless, of course, you have broadband ;-)

They will probably put your footage through a codec of some kind. Most people use MediaCleaner (I think it's now called simply Cleaner) to optimize the footage for streaming.

Static pictures stream the best ;-)

--/ Shangara Singh.

Just to add my two cents, since I've done A LOT of this:

Remember though that "shooting for the web" is an incredibly broad term, similar to saying you'll be shooting film without specifying the format. You should find out what data rate the web video will be delivered at, and if it is being delivered at multiple rates, and what they presume most of their viewers will be viewing it at. If you have to optimized it for 28.8 k delivery, then you're not going to be very happy with the result, no matter how well compressed it is. Many sites have abandoned 28.8 delivery though.

At 56k you get much more recognizable images. Still of a quality that David Sarnoff would have kicked you out of his office for showing him in 1939, but recognizable nonetheless. This is where you really have to minimize camera motion, number of tones and colors, etc. If you have to have a lot of motion, you might want to try using a shutter to minimize blur in the frames.

If you can possibly do a test, at the rates that you will using and with similar subjects, you should. One frustration I've had with doing this work is you don't really have a monitor before the shoot, during set up, to test colors, contrast etc. Often, if it's a live webcast, you only see the final result as it goes out live.

If the rates are over 100k, or 300k then you can actually get a fairly good result. This is often the case with intranet webcasts.

Also, it makes a big difference how the material is being captured into the webcast process. If you can do it component, then by all means do. SDI is also excellent.

I used to do a regular series of webcasts that was about webcasting, and our guests were engineers from the companies that make the commonly used capture boards and software, such as Terran and the like. They were always amazed at the quality of our webcasts as it was usually much better than they were used to for live work. That was because they had bought into a lot of fictions about the way to do this and were using amateur cameras, cheap cards, capturing composite etc. We used either Hitachi studio cameras or the D30 camera you will be using feeding into the live encoding gear with an SDI signal.

In general, you are better off recording the program in a high quality component format, then processing it through the Sorenson codec in Media Cleaner, and then webcasting that, than doing the processing live on the fly.

This is very much a case where the less noise, and the cleaner your signal is, the better your final low res, limited color result will be.

Steven Bradford

Dir of Photography

You really need to talk to the techies and try to find out what they need. Compression algorithms have gotten much better but there are still limitations.

The big thing is not to move the camera if possible. Video compression algorithms work by grabbing a key frame and comparing it to following frames. Anything that doesn't change doesn't need to be re-recorded, therefore the file size stays fairly small. That way, if you are shooting a person against a background, the background gets stored once and the person, and the area just around the person, is the only information that needs to be constantly refreshed.

If you move the camera everything changes and has to be refreshed, resulting in a much bigger file size for that portion of the video.

Some people will tell you that encoding for the web increases contrast. This means that they are using a compression program without really knowing what it is doing. You can control the contrast digitally in anything you shoot for the web in post, it's just that some companies just pipe the footage in one end of the compression program and accept whatever comes out the other side. A couple of these add a bunch of contrast for some unknown reason.

Subtle gradations tend to be a problem as the subtle brightness values will be lost. The gradation will turn very blocky. Be careful of fine backgrounds as they can cause file sizes to bloom. Medium-fast pans typically become blocky blurs.

You may find all of this is true, or none of it, depending on how it's being encoded. If it's going to be compressed into an older version of RealVideo you're in trouble no matter what you do. If they are going to use the Sorenson Video 3 (I believe they're up to 3 now) you may not have to worry about ANY of this.

My advice: go in and watch them encode someone else's video. You'll learn all the do's and don'ts very quickly.

I haven't shot for the web in a long time, fortunately. Producers used to want everything flat-lit and locked down. I think you can push the envelope a lot more these days.

-Art Adams, S.O.C.

Director of Photography

> They will probably put your footage through a codec of some kind. Most people use MediaCleaner (I think it's now called simply Cleaner) to optimize the footage for streaming.

I hear good things about the Sorenson codec. I'm sure they can tell you how the video stream will be compressed. I would also keep movement to a minimum and avoid gaining up the camera if possible. Noise gives the encoder hell.

Joseph T McDonnell III

Cameraman/Operator/Editor

New Orleans, La

>You can control the contrast digitally in anything you shoot for the web in post,

Remember that contrast is different on CRT and LCD screens, and the gamma is different between the Mac and PC platforms. You can totally control all of your image settings with most encoding programs out there, but as with NTSC, what works perfectly on one monitor or platform may not look too good on another.

In general, when encoding footage for the web, I increase the brightness and decrease the contrast a bit. The settings vary between 10 and 40% on a shot by shot basis. In addition, the way the footage is captured into the system will make a difference, 4:1:1 or 4:2:2, as to how well the image will compress.

Shangara Singh wrote:

>They will probably put your footage through a codec of some kind. Most people use MediaCleaner (I think it's now called simply Cleaner) to optimize the footage for streaming.

I helped with the beta-testing for Cleaner 5.1 before Discreet bought Cleaner from Media 100. It is a good program designed for multiple platforms or multiple codecs. However, there are better encoding programs out there for specific platforms or specific codecs. A true discussion of this is beyond the scope of this forum.

"Art Adams, S.O.C." also wrote:

>If they are going to use the Sorenson Video 3 (I believe they're up to 3 now) you may not have to worry about ANY of this.

Sorenson is up to 3.1 these days, and is incredible. However, anything you can do to help the compression at all stages of production will help. In case anyone was wondering, the star wars trailers on the web were encoded in sorenson.

>If the client has anything up on the web currently, study that and ask them if they plan on using the same methods for your footage.

I second that info. Specifically find out what formats/codecs the footage will be in, what frame rate and what size. Those 3 items alone should dictate how you shoot. For example, if your footage will only be encoded at 176x144 @ 10fps (38kbits/s) then you really need to keep your shots static as possible (read: like a blue screen!). But if your footage will only be encoded at 300x225 @ 15fps (279kbits/s) then you can get away with a bunch more motion, as there is a lot more room for changes in the frame. Even a medium speed pan will turn out ok. In addition, if you are using any of the MPEG-based codecs (especially Windows Media, or MPEG-4), then you would want to keep your motion in the frame down, as that particular codec doesnt refresh changed items as well as the Sorenson codec does (i.e. when a person moves their arm fast, the amount of time the codec takes to refresh the background image after the arm has passed is worse, as the codec is concentrating on the moving arm.)

You may also want to do multiple takes of shots for different mediums. For example, shoot a rock solid lock off of a shot for the 56k, then another

one with some motion for the 300k. If you work it out with the editor and producer (and the compressionist!) to provide different content for different streams, then your 300k stream wonÕt be boring, while your 56k stream will be watchable. IÕve found that to be key when providing quality content for the web.

--Photocon

Conrad Hunziker III

www.nightskyent.com

CML'ers

Thanks for the advice for my upcoming shoot. One more question. Does drop frame vs. non-drop have any affect here?

Marty Mullin

Los Angeles

> Does drop frame vs. non-drop have any affect here?

To be safe, you should check with whoever has to take your footage from tape into the computer and find out what makes them happy. But, there is no technical reason they should care what time code format you use.

- Bill Crow

DP - Mariposa, CA