x264 crashes on my CPU

[laserfan]

Somewhere between August and September x264 started crashing on my Pentium P4 Northwood computer WinXP SP3. I've been using r928 successfully but sometime after that it started failing. I wonder if there's a Prescott-specific feature that crashes on my Northwood. I can't find any info on the --asm option, nor does --threads 2 solve the problem. Can anyone here suggest where to look?

Here's a sample command-line that crashes w/r999:

"C:\Program Files\RipBot264\tools\x264\x264.exe" "D:\Temp\RipBot264temp\job1\job1.avs" --pass 1 --bitrate 18342 --stats "D:\Temp\RipBot264temp\job1\job1.stats" --level 4.1 --sar 1:1 --aud --nal-hrd --vbv-bufsize 30000 --vbv-maxrate 30000 --filter 0,0 --bframes 3 --b-pyramid --direct auto --subme 2 --analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "D:\Temp\RipBot264temp\video.264"

As I said, I tried changing --threads auto to 2 but doesn't work. BTW I posted several times in the RipBot264 thread to no response--the developer runs a Q6600.

[Ramir Gonzales]

Somewhere between August and September x264 started crashing on my Pentium P4 Northwood computer WinXP SP3. I've been using r928 successfully but sometime after that it started failing. I wonder if there's a Prescott-specific feature that crashes on my Northwood. I can't find any info on the --asm option, nor does --threads 2 solve the problem. Can anyone here suggest where to look?

Here's a sample command-line that crashes w/r999:

"C:\Program Files\RipBot264\tools\x264\x264.exe" "D:\Temp\RipBot264temp\job1\job1.avs" --pass 1 --bitrate 18342 --stats "D:\Temp\RipBot264temp\job1\job1.stats" --level 4.1 --sar 1:1 --aud --nal-hrd --vbv-bufsize 30000 --vbv-maxrate 30000 --filter 0,0 --bframes 3 --b-pyramid --direct auto --subme 2 --analyse none --me dia --threads auto --thread-input --progress --no-psnr --no-ssim --output "D:\Temp\RipBot264temp\video.264"

As I said, I tried changing --threads auto to 2 but doesn't work. BTW I posted several times in the RipBot264 thread to no response--the developer runs a Q6600.

I experienced the same symptoms, after overclocking my system a little less aggressively, no more crashes/reboots.:)

BTW, overclocking stress-tests like Orthos and the likes are worthless in testing your system stability, there is 1 valuable stresstest : 24hour+ x264 encoding ;)

[LoRd_MuldeR]

Does it crash always and always at the same point? Or do you get random crashes after a longer time of encoding?

Also: Which build exactly do you use?

[laserfan]

I am not overclocking at all. It crashes instantly on launch--I don't know whose build of r999 Atak is using in RipBot264. I'll try to find out.

I'm also thinking about DL'ing & testing enough builds to see which build specifically breaks it. Thanks for the feedback.

[LoRd_MuldeR]

I am not overclocking at all. It crashes instantly on launch--I don't know whose build of r999 Atak is using in RipBot264. I'll try to find out.

What exactly is the crash? You can use GDB (http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=20507) to get more info. And does it crash with all sources?

Also try x264.exe from http://x264.nl/ to be sure...

[laserfan]

Thanks again LM--yes I haven't found a source it doesn't crash on.

I'll look at GDB and try a different build too. Atak is using techouse build:

Source: x264 r999 GIT (git://git.videolan.org/x264.git)

Applied patches (current versions):

x264_hrd_pulldown.09_interlace.diff


Please check http://forum.doom9.org/showthread.php?t=130364 and http://git.videolan.org/gitweb.cgi?p=x264.git;a=shortlog for more info

Compiled by techouse on October 3rd 2008, 10:39:01 CEST with GCC-4.3.2 on Windows Vista Business SP-1 64-bit.

Commandline used: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled

Platform: X86
System: MINGW
asm: yes
avis input: yes
mp4 output: yes
pthread: yes
gtk: no
debug: no
gprof: no
PIC: no
shared: no
visualize: no

[LoRd_MuldeR]

There you have it :p

Commandline used: ./configure --extra-cflags="-march=core2 -pipe" && make fprofiled


This build was explicitly compiled for Core2 CPU's. Your Northwood neither supports SSE3 nor SSSE3, which Core2 does.
Most likely that build crashes on your CPU because of an illegal CPU instruction....

[laserfan]

Well, per your advice I DL'ed the build from x264.nl (duh I should have thought of that), and while it doesn't crash, it just quits without doing anything. But the RipBot log showed me that it didn't like Atak's --nal-hrd option. When I remove that option from the command line, it works properly!

Not sure what --nal-hrd does but I will report this to Atak. Thanks LoRd_MuldeR for your great help!

[LoRd_MuldeR]

Not sure what --nal-hrd does but I will report this to Atak. Thanks LoRd_MuldeR for your great help!

AFAIK that commandline switch is needed for BlueRay compliance only. If you don't care about that, you don't need it :)

Otherwise get a "x264_hrd_pulldown.09_interlace.diff" patched build here:
http://forum.doom9.org/showpost.php?p=1191032&postcount=1212

[laserfan]

AFAIK that commandline switch is needed for BlueRay compliance only. If you don't care about that, you don't need it :)

Otherwise get a "x264_hrd_pulldown.09_interlace.diff" patched build here:
http://forum.doom9.org/showpost.php?p=1191032&postcount=1212Wow, that build works with --nal-hrd intact! You're my new hero!

If you will indulge me a final question you may know: Is -march=pentium2 optiomal for a Pentium 4 processor?

EDIT: NM I think I found my answer (pentium2): HERE. (http://forum.doom9.org/showthread.php?p=1155803#post1155803)

:thanks: :thanks:

[burfadel]

What does --nal-hrd physically do anyway? is it possible to patch an existing stream with this option or can it only be done when encoding? I have no need for the option (yet...) just curious as if it could be done it would be a handy feature/tool.

[LoRd_MuldeR]

If you will indulge me a final question you may know: Is -march=pentium2 optiomal for a Pentium 4 processor?

It's not "optimal", because only a P4-specific build would be optimal for a P4 CPU.

However "-march pentium2" is better than a (generic) build without "-march" switch, because Pentium2 builds can use MMX instructions at least.
It seems that "-march pentium2" is the most commonly used switch for x264 builds. Such builds will run on all CPU's of interest (Pentium2 and newer).

Also you have to keep in mind that x264 performs it's own runtime CPU detection for it's Assembler code. The compiler switch effects the plain C code only!
Therefore the speed difference between a CPU-specific x264 build and a "generic" one will be pretty small in fact...

And it's seems there is no advantage in using any "higher" optimization than "-march pentium2" -- it only restricts the CPU compatibility :rolleyes:

[kemuri-_9]

@burfadel, afaik the nal hrd patch affects the stream data and requires vbv parameters to be set in order to work. so i'm only fairly certain that you can't convert an already encoded stream.

And it's seems there is no advantage in using any "higher" optimization than "-march pentium2" -- it only restricts the CPU compatibility :rolleyes:
it helps when you only have the c code to work with; i.e. using --disable-asm in ./configure (like currently needed for win x64 builds)

[LoRd_MuldeR]

it helps when you only have the c code to work with; i.e. using --disable-asm in ./configure (like currently needed for win x64 builds)

That's a completely different situation. And it doesn't apply to the build that caused trouble for laserfan...

BTW: Did anybody compare the speed of a Core2-optimized/ASM-disabled x64 build to a "normal" ASM-enabled x86 build?

[laserfan]

... it's seems there is no advantage in using any "higher" optimization than "-march pentium2" -- it only restricts the CPU compatibilityThanks, I will communicate your and Sharktooth's opinions on this to the RipBot264 devel. :)

[kemuri-_9]

That's a completely different situation. And it doesn't apply to the build that caused trouble for laserfan...

BTW: Did anybody compare the speed of a Core2-optimized/ASM-disabled x64 build to a "normal" ASM-enabled x86 build?

lol, an x64 build w/o the asm is a complete joke to x86 w/ it

[Dark Shikari]

Note also that last I tried, GCC miscompiled x264 when using march=core2.

[Ranguvar]

Note also that last I tried, GCC miscompiled x264 when using march=core2.

Crash during encoding, garbage output, or degraded encode quality?

[Dark Shikari]

Crash during encoding, garbage output, or degraded encode quality?Instacrash.

[Ranguvar]

Instacrash.

Okay. My core2 builds for myself have been working fine (GCC 4.3.2), I wanted to make sure there was no super-sneaky quality degradation (though it would be unlikely).

[Wishbringer]

P4 Northwood? Isn't it a single core P4 with Hyperthreading (130nm, before Prescott came with 90nm)?
Give it a try and disable Hyperthreading in BIOS and encode again. Maybe you get even a speed increase, because Hyperthreading lowered speed in some applications that thinks there are two real CPUs.
There were (year 2002) some issues with misaligned multithreading code that could lead to crashes (not x264 related) and some mainboard producer offered a bios upgrade with fixed microcode (but not all producer).

edit:
do you really encode with that CPU? Then you can only expect around 1-2fps with HD material!

[roozhou]

Try -march=athlon-xp. It runs faster than p4 builds on most Intel CPUs i tesed, including P3, P4M and Core2.

[nm]

P4 Northwood? Isn't it a single core P4 with Hyperthreading (130nm, before Prescott came with 90nm)?
Give it a try and disable Hyperthreading in BIOS and encode again. Maybe you get even a speed increase, because Hyperthreading lowered speed in some applications that thinks there are two real CPUs.
There were (year 2002) some issues with misaligned multithreading code that could lead to crashes (not x264 related) and some mainboard producer offered a bios upgrade with fixed microcode (but not all producer).
laserfan's problem was already solved and it was caused by a Core2-specific build (gcc -march=core2). I'm also pretty sure that x264 is faster with HT enabled.

[laserfan]

do you really encode with that CPU? Then you can only expect around 1-2fps with HD material!Yep. It is what it is, until I find a deal on a new mobo/cpu/ram.

Try -march=athlon-xp. It runs faster than p4 builds on most Intel CPUs i tesed, including P3, P4M and Core2.According to at least Sharktooth none of the assembly options matter to x264 encoding?

laserfan's problem was already solved and it was caused by a Core2-specific build (gcc -march=core2). I'm also pretty sure that x264 is faster with HT enabled.Yes, I'm using the build that LoRd_MuldeR referred me to earlier.

Thanks for all the feedback.

[LoRd_MuldeR]

According to at least Sharktooth none of the assembly options matter to x264 encoding?

That's because the "-march" option is for the Compiler and thus effects the plain C code in x264 only.
But all performance-critical functions in x264 are written as "hand-optimized" Assembly code, which isn't effected by Compiler optimizations at all.
Plus x264 uses it's own runtime CPU detection to choose the suitable Assembler functions.

Even if x264 was compiled with "-march pentium2", it will still invoke it's SSE2 and SSSE3 optimized Assembly code, when running on a Core2 processor :cool:
Hence the speed-difference between a "-march pentium2" and a "-march core2" build will be negligible...

[laserfan]

LM your explanation is (almost) perfectly clear even to me, and I am not a programmer! ;)

Hopefully the RipBot264 author is smarter even than I am, and will change the build he incorporates to his program! :)