Effects of Re-DCTing Video

The dominant video compression algorithms – MPEG, MJPEG and DV – are based on a mathematical technique called discrete cosine transforms. How does repeatedly applying DCT-based compression algorithms affect a video clip? Folk wisdom says that every time you recompress the clip that you'll degrade it. Further, that applying different algorithms to a clip will do worse than applying the same algorithm multiple times. I decided to test this wisdom.

In these tests, I used Pegasus Imaging's PICVideo MJPEG codec at quality level 13 and the full version of Ligos' LSX-MPEG Premiere plugin in 3 Mbit/s VBR mode. I used MJPEG quality level 13 because the artifacts were slight but common enough to be testable. I didn't want extreme artifacts since nobody keeps bad video; also, I was worried that extreme artifacts would tend to overlay each other, obscuring individual effects. I used Ligos' plugin because it tested as the highest quality in my MPEG encoder reviews. This ensured that the MPEG encoder damaged the image as little as possible of all the encoders I have on hand.

The test clip was a high-action clip from my digital cable system, which uses MPEG. I'm not sure what compression parameters my cable provider uses, but every now and then you can see noticeable artifacts, especially around text and on some abrupt transitions. Assuming that my cable provider uses a very good encoder, I'd estimate that they're encoding at around 3 Mbit/s, with a small chance of being as high as 4 Mbit/s, probably in CBR mode.

For each test I used a "blink test" to compare the first compression step with the last: I loaded each clip into a separate instance of VirtualDub, set each to show the same frame, exactly overlapped the two VirtualDub windows and Alt-Tabbed back and forth between them. Minute differences in quality were immediately clear. I tested several arbitrary frames this way before passing judgement.

Test 1: MJPEG -> MPEG — Simply put, there was no real difference that you couldn't reasonably attribute to the MPEG compression step alone. In fact, I would be hard-pressed to call the second clip significantly worse than the MJPEG intermediate clip. LSX-MPEG is, after all, an incredible encoder.

Test 2: MJPEG -> MJPEG — On recompressing the same clip at MJPEG level 13, the difference was so slight it took several "blinks" to see any difference at all. I then recompressed the clip two more times at this level, whereupon I saw some slight new blockiness and only in occasional frames. I finally increased the number of re-MJPEG steps to 9. (10 MJPEG compressions in all.) With the exception of a few degenerate frames with some very ugly bits of localized blockiness, the difference between the first MJPEG step and the tenth were negligible. Blockiness in all these later steps always appeared in areas of relatively similar color; detail sections seemed to escape unscathed. These degenerate frames were bad enough that I'd call this a bug in the codec rather than an expected re-DCT artifact.

Test 3: MPEG -> MPEG — I did the same test as above, except with MPEG, but only 3 recompressions this time. Again, there was very little change between compressions, but more this time than with MJPEG. Still, a surprisingly small amount considering how much is made of avoiding recompression in the video community.

Test 4: Sliding MPEG -> MPEG — Since the previous tests were almost result-free, I decoded to shake things up a bit: with each recompression I snipped a bit off the front of the clip. With a straight re-encode, each frame gets the same type of MPEG compression: I, P or B. Snipping a bit off the front of the clip virtually ensures that a decoded I frame won't be re-encoded as another I frame and the relative compression types (P and B) would be likely to be relative to a different I or P frame than on the previous encode. The result? The first MPEG and third MPEG steps were virtually identical.

Conclusion

If you have good encoders, I see no reason to worry much about re-encoding your video clips repeatedly, even between MJPEG and MPEG.