Log in

View Full Version : Comparing of grain preserving with AVC and VC1, an unproportionate result got.


raiechun
10th August 2007, 06:14
Before this result be posted some slower settings has been tested, the difference between slower and faster settings become small in the high bitrate, so the faster settings been used.

source: analog TV Capture, 60 secs with 1800 frames, VGA resolution, Montion JPEG compressed, http://www.megashares.com/?d01=a9ffc1c
avisynth filter: ColorYUV(levels="PC->TV")
compressed bitrate: 6336kbps
compression ratio: 17.454 (640 x 480 x12bit x 30fps / 6336kbps)

--compression--
AVC compression program: x264 cli 0.56.667 Cef's build
AVC quantization matrix: M4G HRM V2 from *.mp4 guy (http://forum.doom9.org/showthread.php?t=117041)
program settings: --pass 2 --bitrate 6336 --stats ".stats" --keyint 30 --min-keyint 0 --deadzone-inter 0 --deadzone-intra 0 --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --direct auto --nf --analyse all --8x8dct --qpmin 1 --qpstep 51 --ratetol 0.1 --thread-input --progress --no-dct-decimate --no-psnr --no-ssim --interlaced --output "" "" --aq-strength 0.75 --aq-sensitivity 10

VC1 compression program: Windows Media Encoder 9 with WMV9 advanced profile patch
program settings: mode= 2 Pass VBR, bitrate=6336kbps, resolution= use input size, keyframe interval= 1 sec, video optimization= keep interlaced, http://img9.imagepile.net/img9/6460vc1_fast_01.png

--result--
4 continious frames capture (PNG & JPEG format didn't make big difference in these image)

AVC
http://img9.imagepile.net/img9/676166336cbr_fast_aq0.75-10_cqm-m4g-hrm-v2[(000163)06-56-28].jpg
http://img9.imagepile.net/img9/397776336cbr_fast_aq0.75-10_cqm-m4g-hrm-v2[(000164)06-56-29].jpg
http://img9.imagepile.net/img9/216296336cbr_fast_aq0.75-10_cqm-m4g-hrm-v2[(000165)06-56-30].jpg
http://img9.imagepile.net/img9/10276336cbr_fast_aq0.75-10_cqm-m4g-hrm-v2[(000166)06-56-31].jpg

VC1
http://img9.imagepile.net/img9/23766vc1_vbr_6336k_024[(000164)02-50-49].png
http://img9.imagepile.net/img9/64047vc1_vbr_6336k_024[(000165)02-50-55].png
http://img9.imagepile.net/img9/76777vc1_vbr_6336k_024[(000166)02-51-00].png
http://img9.imagepile.net/img9/69384vc1_vbr_6336k_024[(000167)02-51-04].png

--

The current conclusion is, VC1 preserve grain much more than AVC.

benwaggoner
10th August 2007, 07:15
VC1 compression program: Windows Media Encoder 9 with WMV9 advanced profile patch
program settings: mode= 2 Pass VBR, bitrate=6336kbps, resolution= use input size, keyframe interval= 1 sec, video optimization= keep interlaced, http://img9.imagepile.net/img9/6460vc1_fast_01.png

Interesting, thanks!

You might have gotten even better grain retention at the same speed with:

Perceptual Option: Adaptive Deadzone

Manao
10th August 2007, 07:44
The current conclusion is, VC1 preserve grain much more than AVC.Mine is that your screenshots don't have the same colorimetry, that the AVC seems to have more noise, and that using an interlaced source is definitely not appropriate for such a test ( it would be on an interlaced display, but it's not on a progressive display, since interlacing artefacts tend to mask everything else )

zambelli
10th August 2007, 10:15
VC1 compression program: Windows Media Encoder 9 with WMV9 advanced profile patch
Patch? What patch?

program settings: mode= 2 Pass VBR, bitrate=6336kbps, resolution= use input size, keyframe interval= 1 sec, video optimization= keep interlaced, http://img9.imagepile.net/img9/6460vc1_fast_01.png
A few pointers:
* Set Dquant Option = I & P. You've got enough bits that you can afford to ensure smooth areas get the lowest quantizers
* Set Perceptual Option = Adaptive Dead Zone. I think you'll find it performs very well with grain.
* You'll probably get a slightly better result with 1 B-frame instead of 2. There's no need to match up the number of B-frames with x264 - they're completely different ratecontrols, so it's not like the GOP structures match up either. Might as well use 1 B-frame which seems to work best in VC-1.

Other comments:
* Yeah, I agree with Manao that the colorimetry is off. Not sure why though, your source seems to be in YV12 already.
* I also agree that comparing interlaced is a bad test of grain. Unless you're testing interlaced modes specifically and comparing field to field, you should probably use progressive instead.
* And most importantly: don't start with an already compressed source. You're using MJPEG for your capture. That already destroys some of the grain. Capture uncompressed if you can.

BTW, when people talk about grain, they typically are talking about film grain. Your captures look like TV captures.

Sharktooth
10th August 2007, 12:58
That's NOISE not grain...

Manao
10th August 2007, 13:08
Oh, and I forgot, why .jpg for AVC vs .png for VC1 ?

Dark Shikari
10th August 2007, 13:16
Variable colorimetry, JPG vs PNG? Doesn't seem like a fair test to me :p

Golgot13
10th August 2007, 14:09
JPG vs PNG? Colour ?
No PSNR + can not access at encoded files + result is specific frame + screenshoot not same format
-> I hope "Raiechun" is not a MS person.

Sharktooth
10th August 2007, 14:16
Probably... or a fanboy...

Terranigma
10th August 2007, 14:57
.jpg for the AVC
.png for the VC-1?
That's cheap :rolleyes:
No wonder it took the VC-1 Screenies to load longer than it's AVC counterpart. :scared:

honai
10th August 2007, 16:50
I hope "Raiechun" is not a MS person.


http://en.wikipedia.org/wiki/Tinfoil_hat

;)

Dark Shikari
10th August 2007, 17:13
http://en.wikipedia.org/wiki/Tinfoil_hat

;)In this case I wouldn't be surprised though :rolleyes::p

nurbs
10th August 2007, 17:25
*.mp4 guy recommends "--deadzone-inter 4" and "--deadzone-intra 6" for this matrix. Also why "--nf"?

honai
10th August 2007, 18:14
In this case I wouldn't be surprised though

Surprised by what?

Dark Shikari
10th August 2007, 19:11
Surprised by what?The OP being a Microsoft shill?

Golgot13
10th August 2007, 19:17
http://en.wikipedia.org/wiki/Tinfoil_hat

;)

Nice I need one ;)
I will try to order one at Mr Fox Mulder

Terranigma
10th August 2007, 19:47
The OP being a Microsoft shill?

raiechun could be Bill Gates in disguise. =P

benwaggoner
10th August 2007, 20:15
The OP being a Microsoft shill?
Our shills use DQuant and Adaptive Deadzone :).

zambelli
11th August 2007, 02:30
In this case I wouldn't be surprised though :rolleyes::p
I would certainly hope that if some random MS person decided to join a forum just to post biased comparisons, they'd do a better job of setting them up! Sheesh. :eek::rolleyes:

I'd say both Ben and I spend 30% of our work time just educating customers about video preprocessing in general. I'd kick myself if I ever set up a test that made the same mistakes I've told other people NOT to do.

raiechun
11th August 2007, 02:36
Thanks for comments, a second test has been done, the conclusion don't change.

--compression--
AVC compression program: x264 cli 0.56.667 Cef's build
AVC quantization matrix: M4G HRM V2 from *.mp4 guy (http://forum.doom9.org/showthread.php?t=117041)
AVC program settings: 2 part,

first part is --pass 2 --bitrate 6336 --keyint 30 --min-keyint 0 --deadzone-inter 0 --deadzone-intra 0 --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --direct auto --nf --analyse all --8x8dct --qpmin 5 --qpstep 51 --ratetol 0.1 --cqmfile "M4G HRM V2.cfg" --progress --no-dct-decimate --interlaced --aq-strength 0.75 --aq-sensitivity 10

second part is --pass 2 --bitrate 6336 --keyint 30 --min-keyint 0 --deadzone-inter 4 --deadzone-intra 6 --no-fast-pskip --bframes 2 --b-pyramid --bime --weightb --direct auto --nf --analyse all --8x8dct --qpmin 5 --qpstep 51 --ratetol 0.1 --cqmfile "M4G HRM V2.cfg" --progress --no-dct-decimate --interlaced --aq-strength 0.75 --aq-sensitivity 10

VC1 compression program: Windows Media Encoder 9 with WMV9 advanced profile patch
VC1 program settings: 2 part,

first part is mode= 2 Pass VBR, bitrate=6336kbps, resolution= use input size, keyframe interval= 1 sec, video optimization= keep interlaced, http://img9.imagepile.net/img9/23742vc1-030.png

second part is mode= 2 Pass VBR, bitrate=6336kbps, resolution= use input size, keyframe interval= 1 sec, video optimization= keep interlaced, http://img9.imagepile.net/img9/24196vc1-031.png


--result--
4 continious frames capture

Source:
http://img9.imagepile.net/img9/51871taipei.walker[(000163)06-55-05].jpg
http://img9.imagepile.net/img9/14112taipei.walker[(000164)06-55-05].jpg
http://img9.imagepile.net/img9/2127taipei.walker[(000165)06-55-06].jpg
http://img9.imagepile.net/img9/79484taipei.walker[(000166)06-55-07].jpg

AVC first part:
http://img9.imagepile.net/img9/513586336cbr_fast_aq0.75-10_cqm-m4g-hrm-v2[(000163)02-17-08].jpg
http://img9.imagepile.net/img9/59156336cbr_fast_aq0.75-10_cqm-m4g-hrm-v2[(000164)02-17-09].jpg
http://img9.imagepile.net/img9/490536336cbr_fast_aq0.75-10_cqm-m4g-hrm-v2[(000165)02-17-10].jpg
http://img9.imagepile.net/img9/746006336cbr_fast_aq0.75-10_cqm-m4g-hrm-v2[(000166)02-17-10].jpg
encoded file is available on http://www.megashares.com/?d01=41b2260

AVC second part (change with DeadZone4,6):
http://img9.imagepile.net/img9/229806336cbr_fast_dead4-6_aq0.75-10_cqm-m4g-hrm-v2[(000163)02-17-22].jpg
http://img9.imagepile.net/img9/745296336cbr_fast_dead4-6_aq0.75-10_cqm-m4g-hrm-v2[(000164)02-17-23].jpg
http://img9.imagepile.net/img9/132206336cbr_fast_dead4-6_aq0.75-10_cqm-m4g-hrm-v2[(000165)02-17-24].jpg
http://img9.imagepile.net/img9/90676336cbr_fast_dead4-6_aq0.75-10_cqm-m4g-hrm-v2[(000166)02-17-25].jpg

VC1 first part:
http://img9.imagepile.net/img9/28168vc1_030[(000164)01-21-52].jpg
http://img9.imagepile.net/img9/18962vc1_030[(000165)01-21-54].jpg
http://img9.imagepile.net/img9/37601vc1_030[(000166)01-21-55].jpg
http://img9.imagepile.net/img9/93420vc1_030[(000167)01-21-56].jpg
encoded file is available on http://www.megashares.com/?d01=89ff325

VC1 second part (change with Adaptive DeadZone):
http://img9.imagepile.net/img9/36053vc1_031[(000164)01-22-09].jpg
http://img9.imagepile.net/img9/32718vc1_031[(000165)01-22-10].jpg
http://img9.imagepile.net/img9/44625vc1_031[(000166)01-22-11].jpg
http://img9.imagepile.net/img9/9531vc1_031[(000167)01-22-12].jpg

Enhanced Source:
http://img9.imagepile.net/img9/84986taipei.walker[(000163)06-55-05]_sharped.jpg

Enhanced AVC first part:
http://img9.imagepile.net/img9/214326336cbr_fast_aq0.75-10_cqm-m4g-hrm-v2[(000163)02-17-08]_sharped.jpg

Enhanced VC1 first part:
http://img9.imagepile.net/img9/65483vc1_030[(000164)01-21-52]_sharped.jpg

--

Because the AVC second part is worse than first part, and the VC1 second part is worse than first part, so the encoded files just only provided the first part of VC1 and AVC.

The conclusion is, VC1 retain much grain more than AVC.

--

You might have gotten even better grain retention at the same speed with:

Perceptual Option: Adaptive Deadzone

* Set Dquant Option = I & P. You've got enough bits that you can afford to ensure smooth areas get the lowest quantizers
* Set Perceptual Option = Adaptive Dead Zone. I think you'll find it performs very well with grain.
* You'll probably get a slightly better result with 1 B-frame instead of 2. There's no need to match up the number of B-frames with x264 - they're completely different ratecontrols, so it's not like the GOP structures match up either. Might as well use 1 B-frame which seems to work best in VC-1.
Thanks for comments, the 1 B-frame is suitable in high bitrate, but the Dquant & Adaptive DeadZone don't.


Mine is that your screenshots don't have the same colorimetry, that the AVC seems to have more noise, and that using an interlaced source is definitely not appropriate for such a test ( it would be on an interlaced display, but it's not on a progressive display, since interlacing artefacts tend to mask everything else )

* Yeah, I agree with Manao that the colorimetry is off. Not sure why though, your source seems to be in YV12 already.
The truth is, there's a mistake in capture, the KMPlayer and the VirtualdubMod (capture tools in this test) both convert the colorspace and stretch Y/C levels when the captured image format is PNG.


and that using an interlaced source is definitely not appropriate for such a test ( it would be on an interlaced display, but it's not on a progressive display, since interlacing artefacts tend to mask everything else )
* I also agree that comparing interlaced is a bad test of grain. Unless you're testing interlaced modes specifically and comparing field to field, you should probably use progressive instead.
Thanks for comments, I'll try it if I get the progressive source which have the rich grain.

*.mp4 guy recommends "--deadzone-inter 4" and "--deadzone-intra 6" for this matrix. Also why "--nf"?
The comments "--deadzone-inter 4" and "--deadzone-intra 6" give a slight worse result than "--deadzone-inter 0" and "--deadzone-intra 0" .

* And most importantly: don't start with an already compressed source. You're using MJPEG for your capture. That already destroys some of the grain. Capture uncompressed if you can.
BTW, when people talk about grain, they typically are talking about film grain. Your captures look like TV captures.
I agree, but the MJPEG retain enough grain for this test. I'll try the Lossless compression if possible.

--

The source file is available at #1 post, all your participation and result is welcome.

Sharktooth
11th August 2007, 13:21
LOL deadzone inter and intra both at 0?
qpstep at 51? min keyint at 0? and also adaptive quantization... and even interlaced encoding!!!
well im not surprised your results are just crappy...
However i will repeat myself again... what you have is NOISE not grain... and noise is by definition and interference to the original signal and so it's something definatly not good.
get a real grainy source (and possibly progressive!!!) to make the tests.

For example Band of Brothers (picture already encoded with an old x264 version at an average of ~1680Kbps)
http://www.webalice.it/f.corriga/temp/grain_example.png

foxyshadis
12th August 2007, 01:54
There is some real grain. Most of it is so heavily damaged by the mjpeg encoding and the video noise (some frequency noise in particular) that it'd be better to just randomly generate some on playback than try to store it.

The major piece of the puzzle that was missed was --filter; the x264 default is fairly high strength. -2,-2 or something around that gives noisier flat surfaces, even on lower bitrates with lesser matrices and lesser AQ.

Still, what's left of the "grain" in the source is essentially just random noise with an annoying vertical correlation. Is it worth keeping, when there are so many other ways of re-introducing that noise?

SealTooGreat
12th August 2007, 08:49
The major piece of the puzzle that was missed was --filter; the x264 default is fairly high strength. -2,-2 or something around that gives noisier flat surfaces, even on lower bitrates with lesser matrices and lesser AQ.


It's not missing, encoder's inloop is turnd off by "--nf"

foxyshadis
12th August 2007, 09:33
Ah, then I'm quite confused by the very different results I got, especially with inloop on. Hm. I guess I'll have to download it all again, great.

Sharktooth
17th August 2007, 16:30
http://www.webalice.it/f.corriga/temp/grain/index.htm
samples were taken from a Memento backup (720x288@847kbps) made using a h.264 encoder with some CORRECT settings...