Interlace Quality in TMPGEnc vs CCE

[peterhuh]

Hi!
I have been using TMPGEnc for over 2 years now.
On their webby: http://www.tmpgenc.net/e_about.html, they claim that Quality comes b4 everything. So let's not talk about speed here. I am into the best quality TMPGEnc has to offer.

I have done quite alot of TMPGEnc vs CCE quality myself, and IMO, i have come to the conclusion, that TMPGEnc has almost the same quality as CCE in all aspect except one. Which is interlaced encodings.

I have a PAL DV Camcoder, and i like to keep all my backups onto DVD, @ 50fields/sec. The problem is, TMPGEnc tends to block when met with high motion scence, such as quick panning. The same DV clip when encoded with CCE dosen't show this blocking artifact. At least, not in high bitrate. Further digging, shows that the artifact onli appears in the b-frames.

I have tried all relevent options in TMPGEnc: b-frame spoilage, soften block noise, KVCD matrix, CBR 9800. The blocking artifact still exsist somewhat.

Anyone have found a way to reduce the blocking artifacts in interlaced mode? I am happy if the quality is somewhere near CCE's. Pls take note that i want the final MPEG-2 within DVD spec's. Mi no want long GOP of 10secs! lolz And thanks for your reply! :)

**update**
sorry, i was quit buzy for the pass few days. well, i tot of posting pics for comparison. The following image is taken from a video panning from right to left, very very fast.


http://images5.theimagehosting.com/original.png
Original quality


http://images5.theimagehosting.com/cce.png
CCE quality (b-frame)


http://images5.theimagehosting.com/tmpgenc.png
TMPGEnc quality (b-frame)

I would like to point out, there is alot of noise on the right hand side of everything for TMPGEnc. As the video is panning from right to left, the noise is caused by the previous field. I guess TMPGEnc does not seperate fields before passing through the DCT for B-frames. A bug?

I have also found out something from VirtualDub's File Information dialog box, CCE seems to allocate more bits for B-frames. almost 50% more than TMPGEnc's. Can i adjust TMPGEnc to do the same?

--Additional Info--
No pre/post-processing was used.
The original DV AVI file was drag-n-drop onto both CCE and TMPGEnc.
The free Panasonic DV codec was used
For TMGPEnc, under VFAPI plug-in, onli AVI(OpenDML) File Reader is checked.
All Image was saved using VirtualDub Mod 1.5.4
Discard 2nd field and Bicubic Resized for viewing

Source:-
DV AVI file captured using Adobe Premiere
Interlaced PAL 25fps/50fields 16:9 DAP BFF
Shutter Speed: 1/1000

TMPGEnc:-
TMPGEnc Plus 2.524.63.181
MPEG-2 720x576 25fps CBR 9800kbps
Motion Search: Highest Quality (very slow)
Interlaced PAL 25fps/50fields 16:9 DAP BFF

CCE:-
CCE SP Ver. 2.70.02.00
MPEG-2 720x576 25fps 1-pass CBR 9800kbps
Interlaced PAL 25fps/50fields 16:9 DAP BFF
---------

[WorBry]

If you are convinced that B-frames are the cause, why dont you encode at >6000kbps and knock-off the B-frames. I usually encode VBR at average 8850kbps (max 9250, min 3700, GOP: I1,P4) and AC3 audio and have encountered no such problems, at least with PAL (PAL to NTSC conversion is another story). If you prefer lower bitrates I would recommend using Rui Del Degro's bitrate calculator to obtain the optimum GOP settings - http://dvd-hq.info/Calculator.html

[peterhuh]

yep, that works. but when there is alot of motion, 9800kbps of p-frames is rather insufficient.

[Mug Funky]

are you setting interlace in TMPG? 9.8 should be plenty (i don't recommend going over 8.5 on most stuff, especially for DVD-R).
but then, if CCE works better for you, use that :)

at 9.8 mbps, pretty much any mpeg-2 encoder should be transparent - that's why it was chosen as the max data rate for DVD video. you don't have wacky b-frame spoilage settings in TMPG do you?

you could always give quenc a try - it performs very well on interlaced PAL DV.

[Archimedes]

I’ve made a lot of tests with interlaced sources and low cost encoders like TMPGEnc, CCE Basic, Procoder Express, QuEnc, FreeEnc and HC (visual tests and with special software). All results shows, that the Procoder Express does the best job. QuEnc does also a very good job – and it’s freeware. On interlaced videos with many action, TMPGEnc is not the best choice.

I’ve been using TMPGEnc long time, before CCE Basic and Procoder Express comes out. In my experience, High Quality gives better results than Highest Quality. It depends on the source video.

[onesoul]

I tried many encoders with interlaced source as you can see here (http://forum.doom9.org/showthread.php?s=&threadid=91405), although I didn't include Procoder in the test, I also tested it along cce 2.50 and cce 2.70. I wasn't satisfied even with procoder, for me HC and Quenc are better dealing with interlaced source.
Quenc blurs somewhat, which can be good if you want to cover some noise, although I'd prefer HC, I suggest you try both.

[Archimedes]

Nice test. May i give you my personal ranking, beginning with frame 375.

Frame 375:
1. QuEnc
2. Recode 2
3. HC
4. CCE 3 pass
5. CCE

Frame 488:
1. Recode 2
2. HC
3. QuEnc
4. CCE 3 pass
5. CCE

Frame 517:
1. Recode 2
2. HC
3. QuEnc
4. CCE 3 pass
5. CCE

Frame 573:
1. QuEnc
2. Recode 2
3. HC
4. CCE 3 pass
5. CCE

Analyzed with Fritz Framalyzer (can compare videos and images through pixel comparing). I hope the images were not changed in any form and are representing the original footage.

In my tests, QuEnc and HC also beats the CCE Basic. QuEnc is the closesed to Procoder Express.

[onesoul]

Originally posted by Archimedes
Nice test. May i give you my personal ranking, beginning with frame 375. Thanks :)
Analyzed with Fritz Framalyzer (can compare videos and images through pixel comparing). I hope the images were not changed in any form and are representing the original footage. I did not change or apply any filter on original footage.

Actually where I found procoder as bad as cce (along the pale red) was the initial logo of hbo, procoder made it look like cce (bad).

You can download the original M2V file and try it for yourself.

Interesting tool you got there, I will try it. Although in the end the eyes make the choices (wrong or right ;)).

Does the ranking have scores for each encoder? I would like to see them.

Cheers

edit: I just want to add that for progressive source another story is told, CCE actually can give better results for now ;)

[Archimedes]

No problem, here it is.

Frame 375:
1. QuEnc (3,0755)
2. Recode 2 (3,2443)
3. HC (3,5029)
4. CCE 3 pass (3,9007)
5. CCE (3,9178)

Frame 488:
1. Recode 2 (1,3698)
2. HC (6,3059)
3. QuEnc (6,7319)
4. CCE 3 pass (8,235)
5. CCE (8,3705)

Frame 517:
1. Recode 2 (7,391)
2. HC (8,2559)
3. QuEnc (8,7578)
4. CCE 3 pass (9,2073)
5. CCE (9,2541)

Frame 573:
1. QuEnc (5,4594)
2. Recode 2 (7,2703)
3. HC (8,8469)
4. CCE 3 pass (9,5143)
5. CCE (9,523)

The values means the overall difference between an encoded pixel and an original pixel in the (3 D) RGB color space. All pixels were compared. I saved the jpg files as bmp files and cutted it to 720 x 544, because of the different letters at the top of the files. This bmp files where compared with Fritz Framalyzer (original and encoded frame).

I wrote this little tool, to make it possible to compare the results of different encoder settings etc. Yes, at the end, we make the choices.

[Archimedes]

I downloaded your clip and made a short test. In Procoder Express the default GOP length is 15. You tested the encoders with a GOP length of 12. That makes a difference. Furthermore the images i compared from you where all jpg files (and gamma coreccted). And, where all images from you i frame images? However, the results here can not be compared directly.

However, i set Procoder Express to VBR, 2 pass, 0/4312/9000 bitrate, to be a little bit close to your testing environment.

Fritz Framalyzer reportet this results for
Procoder Express, Highest Quality, DC 9:

Frame 375: 3,9663
Frame 488: 3,9762
Frame 517: 5,971
Frame 573: 5,4964

The software compared the original (not gamma corrected) images and same amount of pixel range i've tested above.
To compare it correctly, the original encoded videos should load into Fritz Framalyzer. And all frames and pixels will be analyzed.

When i analyze your original clip with the encoded Canopus Procoder Express video, i reach a FND index of 4,5167.

[onesoul]

You didn't tell me how procoder express did on the initial logo, I bet it was bad :)

I used Procoder 2 with GOP 12 and GOP 15 aswell the other encoders, didn't make too much difference but I preferred GOP 12.

I don't know what kind of frames I captured, I used avscompare to do it. I don't know why you say they were gamma corrected but I bet if I upload the original bmp files, you won't see a difference between jpg and bmp, honestly, AJC is one of the best jpeg compressors I used so far and I used the screenshot profile. I will upload some bmp's when I get home.

I will try again latest HC, Quenc and procoder 2 and use your tool to compare them, I'll report back later.

[Archimedes]

Here are the first frames of the image comparing with Fritz Framalyzer.

Frame 40:
1. Recode 2 (4,697)
2. QuEnc (23,6782)
3. HC (31,281)
4. CCE 3 pass (46,9392)
5. CCE (49,081)

Frame 75:
1. QuEnc (8,6742)
2. Recode 2 (20,1702)
3. HC (23,2769)
4. CCE 3 pass (25,2121)
5. CCE (27,2741)

Frame 98:
1. HC (3,6884)
2. CCE 3 pass (3,7917)
3. CCE (3,9353)
4. Recode 2 (6,5834)
5. QuEnc (10,0928)

Procoder Express, GOP length 15, Highest Quality, DC 9
(Fritz Framalyzer analyzing window: 0 – 719, 32 – 575, to analyze the same pixel region as above. Be careful to compare with above.):

Frame 40: 19,9254
Frame 75: 8,0425
Frame 98: 3,4599

[onesoul]

As promised here's a link to a original bmp file (The webhost doesn't allow bmp extension, so I added gif extension :)):

http://rapidshare.de/files/1451083/orig_000517.bmp.gif.html

I had some trouble using your tool Fritz Framalizer, I had to reduce by one frame so it wouldn't hang at the end, and I couldn't use procoder2 with picture structure as field or frame, because it would start later than original when comparing. I had to use Picture Structure as frame to get it done right.

Here are the results I got: HC 0.14, GOP 12 2, best profile 4277kbps avg 9000 max, cce standard matrix
FND Index: 5,023 <- lower is better
Matched Pixels: 26,5903 % <- higher is better

Frame with lowest FND index: 0 (0)
Frame with highest FND index: 36 (23,3978)
Frame with highest matched pixels: 36 (100 %)
Frame with lowest matched pixels: 83 (1,2642 %)

Quenc 0.59b4 GOP 12 2 High Quality 4277kbps avg, cce standard matrix
FND Index: 5,5758
Matched Pixels: 22,8006 %

Frame with lowest FND index: 0 (0)
Frame with highest FND index: 41 (26,5189)
Frame with highest matched pixels: 41 (100 %)
Frame with lowest matched pixels: 41 (0,1271 %)

Procoder 2 GOP 12 2 Master quality 4276 kbps avg, frame picture
FND Index: 4,7196
Matched Pixels: 27,9844 %

Frame with lowest FND index: 0 (0)
Frame with highest FND index: 39 (33,8317)
Frame with highest matched pixels: 39 (100 %)
Frame with lowest matched pixels: 39 (0,1751 %)

Procoder 2 GOP 15 2 Master quality 4276 kbps avg, frame picture
FND Index: 4,7204
Matched Pixels: 26,251 %

Frame with lowest FND index: 0 (0)
Frame with highest FND index: 39 (22,7124)
Frame with highest matched pixels: 39 (100 %)
Frame with lowest matched pixels: 39 (0,7347 %)

[Archimedes]

Normally the program stopped correctly at the shortest clip. Some Encoders (it depends on the settings) cut the last frame. This could cause problems with Fritz Framalyzer. You’ve done it right. Analyzing all but the last frame.

The program doesn’t support the field modus. When analyzing is finished, allways take a look at the highest and lowest FND index. The values should be like 3,433 and 6,4555. If you have values like 3,444 and 98,564, there is something wrong.

The matched pixels are not necessary, because, i’ve detected that TMPGEnc is producing allways the best results. But TMPGEnc is also producing the worst results in the not matched pixels. The FND index takes care about it, because it measures all pixels.

Keep in mind, the program is analyzing all frames and pixels you give them.

As you see, the procoder produces the best results. The overall difference between an encoded pixel and an original pixel in the 3-D RGB color space is the smallest.

[Kika]

Like WorBry wrote: In TMPGEnc at such high bitrate, simply knock of the B-Frames. And you can change the P-Spoilage to -20 up to -40. Don't use KVCD-Matrix, and use Soften Block Noise at low values. At high values it will PRODUCE blockiness.

If you won't knock of the B-Frames, set B-Spoilage to -100, P-Spoilage to 20 and use a GOP like that: 1:5:1:1 (PAL) 1:6:1:1 (NTSC).

After that, do your tests again, you may find the results very interesting.

[onesoul]

Frame with highest FND index: 41 (26,5189)
Frame with highest matched pixels: 41 (100 %)
Frame with lowest matched pixels: 41 (0,1271 %)
Looking back again, something is not right here...

But anyway procoder2 did marginally better according to your tool.

Why can't fritz accept video encoded as field type structure? There are many DVD's encoded this way. For interlaced content I guess it is the best option. I can view that encoded file in wmp with no problems.

[Archimedes]

As far as i know, the only encoders which supports field modus is the Canopus Procoder 2.0 and Express. But, i will notice that (field modus support) for future versions.

About the differences. Lower results are better than higher results. What exactly FND difference means regarding the quality of your encodet video, is up to you. Difference like 4,743 and 5,200 you will see when comparing the images. You have to experience with it (compare the values with image comparing). Small differences may be i. e. 4,545 and 4,6551.

[Archimedes]

@Kika:
You’ve right. I tested TMPGEnc with the (old) reference clip from http://www.tecoltd.com/enctest/enctest.htm against other encoders with Fritz Framalyzer. Encoding settings was VBR, 2 pass, 3500/6500/8500 bitrate. TMPGEnc was encoding with 3500/6500/8000 bitrate.

The results:

1. Procoder Express, Highest Quality, DC 8: 7,3347
2. QuEnc, DC 10: 7,5422
3. HC, DC 8: 7,8581
4. FreeEnc, Incredible KDVD: 8,0893
5. CCE Basic, DC 8: 8,2326
6. TMPGEnc, High Quality, DC 10: 8,7692

This is not an encoder test. Because i had to find out the best settings from each encoder. While i tested some settings (DC values etc.) with most of the encoders, i didn’t it with TMPGEnc.

So i tried to encode the video with no b frames in TMPGEnc. The result was 8,3609. Comes close to CCE Basic. But in the test above, the other encoder settings can also be improved to reach better results. But the difference with or without b frames in TMPEnc are remarkable.

[onesoul]

I think you didn't understand the doubt the output log: frame 41 appears on highest and lowest matched pixels :confused:

I tried fritz with cce on which I did 2 encodes and the only difference was on one the zigzag scan was activated and on the other the alternate scan.

Surprisingly there's not much difference visually and fritz shows the same:

CCE Zizag scan:
FND Index: 5,4173
Matched Pixels: 24,1479 %

CCE Alternate scan:
FND Index: 5,4517
Matched Pixels: 24,0895 %

Interlaced source encoding is definitely not a strong side from CCE at least from 2.5 up. I saw the link page you gave and apparently cce 2.0 gave good results (that video was interlaced right?) which seems not be happening now. On the good side cce 2.70 is powerful on progressive source.

But ahead of the values, I still would use Hc encoder over procoder2, the downside of quenc is that it blurs just a little too much which can be good sometimes to get rid of some noise as I said before. On procoder some chroma gets palish like in cce.

[Archimedes]

Ok, i will look at it (frame 41). CCE is better on progressive source, yes, but you can also use it for interlaced material. I began with TMPEGnc, then with CCE Basic and now i’m using the Procoder Express for dv avi interlaced sources.

[Kika]

@Archimedes

Guess i have to make this Tests with Fritz Framalyzer by myself. I bet, i can get a result below 8. ;)
But not with DC 10, i always use DC 9.
And i don't use 2pass, only CQ-Mode will give you the best possible quality.

BTW: Why did you set Max to 8000 instead of 8500?

One trick for TMPGEnc is the use of CQ with other Bitrate-values than most guides are providing. If you need an AVG around 6000, there's no need to set Max at 8000. You can use values about 9000. All you have to do ist to figure out how to set Min and CQ to get the goal. Changing CQ only won't give you the best results.

TMPGEnc is a bit tricky, but if you know the tricks... ;)

[Archimedes]

I set TMPGEnc to a maximum of 8000 because higher values weren’t possible. This was only a very quick test to prove the outputed results of the software. May be, unlocking the default settings helps to put in higher vaules than 8000.

But when we do an encoder test, the settings of each encoder have to be eqal as possible. I’ve also testet the above clip with following encoder settings:


Procoder 2.0: 7,2549
(Mastering Quality, DC 10, 3000/7000/9000, 2 pass)

Procoder Express: 7,2622
(Highest Quality, DC 10, 4000/7000/9000, 2 pass)

Procoder Express: 7,057
(Highest Quality, DC 8, 4000/7000/9000, 2 pass)

[Kika]

But when we do an encoder test, the settings of each encoder have to be eqal as possible.

Right, that's because i asked you about the 8000 kbps setting only for TMPGEnc.

Oh, and by the way: 2pass should only be used on longer sequences. The encoders do have very different methodes to calculate the bitrates in 2pass mode. On short sequences you will only compare... um... nothing? ;) Both, CCE und TMPGEnc do need long videos for a propper 2pass encoding, they are very bad on short videos.

[onesoul]

Originally posted by Kika
Both, CCE und TMPGEnc do need long videos for a propper 2pass encoding, they are very bad on short videos. I haven't tried tmpegenc yet. But that's not true for CCE, especially because you have BIAS value to set (as you probably know it defines the VBR compression curve) which can improve a balanced quality output (if Bias=0 then it's 100% VBR which is practically equivalent to 1-pass OPV.

I have tested a 3 minute clip and I got better output using 2 pass with Bias=40 that the OPV encode, the average bitrate was 3100kbps (quality_precision=25). Out of all cce versions, 2.70 gave me the better results. The clip is for the birds from Monsters_inc DVD, if you want it to test, I will try provide it, this is a progressive source.

[Kika]

because you have BIAS value to set

That's true, but how many users out are able to use this feature?
It's a bit like Archimedes said:

the settings of each encoder have to be eqal as possible

So if you don't want special settings for TMPGEnc for a fast test, you can't use this feature for CCE also.

So, that's my question: What do you realy want? Results as good as possible or results only from standard settings?
If you only want to work with standard settings... ok, forget TMPGEnc.

[onesoul]

So if you don't want special settings for TMPGEnc for a fast test, you can't use this feature for CCE also.

So, that's my question: What do you realy want? Results as good as possible or results only from standard settings? I want results as good as possible, always.
As for a setting like bias not being standard, well, it isn't for now. ;)
Hank315, for example, has plans for implementing such a feature.

[Archimedes]

Because TMPGEnc was allways used with standard settings in encoder tests, it allways looses. Other encoders reaches better results in the standard settings.

A good encoder test environment would be, when each encoder is running with its best settings (possibilities) against a well designed test clip. May be one can define a limitation of the resulted stream size (or bitrate) for all encoders.

As a joke: It would be very interesting, based on a well designed test clip, to make an encoder test, on which every encoder can do what its settings offers, and comparing the encoded videos against the original video with Fritz Framalyzer. The result would be an encoder rating list (based on a special test clip).

[Kika]

Interesting idea: Get the best out of each encoder...

OK, i use TMPGEnc since it's early days (0.11a), so maybe i know one or two tricks. ;)
And the last version of CCE i really tested was 2.66.
I specialized in using TMPGEnc, an encoder i really know - it's advantages and it's weaknesses.