your thoughts on MainConcepts H.264 encoder? [Archive]

Dark Shikari

11th November 2008, 06:14

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

11th November 2008, 07:26

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

11th November 2008, 08:51

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

Chabb

11th November 2008, 13:50

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

11th November 2008, 17:21

@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

11th November 2008, 17:35

the answer is obvious...

azerty@qwaerty

11th November 2008, 17:47

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

11th November 2008, 18:04

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

11th November 2008, 18:08

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

11th November 2008, 18:30

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

11th November 2008, 18:47

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

11th November 2008, 18:49

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

11th November 2008, 19:01

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

11th November 2008, 19:27

LoRd_MuldeR

11th November 2008, 19:53

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

11th November 2008, 19:55

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

11th November 2008, 19:56

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

Dark Shikari

11th November 2008, 20:07

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

11th November 2008, 20:14

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

11th November 2008, 20:25

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

11th November 2008, 20:31

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

11th November 2008, 21:02

poisondeathray

11th November 2008, 21:04

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

11th November 2008, 21:06

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

To diplomatic for my tastes. :rolleyes:

Dark Shikari

11th November 2008, 21:12

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

11th November 2008, 23:43

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

12th November 2008, 00:07

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

12th November 2008, 00:16

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

12th November 2008, 00:32

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

12th November 2008, 00:35

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

12th November 2008, 00:40

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

12th November 2008, 00:47

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

12th November 2008, 01:12

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

12th November 2008, 01:29

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

12th November 2008, 01:31

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

12th November 2008, 01:33

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

azerty@qwaerty

12th November 2008, 01:38

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

12th November 2008, 01:38

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

12th November 2008, 01:40

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

azerty@qwaerty

12th November 2008, 01:41

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

12th November 2008, 01:42

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

12th November 2008, 01:44

azerty@qwaerty

12th November 2008, 01:45

Sharktooth

12th November 2008, 01:47

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

Sagekilla

12th November 2008, 01:49

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

Atak_Snajpera

12th November 2008, 01:52

neuron2

12th November 2008, 02:15

@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!

Sharktooth

12th November 2008, 03:43

wait... i said sagittaire, but that was just a guess... im not 100% sure he's him... (just 99,8%... )

Dark Shikari

12th November 2008, 03:43

wait... i said sagittaire, but that was just a guess... im not 100% he's him... (just 99,8%... )neuron2 is a moderator, he has god powers ;)

azerty@qwaerty

12th November 2008, 08:47

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.

No it's false ... Global PSNR for x264 is OPSNR without bframe deblock ... :search:

Little comparison if you want:

x264 produce this value:
x264 [info]: SSIM Mean Y:0.9809307
x264 [info]: PSNR Mean Y:45.086 U:47.545 V:48.591 Avg:45.797 Global:44.901 kb/s:1152.32

Avisynth PSNR plugin produce this value with coreAVC decoder
OPSNR: 44.9108

and it's the same value here ...

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

Dark Shikari speak about speed and not me. The posted graph is completely ridiculous for many reason:

1) x264 is never 2x more faster than Mainconcept at same quality output (objective or subjective like you want).
2) Nero use fast first pass only for more than 10000 frames. In this case fast first pass is incredibily fast (only 1/10 of the frame are tested or something like that) and Nero speed will be in practice increased by x2
3) The only way for speed test is to have quality reference and the objective reference is the only possible reference. If you don't trust in metric then you can't make comparative speed test. It's simply like that.

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

Well I make little OPSNR test with and without deblock on bframe:

x264 produce this value:
x264 [info]: SSIM Mean Y:0.9809307
x264 [info]: PSNR Mean Y:45.086 U:47.545 V:48.591 Avg:45.797 Global:44.901 kb/s:1152.32

Avisynth PSNR plugin produce this value with coreAVC decoder
PSNR with bframe deblock: 40.3817 44.9108 75.0983
PSNR without bframe deblock: 40.3349 44.9014 75.0983
PSNR without complete deblock: 39.7150 43.7990 69.6803
it's Min Overall Max value for PSNR

Like you can see there are not big difference, isn't it?

Chabb

12th November 2008, 09:04

@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?

Is it so necessary to see the source, cause "the source" was
h1080p trailer of Transporter 3, avisynthed to 720x304.
My upload speed it small, cause I'm not home :)

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

You are so skilled to recognize Photoshop in my posts?
I'm using x264 long enough and still consider that other
AVC coders exists. If one of these coders could be better,
than I'm interested in. So it's useless for me to make
fake images.

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

Even if I'll say these screens are JPEG at quality 90 (of 100) with no color subsampling, JPEG compression artifacts are neglible compared to AVC ones.

azerty@qwaerty

12th November 2008, 09:38

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.

Well x264 use metric like always for these decisions simply because x264 is mathematical algo with metric comparison for all decision and for complexity preservation too. I think that PSY-RDO use SSD for decision. You can perhaps say that PSNR or SSIM are not good metric but certainely not that general metric never work simply because in this case there are not possible lossy codec algo ...

azerty@qwaerty

12th November 2008, 10:10

Well now I wait excuse from Dark Shikari for that ... lol

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

Anyway I think that I will wait a very long time: Really impossible for Dark Shikari to say "I am wrong"

neuron2

12th November 2008, 13:23

@azerty

You have ignored my message above!

That leaves me no option but to ban this account. I'll wait a few hours to give you another chance to respond. Use PM if you prefer.

Also, your last comment about Dark Shikari is an ad hominem that violates rule 4. Please stop that.

Gabriel_Bouvigne

12th November 2008, 14:47

Back to the original topic:

I have not checked, but I would expect MainConcept's encoder to be able to:
*always fulfill VBV constraints, even with tricky content
*put proper HRD info within the bitstream

while x264 can't (yet)

shon3i

12th November 2008, 19:35

I am not guy who use metrics for comparations, but i can say that for same subjective or objective visual quality, MC i a lot faster, and always been. And using x264 high's (subme 9, trellis 2, me tesa) will not make miracle, how much hurt speed. x264 @ normal options is lot slower than MC's. And encodings are look transparent each other, i use random frames, aslo i compare some short sequences, in some cases, i must to say x264 make better decisions, so quality on this places is by hair better on x264 side, but again if we look on speed where is 8fps vs 4fps for mainconcept, for little and invisible difference (without magnifyer) in qualty for me MC does better job.

azerty@qwaerty

12th November 2008, 20:10

@azerty

You have ignored my message above!

That leaves me no option but to ban this account. I'll wait a few hours to give you another chance to respond. Use PM if you prefer.

My habitual login don't work and I haven't make modification. Perhaps account pirating ... ??!

Also, your last comment about Dark Shikari is an ad hominem that violates rule 4. Please stop that.

Well Dark Shikari make that first I think, isn't it?

I have not checked, but I would expect MainConcept's encoder to be able to:
*always fulfill VBV constraints, even with tricky content
*put proper HRD info within the bitstream

- There are problem with vbv if you use average bitrate close to max bitrate (perhaps not in recent SDK version but Sonic report this problem with Cinevision)

- Mainconcept make Segment Reencoded too. Perhaps possible with special x264 front-end?

neuron2

12th November 2008, 20:50

@azerty@qwaerty

Per forum rule 14 your account was banned. Please post using your original account. If you are having a problem logging in please email me at neuron2 at comcast.net and I will assist you to recover your account.

smok3

13th November 2008, 09:39

Bigmango

13th November 2008, 18:20

a quick test (x264 vs MC from CS3), grainy source, lots of random luma grain in the background Mc does a better job (background stays static while with x264 it is warping around), no i can't post a sample unfortunatelly.

Ok, but your post doesn't tell us much if you don't at least post screenshots, encoder versions, bitrate, resolution, encoder settings...

Atak_Snajpera

15th November 2008, 08:10

no i can't post a sample unfortunatelly.
I won't believe it if can't see ...

Sharktooth

15th November 2008, 15:27

same here. claiming something without visual proof is useless.

cogman

15th November 2008, 16:51

Oh this is too funny. DS posted sample, graphs from a third party software, version number, and specific command line options.

azerty posted, hidden config files, no version numbers, no source sample, no way to verify what he has claimed. As well, if you look at the settings he used for x264 they are probably the most damaging for encoding on a first pass. x264 achieved a 90fps first pass while main-concept did a 54fps first pass, and yet your saying that main-concept is just as fast while providing equal quality?

If the data from the first pass is garbage of course x264 will have a hard time competing.

shon3i

15th November 2008, 18:33

OK, here is mine thoughts :)

Source: Harold & Kumar Escape from Guantanamo Bay Blu-Ray Disc VC-1 BD-50
Source Resolution: 1920x1080p
Destination: DVD5/BD5
Target Bitrate: 4673kbps
Target Resolution: 1920x1080p

Encoders: x264 (skystrife build rev.1028) vs Mainconcept Reference 1.6.1

Settings Used:

x264:

--pass 2 --bitrate 4673 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-adapt 2 --weightb --direct auto --deblock -3:-3 --subme 9 --trellis 2 --psy-rd 1.0:1.0 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 8000 --vbv-maxrate 15000 --me umh --merange 32 --threads 6 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --sar 1:1 --mvrange 511 --aud --nal-hrd

No turbo mode during first pass.

Mainconcept:

Basic:

Keyframe Interval: 24
Bitrate Mode: 2-Pass VBR
Averge Bitrate: 4673
Maximum Bitrate: 15000
Quantization: Best

Advanced:

Profile: High
Level: 4.1
Use B-Pictures: 3
Use B-Slices as reference: True
Multiple Slices: 4
Reference Frames: 3
Shearch Shape: 8x8
Subpixel Mode: Quarter
Multi-reference Frame ME: Complex
Sub-block ME: Complex
RDO: Complex
Fast Intra Decisions: False
Fast Inter Decisions: False

Miscellaneous:

Minimum Keyframe Interval: 1
CABAC: True
Use Hadamard Transform: True
Weighted Prediction (P-frames): True
VBV-Buffer: 1000000
Chroma Red Offset: 0
Chroma Blue Offset: 0
Deblocking: -3,-3

everything elese on defaults.

Conclusion:

Source (VC-1)
http://www.imagebam.com/image/6f7da418390691

x264
http://www.imagebam.com/image/83705c18390693

Mainconcept
http://www.imagebam.com/image/b4a9d618390694

Speeds:

Procesor: AMD Phenom X4 9550 @ 2.2GHz (default clock)
Movie duration: 1:47:42
x264: around 20 hours including first pass. 2fps averge.
Mainconcept: around 10 hours including first pass. 4-5 fps avege.

My conclusion: for that speed MC does better job than x264.

background stays static while with x264 it is warping aroundSame here.

poisondeathray

15th November 2008, 18:59

Nice testing shon3i - that's a huge speed difference! on a huge sample LOL

Can you provide some samples where you see the "warping around"? is that with --psy-rd 1.0:1.0 ?

Would --b-adapt 2 , and --trellis 2 slow x264 significantly in that comparison? I have an older Mainconcept build with mcstdh264ve.ax (v. 7.3.0.19115) but am unsure of what the corresponding settings would be for the new b-frame decision and trellis on ?

Bigmango

15th November 2008, 19:51

My conclusion: for that speed MC does better job than x264.

Now this is some nice testing shon3i, although I don't agree with your conclusion :)

Your screenshots show once again what has been demonstrated many times in other tests on these forums: the mainconcept encoder smoothes the picture out, losing detail and object texture.

You can see this clearly in your shots, and it is even more obvious with other shots in these forums where you clearly see things like stone or tree textures losing detail.

x264 is much closer to the source.

But in your test mainconcept is 2 times faster. I think it would be interesting to see the results with the settings tweaked in a way to get both encoders to work at the same speed.

ACoolie

15th November 2008, 19:54

Would --b-adapt 2 , and --trellis 2 slow x264 significantly in that comparison? I have an older Mainconcept build with mcstdh264ve.ax (v. 7.3.0.19115) but am unsure of what the corresponding settings would be for the new b-frame decision and trellis on ?

Yes, lets see a bframe comparison.

Tagert

15th November 2008, 20:42

Yeah I agree, x264 is closer to the source than MC is on the comparison below.
But it's what you prefer really.
Speed or quality :p

MasterNobody

15th November 2008, 21:09

shon3i
Why you use such non optimal settings for x264? Especially this:
--pass 2 --bitrate 4673 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --no-fast-pskip --bframes 3 --b-adapt 2 --weightb --direct auto --deblock -3:-3 --subme 9 --trellis 2 --psy-rd 1.0:1.0 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 8000 --vbv-maxrate 15000 --me umh --merange 32 --threads 6 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --output "output" "input" --sar 1:1 --mvrange 511 --aud --nal-hrdThis settings in my opionion only reduce quality (psy-trellis because 1.0 is too big for it).
Also you must decide what you want quality or speed. If you want quality/speed balanced settings (in my opinion) I would suggest to change your settings to something like this:
--pass 2 --bitrate 4673 --stats ".stats" --level 4.1 --keyint 24 --min-keyint 1 --ref 3 --mixed-refs --bframes 3 --b-adapt 2 --weightb --b-pyramid --direct spatial --deblock -3:-3 --subme 7 --trellis 1 --psy-rd 1.0:0.0 --partitions p8x8,b8x8,i4x4,i8x8 --8x8dct --vbv-bufsize 62500 --vbv-maxrate 15000 --me umh --merange 32 --threads 6 --thread-input --progress --no-psnr --no-ssim --output "output" "input" --sar 1:1 --mvrange 511 --aud --nal-hrd
Green options can be safely deleted from the command line.

LoRd_MuldeR

15th November 2008, 21:15

What's wrong with "--direct auto" in your opinion?

MasterNobody

15th November 2008, 21:44

What's wrong with "--direct auto" in your opinion?
Nothing wrong. I simply prefer "--direct spatial" (in my opinion, may be wrong, it gives better quality then auto; with auto I sometimes see small artifacts).

LoRd_MuldeR

15th November 2008, 21:49

Nothing wrong. I simply prefer "--direct spatial" (in my opinion, may be wrong, it gives better quality then auto; with auto I sometimes see small artifacts).

In my experience, the "auto" mode tends to use spatial in ~99% of all cases anyways...

CruNcher

15th November 2008, 22:10

comparing X264 and MC in screenshots is even more crazy as booth use a complete different PSY approach and as shon3i and smok3 allready said part of that is MC's Quantization approach it is different and it looks far different then compared to X264 in motion (more stable like every object is glued to it's position and only moves when it actually is moving) :) and also everyone here forgets that MC removed complexity masking, who saw it in action knows how compareable it is to X264 VAQ :)

So just lets wait for DivX Encoder Beta and see all the stuff in action there (hopefully), and then compare till then X264 also has some time to improve :)

Dark Shikari

16th November 2008, 05:40

Nothing wrong. I simply prefer "--direct spatial" (in my opinion, may be wrong, it gives better quality then auto; with auto I sometimes see small artifacts).Interesting: the folks at Ateme would say that direct temporal is (almost) strictly better than spatial, for psy reasons.In my experience, the "auto" mode tends to use spatial in ~99% of all cases anyways...I have a clip that uses ~100% temporal (http://mirror05.x264.nl/Dark/Flash/mof.html) (the first minute or two of that) when pyramid isn't used (pyramid makes temporal completely unreasonable for some frames, as the definition of temporal is not really a very good one in the spec...)

kemuri-_9

16th November 2008, 07:22

to assist in this seemingly OT trend...
i often find myself getting 85-90% spatial and 15-10% temporal on auto
i think i might have seen increase in temporal usage with lowering the bitrate (but i'm not really sure on that)

Manao

16th November 2008, 07:53

Interesting: the folks at Ateme would say that direct temporal is (almost) strictly better than spatial, for psy reasons.Indeed, but you won't see the difference at CRF 20, the difference exists mostly for low bitrates, and you won't see the difference on screenshots (on those, spatial gives a better PSNR and/or smaller size and most likely a better visual result) but only while actually watching the video. Of course, as you said, pyramid messes everything up for temporal, making spatial mandatory (and pyramid + spatial >> temporal)

Dark Shikari

16th November 2008, 08:39

Indeed, but you won't see the difference at CRF 20, the difference exists mostly for low bitrates, and you won't see the difference on screenshots (on those, spatial gives a better PSNR and/or smaller size and most likely a better visual result) but only while actually watching the video. Of course, as you said, pyramid messes everything up for temporal, making spatial mandatory (and pyramid + spatial >> temporal)Out of curiosity, on this note, does the Ateme encoder, when using pyramid, use temporal whenever reasonably possible? Or does it just use spatial globally?

Manao

16th November 2008, 09:43

We use it whenever it makes sense, which hardly happens with pyramid (iirc, it makes sense only for the first Bframe of a pyramid, in coding order). Anyway, I think the point is rather moot. On this forum, people doesn't quite know what low bitrate is.

CruNcher

16th November 2008, 09:50

Manao is right with --direct auto/spatial and the lower the bitrate for the resolution you slowly are gonna get problems, i call this one (b-frame wobbling) motion begins to fall apart completely especially visible in camera pans.
Though i never saw that it hurts much or even becomes a visual problem @ high bitrates :) (or for the given resolution acceptable bitrates depends on the compression strength) i would just say --direct auto/spatial doesn't scale perfect but most people aren't going to use x264 for such extreme low bitrate encoding, and those that do will find this out rather fast how to compensate problems visually.

shon3i

16th November 2008, 12:37

Why you use such non optimal settings for x264? Especially this:Is not non optimal, because i want strict Blu-Ray compatability and wanna higest possible quality for it.

-b-pyramid is broken so out of game, because can easly break decoding.
-vbv-buffer must be on 8000, anyways bitrate never reached 6mbps, your buffersize out of all AVCHD or Blu-Ray specifications. Max for Blu-Ray is 30000, and 18000 for AVCHD, but 8000 is just fine for BD5 encoding, it will not hurt quality, btw i use exatly same buffersize for MC.

Well PsyTrellis is maded to incrase PQ, so i don't see reason why not using it on Insane settings?

and also everyone here forgets that MC removed complexity masking, who saw it in action knows how compareable it is to X264 VAQAgree, but hey MC, anyways does a better job without any AQ.

I will post soon new comparation where both encoders use same encoding time, to see what can do for same speed.

CruNcher

16th November 2008, 13:30

Jep you should really try to get the same speed :) disabling VAQ for example also saves some cycles and to much psy for X264 is going to slow it down too but finding the right balance between encoding speed,visual quality(hvs),decoding complexity and final compression factor isn't a easy task (especially as you constantly need to adapt to x264 improvements)

MasterNobody

16th November 2008, 20:21

-b-pyramid is broken so out of game, because can easly break decoding.
Then for honest comparison you can also disable "Use B-Slices as reference" in MC.
-vbv-buffer must be on 8000, anyways bitrate never reached 6mbps, your buffersize out of all AVCHD or Blu-Ray specifications. Max for Blu-Ray is 30000, and 18000 for AVCHD, but 8000 is just fine for BD5 encoding, it will not hurt quality, btw i use exatly same buffersize for MC.
I am not VBV-expert but I highly doubt that specifying --vbv-bufsize smaller than --vbv-maxrate is good idea. If 30000 is max for Blu-Ray specifications than you must use --vbv-bufsize 30000 (--vbv-bufsize 62500 I get from Level 4.1 limits, because I don't see Blu-Ray specifications). And from your post I see that for MC you use
VBV-Buffer: 1000000
Well PsyTrellis is maded to incrase PQ, so i don't see reason why not using it on Insane settings?
Because not all values of options are good (an 1.0 for psy-trellis is too big in my opinion). For example, if you would use --psy-rd 20:0 or --aq-strength 20 it probably would be horible encode.

shon3i

16th November 2008, 23:29

Then for honest comparison you can also disable "Use B-Slices as reference" in MC.This option have nothing to do with quality, even, can make things worse, hornestly, if we talking about fair competirion i shold disable AQ/PsyRDO in x264, but i am not, because i wanted to see what encoder can do with their high's settings, and how that much affect on speed.

If 30000 is max for Blu-Ray specifications than you must useBecause my target is not Blu-Ray Disc, than classical DVD-R dics with UDF 2.50 filesystem called BD-5 disc or DVD with BluRay structure. Because SAP's read disk with 2x you must follow that speed and you must set buffer acording that, 30000 is huge buffer for DVD @ 2x. So AVCHD specification must be followed for BD-5 or BD-9 discs, but there is no point to use maxrate @ 18000, because probably any movie never reach that, and aslo buffer must be less than 18000 because is need to leave room for audio and subtile streams. For BD-5 there is no reason to use nothing higher than 10000 for normal movie with 6mbps and more or less, i use 8000 for safe reason. VBV will not hurt quality if you know what doing, playing with buffer and max rate can make disaster on decoding.

And from your post I see that for MC you useMC, have totaly different VBV system, and very strange setting of buffer, i use 1000000, because last two digits are ussless if we cut it we get 10000 that value i divide by 1.25 and i get 8000, so if you want to get buffersize 8000 you must multiply with 1.25 and just add two zeros at the and of number :), maybe someone of MC developers can explain that math or formula, i found these settings work, but i am realy confused with other VBV settings are in perent :)

To be sure i scan both streams with Elecard Buffer Analyser, and i get both streams have buffer @ 8000 and max rate @ 15000.

Because not all values of options are good (an 1.0 for psy-trellis is too big in my opinion)Ok, I'm aware of, but that your observations are, and from last testings (here on doom9 forum) with PsyRDO/Trellis, show that 1.0:1.0 are much closer to source

Dark Shikari

16th November 2008, 23:46

if we talking about fair competirion i shold disable AQ/PsyRDO in x264Because "fair" means disabling all the best features in x264 to make other encoders look better, right?

shon3i

17th November 2008, 00:02

Because "fair" means disabling all the best features in x264 to make other encoders look better, right?
I am not saying or doing that, i just leave both encoders with at their max settings.

and MasterNobody is that which thinks that B-slices as reference are unfair option for x264, and he is not see that i use AQ or Psy which is definitly not fair for comparing with MC Reference, because MC's Complexity mask is very comparable to x264 VAQ.

Atak_Snajpera

17th November 2008, 00:03

if we talking about fair competirion i shold disable AQ/PsyRDO in x264
Don't make me laugh :) We should use all weapons against MC ... Only insane people would disable those options...

LoRd_MuldeR

17th November 2008, 00:07

I'd say for a fair competition every encoder should be allowed to choose its "optimal" settings for the given source. Usually the settings are provided by the developers.

That's also how the Doom9 Codec comparisons are done...

Shinigami-Sama

17th November 2008, 00:14

LoRd_MuldeR

17th November 2008, 00:39

because 'fair' always means there a handicap for one side you don't want 'fair' in comparisons
you want balls to the wall insane maxed out best each competitors can do
if one can't keep it up its not better...

That's why the developer has to provide the settings for his own encoder, not the tester.

Like each Formula-1 team chooses the setup for their own car ;)

Shinigami-Sama

17th November 2008, 00:41

That's why the developer has to provide the settings for his own encoder, not the tester.

Like each Formula-1 team chooses the setup for their own car ;)

exactly

poisondeathray

17th November 2008, 01:42

Dark Shikari

17th November 2008, 01:47

How does MC's "complexity mask" compare to MC's "adaptive quantization" ? I've seen it mentioned above from CruNcher and shon3i, that they dropped the "complexity mask" feature

The MC version I had been using was 7.3 (bundled with Elecard) and has AQ modes of either luminance, contrast, and complexity from strengths -100 to +100; is this something entirely different or were you referring to the 3rd AQ mode? or are you using a different (newer) MC build ?

I'm not too familiar with MC's settings because I dismissed it long ago because of it's relatively lower quality (compared to x264) , especially at lower bitrates. So I'm just re-investigating this comparison, maybe I've missed some hidden MC settings ?The MC complexity mask is similar to the x264 AQ, except:

1) The algorithm certainly isn't exacly the same to begin with; I'm not sure exactly what it is but I don't think its variance-based. However, it scales similarly.
2) It has rather strong quantizer-field smoothing. Clearly, the idea behind this AQ algorithm is to compensate for the varying texture complexities throughout a frame, something which AQ is very useful for. Unlike x264's method, its purpose doesn't seem to include saving bits on edges/transcients, which it doesn't do well due to the smoothing. Of course, its clear, as I said, that it wasn't meant to do that to begin with.

kolak

18th November 2008, 23:38

The MC complexity mask is similar to the x264 AQ, except:

1) The algorithm certainly isn't exacly the same to begin with; I'm not sure exactly what it is but I don't think its variance-based. However, it scales similarly.
2) It has rather strong quantizer-field smoothing. Clearly, the idea behind this AQ algorithm is to compensate for the varying texture complexities throughout a frame, something which AQ is very useful for. Unlike x264's method, its purpose doesn't seem to include saving bits on edges/transcients, which it doesn't do well due to the smoothing. Of course, its clear, as I said, that it wasn't meant to do that to begin with.

AQ settings in MC engine are quite powerfull, but only Cinevision gives full access to them. It applies all of them (Brightnes, Contrast and Complexity) at the same time. You can set from -100 to 100. It works very well with low light noise and you can nicely tweak your encode, by playing with amount of each AQ.
It looks like new Sony encoder (Blu-code) it's even better and has some new stuff, eg. like Adaptive Deblocking filter.

Andrew

poisondeathray

18th November 2008, 23:47

AQ settings in MC engine are quite powerfull, but only Cinevision gives full access to them. It applies all of them (Brightnes, Contrast and Complexity) at the same time. You can set from -100 to 100. It works very well with low light noise and you can nicely tweak your encode, by playing with amount of each AQ.
It looks like new Sony encoder (Blu-code) it's even better and has some new stuff, eg. like Adaptive Deblocking filter.

Andrew

Interesting. Do you think it's worth the $40,000.00 ? :)

http://pro.sony.com/bbsc/ssr/cat-editing/cat-encodingandauthoring/product-BAEVX1000/

kolak

19th November 2008, 00:06

Interesting. Do you think it's worth the $40,000.00 ? :)

http://pro.sony.com/bbsc/ssr/cat-editing/cat-encodingandauthoring/product-BAEVX1000/

If you compare it to other PRO encoders- yes, it's worth 40K.
It has built in capture module (uses Blackmagic card), slightly funny GUI (because it was made by Japanese programers) and lots of options. I think it's a good encoder. I may be able to tell more about quality soon.

Andrew

shon3i

19th November 2008, 00:42

like Adaptive Deblocking filter.Adaptive Deblocking filter is realy interesting, and very usefull to keep sharpness on higher deblocking. Ateme encoder have it aslo.

poisondeathray

19th November 2008, 00:58

If you compare it to other PRO encoders- yes, it's worth 40K.
It has built in capture module (uses Blackmagic card), slightly funny GUI (because it was made by Japanese programers) and lots of options. I think it's a good encoder. I may be able to tell more about quality soon.

Andrew

I suppose you're right, we are talking about 2 different levels, PRO and hobby folk (I'm in the latter category)

If you do pick this up, I'd love to see examples using the new features

Cheers

Dark Shikari

19th November 2008, 00:58

Adaptive Deblocking filter is realy interestingAll implementations of it that I have seen are simply a table of deblock offsets relative to quantizers: i.e. the theory that deblocking scales too heavily with regards to quantizer, and thus higher frame quantizers deserve lower deblocking offsets. Examples of this that I have confirmed to act this way are Ateme's original encoder (not sure about more recent ones) and the current Youtube encoder.and very usefull to keep sharpness on higher deblocking.I would suspect that deblock-aware RD or QNS would be much more effective at this. The entire point of "adaptive deblocking" is generally not to use higher deblocking.

LoRd_MuldeR

19th November 2008, 01:14

Isn't H.264 deblocking adaptive per definition? And the encoder can only choose α_offset and β_offset values?

Dark Shikari

19th November 2008, 01:22

Isn't H.264 deblocking adaptive per definition? And the encoder can only choose α_offset and β_offset values?"Adaptive deblocking", in the encoder world (not the standards world), generally refers to deblock offset set by the encoder on a per-frame level.

Yes, the H.264 loopfilter is "adaptive", but that use of the term isn't generally used when designing H.264 encoders, since everyone involved already knows how the deblocker works.

LoRd_MuldeR

19th November 2008, 01:29

But how more adaptive can the deblocking be than it already is per standard definition?

Since the deblocking algorithm is part of the H.264 specs and has to be known by the decoder, it cannot be influenced/changed by the encoder.

Well, except for setting the α_offset and β_offset values, which any decoder does...

kolak

19th November 2008, 01:32

Isn't H.264 deblocking adaptive per definition? And the encoder can only choose α_offset and β_offset values?

Ofset valuse change over the time. I don't know the algorytm, but after encoding you have a window which shows you what valuse are used over the time. You can change them anyway and do segment reencoding. I think it's quite useful option.

It's a powerfull encoder- can do full HD in real time on one 8 core machine with quite good quality. It has also farm encoding (for best quality mode=5 machines to get RT) option- so you can add as many machine as you have. Lots of options- something like Cienemacraft HDe.

Andrew

LoRd_MuldeR

19th November 2008, 01:43

Ofset valuse change over the time. I don't know the algorytm, but after encoding you have a window which shows you what valuse are used over the time. You can change them anyway and do segment reencoding. I think it's quite useful option.

Ah! So the α_offset and β_offset values can be set for individual frames, not only on a global scope (like x264 currently does).

Are there any thoughts on choosing α_offset and β_offset adaptively in x264? Would it correlate with VAQ maybe?

Dark Shikari

19th November 2008, 02:06

Are there any thoughts on choosing α_offset and β_offset adaptively in x264? Would it correlate with VAQ maybe?AQ already adapts deblock on a per-block level, as block quantizer determines deblock strength.

As I said, the only algorithm I have ever seen is one that simpler lowers the offset for higher quantizers. I've also heard of the idea of lowering it on unreferenced B-frames, but in my experience the visual effect is basically zero.

neuron2

20th November 2008, 20:33

Dark Shikari

20th November 2008, 20:55

@Zodiaque/azerty@qwaerty/Sagittaire

Stopping creating multiple accounts! What is your problem? We will help you to recover your original account. All new accounts from you will be immediately banned and posts deleted, so give it up.I'm going to guess that the purpose of creating multiple accounts is to create the appearance of a false consensus (sockpuppeting), not because anyone lost their password...

Sagittaire

22nd November 2008, 02:26

@ neuron2

thx for the account reactivation

Oh this is too funny. DS posted sample, graphs from a third party software, version number, and specific command line options.

... but this test is completely false. Like this thread show very well (see shon31 post) subjective quality is by nature ... subjective and for speed test you must compare speed exactly at same speed or quality exactly at same speed. You can make that only with metric here. There are many other error in Dark Shikari test.

azerty posted, hidden config files, no version numbers, no source sample, no way to verify what he has claimed. As well, if you look at the settings he used for x264 they are probably the most damaging for encoding on a first pass. x264 achieved a 90fps first pass while main-concept did a 54fps first pass, and yet your saying that main-concept is just as fast while providing equal quality?

It's not hidden config files. You can reproduce easely my test with graphedit and with directshow Mainconcept/Elecard filter:

1) If x264 can make encoding at 100 fps then MC can too. It's just that MC don't show the good setting for make that in the different gui.

2) Make multipass encoding with high differential speed is useless because the speed gain begin really small with high potential damaging prediction for second pass.
10000/100 + 10000/10 = 100 + 1000 = 1100 sec
10000/50 + 10000/11.11 = 200 + 900 = 1100 sec

Like you see really fast first pass (1:10 ratio with second pass) imply only ~10% for total time encoding. If you make first pass at ratio 1:5 you must only increase second pass speed encoding by ~10% too for obtain same final speed. With slower second pass encoding here you increase really prediction for second pass and final quality will be certainely better even with faster setting in second pass. Mainconcept choose this way with ~1:4 ratio between first and second pass for insane quality mode (total speed gain with higher ratio is marginal and final quality will be lower).

3) Ateme/Nero encoder use really particular fast first pass mode. Encoder analyse only 10% of the frame in first pass. You can potentially have first pass at 200 fps and more (with fastest mode at 100 fps for x264/MC) with nero/ateme. Dark Shikari test is one more time completely false because this fast first pass is active only with more than 10000 frames with nero gui or something like that.

Conclusion: Dark Shikari speed test is really bad ...

comparing X264 and MC in screenshots is even more crazy as booth use a complete different PSY approach and as shon3i and smok3 allready said part of that is MC's Quantization approach it is different and it looks far different then compared to X264 in motion (more stable like every object is glued to it's position and only moves when it actually is moving) and also everyone here forgets that MC removed complexity masking, who saw it in action knows how compareable it is to X264 VAQ

It's not because gui don't show the setting that setting are not always here in SDK. You can always use MaskingStrength and MaskingType in the last 7.5.0 SDK version.

So just lets wait for DivX Encoder Beta and see all the stuff in action there (hopefully), and then compare till then X264 also has some time to improve

I made test with DivX H.264 Codec CLI and CLI produce exactly the same quality than Mainconcept SDK simply because it use exactly the same h264vout.001 file binary than all Mainconcept/Elecard gui. For example you can easely change the h264vout.001 binary from divx (7.3.0 SKD for DivX CLI) with other SDK h264vout.001 binary from other gui (I make that to use the last 7.5.0 binary just with little file rename).

neuron2

22nd November 2008, 02:36

thx for the account reactivation Welcome back. I love happy endings!

CruNcher

23rd November 2008, 09:43

@ neuron2

thx for the account reactivation

... but this test is completely false. Like this thread show very well (see shon31 post) subjective quality is by nature ... subjective and for speed test you must compare speed exactly at same speed or quality exactly at same speed. You can make that only with metric here. There are many other error in Dark Shikari test.

It's not hidden config files. You can reproduce easely my test with graphedit and with directshow Mainconcept/Elecard filter:

1) If x264 can make encoding at 100 fps then MC can too. It's just that MC don't show the good setting for make that in the different gui.

2) Make multipass encoding with high differential speed is useless because the speed gain begin really small with high potential damaging prediction for second pass.
10000/100 + 10000/10 = 100 + 1000 = 1100 sec
10000/50 + 10000/11.11 = 200 + 900 = 1100 sec

Like you see really fast first pass (1:10 ratio with second pass) imply only ~10% for total time encoding. If you make first pass at ratio 1:5 you must only increase second pass speed encoding by ~10% too for obtain same final speed. With slower second pass encoding here you increase really prediction for second pass and final quality will be certainely better even with faster setting in second pass. Mainconcept choose this way with ~1:4 ratio between first and second pass for insane quality mode (total speed gain with higher ratio is marginal and final quality will be lower).

3) Ateme/Nero encoder use really particular fast first pass mode. Encoder analyse only 10% of the frame in first pass. You can potentially have first pass at 200 fps and more (with fastest mode at 100 fps for x264/MC) with nero/ateme. Dark Shikari test is one more time completely false because this fast first pass is active only with more than 10000 frames with nero gui or something like that.

Conclusion: Dark Shikari speed test is really bad ...

It's not because gui don't show the setting that setting are not always here in SDK. You can always use MaskingStrength and MaskingType in the last 7.5.0 SDK version.

I made test with DivX H.264 Codec CLI and CLI produce exactly the same quality than Mainconcept SDK simply because it use exactly the same h264vout.001 file binary than all Mainconcept/Elecard gui. For example you can easely change the h264vout.001 binary from divx (7.3.0 SKD for DivX CLI) with other SDK h264vout.001 binary from other gui (I make that to use the last 7.5.0 binary just with little file rename).

Jep i know that but for me 1Pass quality is important and it's hard to beat X264 here especially in certain situations you need VAQ to compensate Rate Controll inefficiency.
Ateme doesn't need those i would call it balancing, because they have instead of both Mainconcept/X264 a nice working Lookahead :) which hopefully X264 has sooner or later too

kuka2

24th November 2008, 14:38

Couple words about Elecard and Mainconcept encoders.
Elecard people do not work on Mainconcept version of AVC encoder for at least 8-9 months. They released Elecard G4 encoder SDK in April 2008, current Elecard AVC Encoder has version number 1.2 and completely different from Mainconcept one, hasn't many features - two-pass for example, but about twice faster at the same quality. It is used in Elecard Converter Studio starting from v.3.0.
Elecard stopped to use any MC components in their applications from June 2008.
I'd like to suggest you to test CS v.3.1 for Elecard encoder and Reference 1.6.1 for Mainconcept one.

jakor

24th November 2008, 14:46

Atak_Snajpera

24th November 2008, 15:02

DS, as far as I know elecard now ships their own AVC encoder, they do not ship MC encoder inside of the converter application anymore, so you might be testing completely irrelevanant software, either very old mc encoder or elecard avc encoder.
For me Elecard AVC Encoder is useless if I cannot use .avs files as source. I always get error messages. I really want to make few tests (game footage , demoscene footage and so on)...

Dark Shikari

24th November 2008, 17:16

DS, as far as I know elecard now ships their own AVC encoder, they do not ship MC encoder inside of the converter application anymore, so you might be testing completely irrelevanant software, either very old mc encoder or elecard avc encoder.That would be a rather interesting discovery, as one of the guys at Mainconcept pointed me to the trial of the latest version of their encoder, which I proceeded to test...

... and found that (at least IMO, visually) it looked significantly worse than the output of "Elecard HD Converter".

That doesn't seem likely though, as the options in Elecard still exactly match what I know of the Mainconcept API, and I doubt if they made their own encoder that it would just happen to exactly mirror Mainconcept's.

jakor

24th November 2008, 18:54

That would be a rather interesting discovery, as one of the guys at Mainconcept pointed me to the trial of the latest version of their encoder, which I proceeded to test...

... and found that (at least IMO, visually) it looked significantly worse than the output of "Elecard HD Converter".

That doesn't seem likely though, as the options in Elecard still exactly match what I know of the Mainconcept API, and I doubt if they made their own encoder that it would just happen to exactly mirror Mainconcept's.
So for now you're upto make one more test - compare elecard, mc and x264 ;-)

Sagittaire

24th November 2008, 20:06

Elecard people do not work on Mainconcept version of AVC encoder for at least 8-9 months. They released Elecard G4 encoder SDK in April 2008, current Elecard AVC Encoder has version number 1.2 and completely different from Mainconcept

No. MC/Elecard use the same SDK for the last gui (Reference and Converter).

one, hasn't many features - two-pass for example, but about twice faster at the same quality. It is used in Elecard Converter Studio starting from v.3.0.
Elecard stopped to use any MC components in their applications from June 2008.
I'd like to suggest you to test CS v.3.1 for Elecard encoder and Reference 1.6.1 for Mainconcept one.

1) Converter and Reference are simply gui for Mainconcept/elecard SDK codec.

2) The SDK codec in Reference and Converter are exactly the same with exactly the same internal command line.

3) G4 codec are really not twice faster than precedent generation. G4 codec is parhaps 10%-15% faster than my old cli version 2.1.6907 (mercredi 11 octobre 2006, 13:18:26) with best quality/speed setting (3 pyramid bframe, fast rdo, no satd, fast inter, fast multiref, 5 ref, wpred). Converter can use fast first pass and Reference can't but like always it's just gui limitation.

kolak

24th November 2008, 23:37

If anyone is interested Blu-code is a killer :)
The way how it copes with grain or low light digital noise is quite impressive. I'm not sure how it works at 8Mbit, but at typical bitrates for Blu-ray it's the best encoder I've seen.

Andrew

LoRd_MuldeR

24th November 2008, 23:41

If anyone is interested Blu-code is a killer :)
The way how it copes with grain or low light digital noise is quite impressive. I'm not sure how it works at 8Mbit, but at typicla bitrates for Blu-ray it's the best encoder I've seen.

Andrew

Got any samples? :D

kolak

24th November 2008, 23:47

Got any samples? :D

Yes, but I can't make them public. Frame examples (source/encoded) is enough ?

Andrew

LoRd_MuldeR

25th November 2008, 00:03

Yes, but I can't make them public. Frame examples (source/encoded) is enough ?

Andrew

I think a short clip would be most interesting. Preferably a Blu-code and a x264 encode of the same size/bitrate...

kolak

25th November 2008, 00:20

I think a short clip would be most interesting. Preferably a Blu-code and a x264 encode of the same size/bitrate...

Sorry- can't do even frame grabs.

Have a look here for GUI grabs instead :)

edited (forgoten about the link):

http://www.sonycreativesoftware.com/products/bluprint.asp?page=blucodess

Andrew

LoRd_MuldeR

25th November 2008, 00:26

Sorry- can't do even frame grabs.

Have a look here for GUI grabs instead :)

Andrew

If you can't publish any segments of your super-secret source, why not use one of the publicly available HD samples to do the test?

kolak

25th November 2008, 00:32

If you can't publish any segments of your super-secret source, why not use one of the publicly available HD samples to do the test?

It's not about source (I could use any), but about actual file from Blu-code- I can't make it public.

Andrew

TL0

25th November 2008, 00:40

Blu-code?

Are you talking about this Sony encoder?

http://pro.sony.com/bbsc/ssr/cat-editing/cat-encodingandauthoring/product-BAEVX1000/

kolak

25th November 2008, 00:45

Blu-code?

Are you talking about this Sony encoder?

http://pro.sony.com/bbsc/ssr/cat-editing/cat-encodingandauthoring/product-BAEVX1000/

Yes.

Andrew

LoRd_MuldeR

25th November 2008, 01:14

So you got a (legal) copy of that software, but you can't publish any output (no matter what content) from it? :confused:

kolak

25th November 2008, 01:17

So you got a (legal) copy of that software, but you can't publish any output (no matter what content) from it? :confused:

Yep.
During trial period I can't make public anything which comes out from this encoder.

I can always encode any given source and compare it with x264. You have to trust my word of course :)

Andrew

RunningSkittle

25th November 2008, 03:11

From the Sony blu-code brochure:
System Requirements: Workstation
Recommended Workstation: HP xw8600
Operating System: Windows® XP® Professional x64 Edition
Windows Vista® Business x64 Edition
Windows Server 2003, Standard x64 Edition1
CPU: Intel Quad Core Xeon® 3.2 GHz or higher2
Memory: 8 GB or higher
Graphics: Support PCI-Express x 16
HD-SDI I/O card:3 Blackmagic Design Decklink HD Pro 4:4:4 PCIe™/
Decklink HD Extreme4
HDMI I/O card:3 Blackmagic Design Intensity™4
Storage for Data Volume: SAT AII/III internal HDD x 5 units or more, RAID0
USB Port: For Hardware Key
Others: RS-422 port for VTR control
i.LINK port for Handycam camcorder control
1 Window Server 2003 is for encoding made in a distribution encoding system (not for use with a single workstation)
2 AMD CPU is not recommended; this application is optimized for Intel CPU.
3 These two cards cannot be installed in one PC at the same time.
4 These two are the only I/O cards supported as of September 2008.

o.0

CruNcher

25th November 2008, 04:39

So for now you're upto make one more test - compare elecard, mc and x264 ;-)

hmm i doubt that is necessary Mainconcept for sure didn't bought Elecard for fun or to just get the Russian market they wanted their Core Technology (R&D), and that should be mostly know inside of Mainconcepts stuff instead of their allways weaker AVC Technology that was in their old Encoder (basically a modified Reference Encoder with GUI) :P and pretty much the newest stuff is working inside the DivX incarnation :) also the Decoder is much more Advanced then Elecards/Mainconcept current AVC one and almost reaches CoreAVC.

Golgot13

25th November 2008, 13:46

CruNcher

25th November 2008, 21:09

Hi all,

BAEVX1000, aka BluCode, is a nice software (better than Mainconcept core so than Cinevision).
But there are lot of (really) feature to optimize the video, so many authoring companies will never use
the full power of BluCode. With default preset, video quality from Cinevision is same that BluCode
(with "normal" video) .

Today, to my mind, the next level for H264 encoder is the realtime encoding process !!!
I'm not sure that lot of company will buy BluCode because they had CineVision and,
BluCode is slow (need lot of CPU power) and expensive....

HVS or compression efficiency wise better in your eyes, or both ?
tough it wouldn't surprise me the average Joe doesn't see a lot of the R&D stuff of Sony and all the big main H.264 Developers, but you can estimate on the papers and their are some very interesting ones in terms of improvements released in the past if they included a lot of them i would guess they could beat Mainconcept easily with their workforce @ it :)
For Average Joe Sonys Encoder status is still the old one that's available in Vegas :)