x264 crashing on quad core system

--non-deterministic is the trigger. As for why it's at different times, see the option name. Same reason as I why I haven't found the bug yet. What the error message means in detail: Despite all the limitations to search range I put in place, motion estimation managed to return a motion vector pointing into a not-yet-encoded region of the reference frame. Rather than silently produce a video that decodes to something other than x264 thought it was encoding (i.e. containing artifacts), I opt to abort. And the reason for using assert rather than fixing the motion vector is that at that point x264 is in an inconsistent state and I don't know why, so anything I do would at best hide the problem.

My x264.exe keeps crashing during 2nd pass of encoding (VC1 directshow source as well), always at different point of the video. My encoder commandline: --pass 2 --bitrate 8423 --stats "Q:\PE2.stats" --ref 3 --bframes 3 --b-pyramid --weightb --direct auto --subme 6 --trellis 1 --analyse all --8x8dct --vbv-maxrate 25000 --me umh --merange 12 --threads auto --thread-input --cqmfile "W:\HDTV Encoding\eqm_avc_hr.cfg" --progress --no-psnr --no-ssim --output "Q:\PE2.mkv" "Q:\PE2.avs" My avs: directshowsource("q:\evovideo.mkv",audio=false,fps=23.976,seekzero=false,seek=true) crop(2,142,-2,-144) limitedsharpenfaster(strength=220) Spline36Resize(1920,800)

smekoslav: That's not much of a bug report. See, pyrates' post contains an actual error message, and I know what that error means. Your post simply says "it doesn't work". How could anyone possibly help you? (for programs in general). (also applies to x264). Don't bother answering until you've read those in full.

oops, I fixed the first link. The main point of the ffmpeg link is about gdb. If a program crashes, you build a debug version and run it in a debugger.

No, what I described was the error message, not the option. --non-deterministic (erroneously) causes the situation that the assert checks for. The check runs regardless, and the fact that x264 threading normally doesn't crash means that normal encodes aren't corrupted in that manner.