AVI-DV to MPEG vs. MPEG to MPEG

[thecoalman]

This is an extreme example considering the bitrates and the source I'm using. The lights are moving moving and flasshing 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.

Test 1
My source video is a DV-AVI it's a very high quality source. Results from a lower quality source may mask the differences. 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 Secs.) the example frame above is at 7 secs. 2nd frame:

Right Click and select "Save As"

4MB 3000CBR from AVI
4 MB 3000CBR from MPEG
10MB 8000CBR
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

[FulciLives]

I had an ADS Instant DVD 2.0 for a couple of weeks (before returning it). This is an external USB 2 hardware MPEG encoder.

It was capable (as most hardware MPEG encoders are) of doing 15,000kbps CBR and I was able to make it do "I" frame only encoding with a simple "registry edit hack" since that option was possible but not in the software settings.

So in theory that is the "best" capture quality you can get using a hardware MPEG encoder.

I did a few captures at 720x480 15,000kbps CBR with "I" frames only. I did this as a "master" capture ... the way you would capture to AVI using another card like an ATI AIW (using HuffyUV or PICVideo MJPEG) or even DV AVI using something like the Canopus ADVC-100 etc.

I would then edit (using VirtualDubMod ... import edit to AviSynth script) then re-encode with AviSynth script input to CCE to a "standard" MPEG-2 with DVD specs.

The result was good ... sometimes most excellent ... but I got the sense that it was no where near as good if I had captureed to an AVI file with HuffyUV or PICVideo MJPEG (like I did in the "old" days with a simple PCI TV Tuner type capture card). In fact if the source wasn't "perfect" you could see ... not extremely noticeable mind you ... but still you could see MPEG artifacts even in the orginal capture which again was 720x480 15,000kbps CBR "I" frame only. Even if MPEG artifacts like MARCO BLOCKING or MOSQUITO NOISE were absent there was still a certain amount of "blurryness" or "smudgeness" to the image that you don't get with HuffyUV or PICVideo MJPEG captures. I also don't see that in DV AVI although to date my experience with DV AVI has been extremely limited.

So case in point or in other words the reason I brought this up ... do not encode to MPEG format if you intend to re-encode.

- John "FulciLives" Coleman

[thecoalman]

So case in point or in other words the reason I brought this up ... do not encode to MPEG format if you intend to re-encode.

- John "FulciLives" Coleman

The differences are slight at the higher bitrates, may not even be evident unless your looking for it. I had originally posted this on another forum to prove to a another poster that there was a difference. He was insisting that there was no difference and had a big long article on how he had tested it, problem was his testing method was flawed, so of course I had to prove it otherwise. :P

I've never though of trying a very high bitrate mpeg to use as reencode source. It would be interesting to see if there is an improvement in the reencode to 3000CBR. When I get a chance I'll take the source AVI and redo from scratch the first test I did and include another set of results reencoded from 15000CBR.

On a side note this has alos been posted on LS's site. There was an article he posted there about some tests that others had done for reencoding using the same bitrate. In those tests the quality loss was minimal even after multiple reencodes.

I think in the end it comes down how much editing are you going to do and and how much versatility do you want with your end product. Just for example if your going to be using the source to create multiple types of videos (i.e. One for the web, one for CD, one for DVD) then using AVI as the source is in your best interest, same goes for video that is going to be edited extensively. Maybe when I do redo my test I'll add a second set of results where multiple filters have been applied to see what kind of results that gives me.

[spectroelectro]

You're always going to get hammered with real-time MPEG-2 capture as opposed to outside-of-real-time encoded MPEG-2 done from type 2 DV or Huffyuv or even MJpeg with decent settings. Real-time MPEG-2 works under a severe time gun and consequently most real-time MPEG-2 capture has to guesstimate encoding parameters before the memory buffer fills. A multipass software MPEG-2 encoder can scan the video and determine precisely what parameters will minimize compression artifacts.

That said, I'd like to have seen the result from a JVC DRM10. That's a real-time MPEG-2 encoder but it does an absolutely superb job. Frame by frame the results are jus slightly more smudgy and microscopically more blurry than a non-real-time MPEG-2 conversion from Huffyuv source using a good solid MPEG-2 software encoder like Procoder or CCE or Mainconcept or TMPGenc. However, the JVC wins against the software encoders for lack of motion artifacts. In certain infrequent situations, like very slow horizontal or vertical camera pans, you can see slight motion stutter in the software MPEG-2 encoders, whereas there's just none in the MPEG-2 out from the JVC's LSI encoder chip.

Whatever engineers designed the JVC's LSI MPEG-2 encoder chip, they did a fantastic job. It's inspired me to largely abandon software MPEG-2 converter software, except for working with homebrew material I have to do elaborate DV editing on, or After Effects-type video compositing or other special effects with.