MPEG4 Compression

[Jeff Meyer]

I think you’re just running into a barrier that inherently exists with video compression.

Part of video compression depends on the fact that under normal circumstances the entire background of a shot doesn’t completely change from frame to frame. There are instances where this isn’t the case (concerts, sports, fast motion) but for a lot of the footage out there this holds true – interviews, dialogue, product demonstrations, screen captures, etc.

Compression algorithms take advantage of this by sending a “keyframe” or a complete frame, then the next several frames note what has changed since the last keyframe. The frames that are all children ofof the parent “keyframe” are referred to as a “group of pictures.” Codecs that use this kind of scheme are referred to as “Long GOP” codecs – long group of pictures codecs. I would recommend a Google search on the topic if you aren’t familiar.

With video at 800% the background changes much more than normal, so the MPEG4 algorithm can’t keep up. There are few things you can try:

• Deliver in a codec that isn’t long-GOP – ProRes, Animation, Uncompressed. You’ll pay a severe file size penalty this way, but the target will get a near perfect (or perfect) copy of your video.
• Turn your bitrate up and keep your keyframe interval at automatic. Youtube/Vimeo still have their set bitrate they’re going to use no matter what you deliver, but their output will never be better than your input.
• You might play around with some blurs on the fast motion. If the algorithm has fewer edges to worry about it might handle things a bit better. Consequently, you might see macroblocking where there should be smooth gradients. If I had to guess, it won’t be much different, but it might be worth a try if nothing else is working.

I work in sports. When we compress quick pans against a noisy stadium background the limits of compression fiend us all the time.