your thoughts on MainConcepts H.264 encoder?

[Dark Shikari]

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]

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

[Dark Shikari]

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]

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]

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]

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]

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.

[Guest]

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

[Dark Shikari]

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

@ 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).

[Guest]

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

[CruNcher]

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

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]

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.

[Atak_Snajpera]

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]

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]

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]

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]

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]

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]

Got any samples? :D

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

Andrew

[LoRd_MuldeR]

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]

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]

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]

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]

Blu-code?

Are you talking about this Sony encoder?

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

[kolak]

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]

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

[kolak]

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]

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]

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]

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....

[CruNcher]

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 :)

[Shinigami-Sama]

papers and their are some very interesting ones in terms of improvements

video encoding papers interesting?
0_0

[Golgot13]

For Average Joe Sonys Encoder status is still the old one that's available in Vegas :)

Only,
BAEVX1000 was made by two japanese guy...

You didn't go at last NAB because they were on it.