Over the past couple of weeks I have been working tirelessly on export settings for a new web show that will be using a flash encode on a huge 800px wide player. Not many sites out there are running video at 800px wide for obvious reasons. But it will be attempted if not done. The show is looking to advance how people see web video and the quality they see it at. Not an easy feat when you want to run it as big as they do.

Unfortunately, I’m not able to say what the show is called, what its about, who is working on it or anything else surrounding it. However, the interest here is on the player and the video. Blip.tv is a major supplier of web video all over the web. Many people use Blip to distribute their content to their site, iTunes and other venues across the net. Wallstrip.com uses blip and embeds Blip’s player in their site. The concept is similar for the new show.

When you submit video to Blip, they reencode your video at their (less the great) Flash setting, rendering even the cleanest of source files, looking very “YouTubey.” After many conversations with Blip, Wallstrip’s web producer told me that if you submit your own Flash file to them, they will not reencode it. Amazing! This means that you can get a file looking the way you want it, and Blip will post it as they get it.

Excellent, right? Well, almost. In the tests I have run, I found several issues with Flash files that you may not expect if you have been working with QuickTime files. Flash encoded files are more processor intensive than other files, therefore the “max bandwidth” setting can’t be as high as it could with other files. I usually encode *.mov files for the web around 1200 or 1500 kbps which results in a good looking QT files that is playable everywhere. The Flash files we were working on here (800 x 450px) on the other hand bog down even the newest of macs at 1000 kbps. Now you may have a sweet looking file, but 1/2 your viewers will not be able to watch it.

Our solution, lower the bandwidth (about 800kpbs), up the key framing (7), and make the audio mono at 64kbps. This resulted in a (not as good but still) great looking file that didn’t kill every machine we tested it on. It took us about a week and 40 to 50 files to finally find the right combination. As a general rule, do a lot of tests - it will take time, but once you find what you are looking for, it will be well worth it. Also, save every setting you use on a file - name the file the same as you name the saved setting so you can pair them up again later.

As we all know, web video is fun, fresh and exciting to work on, but doing it well, and producing a quality product is the challenge. Happy encoding.

Share This