Current Patches, Where to get them, How they affect speed/output

[Dark Shikari]

Originally Posted by akupenguin

Did you skip over the testing of a normal build with --no-asm ?

Yes, since the bug is most probably in inline assembly, not autoloaded, but that's a good idea--we should test that, too.

[3ngel]

How can it be a bug on one type of processor? Never heard something like this

[LoRd_MuldeR]

Maybe that CPU has some undocumented feature (one may say "bug") that only triggers in this particular situation...

[kemuri-_9]

what was the x264 parameters that you used? I was unable to reproduce the error with the x264.nl build nor my own with some simple settings.
might be specific to the parameters and the cpu...

but then again, i'm still at work and doing these tests through RDP, so it may be messing with the visualization.

either way, it would be helpful for me if you could provide the parameters as i seem to be the only one around with a phenom to try reduplicating the error,
which in then turn can help akupenguin and Dark Shikari at solving the issue.

[3ngel]

It's 2 pass

x264.999kMod.genericGCC433.exe --pass 1 --bitrate 3984 --stats ".stats" --progress --keyint 250 --bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip --mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --direct-8x8 -1 --me umh --merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate  --level 41 --output NUL "t.avs"

x264.999kMod.genericGCC433.exe --pass 2 --bitrate 3984 --stats ".stats" --progress --keyint 250 --bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip --mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --direct-8x8 -1 --me umh --merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate  --level 41 --output "2pass.mkv" "t.avs"

This is getting more and more strange

For the moment i'm alone in my trouble

Ehehe

[LoRd_MuldeR]

3ngel, is your CPU overclocked? Did you run Prime95 for a few hours, check your RAM with Memtest86+ and so on ???

[3ngel]

No, stock cpu and mem. No overclock.

If it was a mem corrupt problem the --noasm would have the same problem (and the problem could not be reproduced systematically as it is).
Moreover the situation happens only on BW credits streams or white text on black. On color or any other stream not a problem.

[kemuri-_9]

Originally Posted by 3ngel

It's 2 pass

x264.999kMod.genericGCC433.exe --pass 1 --bitrate 3984 --stats ".stats" --progress --keyint 250
--bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip
--mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --direct-8x8 -1 --me umh
--merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate  --level 41 --output NUL "t.avs"

x264.999kMod.genericGCC433.exe --pass 2 --bitrate 3984 --stats ".stats" --progress --keyint 250
--bframes 16 --qpmin 10 --qpmax 51 --aq-mode 0 --psy-rd 0.8:0 --no-psnr --no-ssim --no-fast-pskip
--mixed-refs --b-adapt 0 --trellis 2 --ref 9 --no-deblock --subme 7 --direct auto --direct-8x8 -1 --me umh
--merange 32 --nf --weightb --b-pyramid --partitions all --8x8dct --threads auto --thread-input --no-dct-decimate  --level 41 --output "2pass.mkv" "t.avs"

This is getting more and more strange

For the moment i'm alone in my trouble

Ehehe

confirmed error for those settings!
--asm 0 has no error.

StackVertical comparison:
top is --asm 0
bottom is running asm based on cpu detection.
snap

used the std x264.nl build

[Dark Shikari]

Can you raise --asm progressively (MMX2, SSE2Slow, SSE2, etc, etc) and see which setting is the lowest at which the problem occurs?

Oh, and before you do that, make checkasm and run checkasm. It should fail if there really is a problem.

[3ngel]

confirmed error for those settings!

Phew...

Ehehe

[kemuri-_9]

sure i'll do that when i get back to the house, about to leave work now... so be a while
however, i did the same settings except with psy-rd set to 0:0 and couldn't see an error with asm active.

[Dark Shikari]

Originally Posted by kemuri-_9

sure i'll do that when i get back to the house, about to leave work now... so be a while
however, i did the same settings except with psy-rd set to 0:0 and couldn't see an error with asm active.

Since the error could be triggered out of mere coincidence, just because it disappears with an option changed doesn't mean that option is at fault.

[kemuri-_9]

indeed, since dropping it back to threads 1 also didn't have an error.

but as for checking increasing asm to pinpoint the error:
MMX2: no error
SSE2Slow: no error
SSE2: error
SSE2Fast: error

$ ./checkasm.exe 
x264: using random seed 56950896
x264: MMX
 - pixel sad :           [OK]
 - pixel sad_aligned :   [OK]
 - pixel ssd :           [OK]
 - pixel satd :          [OK]
 - pixel sa8d :          [OK]
 - pixel sad_x3 :        [OK]
 - pixel sad_x4 :        [OK]
 - pixel var :           [OK]
 - pixel hadamard_ac :   [OK]
 - intra satd_x3 :       [OK]
 - intra sad_x3 :        [OK]
 - ssim :                [OK]
 - esa ads:              [OK]
 - sub_dct4 :            [OK]
 - sub_dct8 :            [OK]
 - add_idct4 :           [OK]
 - add_idct8 :           [OK]
 - (i)dct4x4dc :         [OK]
 - zigzag_frame :        [OK]
 - zigzag_field :        [OK]
 - mc luma :             [OK]
 - mc chroma :           [OK]
 - mc wpredb :           [OK]
 - hpel filter :         [OK]
 - lowres init :         [OK]
 - intra pred :          [OK]
 - deblock :             [OK]
 - quant :               [OK]
 - dequant :             [OK]
 - denoise dct :         [OK]
 - cabac :               [OK]
x264: MMX Cache64
 - pixel sad :           [OK]
 - pixel sad_x3 :        [OK]
 - pixel sad_x4 :        [OK]
 - mc luma :             [OK]
 - lowres init :         [OK]
x264: MMX Cache32
 - pixel sad :           [OK]
 - pixel sad_x3 :        [OK]
 - pixel sad_x4 :        [OK]
 - mc luma :             [OK]
 - lowres init :         [OK]
x264: SSE2Slow
 - pixel sad_aligned :   [OK]
 - pixel ssd :           [OK]
 - pixel satd :          [OK]
 - pixel sa8d :          [OK]
 - pixel var :           [OK]
 - ssim :                [OK]
 - sub_dct4 :            [OK]
 - sub_dct8 :            [OK]
 - add_idct4 :           [OK]
 - add_idct8 :           [OK]
 - hpel filter :         [OK]
 - intra pred :          [OK]
 - deblock :             [OK]
 - quant :               [OK]
 - dequant :             [OK]
 - denoise dct :         [OK]
x264: SSE2Fast
 - pixel sad :           [OK]
 - pixel sad_x3 :        [OK]
 - pixel sad_x4 :        [OK]
 - pixel var :           [OK]
 - pixel hadamard_ac :   [OK]
 - intra sad_x3 :        [OK]
 - esa ads:              [OK]
 - zigzag_frame :        [OK]
 - mc luma :             [OK]
 - mc chroma :           [OK]
 - mc wpredb :           [OK]
 - hpel filter :         [OK]
 - lowres init :         [OK]
 - intra pred :          [OK]
x264: SSE2Fast Cache64
 - pixel sad :           [OK]
 - pixel sad_x3 :        [OK]
 - pixel sad_x4 :        [OK]
 - mc luma :             [OK]
x264: SSE3
 - pixel sad :           [OK]
 - pixel sad_x3 :        [OK]
 - pixel sad_x4 :        [OK]
x264: All tests passed Yeah :)

[burfadel]

Rev 1000 doesn't (and I'm sure won't be) have to be a bugfix. Any fixes can be released as patches then submitted to GIT once the time comes

[kemuri-_9]

was the information i posted above able to help you (Dark Shikari/akupenguin) in finding the error, or do you still need some more data?

[Dark Shikari]

Originally Posted by kemuri-_9

was the information i posted above able to help you (Dark Shikari/akupenguin) in finding the error, or do you still need some more data?

Can you confirm that all --asm levels work properly on other CPUs, that is, the issue only occurs on Phenom?

The next thing you can do is go throughout x264 commenting out SSE2 function initializations (find if( cpu&X264_CPU_SSE2 ) lines and change them to if(0) ) until the bug stops occurring.

[kemuri-_9]

this came out when i plugged it on my other two computers with --asm SSE2:
top: athlon64 x2 4200+
bottom: prescott (p4 3GHz w/ HT)
snapshot
diff frame within the sample, but still a fubar frame
--asm SSE2Slow was fine once again.

would attribute 3ngel not seeing a problem with it on the athlon64, since the default asm usage is SSE2Slow for them (as you well know).

I'll go through commenting out SSE2 function inits in a bit.

[akupenguin]

Originally Posted by kemuri-_9

top: athlon64 x2 4200+
bottom: prescott (p4 3GHz w/ HT)

You could have just said that both cpus showed the same error, rather than pasting two copies of the same image and making me overlay them in GIMP to make sure that they're identical.

[kemuri-_9]

yeah, hadn't thought about that...

so trying what DS said about the asm init disabling:
removing in quant.c - error
removing in pixel.c:
if( (cpu&X264_CPU_SSE2) && !(cpu&X264_CPU_SSE2_IS_SLOW) ) -> if ( 0 ) - error free
if (cpu&X264_CPU_SSE2 ) -> if( 0 ) - error
removing in dct.c - error

by line commenting within the found bracket (via commenting the specified line only):
//INIT2( sad, _sse2 ); - error
//INIT2( sad_x3, _sse2 ); - error
//INIT2( sad_x4, _sse2 ); - error
//INIT4( hadamard_ac, _sse2 ); - error free
//INIT_ADS( _sse2 ); - error
//pixf->var[PIXEL_8x8] = x264_pixel_var_8x8_sse2; - error
//pixf->intra_sad_x3_16x16 = x264_intra_sad_x3_16x16_sse2; - error

Edit:
all the error blocks I've been seeing are focused on the bottom of the frame, near the frame edge...
possibly related to having a 532 pixel (non mod16) height?

[Dark Shikari]

Hadamard_ac... ooooooooooh, it is a bug in psy-RD, but in the assembly, not the C code or the algorithm!

I'm going to guess there was some sort of overflow, considering the fact that it only happens on a black/white area like that.