MainConcept Reference 2.0 is out

[dand]

MainConcept Reference 2.0 is out, check it out...

[shon3i]

Nice, what version of Mainconcept SDK is used?

And does it support all advanced options that can be found in Sonic Cinevision? Like several AQ modes

[mp3dom]

I think also Rhozet uses the latest SDK from MainConcept. It has the same options as CineVision available to the user.

[roozhou]

Nice, what version of Mainconcept SDK is used?

And does it support all advanced options that can be found in Sonic Cinevision? Like several AQ modes
Current version of Sonic Cinevision is using an outdated version of MainConcept SDK(~2006). Please wait for new version of CV with up-to-date MainConcept AVC/VC1/MPEG2 encoder.

[shon3i]

Current version of Sonic Cinevision is using an outdated version of MainConcept SDK(~2006). Please wait for new version of CV with up-to-date MainConcept AVC/VC1/MPEG2 encoder.
I think i have Cinevision 3 IIRC, i didn't check which SDK uses. Anyway x264 will soon replace all my H264 encoders :)

[roozhou]

I think i have Cinevision 3 IIRC, i didn't check which SDK uses. Anyway x264 will soon replace all my H264 encoders :)

Yes, i was referring to CineVision 3.0.

[mp3dom]

I think i have Cinevision 3 IIRC, i didn't check which SDK uses. Anyway x264 will soon replace all my H264 encoders :)

Yeah, maybe only progressive encodes at the moment :)

[kieranrk]

Yeah, maybe only progressive encodes at the moment :)

Interlaced will probably beat any mbaff encoder anyway.

[mp3dom]

You mean actually or in the near future? Anyway, nice!

[shon3i]

I just checked Reference 2, and it contain encoder from sdk 8.5, which is very very fresh :), and GUI come with all advanced options such AQ. I didn't encode yet, but i think this is big step for Mainconcept to back on H264 scene :)

[aegisofrime]

A very noob question here, but I suppose judging by the screenshots on Mainconcept's website, one can't use Avisynth with it? It looks to be a very consumer oriented, overly user-friendly application.

[shon3i]

Good thing is aslo that support 10-bit encoding

[mp3dom]

The previous Reference supports AVS files (not directly, but you can use the *.* filter and point to avs file and it will be recognized as AVI) so it seems strange that the new version doesn't support it

[poisondeathray]

Good thing is aslo that support 10-bit encoding

as a source or encoding for export?

[shon3i]

as a source or encoding for export?
Prue 10-bit encoding, output is 10-bit. Support High 10 Profile.

AVC-Intra Class 50 and 100 support.

I think is need to deep test of this :)

[Blue_MiSfit]

Oooooh!!

This is integrated with the latest Rhozet release? I have a big farm at work. Maybe I can run some x264 comparison encodes for VOD type scenarios - aka 9mbps CBR 1080p, 4.5mbps CBR 720p, and 2mbps CBR 480p

~MiSfit

[mp3dom]

Reading their press-release seems that the latest version (3.13 or 3.14 or something similar) improves the AVC encoding using the latest SDK from MainConcept (but I don't know if it's the 8.5 version mentioned by shon3i). Anyway it has all the options previously available on CineVision.

[shon3i]

Reading their press-release seems that the latest version (3.13 or 3.14 or something similar) improves the AVC encoding using the latest SDK from MainConcept (but I don't know if it's the 8.5 version mentioned by shon3i). Anyway it has all the options previously available on CineVision.
Yes but Cinevision even now in version 3 (i just checked) use SDK version 7.0 - 7.4, Mainconcept reference 2 not restricted to Blu-Ray so can use full features of H264.

[poisondeathray]

shon3i are you going to do some tests when you get a chance? :)

[roozhou]

Yes but Cinevision even now in version 3 (i just checked) use SDK version 7.0 - 7.4, Mainconcept reference 2 not restricted to Blu-Ray so can use full features of H264.
The new version will use 8.6 SDK.

[Sagittaire]

Well I check 8.5 SDK and this realise seem really interessing

news options:
- p and b frame weight pred
- Custom matrix quantisation
- New AQ option (previous are luma, contrast and complexity)
- Adaptative deblocking

Reference gui seem little buggy with limitation:
- bref and pyramid buggy
- no CQM, b weight pred, adaptative deblocking setting
- inter and intra 8*8 desactived by default

[shon3i]

I think some features like adaptive deblocking is turned on by default in reference. I get original sharp even with 0:0 setting

[Dark Shikari]

I really hope this "reference" is some sort of practical joke.

(500kbps 2-pass, max settings, x264 partition/frametype options set to be comparable, Mainconcept using +60% complexity mask, which seemed to give very vaguely similar quantizer results to x264's AQ)
Mainconcept / x264
(NB: x264 was ~7% smaller in this test)
http://i49.tinypic.com/eqp1nb.pnghttp://i46.tinypic.com/20zskeg.png

(2500kbps 2-pass, max settings, roughly the same as above)
Mainconcept / x264
(NB: x264 was ~3% larger in this test)
http://i46.tinypic.com/33f3x8p.pnghttp://i46.tinypic.com/90c6mc.png

I mean seriously, I remember previous versions doing better than this. Or maybe x264's gotten better faster than Mainconcept has (since the last comparison).

[iwod]

I just checked Reference 2, and it contain encoder from sdk 8.5, which is very very fresh :), and GUI come with all advanced options such AQ. I didn't encode yet, but i think this is big step for Mainconcept to back on H264 scene :)

How is is fresh when newest is 8.6?

[iwod]

@DS - You mention previously that X264 will be available for commercial product... any news yet?

[Blue_MiSfit]

wooooow. I just just interest in Mainconcept again :)

Make me a batch encoding system like Carbon Coder with x264, and a native ProRes decoder. I'll pay you millions of dollars :)

[Dark Shikari]

@DS - You mention previously that X264 will be available for commercial product... any news yet?Really don't want to derail this thread too much more, but the current status is we have about 95% of the rights, we're negotiating with Avail Media, and we're working on our actual license agreement for commercial licenses.

I would say "expect it by summer".

[bob0r]

Fail has a version, version 2.0.
OUT NOW!

[Sagittaire]

Unfortunaly and curiousely Reference don't activate highest possible quality:
- grain optimisation
- pyramid and bref
- adaptative quantisation
- 8*8 inter and intra

IMO reference developpeur doesn't know really well the Mainconcept SDK codec ... lol


I really hope this "reference" is some sort of practical joke

yes ... because I obtain better quality with really old 2006 CLI but with all possible command line.

[iwod]

Unfortunaly and curiousely Reference don't activate highest possible quality:
- grain optimisation
- pyramid and bref
- adaptative quantisation
- 8*8 inter and intra

IMO reference developpeur doesn't know really well the Mainconcept SDK codec ... lol




yes ... because I obtain better quality with really old 2006 CLI but with all possible command line.

Arh.. so any comparison on SDK 8.5 / 8.6 with best settings?

Anyway, where can i find changelog for these updates?

[TEB]

I too agree on this, there are many companies in my field that would pay alot for a opensource system with paid help/consultant hours that roughly would be rhozet carbon coder + x264 in one "product", one can even make a payable pro version that would include options that companies would pay for..

br TE



Really don't want to derail this thread too much more, but the current status is we have about 95% of the rights, we're negotiating with Avail Media, and we're working on our actual license agreement for commercial licenses.

I would say "expect it by summer".

[iwod]

Well, it would at least save us poor soul from those absolute crap H.264 encoder that everyone is using.

[IgorC]

It will be more reasonable to look at Elecard encoder. Mainconcept and Divx are nothing more but Elecard H.264 encoder.

[poisondeathray]

It will be more reasonable to look at Elecard encoder. Mainconcept and Divx are nothing more but Elecard H.264 encoder.

Don't you have it backwards? Elecard used to license from MC (as do dozens of other companies), but released their own encoder about a year ago

[IgorC]

First MC H.264 encoders were pure Elecard's. MC has bought all rights for Elecard H.264 encoder.
That's why Elecard developers had to rewrite their own encoder.

[poisondeathray]

First MC H.264 encoders were pure Elecard's. MC has bought all rights for Elecard H.264 encoder.
That's why Elecard developers had to rewrite their own encoder.


Interesting. I know MC has been around for awhile. I remember using their encoder around ~2004. I think Sony and Adobe had licenced their encoder too around that time. Are you saying this was based on Elecard's ?

And how would looking at Elecard's rewritten encoder today give you information on todays MC implementation? Are they still very similar?

[shon3i]

I was thinking same that Elecard use Mainconcept SDK not vice versa. But i am not very suprised with new Elecard Encoder aslo, It's good but i don't think is better than current Mainconcept SDK 8.5/8.6, maybe i am wrong, i am not use Elecard since last beta test.

[kolak]

Really don't want to derail this thread too much more, but the current status is we have about 95% of the rights, we're negotiating with Avail Media, and we're working on our actual license agreement for commercial licenses.

I would say "expect it by summer".

Very interesting.
How are all the "doom9 people" (who have done thousands of hours of testing and without who x264 would be in dark ages) going to benefit from it?

[kolak]

Unfortunaly and curiousely Reference don't activate highest possible quality:
- grain optimisation
- pyramid and bref
- adaptative quantisation
- 8*8 inter and intra

IMO reference developpeur doesn't know really well the Mainconcept SDK codec ... lol




yes ... because I obtain better quality with really old 2006 CLI but with all possible command line.

Carbon Coder unlocks all of these settings as well as adaptive deblocking and some others.

Andrew

[kolak]

I really hope this "reference" is some sort of practical joke.

(500kbps 2-pass, max settings, x264 partition/frametype options set to be comparable, Mainconcept using +60% complexity mask, which seemed to give very vaguely similar quantizer results to x264's AQ)
Mainconcept / x264
(NB: x264 was ~7% smaller in this test)
http://i49.tinypic.com/eqp1nb.pnghttp://i46.tinypic.com/20zskeg.png

(2500kbps 2-pass, max settings, roughly the same as above)
Mainconcept / x264
(NB: x264 was ~3% larger in this test)
http://i46.tinypic.com/33f3x8p.pnghttp://i46.tinypic.com/90c6mc.png

I mean seriously, I remember previous versions doing better than this. Or maybe x264's gotten better faster than Mainconcept has (since the last comparison).

It looks like to strong settings for complexity mask. On some sources it's very sensitive.

[bob0r]

I think mainconcept mistakenly implemented Just Cause's motion blur module.

[shon3i]

Very interesting.
How are all the "doom9 people" (who have done thousands of hours of testing and without who x264 would be in dark ages) going to benefit from it?
AFAIK, x264 will remain free, only when you need to use it comercialy eg for Blu-Ray, you need licence which can cost or not!

[kolak]

AFAIK, x264 will remain free, only when you need to use it comercialy eg for Blu-Ray, you need licence which can cost or not!

I think it would be nice to charge some money and donate them to charity/wikipedia.


Andrew

[kieranrk]

AFAIK, x264 will remain free, only when you need to use it comercialy eg for Blu-Ray, you need licence which can cost or not!

This isn't true at all but I'll let Dark Shikari clarify.

[LoRd_MuldeR]

AFAIK, x264 will remain free, only when you need to use it comercialy eg for Blu-Ray, you need licence which can cost or not!

x264 is released under the GPL. Even if the developers decided to put x264 under some proprietary license at some point in the future (which they can do, if all people who contributed code agree), the last version/revision that was still released under GPL would remain "free" (GPL'd) until forever. You could still use it for free and you could even continue the development based on that code. That's guaranteed by the "Copyleft" principle of the GPL. Furthermore you do not need a special license to use x264 for commercial purposes, as the GPL explicitly allows everybody to use the software for free and for any purpose, including commercial purposes. Anyway, you would have to pay patenting fees to the H.264 patent holders (not to the x264 team), if you use x264 in a commercial application. And I guess that's what the "commercial license" is all about. Probably the x264 team will also offer "help & support" contracts to their commercial users - that's where money is made with OpenSource software...

[Dark Shikari]

x264 is released under the GPL. Even if the developers decided to put x264 under some proprietary license at some point in the future (which they can do, if all people who contributed code agree), the last version/revision that was still released under GPL would remain "free" (GPL'd) until forever.It's more than that, actually. The contributory license agreement we've used requires that x264 LLC release (under the GPLv2) any modification of x264 that it distributes.

In other words, we have intentionally legally tied our own hands to make it impossible to create a proprietary fork of x264. x264 will forever remain free.

[schweinsz]

It's more than that, actually. The contributory license agreement we've used requires that x264 LLC release (under the GPLv2) any modification of x264 that it distributes.

In other words, we have intentionally legally tied our own hands to make it impossible to create a proprietary fork of x264. x264 will forever remain free.
If I code for x264 and require that my code is free for personal use or freeware and charges for commercial purpose, is it feasible?

[Dark Shikari]

If I code for x264 and require that my code is free for personal use or freeware and charges for commercial purpose, is it feasible?All contributions to x264 are dual-licensed under the GPL and the contributory license agreement.

No matter what happens, it will always be free (under the GPL). Furthermore, there is the extra condition that any modified version distributed under the proprietary license must also be released as GPL.

Being under the GPL, of course, means all your changes will be free for use by anyone, for any purpose, with no restrictions on use.

[schweinsz]

All contributions to x264 are dual-licensed under the GPL and the contributory license agreement.

No matter what happens, it will always be free (under the GPL). Furthermore, there is the extra condition that any modified version distributed under the proprietary license must also be released as GPL.

Being under the GPL, of course, means all your changes will be free for use by anyone, for any purpose, with no restrictions on use.
But how can you make money with avail media? Can I join in that? I believe that I can improve the x264 greatly. Does avail media need more speed?

[Audionut]

I guess Avail says, "We really want this function. Code it for us, and we'll pay you."

[Dark Shikari]

I guess Avail says, "We really want this function. Code it for us and we'll pay you."Indeed, same as with any company that wants features from x264. We have had features sponsored by at least 5 separate companies, possibly more.

[dand]

x264 licence...

Off topic.

[dand]

Reference updated to version 2.1 :)

[shon3i]

Thanks :)

As i can see, Blu-Ray MVC encoder is included.

EDIT: and it uses newest 8.7 SDK :) that is realy nice ;)

[dand]

Reference 2.2 (http://www.mainconcept.com/products/apps-plug-ins/transcoding/reference.html) released!

[CruNcher]

Hehe maybe they fixed the Capture crash ;)

[Biggiesized]

Reference is so buggy that I'm tired of fussing with it and no longer use it.

[shon3i]

Reference is so buggy that I'm tired of fussing with it and no longer use it.
I didn't find is buggy, here work normally. I newer have at least bad expirience. Now contains SDK 8.8

[BlackSand]

Hi all!

Just tried latest Reference 2.2. I was interested in CUDA/GPU h264 encoder quality.

System: NB, i5-2410M / NV GT540M

Source: "I am Legend" movie trailer (h264, 1080p, ~8000Kbps).
Encoding -> 1024x with StaxRip/x264 and MC Ref. 2.2

StaxRip / x264 / Mode: Quality=20 / Film / Slower
~1300Kbps / encoding speed 12 FPS
http://img37.imageshack.us/img37/3450/iamlegendtrailerstax20f.jpg

MC Ref. / Slowest / Const. Quant. Highest (max settings) / SOFTWARE Enc
~1400Kbps / encoding speed 18-20 FPS
http://img600.imageshack.us/img600/7658/iamlegendtrailermcsoft1.jpg

MC Ref. / Slowest / Const. Quant.: Custom / GPU CUDA Enc
~1400Kbps / encoding speed 55-60 FPS
http://img18.imageshack.us/img18/5923/iamlegendtrailermc15cus.jpg

MC Ref. / Slowest / Const. Quant. Highest (max settings) / GPU CUDA Enc
~2000Kbps / encoding speed 55-60 FPS
http://img833.imageshack.us/img833/4629/iamlegendtrailermc15hig.jpg

Badaboom 2.0 / VBR / GPU CUDA
~1400Kbps / encoding speed 55-60 FPS
http://img823.imageshack.us/img823/1537/iamlegendtrailerbbvbr16.jpg

Well, for MC results are not bad, but both with GPU or software encoder video is slightly blurred with lost fine details. You can see it at buildings at the far end of the street, at the bus sign on the right, shop adv (Isolation) on the left, textures etc. And this is with all max settings.

MCR with software encoder gives better quality in low light than CUDA version, in spite of much bigger bit rate on CUDA.

CUDA version with "Quality" setting lower than highest gives seriously degrade in overall quality.

On CUDA version for variable bit rate mode only 1-pass is available.

With any settings GPU version gives almost the same encoding speed (55-60 FPS), which is funny. :confused:

In GPU version most of settings are greyed (locked out):
http://i42.tinypic.com/34he8so.png

http://i40.tinypic.com/rtfiic.png

And that's all settings we have. Not too much.

What I liked in MCR - CUDA speed. :) I think if MainConcept in next versions will bring more quality GPU version of encoder (without lost details and better low light performance), CUDA will still be significant faster than software version.

x264 gives the best quality. :D And can give more speed - preset Slow gives 24 FPS encoding speed and Medium 35 FPS, but at this bit rate only Slower preset gives good quality in low light areas.

It is pity that x264 does not implement CUDA for some tasks. I'm aware of Summer Code x264 2011 - http://wiki.videolan.org/SoC_x264_2011#GPU_motion_estimation and hope this will not just go to oblivion. :)

[MasterNobody]

It is pity that this again comparison of oranges vs. apples. Comparing quality (and so speed difference) at different bitrates is meaningless.

[BlackSand]

It is pity that this again comparison of oranges vs. apples. Comparing quality (and so speed difference) at different bitrates is meaningless.

1300 and 1400 is not so much difference. As of CUDA - yes, with the same settings encoder decides to use much more bit rate with resulting very similar quality as MCR software with less bitrate.

I have added CUDA screenshot with 1400 Kbps (custom quantizers).

Summary:
Quality of MCR software @ 1400 ~= MCR CUDA @ 2000.
Quality of MCR CUDA worse than MCR software at the same bit rate.
MCR at any settings and both GPU/Software has blurred picture comparing original and x264 rip and there is nothing to do with it.

[BlackSand]

Have added Badaboom 2.0 screenshot and reupload all pics (tinypic screwed quality day after).

About Badaboom with CUDA:
- same encoding speed as MCR CUDA ~55-60FPS
- only baseline and main profiles, minimum settings
- VBR only 1-pass
- Constant Quality mode = constant bit rate
- no quality vs speed settings @ CUDA mode
- sharp image with fine details (much better than MCR)
- but does not keep grain and destroy low contrast textures.

Overall image perception of Badaboom CUDA is better than MCR.

Still x264 is the best.

[BlackSand]

Here are the second scene from "I am Legend" trailer, low light test.

Original frame, resized to 1024
http://img714.imageshack.us/img714/1620/iamlegend21024.jpg

StaxRip / x264 / Mode: Quality=20 / Film / Slower
~1300Kbps / encoding speed 12 FPS
http://img267.imageshack.us/img267/6632/iamlegend2stax20filmslo.jpg

MC Ref. / Slowest / Const. Quant. Highest (max settings) / SOFTWARE Enc
~1400Kbps / encoding speed 18-20 FPS
http://img685.imageshack.us/img685/5831/iamlegend2mcsoft15quant.jpg

MC Ref. / Slowest / Const. Quant.: Custom / GPU CUDA Enc
~1400Kbps / encoding speed 55-60 FPS
http://img37.imageshack.us/img37/8905/iamlegend2mc15custom.jpg

Badaboom 2.0 / VBR / GPU CUDA
~1400Kbps / encoding speed 55-60 FPS
http://img683.imageshack.us/img683/4215/iamlegend2bbvbr1670.jpg

If i'm correct, Badaboom & MCR are the only encoders with their own CUDA implementation, others (i.e. MediaExpresso, MediaConverter, MediaCoder) use NV reference code with even worse quality.

[nm]

x264 at medium and veryfast presets might be interesting too. You probably need to adjust CRF for the veryfast version to reach about the same average bitrate.

[benwaggoner]

If i'm correct, Badaboom & MCR are the only encoders with their own CUDA implementation, others (i.e. MediaExpresso, MediaConverter, MediaCoder) use NV reference code with even worse quality.
Elemental Technologies certainly has their own.

Main Concept has their own CUDA implementation, which got quite a bit better in recent drops (although it also got more resource-intensive, particularly in memory). Expression Encoder 4 SP2 includes the latest MC CUDA stuff.

[poisondeathray]

Thanks

Are these same frame type comparisons ? (P vs. P etc...)

Any reason for the color discrepancies ?

[CruNcher]

Elemental Technologies certainly has their own.

Main Concept has their own CUDA implementation, which got quite a bit better in recent drops (although it also got more resource-intensive, particularly in memory). Expression Encoder 4 SP2 includes the latest MC CUDA stuff.

Sorenson Squeze 8 does also but i wonder for what did Nvidia Mental Rays department licensed x264 ;) ?
Also if that is correct and it got better then finaly it should be above Nvidias own Encoder Quality :P though not sure how much Nvidia still invests into updating their own @ least in the beginning it blew Mainconcepts away already with the fact supporting FreXt way before Mainconcept and the technical partnering between them ;)

Here are the second scene from "I am Legend" trailer, low light test.

Original frame, resized to 1024
http://img714.imageshack.us/img714/1620/iamlegend21024.jpg

StaxRip / x264 / Mode: Quality=20 / Film / Slower
~1300Kbps / encoding speed 12 FPS
http://img267.imageshack.us/img267/6632/iamlegend2stax20filmslo.jpg

MC Ref. / Slowest / Const. Quant. Highest (max settings) / SOFTWARE Enc
~1400Kbps / encoding speed 18-20 FPS
http://img685.imageshack.us/img685/5831/iamlegend2mcsoft15quant.jpg

MC Ref. / Slowest / Const. Quant.: Custom / GPU CUDA Enc
~1400Kbps / encoding speed 55-60 FPS
http://img37.imageshack.us/img37/8905/iamlegend2mc15custom.jpg

Badaboom 2.0 / VBR / GPU CUDA
~1400Kbps / encoding speed 55-60 FPS
http://img683.imageshack.us/img683/4215/iamlegend2bbvbr1670.jpg

If i'm correct, Badaboom & MCR are the only encoders with their own CUDA implementation, others (i.e. MediaExpresso, MediaConverter, MediaCoder) use NV reference code with even worse quality.

They use the Reference API and Quality depends on the driver mainly though also the settings used :) ISVs dont adapt also so fast to changes so quality can lower from time until a update, if something major changed in nvcuvenc.dll and the cuda part it makes use of.

Also Arcsoft has their own Encoder actually they have several different ones 1 low Quality Cuda Based (blazing fast), The Reference Nvidia Encoder and 1 Higher Quality x264 based (was majorly bugged with High QP <29,should have been fixed) ;)

Also the compare is not 100% the different colormetrix is visually a problem if you compare such fine details (noise), also missing Nvidias Reference API and Intel Quicksync for Comparison and using a higher quality source instead of a low complexity Apple Trailer Encode.

Elementals Consumer Encoder inside Badaboom is still not as enhanced as their Commercial one unfortunately the Consumer one is more optimized for Speed and getting big content to small devices very fast the Commercial one is balanced more towards Quality than Speed.

[kypec]

@CruNcher: with your high count of posts around here one would assume that you understand very well what is "Quote" button for...
Hint: it's certainly not for quoting a bunch of large screenshots from previous post. Please remove those and keep our forum clean.

[BlackSand]

So, a little summary list of encoders with CUDA implementation of h264:

CyberLink MediaEspresso - NVidia Reference
ArcSoft MediaConverter - NVidia Reference
MediaCoder - NVidia Reference
Main Concept Reference - their own
Elemental Badaboom - their own
Elemental "Pro" - their own; not accessible
Sorenson Squeeze - MainConcept

Anything else?

The first 3 (MediaEspresso, MediaConverter & MediaCoder) was reviewed in
http://www.behardware.com/articles/828-1/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-and-x264.html with CUDA, APP and QuickSync tests.

Artifacts, blurred pictures etc.

x264 at medium and veryfast presets might be interesting too.

StaxRip / x264 / slower / ~1300Kbps / enc. speed 12FPS
http://img842.imageshack.us/img842/6632/iamlegend2stax20filmslo.th.jpg (http://imageshack.us/photo/my-images/842/iamlegend2stax20filmslo.jpg/)

StaxRip / x264 / med / ~1350Kbps / enc. speed 35FPS
http://img819.imageshack.us/img819/8944/iamlegend2stax20filmmed.th.jpg (http://imageshack.us/photo/my-images/819/iamlegend2stax20filmmed.jpg/)

StaxRip / x264 / vfast / ~1300Kbps / enc. speed 75FPS
http://img809.imageshack.us/img809/7843/iamlegend2stax195filmvf.th.jpg (http://imageshack.us/photo/my-images/809/iamlegend2stax195filmvf.jpg/)

Differences not so much, but in dynamics it can be seen very clear and with this decent bit rate I'd use slower, not less.

Are these same frame type comparisons ? (P vs. P etc...)

Any reason for the color discrepancies ?

Definitely these are not I-frame. :)
About color - strange but MC video after encoding was dark (wrong dynamic range 16-235 & 0-255) and I corrected this before taking screenshot. May be something here was with color (mainly red) conversion too.

Also the compare is not 100% the different colormetrix is visually a problem if you compare such fine details (noise), also missing Nvidias Reference API and Intel Quicksync for Comparison and using a higher quality source instead of a low complexity Apple Trailer Encode.

Of course, you are right. It's just a "quick look" test to see if the quality gap between x264 and CUDA based encoders is still wide (around the same bit rate). And the answer - if you need quality, use x264.

I like Badaboom image on daylight scenes but in low light it's terrible. MainConcept gives soft image with lost details, a little better in low light than Badaboom but still bad. Only 1-pass VBR, minimum setting, limited 264 features, bugs...

The only hope for quality and fast encoding - x264 with implementing of some heavy computation tasks on CUDA/OpenCL. :)

[nm]

StaxRip / x264 / slower / ~1300Kbps / enc. speed 12FPS

StaxRip / x264 / med / ~1350Kbps / enc. speed 35FPS

StaxRip / x264 / vfast / ~1300Kbps / enc. speed 75FPS

Differences not so much, but in dynamics it can be seen very clear and with this decent bit rate I'd use slower, not less.

Maybe if you want transparent quality. But even the veryfast frame is way better than any of the CUDA sample frames you have there--and it was encoded faster.

Answer #2: If you need speed, use x264 (or Intel Quick Sync).

[iwod]

Interesting that you are on SandyBridge and decided not to include Quickync in your test.

May be an update with QuickSync?

[BlackSand]

Interesting that you are on SandyBridge and decided not to include Quickync in your test.

May be an update with QuickSync?

If you have installed discrete GPU, you don't have access to QuickSync engine. Some users can get workaround by use Lucid Virtu drivers (check f.e. http://hothardware.com/Reviews/Lucids-Virtu-Software-Combines-Best-of-Both-Worlds/), but this depends from motherboard, bios and configuration.

In my case Intel IGP (HD3000) just disabled without even NV Optimus to work. BIOS mod perhaps can change this but I don't want to try it yet.

Anyway, as I said earlier, QuickSync, CUDA, APP and Software encoders on different programs (x264, MediaEspresso, MediaConverter & MediaCoder) was reviewed here -
http://www.behardware.com/articles/828-1/h-264-encoding-cpu-vs-gpu-nvidia-cuda-amd-stream-intel-mediasdk-and-x264.html

They've made very informative "live" screenshots from Avatar and Inception with all available codecs and modes (include x264 with all presets). And QuickSync was not better than CUDA or APP in term of quality. Very soft, blurred picture. And since QS is a hardware based engine it's unlikely can be improved by new drivers. :D

[CruNcher]

And since QS is a hardware based engine it's unlikely can be improved by new drivers.

Wrong to some degree it can on the base its hard but several stuff can still be improved i saw improvements already with the newest drivers in my Desktop Recording Framework, same for Nvidia i analyzed dozen of driver and results in the beginning and they continuously improved it fixed especialy motion estimation problems (though i think that's one of the things that Intel cant change anymore)

[lutinor]

Question : It will be hard to implant gpu acceleration in x264 cli ? I guess yes but i dunno

[Midzuki]

Question : It will be hard to implant gpu acceleration in x264 cli ? I guess yes but i dunno

http://forum.doom9.org/showthread.php?t=156761

http://forum.doom9.org/showthread.php?t=157714