Cinevision vs x264

[jpsdr]

Hello

In an old post, someone said that for grain, he found that cinevision was a little better than x264. But it was even before mb-tree was done.

Does someone know, in the actual state of x264 (mb-tree + b-pyramid + weightp + etc...), for source with no grain, wich between Cinevision and x264 give the better result ?
It's in the idea of making blu-ray, so average bitrate will be globaly high (around something like 15000kb-20000kb), so it's not for low bitrate.

The only sure advantage for now with Cinevision is to be (in theorie) 100% blu-ray compliant. But, with all the improvement in x264, i've the felling that it may be better than Cinevision, but if there is someone who have allready made tests, i'm interested in.

[LoRd_MuldeR]

I don't how old that post you are referring to is, but x264 should provide excellent grain retention now. Only make sure you use "--tune film" or "--tune grain" for such material.

Using one of the "slower" presets won't hurt either ;)

About BluRay compatibility: x264 should be able to produce 100% BluRay compatible output now. Slices are supported now, B-Pyramid has a BluRay compatible mode and so on.

However you (currently) may still need a build with the NAL HRD patch, if I'm not mistaken...

[roozhou]

Cinevision uses Mainconcept's encoder SDK. Your question should be "Mainconcept vs x264".

[jpsdr]

I don't how old that post you are referring to is, but x264 should provide excellent grain retention now. Only make sure you use "--tune film" or "--tune grain" for such material.

As i said, this point was not relevant, as it's for encoding source without grain. So, as it was the only point wich the user said it prefer Cinevision (Mainconcept), i was wondering what was the actual status, and even more, for source without grain.

I know that with nal_hrd patch, in theory x264 produce blu-ray compliant stream, and more, nal_hrd is about to be committed, so it'll soon no longer be a patch.

With the information i can gather for now, my guess is that x264 is better than Cinevision (Mainconcept), but if possible, i wanted more than a guess, if by chance someone have already made some test to compare.

[SquallMX]

Small, unscientific comparation, 7.5 Mbps (Max 15 Mbps, Buffer 24 Mbps, Keyint 48) 1080p:

x264 1273 (--deblock -2:-1 --b-adapt 2 --direct auto --slices 4 --qpmax 44 --ipratio 1.1 --pbratio 1.2 --rc-lookahead 48 --ssim --bframes 3 --mvrange 511 --aud --nal-hrd --weightp 0):
http://www.imagechile.net/img/X2641111.png
http://www.imagechile.net/img/X26411061.png

Cinevision AVC 3.0 (Default Settings):
http://www.imagechile.net/img/CV1617.png
http://www.imagechile.net/img/CV21767.png

Cinevision VC-1 3.0 :eek:(Default Settings):
http://www.imagechile.net/img/VC11072.png
http://www.imagechile.net/img/VC21581.png

IMHO x264>>CineVision 3.0 AVC>>>>VC-1

[poisondeathray]

I don't think there was ever a question at low bitrates, that x264 holds a huge advantage. I think it reasonable to say that 7.5Mb/s for this source is "low."

I think there were some people (or maybe 1 person) that argued that at high bitrate ranges, they preferred Cinevision.

IMO I find it hard to believe. If x264 can achieve a certain level of quality at a much lower bitrate, when you increase the bitrate it should improve the results. (i.e. how does x264 suddenly become worse, or how does Cinevision suddenly become better in that higher range)? I know it's not a linear relationship for the compression or if you use PSNR /bitrate plots.

[Dark Shikari]

"X is tuned for high bitrates" is a euphemism for "X sucks, so it needs high bitrates to generate good results".

[jpsdr]

DS, i love your comment...

[Keiyakusha]

Guys can you post links to images instead of embedding them into post? Thanks.

[Chengbin]

I think that comment was made in Lyris's "x264 encoding for BD" thread where Lyris wants to use x264 instead of pro encoders to encode the Blu-ray movie project he's working on.

I highly doubt an encoder can be tuned for high bitrate. I highly doubt another H.264 can beat x264 in picture quality, even without mbtree and weighted P frames.

[LoRd_MuldeR]

I highly doubt an encoder can be tuned for high bitrate.

Of course not. Unless a encoder is completely broken, it will always look better (or at least equivalent) when increasing the bitrate. So an encoder that retains good quality at low bitrates will retain even better quality at high bitrates. But this conclusion certainly doesn't work the other way around! Also: The higher the bitrate, the less challenging it is to retain good quality. Hence the difference between "good" and "bad" encoders fades with increasing bitrate. Even the most crappy encoder can retain transparent quality, if you only raise the bitrate enough. Therefore encoders must always be compared at a reasonable bitrate. You should neither use an ultra-high bitrate where all encoders look transparent nor an ultra-low bitrate where all encoders look horrible...

[Manao]

I would disagree. Low bitrate conveys a notion that the bitrate is indeed too low for the video, thus that artifacts will be present but acceptable. Thus, being good at low bitrates means having some artifacts, but not too much, or are least less than the competition.

Reversely, high bitrate implies at least lack of artifacts (which is not the same as transparency). And nothing guarantees that a good encoder at low bitrates (thus with a manageable amount of artifacts) will keep the artifacts at bay at high bitrates.

As a (somewhat) contrived example, you can consider x264, before weightp. It was considered good at low bitrates, even on video with some fades. However, at high bitrates, it might have broken down on some fades, and compared to an encoder that did handled fades, with perhaps less transparency throughout the movie, but artifact free on the fades, I would have considered it worse.

[shon3i]

Cinevision AVC 3.0 (Default Settings):
I am not saying that Cinevision will beat x264, but you should play with FGO, AQ, Pulse reducition, DVO Grain, you will get much better and maybe best results IMHO.

[Dark Shikari]

I would disagree. Low bitrate conveys a notion that the bitrate is indeed too low for the video, thus that artifacts will be present but acceptable. Thus, being good at low bitrates means having some artifacts, but not too much, or are least less than the competition.

Reversely, high bitrate implies at least lack of artifacts (which is not the same as transparency). And nothing guarantees that a good encoder at low bitrates (thus with a manageable amount of artifacts) will keep the artifacts at bay at high bitrates.

As a (somewhat) contrived example, you can consider x264, before weightp. It was considered good at low bitrates, even on video with some fades. However, at high bitrates, it might have broken down on some fades, and compared to an encoder that did handled fades, with perhaps less transparency throughout the movie, but artifact free on the fades, I would have considered it worse.It depends what you consider "low bitrate". Indeed, at very low bitrates, one has to accept artifacts somewhere, which is where MB-tree is most effective: it destroys quality in some parts of a scene in order to maximize quality everywhere else--and this is acceptable.

At medium bitrates, I don't think this holds true any longer; I don't think you need to go anywhere near "high bitrates" for this to stop being as true. So the point about fades is equally valid for medium bitrates, really.

I'd define "low bitrates" as CRF > 28, "medium bitrates" as 28 > CRF > 18, and "high bitrates" as CRF < 18, roughly.

[Sagittaire]

I'd define "low bitrates" as CRF > 28, "medium bitrates" as 28 > CRF > 18, and "high bitrates" as CRF < 18, roughly.

In my memory BD H264 casino royal stream at 35 Mbps use somethink like ~q22 for average quant with extremely high quality ...

[Chengbin]

In my memory BD H264 casino royal stream at 35 Mbps use somethink like ~q22 for average quant with extremely high quality ...

How can you get qp value for an already encoded video?

[LoRd_MuldeR]

How can you get qp value for an already encoded video?

Read it out from the encoded stream? But be aware that you look at the block quantizers, not only the frame quantizers.

[Dark Shikari]

In my memory BD H264 casino royal stream at 35 Mbps use somethink like ~q22 for average quant with extremely high quality ...I said CRF, not quantizer. x264 at CRF 25 can have average quants of 30-35 or more in some cases.

[poisondeathray]

Read it out from the encoded stream? But be aware that you look at the block quantizers, not only the frame quantizers.

squallmx is using ffdshow's osd to display the frame quantizers in his screenshots

Are you saying those are "block quantizers"?

What is the significance of this difference? I vaguely remember it being discussed but the search function is limited

Thanks

[Dark Shikari]

squallmx is using ffdshow's osd to display the frame quantizers in his screenshots

Are you saying those are "block quantizers"?

What is the significance of this difference? I vaguely remember it being discussed but the search function is limited

ThanksFrame quantizers can be completely misleading, since they don't actually have to mean anything: you could have a frame quantizer of 0 and every block having a quantizer of 51. It all depends on how the encoder works.

[LoRd_MuldeR]

squallmx is using ffdshow's osd to display the frame quantizers in his screenshots

Are you saying those are "block quantizers"?

I don't think ffdshow's OSD displays the average block quantizer, but the frame quantizer. Hence that info can be completely misleading, for the reasons mentioned by Dark Shikari.

However ffdshow also offers a "Visualization" feature, which can display the motion vectors as well as the individual block quantizers...

[Emulgator]

Squall MX, in your comparison you wrote

x264 1273 (--deblock -2:-1 --b-adapt 2 --direct auto --slices 4 --qpmax 44 --ipratio 1.1 --pbratio 1.2 --rc-lookahead 48 --ssim --bframes 3 --mvrange 511 --aud --nal-hrd --weightp 0):

Had it been really 1273 or probably 1373 ?

(nice comparison BTW, I see the same Mainconcept structured-and-per-frame-changing-blocks-for-grain as in Mainconcept MPEG2 XS, standalone 1.5.1 etc.)

[Emulgator]

However ffdshow also offers a "Visualization" feature, which can display the motion vectors as well as the individual block quantizers...

Many thanks for pointing me to this one, LoRd_MuldeR.

For quite some time I was looking for a tool to estimate the quality of my encodes,
especially if encoders take their time to do motion search and output useful motion vectors
or just skip this and spend their time and bits on DCT alone.

Back in 2003 somewhere in paper a tool named Pframe was mentoned, but I never found it.
ffdshow rules!

[LoRd_MuldeR]

You can also use this tool to analyze H.264 streams in Detail:
http://h264visa.com/downloads.html

It's not free, but there's a free trial period. And after you re-install you can have the trial again ;)

[SquallMX]

Squall MX, in your comparison you wrote

x264 1273 (--deblock -2:-1 --b-adapt 2 --direct auto --slices 4 --qpmax 44 --ipratio 1.1 --pbratio 1.2 --rc-lookahead 48 --ssim --bframes 3 --mvrange 511 --aud --nal-hrd --weightp 0):

Had it been really 1273 or probably 1373 ?

My bad, I used x1373 x86 ICC by techouse.

BTW Cinevision has a lot of filters for optimize the encoding quality, an advance user could create a better looking video, I just used the default settings :helpful:. Still VC-1 encode looks really bad :confused:...

[shon3i]

Still VC-1 encode looks really badWhat a suprise :rolleyes:, VC-1 is very weak comparing to H264 with those bitrates. Anyway Mainconcept VC-1 implementaion is not worth mentioning,there is other VC-1 solutions which can easily cope with H264 implementations, but in certain ranges. Cinevision H264/AVC need more tweaks and quality will be much raised. Default settings are usefull for 20mbps and up ;)

[Biggiesized]

CineVision's VC-1 implementation is garbage. I truly mean that. It's nothing like PSE.

I think CineVision is probably the worst professional encoder. However, it has a lot of good filters (which I am against using) and it is EXTREMELY user friendly.

I've done test encodes on the Crowd Run sequence with Blu-code, CineVision, PSE and x264. In terms of quality and grain retention, x264 bested them all. Blu-code and PSE were a toss-up; Blu-code had fewer visible artifacts, but PSE held more detail. CineVision was just terrible all the way around.