Variance AQ Megathread (AQ v0.48 update--defaults changed)

[vpupkind]

Bitrate constraints?
ABR, with VBV of 1-2 sec.

[Dark Shikari]

ABR, with VBV of 1-2 sec.What do you mean--it violates VBV maxrate? 2pass ABR doesn't currently obey VBV maxrate properly anyways.

[vpupkind]

What do you mean--it violates VBV maxrate? 2pass ABR doesn't currently obey VBV maxrate properly anyways.
When I am measuring the maximum VBV fullness on a 2-sec buffer, I see that with low qcomp the buffer stays reasonably close to the limit.
When 0.48 is used, the buffer can reach >200% of the VBV size

[Dark Shikari]

When I am measuring the maximum VBV fullness on a 2-sec buffer, I see that with low qcomp the buffer stays reasonably close to the limit.
When 0.48 is used, the buffer can reach >200% of the VBV sizeHmm... somehow this doesn't surprise me.

We need VBV lookahead :p

[TheRyuu]

I built this last minute for anyone who wanted to try it (I haven't tested it, the most tested I did was it patched/builded without error).

http://www.fileducky.com/rIhWCgXL/

Has the older AQ 0.46 that is supposedly better (for animation) in a way (I haven't tested this yet) and also contains DeathTheSheep's updated me-prepass patch as well since that option was a personal favorite of mine.

Enjoy.

P.S. On a side note, is using -funroll-loops (unrolling the loops) particularly useful in building x264?

[desta]

On the help it says --aq-strength is defaulted to 0.5, but you still have to actually enter a value for the strength for AQ to be turned on...

To run default settings, wouldn't it be easier to either:
- Have it on by default :D (I think many would agree), and turn it off by '--aq off' or
- Be able to turn it on by just '--aq'? (on by default when set, but still allow '--aq on', and when set use the default settings.

The other options can remain, it just seems silly having it as a default 0.5 when you have to state it anyway!
What it actually says is..

How to use AQ:

1. AQ is on by default at strength 0.5. Change --aq-strength to make it stronger or weaker.

[burfadel]

Ah ok! Haven't done any encoding since then, I didn't realise it was on by default. Earlier it was stated AQ would not be on by default, and that it will only be available as an option unless otherwise stated.

Its a great feature, it definitely makes sense to have it on by default.

[Yoshiyuki Blade]

Yeah, at lower bitrates, v0.48 does not seem to deal with dark/flat scenes quite as well as 0.45 (and probably 0.46, though I haven't tested it myself) on this particular anime test. Although using the recommended default settings combined with Sharktooth's CQM looks much better than any other tests I've done with the recent patches, the blockyness in some areas are still quite distracting.

AQ v0.48 --qcomp 1.0 --aq-strength 0.5 --aq-sensitivity 13: 179 MB (Sample 2 (http://www.mediafire.com/?49jwuzgnf1e))

Compare it to Sample 2 posted here (http://forum.doom9.org/showthread.php?p=1094123#post1094123).

All settings and bitrate pretty much identical except for the obvious ones (qcomp and aq).

[burfadel]

I agree, at lower bitrates it does block. I mentioned that earlier, although it is different now, a lower strength at 0.3 and higher sensitivity 16.5 as mentioned earlier fixes that blocking and still gives good results without changing the final file size.

I have a suggestion that at high resolution (the cutoff point which will need to be determined) to use the current default settings, and at lower resolution have different default settings as I outlined above. Maybe have it on a linear formulated scale for strength and sensitivity or something?

[Dark Shikari]

Yeah, at lower bitrates, v0.48 does not seem to deal with dark/flat scenes quite as well as 0.45 (and probably 0.46, though I haven't tested it myself) on this particular anime test. Although using the recommended default settings combined with Sharktooth's CQM looks much better than any other tests I've done with the recent patches, the blockyness in some areas are still quite distracting.

AQ v0.48 --qcomp 1.0 --aq-strength 0.5 --aq-sensitivity 13: 179 MB (Sample 2 (http://www.mediafire.com/?49jwuzgnf1e))

Compare it to Sample 2 posted here (http://forum.doom9.org/showthread.php?p=1094123#post1094123).

All settings and bitrate pretty much identical except for the obvious ones (qcomp and aq).I don't see any real difference between your two samples. There's a bit of different bit distribution (some frames look better in one, some in the other, but mainly due to different frame size), but the main thing I see is the 0.45 has terribly uneven quantizer distribution, wasting bits, while the 0.48 has much smoother distribution.

I cannot see any real problem visually in either encode.

[DeathTheSheep]

Both of these clips look pretty much fine to me, too. That's my $0.02... Just out of curiosity, what's the SSIM for each of them?

[Yoshiyuki Blade]

I don't see any real difference between your two samples. There's a bit of different bit distribution (some frames look better in one, some in the other, but mainly due to different frame size), but the main thing I see is the 0.45 has terribly uneven quantizer distribution, wasting bits, while the 0.48 has much smoother distribution.

I cannot see any real problem visually in either encode.

The most noticeable difference between the clips is when the dark area slowly reveals the character Usui at about 13 seconds in. The fade-in effect is less blocky on the v0.45 clip. But yeah I have to agree that for the most part its comparable. Perhaps the rest is up to tweaking the strength for optimal results.

Both of these clips look pretty much fine to me, too. That's my $0.02... Just out of curiosity, what's the SSIM for each of them?

SSIM...? lol, it's gonna be a long time before I stop considering myself a n00b :D. All of my observations so far were done purely subjectively by eye.

[CruNcher]

@Dark Shikari
i lost a little track of what's going on but i tried the latest AQ and got this result i had to use --aq-strength 1.0 else the background (left of here) was to blocky everything looks fine except the silhouette of her face it shows extreme ringing like the AQ amplified it to much.

http://mirror05.x264.nl/CruNcher/force.php?file=./strange-ringing.mkv

hehe ok my old matrix workaround fixed it again,at least lowered the problem so that's visual not so noticeable anymore :)

http://mirror05.x264.nl/CruNcher/force.php?file=./ringing-killed.mkv

[Morte66]

0.48 with defaults is looking good, and making good use of bitrate, on my crf 18/16 encodes from cleaned up SDDVD/HDDVD. My thanks to all concerned.

[LoRd_MuldeR]

Just for info:
An "experimental" build of Avidemux that includes the x264 VAQ Patch v0.48 is available now :)
There are no GUI controls to adjust the AQ settings yet, but it will be on by default.

http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux
http://razorbyte.com.au/dev_dump/

[bob0r]

x264.736.modified.01.exe (http://files.x264.nl/x264.736.modified.01.exe)

General thread:
http://forum.doom9.org/showthread.php?t=130364

x264_aq_var.48.diff
http://forum.doom9.org/showthread.php?t=132760
x264.gaussian.cplxblur.01.diff
Dark Shikari: - gaussian cplxblur: gives a tiny improvement in 2pass ratecontrol
x264_me-prepass_DeathTheSheep.01.diff
http://forum.doom9.org/showthread.php?p=1093523
x264_2pass_vbv.4.MatMaul.diff
http://mailman.videolan.org/pipermail/x264-devel/2008-January/004015.html
x264_hrd_pulldown.04.diff
- HRD and pulldown for HD compatibility

[DeathTheSheep]

Here's a little test I performed, which supports my earlier postulate.

SETUP
Default baseline level 1.3 settings plus: -q30 --no-fast-pskip -m6 --me umh --keyint 1500.
This commandline was chosen for its representative simplicity. Testing indicates that the results below hold for more advanced commandlines as well.

Source: 2039 frame Bleach anime high-motion intro, 320x240 (QVGA) resolution, ~3mbps XviD encoded.

Binaries: 0.47 (http://files.x264.nl/AQ/force.php?file=./x264.721.dark.aq.0.47.exe) and 0.46 (http://mirror05.x264.nl/Dark/force.php?file=./x264_AQ_0.46.exe).

AQ strength settings:
0.47: Strength 1.0 (0.5 is default/recommended, and I used this first, but was advised against doing so, so repeated test with 1.0 for uniformity. Similar results.
0.46: Strength 1.0 (remember, the old algorithm had a different strength system, and 1.0 was recommended).

Threshold was adjusted so that final size was roughly the same. Because of resolution, higher-than-anticipated threshold applies (around 24.5 for 0.46 and 20.3 for 0.47).

RESULTS:
0.46 was clearly the winner (at least in regard to this source/bitrate).
SSIM
0.46: 0.9747229
0.47: 0.971398
Note: 0.46 is the metric winner, its SSIM score higher, but even so, the closeness of the score is deceptive.

PICTURES:
Visual evidence, chosen out of a group of 15 randomly selected screenshots in the 2039-frame sample. The source is not shown; however, at this bitrate, the quality difference should be apparent, regardless. Note: Zooming in may be required to asses images if viewed on a high-resolution display.

LEFT (or top) IMAGES FROM 0.47, RIGHT (or bottom) IMAGES FROM 0.46.

http://i249.photobucket.com/albums/gg201/saskura_80211b/x264/b116.pnghttp://i249.photobucket.com/albums/gg201/saskura_80211b/x264/46-116.png
Outline around orange-hair character is cleaner, sharper. More ground detail present, and character's arm is more clearly visible. Less artifacting visible around clouds, sword hilt, under top subtitles.

http://i249.photobucket.com/albums/gg201/saskura_80211b/x264/b215.pnghttp://i249.photobucket.com/albums/gg201/saskura_80211b/x264/46-215.png
Reflection in sword in clearer, sharper, less blurred edges, proper color proportion, less artifacting all around (especially around reflection edges).

http://i249.photobucket.com/albums/gg201/saskura_80211b/x264/b246.pnghttp://i249.photobucket.com/albums/gg201/saskura_80211b/x264/46-246.png
Entire outer circumference of female character's hair much less severely blurred (especially on left of head in darkest area).

http://i249.photobucket.com/albums/gg201/saskura_80211b/x264/b666.pnghttp://i249.photobucket.com/albums/gg201/saskura_80211b/x264/46-666.png
Much fewer border artifacts, clearer edges, more edge detail kept. More accurate preservation of character's feet.

http://i249.photobucket.com/albums/gg201/saskura_80211b/x264/b770.pnghttp://i249.photobucket.com/albums/gg201/saskura_80211b/x264/46-770.png
Slightly less blocking and artifacting on color gradients.

http://i249.photobucket.com/albums/gg201/saskura_80211b/x264/b1343.pnghttp://i249.photobucket.com/albums/gg201/saskura_80211b/x264/46-1343.png
Much clearer edge and detail retention in dark areas. Specifically note the 2 parallel lines (center) on character's suit.

http://i249.photobucket.com/albums/gg201/saskura_80211b/x264/b1693.pnghttp://i249.photobucket.com/albums/gg201/saskura_80211b/x264/46-1693.png
Better fine detail retention, edge preservation, lack of artifacts and color smearing. Specifically note the cat's whiskers and right ear.

CONCLUSION AND GENERAL REMARKS:
If not already readily obvious, 0.46, in technical terms, is t3h w1n in this case, sample, resolution, bitrate, source (to be slightly specific). However, due to the representative nature of this test, I would make so bold as to extend these results to many other sources of this nature; that is, due to this test and previous experience, I believe these results apply to other low-bitrate anime samples, if not a more general range of samples as well. More testing may be required to verify this assumption.

The following statements can be deemed invalid in this case:
- SSIM increases with the new AQ.
- The new AQ allocates bits in areas that need them most (see results of previous test for more concrete evidence of this).
- Visual quality improves with the new AQ.
Again, the evidence shared above tends to refute these statements, for the most part.

RAW .264 LINKS:
0.46 Clip (http://gabext.com/samples/ssim-0.9747229_AQ46.264)
0.47 Clip (http://gabext.com/samples/9741398_AQ47_1.0test.264)

[edit1] Added descriptions under images to make known what to look for.
[edit2] Reuploaded images as VGA PNGs.
[edit3] Replaced strength 0.5 AQ 0.47 with strength 1.0, as used in 0.46. All results and pictures updated (descriptions didn't change much, in honesty). There is a slight improvement in the areas of mention, but marked degradation in high-contrast areas, which I didn't touch on.

[Dark Shikari]

AQ strength settings:
0.47: Strength 0.5 (default/recommended, also tried 0.3 as suggested for anime with worse effect, as well as 0.6 with little difference).
0.46: Strength 1.0 and 1.1Your entire test is invalid (and one could probably say, rigged). The reason the "old AQ looks worse" is because you used a lower strength on the new one. Looking at the quantizer distribution, it appears part of the problem is my algorithm to reduce quantizer bit cost, which was present in previous versions of AQ. Its just that at a low enough strength, the quantizer change is near nil--looking at the quantizer distribution in your 0.47 encode, that appears to be the case. It has nothing to do with 0.47's "different algorithm"--its simply because your strength was so weak it did nearly nothing at all on your anime source.
(remember, the old algorithm had a different strength system, and 1.0 was recommended).No, it didn't have a different strength system. 0.5 is recommended just because its better to be conservative and avoid artifacting than be aggressive and result in too much artifacting.

In particular, the primary reason for 0.46 looking "better" is because it spent less bits coding the subtitles.

Looking at both your encodes though, it appears as if something is seriously wrong with the quantizers. There are some scenes with some serious contrast between flat and complex areas--yet the quantizer is nearly flat across the frame--and thats in your strength 1.0 encode! There is something obviously wrong here.

[DeathTheSheep]

Is that so? Then at least it makes a good comparison between the effectiveness of different strengths (or rather, old defaults vs new defaults). :)

I'll just go n' substitute strength 1.0 for 0.47 real quick.

PS: The visual quality of the subtitles differs very little between the two encodes, though the bits drawn from it seem to have been quite useful elsewhere.
PPS: It also means lower strength is NOT necessarily good for anime, as has been claimed throughout the thread. ;)

[Dark Shikari]

Is that so? Then at least it makes a good comparison between the effectiveness of different strengths (or rather, old defaults vs new defaults). :)

I'll just go n' substitute strength 1.0 for 0.47 real quick.

PS: The visual quality of the subtitles differs very little between the two encodes, though the bits drawn from it seem to have been quite useful elsewhere.Test this. After you're done with your 0.47 1.0 strength encode, do another with the following line commented out:

if(abs(new_qp - h->mb.i_last_qp) == 1) new_qp = h->mb.i_last_qp;

in ratecontrol.c. Post the .h264 files for both.

[DeathTheSheep]

Quite interesting. I'll certainly give that a spin...

I assume you mean commented out of .47/.48, right? :)

[Dark Shikari]

Quite interesting. I'll certainly give that a spin...

I assume you mean commented out of .47/.48, right? :)Yes. Well, try the same for 0.46 if you're curious. It'll make debugging much easier.

And seriously, get on MSN or something, it'll make this all much easier.

[DeathTheSheep]

There we go. Again, results not much different-- the areas of mention had some improvement, but the high-contrast regions suffer a huge quality drop, which isn't clear in those specific pictures (well, actually, now that I check, it's there somewhat. Whew). 0.46 is still the obvious winner, though.

MSN...well uh, when I'm in my gmail inbox, there's a chat window to the left. I wonder... :)

[edit]Don't you love when people edit posts? 80% of the time I never see all the little things they change. Sheesh. :D

And it's like 1AM here. I'm...gunna take this up tomorrow I guess. Lots of physics homework, ugh. Electric fields, capacitors, ugly surface integrals, sheesh. Unlike you, physics is not my cup-o-tea... :(

[Dark Shikari]

There we go. Again, results not much different-- the areas of mention had some improvement, but the high-contrast regions suffer a huge quality drop, which isn't clear in those specific pictures (well, actually, now that I check, it's there somewhat. Whew). 0.46 is still the obvious winner, though.

MSN...well uh, when I'm in my gmail inbox, there's a chat window to the left. I wonder... :)

[edit]Don't you love when people edit posts? 80% of the time I never see all the little things they change. Sheesh. :D

And it's like 1AM here. I'm...gunna take this up tomorrow I guess. Lots of physics homework, ugh. Electric fields, capacitors, ugly surface integrals, sheesh. Unlike you, physics is not my cup-o-tea... :(Words do me nothing, quantizer distributions (aka .h264 streams) are much more useful ;)

[wata]

is VAQ suitable for crf encoding?
i test it on a few clips crf=18
with 0.48
the filesize of all clips always increase (>20%) with default AQ setting then without AQ
with 0.45 strength 1 sensitivity 0
filesize is almost always lower but very close than without AQ

[Dark Shikari]

is VAQ suitable for crf encoding?
i test it on a few clips crf=18
with 0.48
the filesize of all clips always increase (>20%) with default AQ setting then without AQ
with 0.45 strength 1 sensitivity 0
filesize is almost always lower but very close than without AQYes, it is suitable for CRF encoding. If the filesize gets bigger than you want--raise the CRF.

[Sharktooth]

VAQ enabled x264 build is now included in MeGUI auto-update.
Hope it helps.

[wata]

test some more

for 0.48 i have to increase crf by 2 (default setting) to match no aq size
so now crf 18 = crf 20

for 0.45 i have to decrease crf by 1 (aq 1.0 sen 0)
crf 18 = crf 17

[CruNcher]

I see DeathTheSheep confirmed the edge ringing problem also with Anime :)

[DeathTheSheep]

Words do me nothing, quantizer distributions (aka .h264 streams) are much more useful ;)
I really did update the whole test for the new 1.0 strength, including all images and the new .264 stream (click the link!). Now it's no longer "rigged" by any means :(, but the end results are *very* similar except for slight improvements to the regions of mention and slight degradations near edges. That's exactly what I mean when I say nobody sees the extent to which someone edits their posts! I'll betcha nobody else noticed the update/refresh either. But I am going to use this quote of yours in a drama novel one day. "Alas dear Yorrik, but that thy words do me nothing. 'Tis your quantizer distributions which art far more useful." :D

CruNcher: Yep, maybe so, though unfortunately I wasn't using Shin Taketori Monogatari so it must have been painful to see. ;)

[DeathTheSheep]

With r736, I did the following tests at strength 1.0:
AQ46 original (o) and commented (c).
AQ47 original (o) and commented (c).

Clips found here (http://gabext.com/samples/Shikari).
Random comment: Looks like r736 is worse than r721 (lower SSIM, higher filesize) with same AQ46 settings. Why is that?

[akupenguin]

If the discrepancy appeared in r731, then look at http://akuvian.org/images/tesa2.png. Note that the umh change reduces quality at any given value of merange, but improves the quality-per-speed curve.
If the discrepancy appeared in any other rev, then I need more info.

[DeathTheSheep]

I'll check on that.

By the way, I did notice that the new tesa delivers less quality per bitrate, and the point of diminishing returns generally occurs at smaller meranges. Given its nature as an "insane" option in the first place (that is, only those who want max quality regardless of speed cost would use it regularly), is there a threshold I can adjust (line no.) to restore the higher quality but slower behavior of the old tesa? The difference is actually quite noticeable at the sources/bitrates above, even more so at higher meranges.

Also, for some reason, I find that revision 736 (3.7fps) is only marginally faster than 681 (3.3fps) with prepass and satd, so I'd certainly go with the quality boost of the latter's satd rather than experience the marginal speed boost.

[akupenguin]

is there a threshold I can adjust (line no.) to restore the higher quality but slower behavior of the old tesa?
line 493 (sad_thresh) and line 501 (17/16) and line 537 (limit).

old tesa is equivalent to sad_thresh=10, ads threshold=5/4, limit=infinity

[DeathTheSheep]

int sad_thresh = i_me_range <= 16 ? 10 : i_me_range <= 24 ? 11 : 12;

What! Dynamic merange-adaptive threshold? Genius! :p

What exactly does limit do? I'd assume scaling it by a factor rather than adding a constant, but what would a higher denominator (i_me_range / 3) do as opposed to a higher numerator (i.e. what happens if the limit goes up rather than down)?

[edit]Never mind, I'll figure it out soon enough.

[edit2] Yes, it appears to be r731. And in tests with other sources at higher bitrates, this umh quality decrease seems to be negligible anyway. It's faster, though.

[talen9]

VAQ enabled x264 build is now included in MeGUI auto-update.
Hope it helps.

It's compiled without MP4 support :rolleyes:

Oh well, using raw h.264 is the same for me, that's only that "MP4" is the default output format in MeGUI and this should raise many complaints, i think ;)

[Dark Shikari]

It's compiled without MP4 support :rolleyes:Oops! :p

[IgorC]

Also, for some reason, I find that revision 736 (3.7fps) is only marginally faster than 681 (3.3fps)
Marginally? +12% speed?

[ToS_Maverick]

Dark Shikari, just wanted to inform you, i did encode some live-concert footage, with smog and gradients in the fog and so on...
your default settings (0.5, 13) turned out to be the best choice visually!

[Sagekilla]

Marginally? +12% speed?

Indeed.. 3.7 fps vs 3.3 fps is a huge difference, especially with a movie that's 200,000 frames long. In that case, it can make a difference of up to 110 minutes!

[bob0r]

It's compiled without MP4 support :rolleyes:

...

x264.736.megui.exe --help
x264 core:58 svn-736M
Syntax: x264 [options] -o outfile infile [widthxheight]

Infile can be raw YUV 4:2:0 (in which case resolution is required),
or YUV4MPEG 4:2:0 (*.y4m),
or AVI or Avisynth if compiled with AVIS support (yes).
Outfile type is selected by filename:
.264 -> Raw bytestream
.mkv -> Matroska
.mp4 -> MP4 if compiled with GPAC support (yes)


x264.736.megui.exe --threads 2 -B5000 -m6 -r5 --direct=temporal --me=hex -b2 -w --qcomp=0.10 -A"p8x8,i8x8,i4x4" -8 --fps=25 --output test.mp4 720p50_mobcal_ter.yuv 1280x720

encoded 504 frames, 6.09 fps, 5168.29 kb/s

test.mp4 plays fine with MPC (internal splitter)

or Haali Splitter:
http://x264.nl/x264.736.megui.mp4.output.jpg

C:\Program Files\megui\tools\x264\x264.exe <-- OLD
C:\Program Files\megui\tools\x264\x264.736.megui.exe <-- NEW build

*slaps Sharktooth for making all of the above information useless!

Rename x264.736.megui.exe to x264.exe and your problem is solved.

The old x264.exe is Cef's 709 build, which also has .mp4 output, i can not reproduce.

[DeathTheSheep]

I don't think there's a person on the planet who'd want to encode 200,000 frames with high merange satd in baseline profile. Simply why bother? :p

Yes 12% is big. But relative to the speed/quality loss you'll already be destined to suffer by that point, it's already negligible. For instance, sane settings for that same clip (the 3.3 vs 3.7), I get well over 60fps. I'd say there's less than 10% quality loss at that speed, too. No, tesa isn't about the 12%--when you're already reduced to the single-digits for minimal gain, it's really a drop in the bucket.

DS, how goes the analysis of the clips I uploaded? Does the "problem" you mentioned look solvable?

[Sagekilla]

*Coughs* Well.. I didn't encode in baseline but I did encode close to 200,000 frames using a high merange + esa.

[DeathTheSheep]

With both limiting if() statements commented out and old satd thresholds restored (thresh=10, ads=5/4), speed is significantly slower than r681. Filesize also higher, ssim lower.

Interesting. I don't think this has anything to do with r731. :) I've also noticed that r736 doesn't achieve the high burst speeds that r681 did on low-motion scenes.

[MfA]

BTW, I'm curious ... why doesn't x.264 do plain RDO optimization of mb_qp_delta? Are the potential gains too small?

[Dark Shikari]

BTW, I'm curious ... why doesn't x.264 do plain RDO optimization of mb_qp_delta? Are the potential gains too small?Such optimization would only be useful if one did it as a trellis, mostly likely; and such a thing is quote possible.

If you mean "RDO" as in somehow optimizing each block to its optimal QP, rather than just RDO to save bits spent on qp_delta, thats absurdly slow and not even optimal.

[DeathTheSheep]

So what are your plans for AQ now? Do you have a list of priorities like:

1. Bugfix
2. Add lambda/enhancements
3. Bugfix
4. Get in CVS

...or something like that?
Also, do you have any remarks pertaining to the samples I uploaded?

Cheers!

[Dark Shikari]

DtS, I looked at your updated 0.47 and the quantizer distributions are completely impossible. After considerable testing with my own sources, there is no way they could possibly be generated by my algorithm [note: code != algorithm, a mistake in the code can result in deviation from the algorithm)]

Please post a link to your source so that I can attempt to replicate your results.

[DeathTheSheep]

Interesting... Okay, I'll get you (a) source. I can't just give you the plain XviD, since I used an avisynth script with functions that don't exist anymore, and a modded ffdshow with custom filter settings for the decoding.

So I'll give you a "new" source (already resized and filtered!), a very high bitrate (-q1) x264 re-encode of the original to replicate the results on.

I included:
- EXACT avs, cmd, source avi used.
- EXACT build used (also linked to in my test earlier, originated from bobor's mirror).
- EXACT output file produced by the above setup (its the only .264 file there).

If you download everything to the same directory, just double-click the cmd and you should get the exact output .264 I included.

http://gabext.com/samples/Shikari

Knock yourself out! (In a good way.) :)

[edit]Ups.

[Dark Shikari]

Interesting... Okay, I'll get you (a) source. I can't just give you the plain XviD, since I used an avisynth script with functions that don't exist anymore, and a modded ffdshow with custom filter settings for the decoding.

So I'll give you a "new" source (already resized and filtered!), a very high bitrate (-q1) x264 re-encode of the original to replicate the results on.

I included:
- EXACT avs, cmd, source avi used.
- EXACT build used (also linked to in my test earlier, originated from bobor's mirror).
- EXACT output file produced by the above setup (its the only .264 file there).

If you download everything to the same directory, just double-click the cmd and you should get the exact output .264 I included.

http://gabext.com/samples/Shikari

Knock yourself out! (In a good way.) :)

[edit]Ups.Answer: stop adjusting your sensitivity. It looks just fine at sensitivity 13. Kthx. :p