your thoughts on MainConcepts H.264 encoder?

[Sharktooth]

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

[Dark Shikari]

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]

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]

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

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]

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"

[Guest]

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

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]

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]

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

[Guest]

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

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.

[Bigmango]

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]

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

[Sharktooth]

same here. claiming something without visual proof is useless.

[cogman]

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]

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]

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]

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]

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]

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]

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]

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

[MasterNobody]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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

[LoRd_MuldeR]

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]

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]

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 ?

[Dark Shikari]

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]

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]

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]

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]

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]

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