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

[Fantacinni]

Why I can't make x264 r786 with x264_aq_var.48?

[bob0r]

Why I can't make x264 r786 with x264_aq_var.48?

Because some code has changed in x264.
Now we truely have to wait for AQ to hit git :D

Revision 785 is the last where current AQ 0.48 compiling works.

All other patches still work.

[MythCreator]

Because some code has changed in x264.
Now we truely have to wait for AQ to hit git :D

Revision 785 is the last where current AQ 0.48 compiling works.

All other patches still work.


Is that means AQ 1.0 will be soon?

[Sagittaire]

The patch is here
http://mailman.videolan.org/pipermail/x264-devel/2008-March/004221.html

... but don't work for me. Problem at line 5 in compilation.

diff --git a/common/common.c b/common/common.c
index 44d9113..17f37f5 100644
--- a/common/common.c
+++ b/common/common.c
@@ -123,6 +123,8 @@ void x264_param_default( x264_param_t *param )
param->analyse.i_chroma_qp_offset = 0;
param->analyse.b_fast_pskip = 1;
param->analyse.b_dct_decimate = 1;
+ param->analyse.f_aq_strength = 0.5;
+ param->analyse.i_aq_mode = 2;
param->analyse.i_luma_deadzone[0] = 21;
param->analyse.i_luma_deadzone[1] = 11;
param->analyse.b_psnr = 1;
@@ -455,6 +457,10 @@ int x264_param_parse( x264_param_t *p, const char
*name, const char *value )
p->analyse.b_fast_pskip = atobool(value);
OPT("dct-decimate")
p->analyse.b_dct_decimate = atobool(value);
+ OPT("aq-strength")
+ p->analyse.f_aq_strength = atof(value);
+ OPT("aq-mode")
+ p->analyse.i_aq_mode = atoi(value);
OPT("deadzone-inter")
p->analyse.i_luma_deadzone[0] = atoi(value);
OPT("deadzone-intra")
@@ -883,6 +889,10 @@ char *x264_param2string( x264_param_t *p, int b_res )
s += sprintf( s, " ip_ratio=%.2f", p->rc.f_ip_factor );
if( p->i_bframe )
s += sprintf( s, " pb_ratio=%.2f", p->rc.f_pb_factor );
+ if( p->analyse.i_aq_mode )
+ s += sprintf( s, " aq=%d:%.1f", p->analyse.i_aq_mode,
p->analyse.f_aq_strength );
+ else
+ s += sprintf( s, " aq=0" );
if( p->rc.psz_zones )
s += sprintf( s, " zones=%s", p->rc.psz_zones );
else if( p->rc.i_zones )
diff --git a/encoder/analyse.c b/encoder/analyse.c
index 0264621..0f313a9 100644
--- a/encoder/analyse.c
+++ b/encoder/analyse.c
@@ -2064,8 +2064,13 @@ void x264_macroblock_analyse( x264_t *h )
int i_cost = COST_MAX;
int i;

- /* init analysis */
- x264_mb_analyse_init( h, &analysis, x264_ratecontrol_qp( h ) );
+ h->mb.i_qp = x264_ratecontrol_qp( h );
+
+ if( h->param.analyse.i_aq_mode )
+ x264_adaptive_quant( h );
+
+ /* init analysis */
+ x264_mb_analyse_init( h, &analysis, h->mb.i_qp );

/*--------------------------- Do the analysis ---------------------------*/
if( h->sh.i_type == SLICE_TYPE_I )
diff --git a/encoder/encoder.c b/encoder/encoder.c
index 3dadb02..3bd9e70 100644
--- a/encoder/encoder.c
+++ b/encoder/encoder.c
@@ -401,6 +401,7 @@ static int x264_validate_parameters( x264_t *h )
h->param.analyse.b_fast_pskip = 0;
h->param.analyse.i_noise_reduction = 0;
h->param.analyse.i_subpel_refine = x264_clip3(
h->param.analyse.i_subpel_refine, 1, 6 );
+ h->param.analyse.i_aq_mode = 0;
}
if( h->param.rc.i_rc_method == X264_RC_CQP )
{
@@ -475,6 +476,11 @@ static int x264_validate_parameters( x264_t *h )
if( !h->param.b_cabac )
h->param.analyse.i_trellis = 0;
h->param.analyse.i_trellis = x264_clip3(
h->param.analyse.i_trellis, 0, 2 );
+ h->param.analyse.i_aq_mode = x264_clip3(h->param.analyse.i_aq_mode, 0, 2);
+ if(h->param.analyse.f_aq_strength <= 0) h->param.analyse.i_aq_mode = 0;
+ /* VAQ on mode 1 effectively replaces qcomp, so qcomp is raised
towards 1 to compensate. */
+ if(h->param.analyse.i_aq_mode == 2)
+ h->param.rc.f_qcompress = x264_clip3f(h->param.rc.f_qcompress
+ h->param.analyse.f_aq_strength * 0.4 / 0.28, 0, 1);
h->param.analyse.i_noise_reduction = x264_clip3(
h->param.analyse.i_noise_reduction, 0, 1<<16 );

{
diff --git a/encoder/ratecontrol.c b/encoder/ratecontrol.c
index 0c8a6d7..30c0994 100644
--- a/encoder/ratecontrol.c
+++ b/encoder/ratecontrol.c
@@ -127,6 +127,10 @@ struct x264_ratecontrol_t
predictor_t *pred_b_from_p; /* predict B-frame size from P-frame satd */
int bframes; /* # consecutive B-frames before this
P-frame */
int bframe_bits; /* total cost of those frames */
+
+ /* AQ stuff */
+ float aq_threshold;
+ int *ac_energy;

int i_zones;
x264_zone_t *zones;
@@ -169,6 +173,92 @@ static inline double
qscale2bits(ratecontrol_entry_t *rce, double qscale)
+ rce->misc_bits;
}

+// Find the total AC energy of the block in all planes.
+static int ac_energy_mb( x264_t *h, int mb_x, int mb_y, int *satd )
+{
+ DECLARE_ALIGNED( static uint8_t, flat[16], 16 ) =
{128,128,128,128,128,128,128,128,128,128,128,128,128,128,128,128};
+ unsigned int var=0, sad, ssd, i;
+ for( i=0; i<3; i++ )
+ {
+ int w = i ? 8 : 16;
+ int stride = h->fenc->i_stride[i];
+ int offset = h->mb.b_interlaced
+ ? w * (mb_x + (mb_y&~1) * stride) + (mb_y&1) * stride
+ : w * (mb_x + mb_y * stride);
+ int pix = i ? PIXEL_8x8 : PIXEL_16x16;
+ stride <<= h->mb.b_interlaced;
+ sad = h->pixf.sad[pix](flat, 0, h->fenc->plane[i]+offset, stride);
+ ssd = h->pixf.ssd[pix](flat, 0, h->fenc->plane[i]+offset, stride);
+ var += ssd - (sad * sad >> (i?6:8));
+ // SATD to represent the block's overall complexity (bit
cost) for intra encoding.
+ // exclude the DC coef, because nothing short of an actual
intra prediction will estimate DC cost.
+ if( var && satd )
+ *satd += h->pixf.satd[pix](flat, 0,
h->fenc->plane[i]+offset, stride) - sad/2;
+ }
+ return var;
+}
+
+void x264_autosense_aq( x264_t *h )
+{
+ double total = 0;
+ double n = 0;
+ int mb_x, mb_y;
+ /* FIXME: Some of the SATDs might be already calculated elsewhere
(ratecontrol?). Can we reuse them? */
+ /* FIXME: Is chroma SATD necessary? */
+ for( mb_y=0; mb_y<h->sps->i_mb_height; mb_y++ )
+ for( mb_x=0; mb_x<h->sps->i_mb_width; mb_x++ )
+ {
+ int energy, satd=0;
+ energy = ac_energy_mb( h, mb_x, mb_y, &satd );
+ h->rc->ac_energy[mb_x + mb_y * h->sps->i_mb_width] = energy;
+ /* Weight the energy value by the SATD value of the MB.
This represents the fact that
+ the more complex blocks in a frame should be weighted
more when calculating the optimal threshold.
+ This also helps diminish the negative effect of large
numbers of simple blocks in a frame, such as in the case
+ of a letterboxed film. */
+ if( energy )
+ {
+ x264_cpu_restore(h->param.cpu);
+ total += logf(energy) * satd;
+ n += satd;
+ }
+ }
+ x264_cpu_restore(h->param.cpu);
+ /* Calculate and store the threshold. */
+ h->rc->aq_threshold = n ? total/n : 15;
+}
+
+/*****************************************************************************
+* x264_adaptive_quant:
+ * adjust macroblock QP based on variance (AC energy) of the MB.
+ * high variance = higher QP
+ * low variance = lower QP
+ * This generally increases SSIM and lowers PSNR.
+*****************************************************************************/
+void x264_adaptive_quant( x264_t *h )
+{
+ int qp = h->mb.i_qp;
+ int energy;
+ if(h->param.analyse.i_aq_mode == 2)
+ energy = ac_energy_mb( h, h->mb.i_mb_x, h->mb.i_mb_y, NULL );
+ else
+ energy = h->rc->ac_energy[h->mb.i_mb_xy];
+ if(energy == 0)
+ h->mb.i_qp = h->mb.i_last_qp;
+ else
+ {
+ x264_cpu_restore(h->param.cpu);
+ float result = energy;
+ /* Adjust the QP based on the AC energy of the macroblock. */
+ float qp_adj = 3 * (logf(result) - h->rc->aq_threshold);
+ if(h->param.analyse.i_aq_mode == 1) qp_adj =
x264_clip3f(qp_adj, -5, 5);
+ int new_qp = x264_clip3(qp + qp_adj *
h->param.analyse.f_aq_strength + .5, h->param.rc.i_qp_min,
h->param.rc.i_qp_max);
+ /* If the QP of this MB is within 1 of the previous MB, code
the same QP as the previous MB,
+ * to lower the bit cost of the qp_delta. */
+ if(abs(new_qp - h->mb.i_last_qp) == 1) new_qp = h->mb.i_last_qp;
+ h->mb.i_qp = new_qp;
+ }
+ h->mb.i_chroma_qp = i_chroma_qp_table[x264_clip3( h->mb.i_qp +
h->pps->i_chroma_qp_index_offset, 0, 51 )];
+}

int x264_ratecontrol_new( x264_t *h )
{
@@ -244,7 +334,7 @@ int x264_ratecontrol_new( x264_t *h )
rc->rate_tolerance = 0.01;
}

- h->mb.b_variable_qp = rc->b_vbv && !rc->b_2pass;
+ h->mb.b_variable_qp = (rc->b_vbv && !rc->b_2pass) ||
h->param.analyse.i_aq_mode;

if( rc->b_abr )
{
@@ -458,10 +548,13 @@ int x264_ratecontrol_new( x264_t *h )
x264_free( p );
}

- for( i=1; i<h->param.i_threads; i++ )
+ for( i=0; i<h->param.i_threads; i++ )
{
h->thread[i]->rc = rc+i;
- rc[i] = rc[0];
+ if( i )
+ rc[i] = rc[0];
+ if( h->param.analyse.i_aq_mode == 1 )
+ rc[i].ac_energy = x264_malloc( h->mb.i_mb_count * sizeof(int) );
}

return 0;
@@ -623,6 +716,8 @@ void x264_ratecontrol_delete( x264_t *h )
x264_free( rc->zones[i].param );
x264_free( rc->zones );
}
+ for( i=0; i<h->param.i_threads; i++ )
+ x264_free( rc[i].ac_energy );
x264_free( rc );
}

@@ -729,6 +824,12 @@ void x264_ratecontrol_start( x264_t *h, int i_force_qp )

if( h->sh.i_type != SLICE_TYPE_B )
rc->last_non_b_pict_type = h->sh.i_type;
+
+ /* Adaptive AQ thresholding algorithm. */
+ if( h->param.analyse.i_aq_mode == 2 )
+ h->rc->aq_threshold = logf(14280.0); /* Arbitrary value for
"center" of AQ curve. */
+ else if( h->param.analyse.i_aq_mode == 1 )
+ x264_autosense_aq(h);
}

double predict_row_size( x264_t *h, int y, int qp )
diff --git a/encoder/ratecontrol.h b/encoder/ratecontrol.h
index d4af2c0..e8b2ea1 100644
--- a/encoder/ratecontrol.h
+++ b/encoder/ratecontrol.h
@@ -34,6 +34,7 @@ void x264_ratecontrol_mb( x264_t *, int bits );
int x264_ratecontrol_qp( x264_t * );
void x264_ratecontrol_end( x264_t *, int bits );
void x264_ratecontrol_summary( x264_t * );
+void x264_adaptive_quant ( x264_t * );

#endif

diff --git a/x264.c b/x264.c
index f68755d..cf318ed 100644
--- a/x264.c
+++ b/x264.c
@@ -244,6 +244,14 @@ static void Help( x264_param_t *defaults, int b_longhelp )
" - 2: enabled on all mode
decisions\n", defaults->analyse.i_trellis );
H0( " --no-fast-pskip Disables early SKIP detection
on P-frames\n" );
H0( " --no-dct-decimate Disables coefficient
thresholding on P-frames\n" );
+ H0( " --aq-strength <float> Reduces blocking and blurring
in flat and\n"
+ " textured areas. [%.1f]\n"
+ " - 0.2: weak AQ\n"
+ " - 1.0: very strong AQ\n",
defaults->analyse.f_aq_strength );
+ H0( " --aq-mode <integer> How AQ distributes bits [%d]\n"
+ " - 0: Disabled\n"
+ " - 1: Avoid moving bits
between frames\n"
+ " - 2: Move bits between
frames\n", defaults->analyse.i_aq_mode );
H0( " --nr <integer> Noise reduction [%d]\n",
defaults->analyse.i_noise_reduction );
H1( "\n" );
H1( " --deadzone-inter <int> Set the size of the inter luma
quantization deadzone [%d]\n", defaults->analyse.i_luma_deadzone[0] );
@@ -407,6 +415,8 @@ static int Parse( int argc, char **argv,
{ "trellis", required_argument, NULL, 't' },
{ "no-fast-pskip", no_argument, NULL, 0 },
{ "no-dct-decimate", no_argument, NULL, 0 },
+ { "aq-strength", required_argument, NULL, 0 },
+ { "aq-mode", required_argument, NULL, 0 },
{ "deadzone-inter", required_argument, NULL, '0' },
{ "deadzone-intra", required_argument, NULL, '0' },
{ "level", required_argument, NULL, 0 },
diff --git a/x264.h b/x264.h
index 70c9eaf..c367c41 100644
--- a/x264.h
+++ b/x264.h
@@ -232,6 +232,8 @@ typedef struct x264_param_t
int i_trellis; /* trellis RD quantization */
int b_fast_pskip; /* early SKIP detection on P-frames */
int b_dct_decimate; /* transform coefficient
thresholding on P-frames */
+ float f_aq_strength; /* psy adaptive QP */
+ int i_aq_mode; /* 0 = off, 1 = auto, 2 = static sensitivity */
int i_noise_reduction; /* adaptive pseudo-deadzone */

/* the deadzone size that will be used in luma quantization */

[bob0r]

fix:
change this part:
DECLARE_ALIGNED( static uint8_t, flat[16], 16 ) =
to
DECLARE_ALIGNED_16( static uint8_t flat[16] ) =

Also works for AQ 0.48.

Dark_Shikari still recommends we use 0.48, as 1.0 will have changed defaults, the same workings, just other values!

[J_Darnley]

I've already done that for 0.48 (and called it 0.49) and it still fails.
encoder/ratecontrol.c:179:50: macro "DECLARE_ALIGNED_16" passed 2 arguments, but takes just 1
encoder/ratecontrol.c:179:50: macro "DECLARE_ALIGNED_16" passed 2 arguments, but takes just 1
encoder/ratecontrol.c: In function `ac_energy_mb':
encoder/ratecontrol.c:179: error: `DECLARE_ALIGNED_16' undeclared (first use in this function)
encoder/ratecontrol.c:179: error: (Each undeclared identifier is reported only once
encoder/ratecontrol.c:179: error: for each function it appears in.)
encoder/ratecontrol.c:179: error: syntax error before '{' token
encoder/ratecontrol.c:179: warning: no return statement in function returning non-void
encoder/ratecontrol.c: At top level:
encoder/ratecontrol.c:182: error: syntax error before "for"
encoder/ratecontrol.c:185: error: `h' undeclared here (not in a function)
encoder/ratecontrol.c:187: error: `w' undeclared here (not in a function)
encoder/ratecontrol.c:187: error: `mb_x' undeclared here (not in a function)
encoder/ratecontrol.c:187: error: `mb_y' undeclared here (not in a function)
encoder/ratecontrol.c:189: error: initializer element is not constant
encoder/ratecontrol.c:190: error: syntax error before '<<=' token
encoder/ratecontrol.c:191: warning: type defaults to `int' in declaration of `sad'
encoder/ratecontrol.c:191: error: conflicting types for 'sad'
encoder/ratecontrol.c:181: error: previous declaration of 'sad' was here
encoder/ratecontrol.c:191: error: `flat' undeclared here (not in a function)
encoder/ratecontrol.c:191: warning: data definition has no type or storage class
encoder/ratecontrol.c:192: warning: type defaults to `int' in declaration of `ssd'
encoder/ratecontrol.c:192: error: conflicting types for 'ssd'
encoder/ratecontrol.c:181: error: previous declaration of 'ssd' was here
encoder/ratecontrol.c:192: warning: data definition has no type or storage class
encoder/ratecontrol.c:193: error: syntax error before '+=' token
encoder/ratecontrol.c: In function `parse_zone':
encoder/ratecontrol.c:570: warning: unused variable `saveptr'
encoder/ratecontrol.c: In function `parse_zones':
encoder/ratecontrol.c:613: warning: unused variable `saveptr'
make: *** [encoder/ratecontrol.o] Error 1
Is this an error on my end and/or do I need some other patch or make some other change? I tried using DECLARE_ALIGNED and it removed the problems with that but then it bitched about flat and the errors about w, h mb_x and mb_y remained. Also what I don't understand is why a 'simple' cosmetics change causes all these errors, ratecontrol.c wasn't changed in the last commit.

Anyway, I am sticking with r785 for now as the cosmetics don't make any change to the binary (right?).

[addit]

VAQ 2.0, impressive, most-impressive...

[bob0r]

@J_Darnley

You must have make a typ0 somewhere, can you paste the line you edited?

And yes you can use 785 just as fine.

[microchip8]

@ J_Darnley

you forgot to remove a comma between the ( .... ). The below code is correct

( static uint8_t flat[16] )

[Zep]

VAQ 1.0 has been released to Akupenguin for integrating with the official x264.

And here's a preview of VAQ 2.0 Pre-Alpha (links go to videos). The difference is... wow.
SSIM with VAQ 2.0 strength 1.0 (http://www.mediafire.com/?nmzhuturdm2): 0.9092416 (48.1% improvement over no AQ)


very nice detail but the contrast takes a hit and the over all encode looks a bit flat/washed out? Can that be improved upon? :D

[DeathTheSheep]

Where is this VAQ 2.0? Closed testing only? Or pre-pre-pre-pre-alpha? Or both? :) 50% SSIM improvement is surely nothing to scoff at.

[J_Darnley]

@ J_Darnley

you forgot to remove a comma between the ( .... ). The below code is correct

( static uint8_t flat[16] )
Thank you. I missed that lack of comma from bob0r's post.

Where is this VAQ 2.0? Closed testing only? Or pre-pre-pre-pre-alpha? Or both? :) 50% SSIM improvement is surely nothing to scoff at.
See my previous post where I asked the same question but then found the answer in another thread: http://forum.doom9.org/showthread.php?p=1115512#1115512
Its not released yet, still in early development ;)

1.0 will go into official GIT soon.

[Dark Shikari]

very nice detail but the contrast takes a hit and the over all encode looks a bit flat/washed out? Can that be improved upon? :DWhy do people keep opening multiple windows when comparing video, and then complain about the overlay not doing the proper TV -> PC luma conversion? :rolleyes:

[BoNz1]

VAQ 1.0 has been released to Akupenguin for integrating with the official x264.

And here's a preview of VAQ 2.0 Pre-Alpha (links go to videos). The difference is... wow.
SSIM with VAQ 2.0 strength 1.0 (http://www.mediafire.com/?nmzhuturdm2): 0.9092416 (48.1% improvement over no AQ)
SSIM with VAQ 2.0 (http://www.mediafire.com/?vdimcbmzdiz): 0.9016686 (36.7% improvement over no AQ)
SSIM with VAQ 0.48/1.0 (http://www.mediafire.com/?dhastytmz5w): 0.8881315 (13.8% improvement over no AQ)
SSIM with no VAQ (http://www.mediafire.com/?d1byyzumied): 0.8655435


Wow, that is absolutely huge. Seriously. Just look at the branches of the trees in the background and the ripples on the water in the foreground. They are completely washed out without VAQ but with it they are much clearer. Nicely done.

[bcrabl]

The difference is huge!

[burfadel]

The most striking thing is the AQ files are actually slightly smaller, so in effect VAQ2 strength 1 is even more efficient than 48.1% when taking in to account file size! (as you can slightly lower the crf).

[Dark Shikari]

The most striking thing is the AQ files are actually slightly smaller, so in effect VAQ2 strength 1 is even more efficient than 48.1% when taking in to account file size! (as you can slightly lower the crf).They're encoded in target bitrate mode (twopass), not CRF.

[burfadel]

ah ok! that does make for better comparison! If its a target bitrate mode, how come the no-aq file is larger?

[Dark Shikari]

ah ok! that does make for better comparison! If its a target bitrate mode, how come the no-aq file is larger?Because its only 200 frames, so the 2pass can't really get the bitrate perfectly.

Also note that I have already found some flaws in the algorithm used here that cause problems on some other sources, so as I said its definitely in early development. I have no doubt they can be fixed though.

[Zep]

Why do people keep opening multiple windows when comparing video, and then complain about the overlay not doing the proper TV -> PC luma conversion? :rolleyes:

huh? just 1 window. over lay is off anyway. I looked at one closed it then opened the new one.


NOTE: lets test your theory. I will open both in different order. Still washed out. Now I will open 2 copies of the same clip. exact same appearance. So we know that is not the problem.

[Razorholt]

@Darky: Can you please give us a rough idea on when both VAQ 1.0 and VQ 2.0 will be available for testing at least? I am about to encode more than 150 videos and I don't want to redo the whole batch after I find out your VAQ would have given a better result :D

Cheers,
- Dan

[Dark Shikari]

@Darky: Can you please give us a rough idea on when both VAQ 1.0 and VQ 2.0 will be available for testing at least? I am about to encode more than 150 videos and I don't want to redo the whole batch after I find out your VAQ would have given a better result :D

Cheers,
- DanMost current modified builds contain VAQ1 (0.48, technically, but 1.0 is just the cleaned up version for release; no algorithmic changes).

VAQ2 will be in a few weeks to months.

[DeathTheSheep]

Nice. Getting it perfected a bit, eh?

One question. Based on your testing so far, how good is it on anime?

[Dark Shikari]

Nice. Getting it perfected a bit, eh?

One question. Based on your testing so far, how good is it on anime?I just did some testing... and I'm not really sure.

In some cases AQ is vastly better than no AQ; in other cases its noticeably worse (due to the bits being moved from one place to another, lowering quality in those original places). There isn't too much difference between VAQ1 and VAQ2.

[DeathTheSheep]

Ah, you win some, you lose some. :(

Would you say it beats 0.46 for anime, assuming CQP (I know, I know...but still)?

[Dark Shikari]

Ah, you win some, you lose some. :(

Would you say it beats 0.46 for anime, assuming CQP (I know, I know...but still)?I really can't say at this point whether AQ is better than non-AQ or what. Almost all the AQ algorithms are nearly exactly the same for anime in terms of results, except that VAQ2 weights single edges somewhat lower and multiple tightly spaced edges a lot higher.

The general end result is that x264 looks more like Xvid; more blurred/ringy edges at low bitrates, but less blurring of background detail.

One of the general problems I'm encountering is that sharp edges cause every single VAQ so far to raise the quantizer a lot, even though this might not be justified. Perhaps I need an AQ metric that can somehow measure complexity independent of such edges?

Edit: I did a bit more looking over my tests and it appears the primary "problem" is that bits are redistributed--some scenes get more than before, some less. This actually seems to be a good thing overall, since there's huge amounts of background blurring that are fixed by AQ. Overall I'd say its a positive at this point, and the various VAQs are mostly indistinguishable. There's still room for improvement though.

[burfadel]

Modern animation usaually has very flat blocks (I say modern as for example, the original Tom & Jerry cartoons for the 40's were textured), so couldn't there be a way for the encoder to realise its an animation or animation segment and maybe lower the strength or change the sensitivity etc based on this? That would solve the lower quality with animation problem.

[ImmortAlex]

Smells like "cartoon mode" in XviD :)

[Lele-brz]

I was very impress by the VAQ 2.0 and I'm looking forward to using it.
I wrote a tool to compare two videos in the same window, and you can easily see how big the improvement is.
I don't know the policy about posting a link to a software and I don't even want to go off topic.

Anyway the software can be found here:
http://www.mediafire.com/?2j1h211ba1m

It's for Windows, after launching "CompVideo" just left click to switch from one version to the other.

Bye

PS: Hope this doesn't violate any posting rule.

[burfadel]

Kinda like cartoon mode I guess, except I mean a completely automatic decision based on the flatness of the current section. SO for normal video its at the default AQ settings, and when large flatness is detected a trimming of the strength or adjustment of the sensitivity etc so as to not lose line detail.

[Sharktooth]

I was very impress by the VAQ 2.0 and I'm looking forward to using it.
I wrote a tool to compare two videos in the same window, and you can easily see how big the improvement is.
I don't know the policy about posting a link to a software and I don't even want to go off topic.

Anyway the software can be found here:
http://www.mediafire.com/?2j1h211ba1m

It's for Windows, after launching "CompVideo" just left click to switch from one version to the other.

Bye

PS: Hope this doesn't violate any posting rule.
it should be ok unless you infested your software with viruses, malwares, etc.. :p
in that case, revenge is a meal best server cold... :D

[DeathTheSheep]

Lol, are you thinking Sony rootkits and DRM, Sharktooth? :p

[burfadel]

I guess the variable VAQ (VVAQ?!) I suggested earlier, where the strength is reduced and/or the sensitivity increased for clips with a high level of flatness (ie most animation) etc to overcome sharp line degradation wouldn't actually work?

[akupenguin]

Modern animation usaually has very flat blocks (I say modern as for example, the original Tom & Jerry cartoons for the 40's were textured), so couldn't there be a way for the encoder to realise its an animation or animation segment and maybe lower the strength or change the sensitivity etc based on this? That would solve the lower quality with animation problem.
Probably possible, but what do you gain by that? Detecting animation is just a user-interface convenience, a shortcut for saying "so use these other settings on anime". The hard part is writing the alternate algorithm that works there.

[burfadel]

The idea was more to automatically scale back the aq settings when flat scenes are detected, so bitrate is not lost where its not needed (say a bright very flat floor for example in animation). It seems what people refer to as a loss of clarity is in animation that is bright, and due to the smoothness of the surrounding pieces around the lines the shifting of bits from those lines becomes more noticeable. Although the settings can be done manually, by having it set to auto people not acustomed to choosing their own settings based on the source will benefit, as well as everyone else due to simplifying the adjustment of options.

Automatic AQ would be harder to implement for 2 pass, but the idea I had for CRF is to have say, the default strength of 0.5 and sensitivity 13 for normal shots, and then when a flatness threshold is achieved scale it back to say 0.4 and sensitivity 14 or something along those lines. The strength being +0.5 or -2. and sensitivity -1 to +4 would be good compromise and be suited for most sources in my opinion (maybe slightly less than that).

Wasn't automatic thresholding etc exist in earlier revisions? maybe that part can be reintroduced, possibly with the ability to turn it off. Anyways, a strength of 0.3 and sensitivity of 16 or so does seem better for some animation clips.

[DeathTheSheep]

Yeah, since I did promise to maintain it, and 2.0 may be a few days/weeks/months/hours away, why not have at 0.46 in the meantime. Special edition updated for 798. :p

Index: encoder/ratecontrol.h
===================================================================
--- encoder/ratecontrol.h (revision 721)
+++ encoder/ratecontrol.h (working copy)
@@ -34,6 +34,8 @@
int x264_ratecontrol_qp( x264_t * );
void x264_ratecontrol_end( x264_t *, int bits );
void x264_ratecontrol_summary( x264_t * );
+void x264_autosense_aq ( x264_t *);
+void x264_adaptive_quant ( x264_t * );

#endif

Index: encoder/encoder.c
===================================================================
--- encoder/encoder.c (revision 721)
+++ encoder/encoder.c (working copy)
@@ -472,6 +472,8 @@
if( !h->param.b_cabac )
h->param.analyse.i_trellis = 0;
h->param.analyse.i_trellis = x264_clip3( h->param.analyse.i_trellis, 0, 2 );
+ if( h->param.analyse.b_aq && h->param.analyse.f_aq_strength <= 0 )
+ h->param.analyse.b_aq = 0;
h->param.analyse.i_noise_reduction = x264_clip3( h->param.analyse.i_noise_reduction, 0, 1<<16 );

{
@@ -1046,6 +1048,18 @@
h->mb.i_last_qp = h->sh.i_qp;
h->mb.i_last_dqp = 0;

+ /* Adaptive AQ sensitivity algorithm. */
+ if(h->param.analyse.b_aq)
+ {
+ x264_cpu_restore(h->param.cpu);
+ if(h->param.analyse.f_aq_sensitivity != 0)
+ h->aq_threshold = powf(h->param.analyse.f_aq_sensitivity,4)/2;
+ else
+ {
+ x264_autosense_aq(h);
+ }
+ }
+
for( mb_xy = h->sh.i_first_mb, i_skip = 0; mb_xy < h->sh.i_last_mb; )
{
const int i_mb_y = mb_xy / h->sps->i_mb_width;
Index: encoder/ratecontrol.c
===================================================================
--- encoder/ratecontrol.c (revision 721)
+++ encoder/ratecontrol.c (working copy)
@@ -126,6 +126,9 @@
predictor_t *pred_b_from_p; /* predict B-frame size from P-frame satd */
int bframes; /* # consecutive B-frames before this P-frame */
int bframe_bits; /* total cost of those frames */
+
+ /* AQ stuff */
+ int *ac_energy;

int i_zones;
x264_zone_t *zones;
@@ -168,7 +171,134 @@
+ rce->misc_bits;
}

+//Finds the total AC energy of the block in all planes. Does not require the MB to be cached.
+static int ac_energy_mb_uncached(x264_t *h, int i_pix_offset0, int i_pix_offset1)
+{
+ DECLARE_ALIGNED_16( static uint8_t zero[16] );
+ int sad = h->pixf.sad[PIXEL_16x16](zero,0,&h->fenc->plane[0][i_pix_offset0], h->fenc->i_stride[0] << h->mb.b_interlaced) >> 4;
+ int ssd = h->pixf.ssd[PIXEL_16x16](zero,0,&h->fenc->plane[0][i_pix_offset0], h->fenc->i_stride[0] << h->mb.b_interlaced);
+ int totalSSD = ssd - (sad * sad);
+ sad = h->pixf.sad[PIXEL_8x8](zero,0,&h->fenc->plane[1][i_pix_offset1], h->fenc->i_stride[1] << h->mb.b_interlaced) >> 3;
+ ssd = h->pixf.ssd[PIXEL_8x8](zero,0,&h->fenc->plane[1][i_pix_offset1], h->fenc->i_stride[1] << h->mb.b_interlaced);
+ totalSSD += ssd - (sad * sad);
+ sad = h->pixf.sad[PIXEL_8x8](zero,0,&h->fenc->plane[2][i_pix_offset1], h->fenc->i_stride[2] << h->mb.b_interlaced) >> 3;
+ ssd = h->pixf.ssd[PIXEL_8x8](zero,0,&h->fenc->plane[2][i_pix_offset1], h->fenc->i_stride[2] << h->mb.b_interlaced);
+ totalSSD += ssd - (sad * sad);
+ return totalSSD;
+}
+
+//Find the total SATD score of a block. Represents the block's overall complexity (bit cost) for intra encoding.
+static int satd_mb(x264_t *h, int i_pix_offset0, int i_pix_offset1)
+{
+ DECLARE_ALIGNED_16( static uint8_t zero[16] );
+ int totalSATD = h->pixf.satd[PIXEL_16x16](zero,0,&h->fenc->plane[0][i_pix_offset0], h->fenc->i_stride[0] << h->mb.b_interlaced);
+ totalSATD += h->pixf.satd[PIXEL_8x8](zero,0,&h->fenc->plane[1][i_pix_offset1], h->fenc->i_stride[1] << h->mb.b_interlaced);
+ totalSATD += h->pixf.satd[PIXEL_8x8](zero,0,&h->fenc->plane[2][i_pix_offset1], h->fenc->i_stride[2] << h->mb.b_interlaced);
+ return totalSATD;
+}

+void x264_autosense_aq( x264_t *h )
+{
+ double total = 0;
+ double n = 0;
+ /* FIXME: Easier way to iterate over MBs? Do we need to do the full cache_load? */
+ /* FIXME: Some of the SATDs might be already calculated elsewhere (ratecontrol?). Can we reuse them? */
+ /* FIXME: Store the data, then do the logs after, to avoid the cpu_restores every single cycle? */
+ /* FIXME: Is chroma SATD necessary? */
+ int i_mb_y = 0;
+ int i_mb_x = 0;
+ while( i_mb_y < h->sps->i_mb_height )
+ {
+ int i_stride = h->fdec->i_stride[0];
+ const int i_pix_offset0 = h->mb.b_interlaced
+ ? 16 * (i_mb_x + (i_mb_y&~1) * i_stride) + (i_mb_y&1) * i_stride
+ : 16 * (i_mb_x + i_mb_y * i_stride);
+ i_stride = h->fdec->i_stride[1];
+ const int i_pix_offset1 = h->mb.b_interlaced
+ ? 8 * (i_mb_x + (i_mb_y&~1) * i_stride) + (i_mb_y&1) * i_stride
+ : 8 * (i_mb_x + i_mb_y * i_stride);
+ int energy = ac_energy_mb_uncached(h,i_pix_offset0,i_pix_offset1);
+ h->rc->ac_energy[i_mb_x + i_mb_y * h->sps->i_mb_width] = energy;
+ /* Weight the energy value by the SATD value of the MB. This represents the fact that
+ the more complex blocks in a frame should be weighted more when calculating the optimal sensitivity.
+ This also helps diminish the negative effect of large numbers of simple blocks in a frame, such as in the case
+ of a letterboxed film. */
+ if(energy != 0)
+ {
+ int satd = satd_mb(h,i_pix_offset0,i_pix_offset1);
+ x264_cpu_restore(h->param.cpu);
+ total += log(energy) * satd;
+ n += satd;
+ }
+ i_mb_x++;
+ if(i_mb_x == h->sps->i_mb_width)
+ {
+ i_mb_x = 0;
+ i_mb_y++;
+ }
+ }
+ x264_cpu_restore(h->param.cpu);
+ /* Calculate and store the threshold. */
+ if(n == 0) h->aq_threshold = 100000;
+ else h->aq_threshold = expf(total / n);
+}
+
+
+//Finds the total AC energy of the block in all planes.
+static int ac_energy_mb_cached(x264_t *h)
+{
+ DECLARE_ALIGNED_16( static uint8_t zero[16] );
+ int sad = h->pixf.sad[PIXEL_16x16](zero,0,h->mb.pic.p_fenc[0],FENC_STRIDE) >> 4;
+ int ssd = h->pixf.ssd[PIXEL_16x16](zero,0,h->mb.pic.p_fenc[0],FENC_STRIDE);
+ int totalSSD = ssd - (sad * sad);
+ sad = h->pixf.sad[PIXEL_8x8](zero,0,h->mb.pic.p_fenc[1],FENC_STRIDE) >> 3;
+ ssd = h->pixf.ssd[PIXEL_8x8](zero,0,h->mb.pic.p_fenc[1],FENC_STRIDE);
+ totalSSD += ssd - (sad * sad);
+ sad = h->pixf.sad[PIXEL_8x8](zero,0,h->mb.pic.p_fenc[2],FENC_STRIDE) >> 3;
+ ssd = h->pixf.ssd[PIXEL_8x8](zero,0,h->mb.pic.p_fenc[2],FENC_STRIDE);
+ totalSSD += ssd - (sad * sad);
+ return totalSSD;
+}
+
+/*****************************************************************************
+* x264_adaptive_quant:
+ * adjust macroblock QP based on variance (AC energy) of the MB.
+ * high variance = higher QP
+ * low variance = lower QP
+ * This generally increases SSIM and lowers PSNR.
+ * To save bits in B-frames, adaptive lambda is used instead of adaptive quantization.
+*****************************************************************************/
+void x264_adaptive_quant( x264_t *h )
+{
+ int qp = h->mb.i_qp;
+ int energy;
+ x264_cpu_restore(h->param.cpu);
+ if(h->param.analyse.f_aq_sensitivity != 0)
+ {
+ energy = ac_energy_mb_cached(h);
+ }
+ else energy = h->rc->ac_energy[h->mb.i_mb_xy];
+ if(energy == 0)
+ {
+ h->mb.i_qp = h->mb.i_last_qp;
+ h->mb.i_chroma_qp = i_chroma_qp_table[x264_clip3( h->mb.i_qp + h->pps->i_chroma_qp_index_offset, 0, 51 )];
+ }
+ else
+ {
+ x264_cpu_restore(h->param.cpu);
+ float result = energy;
+ /* Adjust the QP based on the AC energy of the macroblock. */
+ int qp_adj = -3.0 * h->param.analyse.f_aq_strength * log(result / h->aq_threshold);
+ if(h->param.analyse.f_aq_sensitivity == 0) qp_adj = x264_clip3(qp_adj,-5*h->param.analyse.f_aq_strength,5*h->param.analyse.f_aq_strength);
+ int new_qp = x264_clip3(qp - qp_adj,h->param.rc.i_qp_min,h->param.rc.i_qp_max);
+ /* If the QP of this MB is within 1 of the previous MB, code the same QP as the previous MB, to lower the bit
+ cost of the qp_delta. */
+ if(abs(new_qp - h->mb.i_last_qp) == 1) new_qp = h->mb.i_last_qp;
+ h->mb.i_qp = new_qp;
+ h->mb.i_chroma_qp = i_chroma_qp_table[x264_clip3( h->mb.i_qp + h->pps->i_chroma_qp_index_offset, 0, 51 )];
+ }
+}
+
int x264_ratecontrol_new( x264_t *h )
{
x264_ratecontrol_t *rc;
@@ -727,6 +857,19 @@

if( h->sh.i_type != SLICE_TYPE_B )
rc->last_non_b_pict_type = h->sh.i_type;
+
+ /* Adaptive AQ sensitivity algorithm. */
+ if(h->param.analyse.f_aq_strength != 0)
+ {
+ if(h->param.analyse.f_aq_sensitivity != 0)
+ {
+ h->aq_threshold = powf(h->param.analyse.f_aq_sensitivity,4)/2;
+ }
+ else
+ {
+ x264_autosense_aq(h);
+ }
+ }
}

double predict_row_size( x264_t *h, int y, int qp )
Index: encoder/analyse.c
===================================================================
--- encoder/analyse.c (revision 721)
+++ encoder/analyse.c (working copy)
@@ -29,6 +29,7 @@
#endif

#include "common/common.h"
+#include "common/cpu.h"
#include "macroblock.h"
#include "me.h"
#include "ratecontrol.h"
@@ -2047,8 +2048,13 @@
int i_cost = COST_MAX;
int i;

- /* init analysis */
- x264_mb_analyse_init( h, &analysis, x264_ratecontrol_qp( h ) );
+ h->mb.i_qp = x264_ratecontrol_qp( h );
+
+ if( h->param.analyse.b_aq )
+ x264_adaptive_quant( h );
+
+ /* init analysis */
+ x264_mb_analyse_init( h, &analysis, h->mb.i_qp );

/*--------------------------- Do the analysis ---------------------------*/
if( h->sh.i_type == SLICE_TYPE_I )
Index: x264.c
===================================================================
--- x264.c (revision 721)
+++ x264.c (working copy)
@@ -243,6 +243,14 @@
" - 2: enabled on all mode decisions\n", defaults->analyse.i_trellis );
H0( " --no-fast-pskip Disables early SKIP detection on P-frames\n" );
H0( " --no-dct-decimate Disables coefficient thresholding on P-frames\n" );
+ H0( " --aq-strength <float> Amount to adjust QP/lambda per MB [%.1f]\n"
+ " 0.0: no AQ\n"
+ " 1.0: medium AQ\n", defaults->analyse.f_aq_strength );
+ H0( " --aq-sensitivity <float> \"Center\" of AQ curve. [%.1f]\n"
+ " 0: automatic sensitivity (avoids moving bits between frames)\n"
+ " 10: most QPs are raised\n"
+ " 20: good general-use sensitivity\n"
+ " 30: most QPs are lowered\n", defaults->analyse.f_aq_sensitivity );
H0( " --nr <integer> Noise reduction [%d]\n", defaults->analyse.i_noise_reduction );
H1( "\n" );
H1( " --deadzone-inter <int> Set the size of the inter luma quantization deadzone [%d]\n", defaults->analyse.i_luma_deadzone[0] );
@@ -406,6 +414,8 @@
{ "trellis", required_argument, NULL, 't' },
{ "no-fast-pskip", no_argument, NULL, 0 },
{ "no-dct-decimate", no_argument, NULL, 0 },
+ { "aq-strength", required_argument, NULL, 0 },
+ { "aq-sensitivity", required_argument, NULL, 0 },
{ "deadzone-inter", required_argument, NULL, '0' },
{ "deadzone-intra", required_argument, NULL, '0' },
{ "level", required_argument, NULL, 0 },
Index: common/common.c
===================================================================
--- common/common.c (revision 721)
+++ common/common.c (working copy)
@@ -123,6 +123,9 @@
param->analyse.i_chroma_qp_offset = 0;
param->analyse.b_fast_pskip = 1;
param->analyse.b_dct_decimate = 1;
+ param->analyse.b_aq = 0;
+ param->analyse.f_aq_strength = 0.0;
+ param->analyse.f_aq_sensitivity = 20;
param->analyse.i_luma_deadzone[0] = 21;
param->analyse.i_luma_deadzone[1] = 11;
param->analyse.b_psnr = 1;
@@ -455,6 +458,13 @@
p->analyse.b_fast_pskip = atobool(value);
OPT("dct-decimate")
p->analyse.b_dct_decimate = atobool(value);
+ OPT("aq-strength")
+ {
+ p->analyse.f_aq_strength = atof(value);
+ p->analyse.b_aq = (p->analyse.f_aq_strength > 0.0);
+ }
+ OPT("aq-sensitivity")
+ p->analyse.f_aq_sensitivity = atof(value);
OPT("deadzone-inter")
p->analyse.i_luma_deadzone[0] = atoi(value);
OPT("deadzone-intra")
@@ -815,9 +825,9 @@
c = a % b;
while(c)
{
- a = b;
- b = c;
- c = a % b;
+ a = b;
+ b = c;
+ c = a % b;
}
*n /= b;
*d /= b;
@@ -935,10 +945,15 @@
s += sprintf( s, " pb_ratio=%.2f", p->rc.f_pb_factor );
if( p->rc.psz_zones )
s += sprintf( s, " zones=%s", p->rc.psz_zones );
+ if( p->analyse.b_aq )
+ s += sprintf( s, " aq=1:%.1f:%.1f", p->analyse.f_aq_strength, p->analyse.f_aq_sensitivity );
else if( p->rc.i_zones )
s += sprintf( s, " zones" );
}

+ if( p->analyse.b_aq )
+ s += sprintf( s, " aq=1:%.1f:%.1f", p->analyse.f_aq_strength, p->analyse.f_aq_sensitivity );
+
return buf;
}

Index: common/common.h
===================================================================
--- common/common.h (revision 721)
+++ common/common.h (working copy)
@@ -331,8 +331,9 @@
x264_frame_t *fref1[16+3]; /* ref list 1 */
int b_ref_reorder[2];

+ /* AQ stuff */
+ float aq_threshold;

-
/* Current MB DCT coeffs */
struct
{
Index: x264.h
===================================================================
--- x264.h (revision 721)
+++ x264.h (working copy)
@@ -230,6 +230,9 @@
int i_trellis; /* trellis RD quantization */
int b_fast_pskip; /* early SKIP detection on P-frames */
int b_dct_decimate; /* transform coefficient thresholding on P-frames */
+ int b_aq; /* psy adaptive QP */
+ float f_aq_strength;
+ float f_aq_sensitivity;
int i_noise_reduction; /* adaptive pseudo-deadzone */

/* the deadzone size that will be used in luma quantization */

[Ranguvar]

IIRC, Sharktooth once said something about not using his high bitrate AVC CQM with AQ, I believe because of something like them both doing the same thing.

Please, what are the effects of using custom matrices with VAQ? Is it recommended to choose one, or the other?

[Dark Shikari]

IIRC, Sharktooth once said something about not using his high bitrate AVC CQM with AQ, I believe because of something like them both doing the same thing.

Please, what are the effects of using custom matrices with VAQ? Is it recommended to choose one, or the other?They work fine with VAQ; its just that they might be less necessary.

[*.mp4 guy]

They work fine with VAQ; its just that they might be less necessary.

They work fine with it, but often they are both trying to achieve the same thing, and have similar disadvantages. Often what happens when you use a cqm and aq at the same time on qp ~20+ encodes is that the disadvantages outway the advantages. Both cqm's and aq are technically bad for efficiency, and both introduce ringing, putting them together never works well on low bitrates, and is risky until you get to very very high bitrates.

[CruNcher]

They work fine with it, but often they are both trying to achieve the same thing, and have similar disadvantages. Often what happens when you use a cqm and aq at the same time on qp ~20+ encodes is that the disadvantages outway the advantages. Both cqm's and aq are technically bad for efficiency, and both introduce ringing, putting them together never works well on low bitrates, and is risky until you get to very very high bitrates.

My Experience is that for High Profile a CQM with VAQ can
help visualy reducing the ringing introduced (or amplified "source allready had visible ringing @ edges") by it @ edges, unfortunately that isn't possible for Main Profile.

@DeathTheSheep
Nice thx and yeah the older generation of AQs was more sane with the Edges the new generation after 0.46 amplifies ringing or creates ringing very often (especialy in live encoding scenarios), especialy it's bad for Main Profile where you have no chance to compensate it visualy with a CQM.

[burfadel]

A strength of 0.3 and sensitivity of 17 goes a long way to help with that I feel.

[CruNcher]

jep burfadel sure pumping up the bitrate helps but exactly that's what i try to avoid here :D

[burfadel]

On a test I just did, which concurs with an earlier test of mine:

AQ Disabled:
Size:1242kb, SSIM:0.9796759

Strenth Default, Sensitivity Default
Size:1169kb, SSIM:0.9793588

Strenth 0.5, Sensitivity 0 (Sensitivity 0 = automatic)
Size:1240kb, SSIM:0.9809342

I also did some other values, but the file sizes were larger. Going by that, the default sensitivity is not ideal and you actually end up with a lower SSIM! Having the sensitivity as automatic (set to 0), the file size is essentially identical to that of no AQ but the SSIM is raised.

Wasn't it the default of 0.46 to have automatic sensitivity? that may be why it produces better results in certain circumstances. Have a try, it would be interesting to see whether you come to the same conclusions! Automatic sensitivity was also slightly faster :)

[Dark Shikari]

I also did some other values, but the file sizes were larger. Going by that, the default sensitivity is not ideal and you actually end up with a lower SSIM! Having the sensitivity as automatic (set to 0), the file size is essentially identical to that of no AQ but the SSIM is raised.Comparing between different file sizes is totally meaningless.
Wasn't it the default of 0.46 to have automatic sensitivity?No

[burfadel]

Comparing between different file sizes is totally meaningless.


I do realise that :) probably wasn't the best thing to say! I was more getting to the point that the SSIM increases without a penalty in terms of file size when the sensitivity is set to 0.

I did the same test again, with a different clip. This came up with more interesting results...

With default AQ settings:
SSIM: 9811467
Size: 3870kb

With Sensitivity 0, default strength:
SSIM: 9813178
Size: 3755kb

In this case sensitivity set to automatic increased SSIM over that of default, and had a smaller file size!... And yes I know file size isn't a good comparison, but the fact that its better quality and smaller does has some significance. Subjectively the results are identical.

For those with bad results with AQ 0.48, maybe they should try sensitivity of 0 and see if their results improve?

I do apologise for going on about it, especially if it is only I who have had these results! I just can't help to mention that it consistently comes up with better results with sensitivity of 0 over that of the default :)

[Dark Shikari]

I just can't help to mention that it consistently comes up with better results with sensitivity of 0 over that of the default :)Better SSIM doesn't actually necessarily mean better quality.

[burfadel]

Ah ok! that explains it then :) I'm looking forward to VAQ 2.0, keep up the good work!

[CruNcher]

burfadel sensitivity 0 is the worst you can do visualy in many cases (to less bits are moved into the background in most of the scenes)

[Razorholt]

Hopefully v2.0 will end the "VAQ 0.46 vs. VAQ 0.48" war. BTW, I like 0.46 better when I'm dealing with very low birates (550 to 640). Speaking of which, what is the minimum birates required for VAQ to act efficiently? Should I disable it when dealing with very low birates?

I'm on a challenge here :D : http://forum.doom9.org/showthread.php?p=1119102#post1119102


Thanks,
-Dan

[canuckerfan]

was digging through this thread and I must say it's a very interesting read. was wondering if VAQ is enabled by default in Jarod's patched builds?