1 person found this helpful
Actually the issue may be in the camera motion itself. The critical factor for MPEG compression is the contrast differences from GOP to GOP or I-Frame to I-Frame. If the motion is too slow, there is no difference and the compression will re-use the same blocks forever. If there is too much motion with fine details, then there are almost inevitably blocks simply because a fine details such as a motionblur streak may be below the smallest block size or the overall amount of fine detail exhaust the data rate. Some of these things can be influenced by the choice of encoder and quality settings, of course, but not always. Contrary to what you think, decreasing keyframe intervals may only make things worse, as it will create more base keyframes which are always recalculated fresh without reusing previous motion analysis data. It is usually best to leave these things at automatic/ the default settings. Same would apply to trying to enforce CBR... however, from your description it sounds like you are doing the encoding directly from AE, and thus even the VBR does not produce such great results. Maybe you could try this in AME? That should make things better. As for otehr tricks - the usual "add some noise" would of course also work by visually breaking up reagions and continually randomizing block allocation, but it will also increase file sizes and data rates. If you downsize larger output, you may also consider adding a slight blur before resizing. This will distribute luminance more evenly across the image and also helps to get better compression. You can also directly just blur the luminance using a channel blur effect...
Compression for the Web is a dark art, it's al experimentation becuase the results are not only entirely subjective, they are influenced by stuff that's completely out of yopiur control If your'e going up to one of the video sites, the file may be processed after you upload. And you have control over how your visitors see it on their computers.
I'd start with CBR. The file will be a bit larger. H.264 is fine.
There are much more informative sites all over the Net dealing specifically with compression of all typs for all types of delivery systems.
Thanks guys -both answers helpful!
I'm still open for tips from other power users! What way does your company solve the issue of making camera movements look good even in web compressed videos? A great deal of videos nowadays seem to contain nice and smooth camera motion, so I can't be the only one struggling with such compression issues
I googled a great deal on the subject, but basically only found tips like "keep the camera stationary". But is that really the only option? Feels like it can't be, since there are so many cool videos with all kinds of camera movements!
The more a camera moves, the more difficult it is to compress for the web. That's just the way it is. When you are making videos for the web there are different rules of thumb to keep in mind over standard production. One of them is to keep the camera as steady as possible.