your thoughts on MainConcepts H.264 encoder?

[ellesshoo]

I don't want to get into a "coder1 vs coder2" debate. However, so much talk around here is x.264 centric. Is there anything that mainconcept's offering has that is interesting to the members at large? Are there things it can do that x.264 can't.. yet? I've played with numerous presets on both and my impression is that mc is faster while x.264 is higher quality. For my eye, the difference in quality is minimal.

Other then cost, is there some other reason x.264 is more widely used and discussed here?

[roozhou]

MainConcept supports slices and PAFF while x264 doesn't.

[Sagekilla]

x264 used to support slices, but only for slice based MT. Still, that's been removed now so it can be ignored. The main differences are in quality and speed, depth of RDO and psychovisual enhancements.

[Dark Shikari]

My impression:

1. Mainconcept is pretty competitive with x264 PSNR-wise. In some cases it beats it--mostly due to better QP choice for I-frames in static scenes (in 2pass mode). A lot of the difference has been eliminated by b-adapt 2. Obviously, this is all with psyopts off; any encoder under the sun can beat x264 PSNR-wise when AQ and psy-RD are on.

x264 has far more ridiculous RDO than Mainconcept does, so I suspect any case where it loses PSNR-wise is due to ratecontrol as mentioned above, not mode decision.

Also note I really haven't done this comparison for at least a year, so I have no exact idea how things have changed in the meantime. Nor do I care enough about PSNR to do it again.

2. Its extremely B-frame happy. It really likes using 3 B-frames, especially with pyramid mode enabled. In my experience I'm not entirely sure how good an idea this is. The Ateme guys might have more to say about the merits (or lack thereof) of using too many B-frames.

3. Its a somewhat slow encoder that's 2-3 times slower than x264 on comparable settings. Now, x264 is optimized to an almost unfair level, so its not really right to compare an encoder against x264 and declare it "slow" just because x264 is a lot faster than it. Overall the encoder's speed is decent, compared to others on the market (see chart below).

You noted Mainconcept seemed "faster": one mistake people tend to make when testing x264 is that they jack up the speed settings on other encoders but they don't max the speed settings on x264 when doing the comparison. Here's a benchmark from a bit back where I maxed the speed settings for all the encoders listed (of course, I kept all features required for High Profile--so I used B-frames, 8x8dct, etc):

http://i37.tinypic.com/m8pkc2.png

"Elecard HD" is the Elecard frontend for the Mainconcept core.

4. The guys at Elecard seriously need to hire someone who can speak English to proofread their interface.

5. The output from it looks IMO pretty awful unless you enable complexity masking (similar to x264's AQ)... but apparently they removed that in the most recent version, making the entire encoder useless. Its main trouble is that it really likes blurring, which is great PSNR-wise but visually really doesn't look very good. Now, for a software encoder, Mainconcept is pretty high up there quality-wise, despite what I'm saying here; this really doesn't speak well for some of the others out there.x264 used to support slicesIt still does. There's a patch for support--all the internal code necessary for slices (well, almost all) was kept to some extent despite slice-based threading being removed; most of the "missing support" is just on an interface level.

Feature comparison:

Things x264 has that Mainconcept doesn't:

Support for >3 B-frames
Psy optimizations (No, "film grain optimization" in Mainconcept does not really count).
GOP size > 300
Constant Quality mode (no, constant quantizer mode doesn't count)
Lossless mode
Psub8x8 partitions
CQMs (I think)

Things Mainconcept has that x264 doesn't:

P-frame weighted prediction (I think?)
PAFF
Adaptive MBAFF (coming soon to an x264 near you)
Slices
More fine-grained control over MB types analyzed (you can turn off i16x16, and you can turn off i4x4 in I-frames)

By the way, if anyone "in the know" has an idea, which product has the latest publicly available version of the Mainconcept encoder? Is it Elecard HD 3.0, or is it the latest DivX alpha encoder?

[shon3i]

Things Mainconcept has that x264 doesn't:

P-frame weighted prediction (I think?)
PAFF
Adaptive MBAFF (coming soon to an x264 near you)
Slices
More fine-grained control over MB types analyzed (you can turn off i16x16, and you can turn off i4x4 in I-frames)
you forgot to say :) Full and safe Blu-Ray compatability, which nowdays is main offer for most users.

About speed, on my Phenom X4 9550 MC/Elecard high settings, show big speed impact comparing to x264 default settings.

[smok3]

any clues how old/new is the version in premiere cs3?

[Chabb]

In SD resolutions Mainconcept does much more brurring, but edges are sharp
(at least the one coder, that included in TMPGEnc XPress 4.6)
While x264 with all features like AQ and psy naturally looks more detailed
at a cost that edges are somewhat jaggy and blocking occures.
Also Mainconcept does awful fades (even more blur than usually), while x264 stays relatively detailed.

x264 options:
cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=9 psy_rd=1.0:0.0 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-2 threads=3 nr=0 decimate=0 mbaff=0 bframes=2 b_pyramid=1 b_adapt=2 b_bias=0 direct=3 wpredb=1 keyint=250 keyint_min=1 scenecut=40(pre) rc=crf crf=29.2 qcomp=1.00 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00

Mainconcept options set as close as possible (CQ mode, ref=3, bframes=2 etc)

Both files are 11.5Mb.

http://img230.imageshack.us/img230/2065/850kb0.th.jpg (http://img230.imageshack.us/my.php?image=850kb0.jpg)http://img230.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php) http://img219.imageshack.us/img219/2585/1200tk9.th.jpg (http://img219.imageshack.us/my.php?image=1200tk9.jpg)http://img219.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php) http://img390.imageshack.us/img390/6612/1550sk5.th.jpg (http://img390.imageshack.us/my.php?image=1550sk5.jpg)http://img390.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php) http://img219.imageshack.us/img219/7033/2264xp8.th.jpg (http://img219.imageshack.us/my.php?image=2264xp8.jpg)http://img219.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php) http://img65.imageshack.us/img65/6162/2650nz0.th.jpg (http://img65.imageshack.us/my.php?image=2650nz0.jpg)http://img65.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

[shon3i]

@Chabb can you aslo add source on the top? to we can see what is closer to source?

btw what is movie with Jason Statham? Transporter 3? I didn't knew is alredy out?

[Sharktooth]

the answer is obvious...

[azerty@qwaerty]

No ...

1) x264 produce better PSNR/SSIM than Mainconcept/Ateme/Sony/Thomson without psy/AQ mode and by far
2) At the same PSNR/SSIM Mainconcept is faster than x264 or Ateme and by far
3) The last know Mainconcept SDK binary is 7.5.0.
4) Many frontend use Mainconcept SDK encoder like DivX7, TMPGEnc, Adobe, Sonic

[poisondeathray]

Interesting comments & observations

@Chabb - since Mainconcept doesn't have an equivalent constant quality (not constant quantizer) mode, would the more appropriate "apples-to-apples" comparison be 2pass mode for both?

[Sharktooth]

azerty@qwaerty:
1) not always true and definatly not by far. but x264 produce always a better quality. metrics DO NOT represent quality.
2) metrics DO NOT represent quality. x264 produces a better quality output even with a lower PSNR/SSIM than elecard. so the metric comparison is completely off.
3) so what? elecard converter studio 3 has the latest elecard encoder...
4) -> 3)

[Dark Shikari]

2) At the same PSNR/SSIM Mainconcept is faster than x264 or Ateme and by farI find this extremely doubtful, especially if you're implying this is true at all points on the speed/quality curve... especially since Mainconcept's max speed is under half of x264's max speed :p

[azerty@qwaerty]

I find this extremely doubtful, especially if you're implying this is true at all points on the speed/quality curve... especially since Mainconcept's max speed is under half of x264's max speed :p

Very bad way to compare speed. You must compare speed at the same quality (PSNR or SSIM for exemple) and not max possible speed. Moreover I have a special Mainconcept CLI encoder with all possible option and higher max possible speed.

azerty@qwaerty:
1) not always true and definatly not by far. but x264 produce always a better quality. metrics DO NOT represent quality.


There are not other objective way to measure quality. Only metric. By defintion subjective way is always ... subjective. For my eyes x264 is not always the best: x264 with psy mode produce more detail preservation but major mosquito noise too. More temporal flicking too. If you use metric with good delta thresold you can always say that A is better than B. For me all the overall subjective comparison are always worse than objective comparison (like the ridiculous screenshot comparison in this thread). Moreover all codec in the world use metric (and x264 psy mode too) for decision. Anyway objective test is really not perfect method but for me subjective comparison is even worse.


2) metrics DO NOT represent quality. x264 produces a better quality output even with a lower PSNR/SSIM than elecard. so the metric comparison is completely off.

Completely false here. There are not other way that compare speed at the same metric. Completely impossible to compare speed with other way (like subjective reference). The Dark Shikari speed comparison graph is completely ridiculous because there are not quality reference.


3) so what? elecard converter studio 3 has the latest elecard encoder...

Last gui don't mean last SDK. DivX 7 H264 CLI encoder use old 7.3.0 SDK encoder. Last SDK from mainconcept don't improve quality but only speed.

[LoRd_MuldeR]

Very bad way to compare speed. You must compare speed at the same quality (PSNR or SSIM for exemple) and not max possible speed.

The problem is: How do you define "same quality" ???

PSNR and SSIM are not very suitable, as metrics do not represent actual subjective quality.

You'd have to disable all Psy optimizations and then the speed-measure is incomplete...

[azerty@qwaerty]

The problem is: How do you define "same quality" ???

PSNR and SSIM are not very suitable, as metrics do not represent actual subjective quality.

You'd have to disable all Psy optimizations and then the speed-measure is incomplete...

Yes certainely ... like subjective comparison are not always suitable (I have sujective test in the memory with quality score higher than ... source).

Anyway for speed you must use same quality reference and there are not other way than metric here. There are not other possible way in this particular test.

[avdw]

In SD resolutions Mainconcept does much more brurring, but edges are sharp
(at least the one coder, that included in TMPGEnc XPress 4.6)
While x264 with all features like AQ and psy naturally looks more detailed
at a cost that edges are somewhat jaggy and blocking occures.
Also Mainconcept does awful fades (even more blur than usually), while x264 stays relatively detailed.

x264 options:
cabac=1 ref=3 deblock=1:0:0 analyse=0x3:0x133 me=umh subme=9 psy_rd=1.0:0.0 mixed_ref=1 me_range=16 chroma_me=1 trellis=1 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-2 threads=3 nr=0 decimate=0 mbaff=0 bframes=2 b_pyramid=1 b_adapt=2 b_bias=0 direct=3 wpredb=1 keyint=250 keyint_min=1 scenecut=40(pre) rc=crf crf=29.2 qcomp=1.00 qpmin=10 qpmax=51 qpstep=4 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00

Mainconcept options set as close as possible (CQ mode, ref=3, bframes=2 etc)

Both files are 11.5Mb.

http://img230.imageshack.us/img230/2065/850kb0.th.jpg (http://img230.imageshack.us/my.php?image=850kb0.jpg)http://img230.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php) http://img219.imageshack.us/img219/2585/1200tk9.th.jpg (http://img219.imageshack.us/my.php?image=1200tk9.jpg)http://img219.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php) http://img390.imageshack.us/img390/6612/1550sk5.th.jpg (http://img390.imageshack.us/my.php?image=1550sk5.jpg)http://img390.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php) http://img219.imageshack.us/img219/7033/2264xp8.th.jpg (http://img219.imageshack.us/my.php?image=2264xp8.jpg)http://img219.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php) http://img65.imageshack.us/img65/6162/2650nz0.th.jpg (http://img65.imageshack.us/my.php?image=2650nz0.jpg)http://img65.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

Sorry to burst you bubble, but i think you just gave us a x264 vs Photoshop comparison....

[LoRd_MuldeR]

Sorry to burst you bubble, but i think you just gave us a x264 vs Photoshop comparison....

IMO x264 looks more detailed, Mainconcept looks much smoother. No big surprise, considering x264's Psy RDO feature...

[Dark Shikari]

Very bad way to compare speed. You must compare speed at the same quality (PSNR or SSIM for exemple) Obviously: my point was that your statement is highly doubtful given the fact that many x264 speeds don't have a Mainconcept equivalent.

If you want to make extreme claims like the above, back them up with facts, not platitudes. Last time I tested Mainconcept, it was slow as crap and looked awful, and I doubt they've revolutionized the encoder in two or three months. If you want to complain about me using an older version, provide me with the latest Mainconcept SDK.Completely false here. There are not other way that compare speed at the same metric. Completely impossible to compare speed with other way (like subjective reference). The Dark Shikari speed comparison graph is completely ridiculous because there are not quality reference.No, it isn't ridiculous, because I used comparable settings, using the same macroblock modes, the same motion search (refs, etc), the same number of B-frames, the same macroblock decision metric (SAD).

Obviously, it isn't perfect, but that was a test of maximum speed, not "speed vs quality", because in many cases one simply does not care about quality and only need speed. One example would be HD broadcast/streaming encoding, where up to a point speed is the only thing that matters. For example, Mainconcept cannot deliver the speed necessary to do 1080i/p realtime encoding, even on fastest settings, so quality is totally meaningless in such a case.

Now, I know you're probably a Mainconcept employee or similar shilling their product, Mr. only-has-3-posts-outside-this-thread, but if you're going to dispute actual numbers, back them up with your own on standardized test sequences that are replicable by everyone else. I'd do it myself, but I'm lazy, so I'm not going to bother unless you're going to do the same.

[poisondeathray]

I think avdw meant since the screenshots are .jpg, not .png or some other lossless, that the screenshots are not as useful

[Dark Shikari]

I think avdw meant since the screenshots are .jpg, not .png or some other lossless, that the screenshots are not as usefulIndeed, screenshots should always be PNG.

[LoRd_MuldeR]

I think avdw meant since the screenshots are .jpg, not .png or some other lossless, that the screenshots are not as useful

Didn't notice that it's a JPEG file. Of course it should be PNG for correct comparison. However the differences are clearly visible anyways...

(If x264 looks much more detailed in the JPEG version, I can assume that it looked superior in the original screenshot too)

[azerty@qwaerty]

Obviously: my point was that your statement is highly doubtful given the fact that many x264 speeds don't have a Mainconcept equivalent.

Well I can make test if you want. You have 3 reference profil encoding for x264? ("fastest", "insane", "best quality/speed")


If you want to make extreme claims like the above, back them up with facts, not platitudes. Last time I tested Mainconcept, it was slow as crap and looked awful, and I doubt they've revolutionized the encoder in two or three months. If you want to complain about me using an older version, provide me with the latest Mainconcept SDK.

Well simply because your test is crap.


No, it isn't ridiculous, because I used comparable settings, using the same macroblock modes, the same motion search (refs, etc), the same number of B-frames, the same macroblock decision metric (SAD).

You can't compare RDO and ME like that.


Obviously, it isn't perfect, but that was a test of maximum speed, not "speed vs quality", because in many cases one simply does not care about quality and only need speed. One example would be HD broadcast/streaming encoding, where up to a point speed is the only thing that matters. For example, Mainconcept cannot deliver the speed necessary to do 1080i/p realtime encoding, even on fastest settings, so quality is totally meaningless in such a case.

Like always false. Easy to make realtime encoding with really simple Q6600 and fastest profil (without ME, RDO, SADT ....). It's like for Nero/Ateme: Nero don't have the complete available command and by far.


Now, I know you're probably a Mainconcept employee or similar shilling their product

No. You are simply not objective with the other H264 codec. Really easy for me to prove that.

[Dark Shikari]

OK, I decided not to be lazy and to actually do some real tests to put this to rest. I chose "middle ground" settings to be fair: settings that are not really fast or really slow, but ordinary encoding settings. For Mainconcept, that is. I really had to pick very slow settings on x264 to slow it down to Mainconcept's level.

Source: Touhou

Settings:
x264 --no-cabac --quiet --keyint 300 --progress --psy-rd 0 --aq-mode 0 --bitrate 1000 --pass 1 --bframes 3 --b-pyramid --subme 2 --partitions none -o NUL input.avs --threads auto;x264 --bitrate 1000 --pass 2 --bframes 3 --b-pyramid --ref 7 --psy-rd 0 --aq-mode 0 --progress --8x8dct -o test_x264.mkv --threads auto --subme 9 input.avs --keyint 300 --mixed-refs --me umh --trellis 1
Mainconcept: Fast RD, 4 reference frames, 3 b-frames, High Profile, all partition types, CABAC, twopass bitrate 1000, b-refs/pyramid, Qpel, weighted pred, subblock search, fast subblock search, fast multiref search, SATD, fast inter/intra decision, default on everything else. No AQ.

FPS:
Mainconcept: 26fps (average over both passes)
x264: 27.5fps (average over both passes)

Mean Luma PSNR:
Mainconcept: 30.87819
x264: 32.87380
(Blue=x264)
http://i35.tinypic.com/o05wlg.png

Mainconcept higher PSNR at the same fps? Is this some sort of joke?
No. You are simply not objective with the other H264 codec. Really easy for me to prove that.You're right. I was being far too kind to Mainconcept, definitely not objective at all. I take back what I said earlier about Mainconcept being competitive: it isn't.

For those curious, here's the video streams themselves: Linkage (http://www.mediafire.com/?kmihdwwz2dq)

[ajp_anton]

DS:
Since the differences in the two passes are so different, I don't think it's right to average their speed. At least without telling how you averaged them (2fps + 100fps should "average" to ~4, not 51).
Also, will x264's --ref 7 and MC's 4 references somehow result in the same number because --ref is the DPB size?

[poisondeathray]

Nice to see some testing being done

@Dark Shikari: can you please provide the version information for x264 and Mainconcept AVC on your most recent testing?

@azerty@qwaerty: please do the testing you proposed. More testing and data is better than less data IMO. Do you have access to the new Mainconcept SDK versions? Most people only have access through the Premiere plugin or TMPGenc... which are probably older versions.

[Audionut]

You're right. I was being far too kind to Mainconcept, definitely not objective at all.

To diplomatic for my tastes. :rolleyes:

[Dark Shikari]

DS:
Since the differences in the two passes are so different, I don't think it's right to average their speed. At least without telling how you averaged them (2fps + 100fps should "average" to ~4, not 51).That isn't how I averaged them. I averaged using 2 / (1/firstpass + 1/secondpass), which is equivalent to the way Mainconcept displays the averaged FPS. The FPSs were ~64 and ~18, respectively.
Also, will x264's --ref 7 and MC's 4 references somehow result in the same number because --ref is the DPB size?No, I didn't care about DPB size, I just upped x264 settings until I got it nearly as slow as Mainconcept.
Nice to see some testing being done

@Dark Shikari: can you please provide the version information for x264 and Mainconcept AVC on your most recent testing?x264: r1016
Mainconcept: Elecard Converter Studio: 2.0.4 build 71008

I'd prefer to test with a newer version of Mainconcept, but it is not reasonable to expect me to go out and spend thousands of dollars on a slightly more recent update for the purpose of testing someone else's encoder. If someone wants me to test the absolute latest, they should send me the absolute latest, whatever that may be. I'd be happy to run the test again with a newer Mainconcept with similar settings (and I'll lower x264's settings accordingly if Mainconcept has gotten faster).

[azerty@qwaerty]

To diplomatic for my tastes. :rolleyes:

... lol

Just little test like that because it's not the best quality/speed profil for Mainconcept:


x264 with your setting, 267 sec, 43.69 dB
Max speed is 105 fps for fastest profil


Mainconcept with fast first pass, 239 sec, 43,76 dB
easy for me to reproduce that with elecard or mainconcept gui.
Max speed is 90 fps for fastest profil


Source: high quality King Kong vob trailer 720*480 with really various type scene. "Real Life" encoding at 1000 Kbps with "Real Life" quantizer ("DivX" like encoding).





D:\Mes dossiers\Codec\x264>x264 --no-cabac --quiet --keyint 300 --progress --psy-rd 0 --aq-mode 0 --
bitrate 1000 --pass 1 --bframes 3 --b-pyramid --subme 2 --partitions none -o NUL test.avs --threads
auto
avis [info]: 720x480 @ 23.98 fps (4123 frames)

encoded 4123 frames, 94.61 fps, 1046.86 kb/s

D:\Mes dossiers\Codec\x264>x264 --bitrate 1000 --pass 2 --bframes 3 --b-pyramid --ref 5 --psy-rd 0 -
-aq-mode 0 --progress --8x8dct -o test_x264.mp4 --threads auto --subme 9 test.avs --keyint 300 --mix
ed-refs --me umh --trellis 1
avis [info]: 720x480 @ 23.98 fps (4123 frames)
x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 Cache64
x264 [info]: profile High, level 3.0
mp4 [info]: initial delay 2002 (scale 24000)
x264 [info]: slice I:102 Avg QP:20.06 size: 20661 PSNR Mean Y:49.33 U:53.69 V:54.21 Avg:50.26 Gl
obal:47.04
x264 [info]: slice P:2091 Avg QP:22.86 size: 7589 PSNR Mean Y:44.97 U:49.19 V:50.11 Avg:45.94 Gl
obal:43.68
x264 [info]: slice B:1930 Avg QP:23.03 size: 1817 PSNR Mean Y:46.21 U:50.79 V:51.39 Avg:47.15 Gl
obal:43.59
x264 [info]: consecutive B-frames: 24.0% 31.9% 12.2% 31.8%
x264 [info]: mb I I16..4: 35.0% 55.6% 9.4%
x264 [info]: mb P I16..4: 10.5% 14.5% 1.9% P16..4: 31.5% 10.2% 5.6% 0.0% 0.0% skip:25.8%
x264 [info]: mb B I16..4: 0.3% 0.6% 0.1% B16..8: 26.1% 1.7% 1.5% direct: 1.8% skip:67.9% L
0:30.3% L1:51.2% BI:18.5%
x264 [info]: 8x8 transform intra:54.3% inter:72.2%
x264 [info]: ref P L0 84.7% 8.1% 4.0% 1.6% 1.5%
x264 [info]: ref B L0 90.5% 6.3% 2.3% 0.9%
x264 [info]: ref B L1 97.8% 2.2%
x264 [info]: SSIM Mean Y:0.9786082
x264 [info]: PSNR Mean Y:45.654 U:50.048 V:50.807 Avg:46.615 Global:43.692 kb/s:999.38

encoded 4123 frames, 18.45 fps, 999.56 kb/s



4123/94.61+4123/18.45 = 267 sec



D:\Mes dossiers\Codec\Elecard2>set E_SRC=test.avs

D:\Mes dossiers\Codec\Elecard2>set E_BR=1000000

D:\Mes dossiers\Codec\Elecard2>mch264ve.exe config11.cfg SourceFileName = test.avs TargetFileName =
"ElecardAVC_900.264" AvgBitrate = 1000000

THIS SOFTWARE IS FOR EVALUATION PURPOSES ONLY!

[time: 0:01:17] [left: 0:00:00] [speed: 53.3 fps] [queue: 0.000 ms]]

Summary information:
Number of coded frames 4123
Total encoding time 77374 ms
Average time per frame 18.766 ms
Average speed achieved 53.3 fps
Average bitrate 1486.14 kbit/sec @ 23.98 Hz

D:\Mes dossiers\Codec\Elecard2>mch264ve.exe config22.cfg SourceFileName = test.avs TargetFileName =

Copyright (c) 2006 MainConcept AG

THIS SOFTWARE IS FOR EVALUATION PURPOSES ONLY!

[time: 0:02:41] [left: 0:00:00] [speed: 25.5 fps] [queue: 0.000 ms]]

Summary information:
Number of coded frames 4123
Total encoding time 161482 ms
Average time per frame 39.166 ms
Average speed achieved 25.5 fps
Average bitrate 997.77 kbit/sec @ 23.98 Hz

Overall PSNR (Y) 42.582 dB
Overall PSNR (U) 47.571 dB
Overall PSNR (V) 48.599 dB
Overall PSNR (A) 43.767 dB


4123/53.3+4123/25.5 = 239 sec

[nurbs]

Not sure if I'm reading this right, but from what you posted x264 is about 12% slower but has almost 2.85 dB higher average PSNR. That pretty much confirms what Dark Shikari wrote.

[Dark Shikari]

Not sure if I'm reading this right, but from what you posted x264 is about 12% slower but has almost 2.85 dB higher average PSNR. That pretty much confirms what Dark Shikari wrote.Be very careful to not confuse mean PSNR and global PSNR, and also be careful not to confuse luma PSNR and average PSNR.

Finally, azerty's PSNR measurement method is faulty, because it assumes that the encoders' PSNR measurement is correct. For x264, at least, it is not, because by default x264 does not deblock in unreferenced frames.

I would recommend measuring PSNR manually using something like MSU Video Quality Tool and posting the graph, as I did. This also helps compare overall distribution of quality.

[azerty@qwaerty]

Finally, azerty's PSNR measurement method is faulty, because it assumes that the encoders' PSNR measurement is correct. For x264, at least, it is not, because by default x264 does not deblock in unreferenced frames.

I would recommend measuring PSNR manually using something like MSU Video Quality Tool and posting the graph, as I did. This also helps compare overall distribution of quality.

No Overall PSNR will be exactly the same with external plugin.

x264 don't produce 2X speed if you compare with other H264 encoder. In fact Mainconcept SDK is faster than x264.

[Dark Shikari]

No Overall PSNR will be exactly the same with external plugin.So you're saying that a developer of x264 is wrong about whether x264 generates an exactly correct OPSNR value, while you, with not a single x264 commit to your name, know the entire codebase perfectly? :rolleyes:

[azerty@qwaerty]

So you're saying that a developer of x264 is wrong about whether x264 generates an exactly correct OPSNR value? :rolleyes:

Yes ... because I make measure with external plugin too. I confirm that ... like I confirm that Mainconcept is faster than x264. Your previous test and graph are simply ridiculous.



while you, with not a single x264 commit to your name, know the entire codebase perfectly?

Well I confirm that you are not a Mainconcept developper because you doesn't know very this codec ... lol.
Like I confirm as always you are not really modest. It's impossible for you to say "I'am wrong in this case".

[Dark Shikari]

Yes ... because I make measure with external plugin too. I confirm that ... like I confirm that Mainconcept is faster than x264. Your previous test and graph are simply ridiculous.Well there's no point in me responding further to such an obvious Mainconcept shill, but before I add you to my forum ignore list, you have called my test "ridiculous"... yet your test involves:

1. An encoder that is not publicly available.
2. Output files which you have not posted, forcing us to take everything you post on your word.
3. You haven't posted your configuration either.

My test is done with the actual, publicly available encoder, with ordinary near-default encoding settings. Yours is done with something nobody else can replicate due to not having access to, secret settings which you have hidden from other users, further obfuscating the test. And finally, in the end it becomes clear that you actually made up the numbers, because you got caught by x264's lack of deblocking in B-frames: the fact that you claim the externally measured PSNR is exactly equivalent to x264's printed PSNR is proof that your entire test is falsified, as if you had actually done it, you would have noticed there was a significant measurable difference.

I'm done with such silliness. If you want to perform real, unbiased tests, don't obfuscate everything you do and then lie about it. I don't at all doubt that Mainconcept can beat x264 PSNR-wise. I would not even be that surprised if, at some points on the speed-quality curve, it wins, PSNR-wise. But I am not going to debate an obvious shill. This is pointless.

[azerty@qwaerty]

1) Well I make many other reproductible test on this forum with another nickname ...

2) I use for this test very old CLI version (october 2006). SDK 7.5.0 is really faster I think. You can reproduce the test with DivX 7 CLI encoder for example.

3) OPSNR calculation will be the same with internal x264 or with external plugin. I have never see more than 0.1 dB for difference, not here for sure. You want the test too ...

4) I use really simple c2d at 2.66 Mhz with 2 GB under WinXP, really classical PC.

5) Your test is completely ridiculous because your source is inusual. and you make generalisation.


the fact that you claim the externally measured PSNR is exactly equivalent to x264's printed PSNR is proof that your entire test is falsified

The "same" don't mean "exactly equivalent". I think that you are ridiculous like your test for compare x264 at other H264 encoder. Impossible for you like always to say that: "i'am wrong here".

Pitoyable ... in french

[Sagekilla]

3) OPSNR calculation will be the same with internal x264 or with external plugin. I have never see more than 0.1 dB for difference, not here for sure. You want the test too ...

Edit: Mixing up my words: You're comparing the overall PSNR of Mainconcept to the Global PSNR of x264. You're comparing apples to oranges!

[LoRd_MuldeR]

1) Well I make many other reproductible test on this forum with another nickname ...

14) Multiple registrations are prohibited and are grounds for immediate account deletion.

[Dark Shikari]

14) Multiple registrations are prohibited and are grounds for immediate account deletion.Oh, so he must be Sergey ;)

[azerty@qwaerty]

Except for the fact that the mainconcept decoder never printed out OPSNR. Only Y, U, V and AVG. x264 was the only one that printed out OPSNR so you're comparing two completely different things.

Well not for my CLI encoder. I obtain directly good OPSNR value.


Multiple registrations are prohibited and are grounds for immediate account deletion

My previous nick don't work with my password but it's really good argumentation here.


Oh, so he must be Sergey

No.

[Sharktooth]

are you $^*@ or what?
this discussion is pointless.
metrics do not represent quality but an index of difference from the original. that says it all...
if you want to compare the visual quality compare 2 clips at the same bitrate having the encoders running at the same speed (as D_S did...).
and again METRICS DO NOT REPRESENT QUALITY... hope you understood that...

P.S.: he's not sergey, he's french... and so fanatic about metrics it makes me think he's sagittaire...

[Sagekilla]

@azerty: Re-read my post, I mixed up my words.

[azerty@qwaerty]

Edit: Mixing up my words: You're comparing the overall PSNR of Mainconcept to the Global PSNR of x264. You're comparing apples to oranges!

No, it's OPSNR for x264, Elecard, Ateme and etc etc

[LoRd_MuldeR]

My previous nick don't work with my password but it's really good argumentation here.

http://forum.doom9.org/login.php?do=lostpw :rolleyes:

(This of course won't allow you to re-activate your account after suspension)

[Sagekilla]

No, you're ignoring my point once again.

Look:
x264 [info]: PSNR Mean Y:45.654 U:50.048 V:50.807 Avg:46.615 Global:43.692 kb/s:999.38

Overall PSNR (Y) 42.582 dB
Overall PSNR (U) 47.571 dB
Overall PSNR (V) 48.599 dB
Overall PSNR (A) 43.767 dB



You're comparing Average Overall PSNR of Mainconcept to the Global Overall PSNR of x264. Apples to oranges. You should be comparing Average Overall PSNR to Average Overall PSNR.

I highlighted the values you should be comparing.

[azerty@qwaerty]

are you $^*@ or what?
this discussion is pointless.
metrics do not represent quality but an index of difference from the original. that says it all...
if you want to compare the visual quality compare 2 clips at the same bitrate having the encoders running at the same speed (as D_S did...).
and again METRICS DO NOT REPRESENT QUALITY... hope you understood that...

P.S.: he's not sergey, he's french... and so fanatic about metrics it makes me think he's sagittaire...

There are not other way for compare speed. You must use this method. Only speed at the same metric or metric at the same speed. Not the choice.

For compare quality it's another problem.

[Sharktooth]

the original poster talks about quality... not metrics...

[Sagekilla]

He's confusing "quality" for similarity to image. That's all PSNR and SSIM do.

[Atak_Snajpera]

azerty@qwaerty
Who cares if one encoder has better metric numbers if overall picture quality is not optimal for human eyes? AQ and Psy-RDO proves that eye sense prefers grain/noise over perfectly smoothed ares. End of story.

[Guest]

@azerty aka Sagittaire

One of these accounts must be terminated.

If possible I will try to find a way to retain your posts as azerty but if there is not a way, it's your own fault.

Your password can be reset. You've only to ask. Theoretically, both accounts can now be deleted but we are not unreasonable.

Let's get you reset as Sagittaire (the one we know and love) and then see what can be done. I'll ask Swede about it.

Please reset your password and continue posting as Sagittaire. Thanks!