lighting/compression for the web

[Mark Tarman]

I have tried to find a thread about lighting for the web but cant seem to find one. I am filming a short 20 second blip for a company thanking their new customers for investing in the business. How do you suggest i go about doing this. oh and does compression need to be mpeg2 in order to play on the web? im not posting it but will be giving them the compressed video. thanks for your suggestions.

[Matthew Craggs]

Originally Posted by Mark Tarman

oh and does compression need to be mpeg2 in order to play on the web?

I don't have a good answer about lighting, but I can assure you that your video does not need to be MPEG2 compressed

[Benjamin Hill]

Mark, like many others these days I shoot a lot of video that ends up on the web and I'd say web delivery is less forgiving in *some* ways than Tv/DVD, mainly because of compression and resolution limitations.

If you practice solid lighting/composition techniques when you're shooting whatever it is you're shooting, and it looks good on your video monitor at full-res, it should hold up when compressed & down-rez'd to 320x240 mp4, etc.

There are many different formats for web and my personal favorite at the moment is Flash video. Hope this helps,

[Bill Davis]

I'll second what others here have said. The kind of lighting you use isn't really going to have a significant effect on the "compressability" of your footage (if that's even a word...)

What IS going to effect how well it compresses is the changes that happen between frames.

The classic example is a shot of a tree against the sky compresses very poorly because the luminance and chromanance values of all the pixels are changing rapidly frame to frame as the leaves sway. Dark to light, green to blue, everything is constantly in flux, which makes it hard for software to detect patterns that it can shorten into "this pixel stays green for 200 frames" kind of code.

A talking head against any static background - no matter how complicated the lighting or the background is - will compress well as long as the individual pixel values stay the same over a large range of frames..

In essense, in compressing for the web, frame to frame change is bad.

Simple as that.

[John Pritchard]

Honestly, for web video (and a lot of people will probably disagree with me), I'd go straight for flash .flv video. The pro's of MP4 just do not outweigh the compatibility benefits of going .flv. Nothing will piss a client off more than finding out "Hey, a fifth of our viewers are having problems seeing the content."

Go .flv.

[Ervin Farkas]

Professional softwares usually apply a lot of adjustment before compressing for the web. Sorenson Squeeze for example increases contrast, reduces brightness, increases gamma, applies video noise reduction, and normalizes audio. Unless you will be using a high quality professional software, you should apply these changes in your NLE before feeding the footage to the compressor.

Two other extremely important issues are resizing and deinterlacing - best practice is to do these two steps BEFORE compressing. Some NLEs do better than others when it comes to these; you can use very good free software to resize and deinterlace (VirtualDub for example - first deinterlace, then resize).

From my own experiments, the quality list goes: Real Media, Windows Media, QT/H264 and Flash, with RM being the best, QT & Flash the poorest. Of course others may have a different opinion based on their own tests. The biggest problem is that the popularity of players is in invers order, Flash being the most wide spread, Real the least.

For me personally Windows Media is the best compromise.