Re-encoding (re-DCT) video tests

[admin]

from http://tangentsoft.net/video/mpeg/re-dct.html

Quote:

Videographica: 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 family of theories.

In these tests, I used PICVideo's 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 recent 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.

Future tests
I may re-do test 4 with a poorer encoder (TMPGEnc, perhaps) to see if it suffers more from generation damage.

I suspect that editing an IPB MPEG file will cause visible damage on successive re-encodes. Currently, the only platform likely to tempt people to edit IPB video in a deep way is the Pinnacle DC1000 and DC2000. MPEG editing to the rest of the world means using a secondary video editor, therefore there shouldn't be much re-MPEG'ing going on.

I should test DV as well, but I lack a DV encoder. Until then, I have no reason to suspect that it would fare worse than MJPEG, since the two technologies are supposed to be quite similar.

I suspect that changing the quality level between each encode would cause more generation damage. I don't plan on doing this test anytime soon, though, because most people only change their quality level at most once, from a high initial encoding quality to a lower quality level for the final product.

Interesting.

[thecoalman]

Admin Note: All videos and images have been attached/archived to this thread, in case the original nepadigital site disappears.
`````````````````````````````````````````````````` ````

This is to show the difference between going directly from a high quality DV-AVI to DVD compliant MPEG compared to reencoding from MPEG to MPEG. This is an extreme example considering the bitrates and the source I'm using. The lights are moving moving and flashing so the examples do a good job of illustrating the differences. Also note that I'm using JPG's which themselves are a lossy format so they are not entirely accurate.


Test 1

My source video is a DV-AVI it's a very high quality source. Lower quality sources may mask the results. I encoded the AVI to both 8000CBR and 3000CBR. I also reencoded the 8000 CBR to 3000CBR. I'm using Ulead MSP using basic templates with the exception of the bit rates.

Here'a a screenshot of the AVI:


The 8000CBR MPEG, notice the edges of the center light produce a little macroblocking. Very little and would be imperceptible when it's playing:


The 3000CBR MPEG encoded from the AVI, Lot's of macroblocking:


The 3000CBR MPEG encoded from the 8000CBR MPEG, a real lot of macroblocking:


As you can see the the mpeg reencoded from the mpeg shows signifgantly more macroblocking compared to the one encoded directly from the AVI. Encoding from the best source always produces a better result, if your just cutting and trimming the ends, adding a few transitions and most of the video doesn't have to be reencoded that just may be the way to do it. It's definitley faster. Personally I'm a perfectionist and prefer to have the highest quality video I can get.

Here's links to the videos (10 seconds) the example frame above is at 7 secs. 2nd frame:

Right Click and select "Save As"
- 4MB 3000CBR from AVI
- 4MB 3000CBR from MPEG
- 36MB AVI


Test 2

I Did a little more experimenting. I took my AVI source and created a 6000VBR MPEG to be used as a source file. I split the AVI source in half and did a 4 second crossfade, so we have 1 second on either side with no cross fade. I then created a 6000VBR MPEG from the AVI.

I then did the same thing to the MPEG that I'm using as a source file. Here's the results.

The MPEG encoded from the AVI:


The MPEG encoded from the MPEG:


If you focus your attention on the light to the right you can see a slight difference. Is it huge difference? No not really, but with the combination of high quality 3CCD cams coming into the consumer market and TV's becoming larger and larger any quality loss will be noticeable.

Here's some close-ups, notice the right edge of the blue light:

The MPEG encoded from the AVI: ---- The MPEG encoded from the MPEG:


The clips themselves (4MB each):
- MPEG encoded from AVI
- MPEG encoded from MPEG

[admin]

Archived versions of large files from above attached below.