Another milestone of sorts — an even 350 active FATE tests. Thanks to Vitor for figuring out what was wrong with my ea-tgq test. It seems that I was being overzealous with my application of the ‘-idct simple’ option. While normally standard testing procedure for DCT-type codecs, the simple IDCT option made this test overflow, according to Vitor.
I’m really starting to run out of FATE tests to add before I’m forced to stop putting off the fundamental upgrades that would allow me to test the remaining stuff (mostly encoders, muxers, and bit-inexact audio).
I learned something else related to FATE: Don’t mount a suite of FATE samples over wireless if such an arrangement can be avoided. I was able to save around 4 minutes per test cycle on my Mac Mini by not mounting the share with 300 MB of FATE test samples via wireless-G, but instead rsyncing locally. Thus, the Mac Mini, which only has to worry about 2 configurations, tends to be the most frequent builder.
Eating my own rsync repository has the benefit of allowing me to properly test that samples are staged before I activate them, which has bitten us repeatedly.
> Thanks to Vitor for figuring out what was wrong with my ea-tgq test. It seems that I was being overzealous with my application of the ‘-idct simple’ option. While normally standard testing procedure for DCT-type codecs, the simple IDCT sample made this test overflow, according to Vitor.
Yes, unfortunately several codecs use the IDCT pointer for things that aren’t even close to regular IDCT. Bink and vp3 do it too.
I’m not sure about the “not even close” part. At least in VP3, the IDCT is documented to be a different type (type II?) than the usual JPEG/MPEG IDCT.
Bink’s IDCT is bit exact across platforms. That alone makes me suspicious.
> It seems that I was being overzealous with my application of
> the ‘-idct simple’ option. While normally standard testing
> procedure for DCT-type codecs, the simple IDCT option made
> this test overflow
Another advantage of not overusing “-idct simple” is that it allows for testing the other IDCT algos.
For those wondering what exactly was wrong with the simple IDCT in this case, the following code (triggered by ea-tgq) gives different results on x86 and PPC for “-idct simple”:
static void test1(DSPContext *dsp)
{
DECLARE_ALIGNED_16(DCTELEM, block)[64] = {0};
DECLARE_ALIGNED_16(int8_t, out)[128] = {0};
int i,j;
block[ 0] = 4192;
block[ 8] = -1536;
block[16] = -1280;
block[24] = -896;
block[32] = -480;
block[40] = -160;
block[48] = 0;
block[56] = 32;
dsp->idct_put(out , 16, block);
for(i=0; i < 8; i++) {
for(j=0; j < 8; j++)
av_log(NULL, AV_LOG_ERROR, "%i ", out[i*16+j]);
av_log(NULL, AV_LOG_ERROR, "\n");
}
}