View Full Version : x264 crash, help me diagnose.
Adub
27th January 2007, 05:20
Okay, so I am running x264 620 in MeGUI 0.2.4.1026. I was running a movie, Step Up, overnight using the HQ-Slow profile, and the threads parameter set to 0, aka "threads auto".
I recieved an error from Windows saying I, well, had an error. MeGUI reported this,
avis [info]: 1280x704 @ 23.98 fps (148987 frames)
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
x264 [warning]: VBV maxrate specified, but no bufsize.
mp4 [info]: initial delay 2002 (scale 24000)
So I went and ran a 1 pass encode to see if that narrowed down some things. I ran the 1P-Maxspeed preset. No crash.
So I ran the HQ-Slow auto 2 pass over again, to see if maybe there was a problem with the old 1st pass file. yep, crashed again.
Here is my script:
SetMTmode(2)
DGDecode_mpeg2source("C:\STEP_UP\VTS_01_1.d2v", info=3)
Colormatrix(hints=true)
AssumeTFF().Telecide(guide=1).Decimate()
#crop
#resize
#denoise
autocrop(0)
Spline36resize(1280,704)
Anyone got any ideas?
Note: The auto pass runs crashed in different places. One was at 53.8%, another was at 38.3%, or atleast around there.
foxyshadis
27th January 2007, 06:22
You might want to try just playing the file straight through in vdub a few times, just to be sure it isn't the MT avisynth causing the crash. Also, just for fun, run it once while x264 encodes a blankclip(pixel_type="YV12",length=100000).AddGrain(100,0,0) just as an encoding stability test. (I find x264 a better torture test than prime95...)
Adub
27th January 2007, 07:05
So, I should play the script, the whole movie, in vdub a few times? Okay.
Then your next sentence. Run it once while x264 encodes a blankclip.... Run what once? the vdub play?
Well I am running the torture test right now. I will report back with results.
Edit: Oh, I forgot.
I ran the second pass of the automatic 2 pass again and if crashed in around the same area. @38.4% or frame 57212/148987 a "b" frame according to the in section in the pass log, instead of 59446/148987 a "B" frame according to the in section in the pass log, as before.
foxyshadis
27th January 2007, 08:12
If it crashes in exactly the same way twice, it's almost certainly not a hardware stability issue. So I strongly suspect the MT avisynth, in the absense of known x264 bugs that'd cause this. But it will be quite hard to get to the bottom if the script plays fine on its own, and a lossless encode fed to x264 doesn't crash. (In fact, running the lossless encode instead of simply playing would be smart, I suppose.) I guess in that case it could be a thread-interaction issue, but you'd need more debugging.
Adub
27th January 2007, 08:25
Well, I am on 97.4% of the 2nd pass of the blankclip cript and so far no error. I am leaning towards the MT avisynth error. I will try the Step Up script without the SetMTmode(2) in the beginning, so that it only runs on the one thread or so.
Edit: okay finished blankclip encode, no errors reporting.
Note: I ran it using the HQ-Slow settings, just to keep the settings constant. It really is looking like that MT error. Will report back when non-SetMTmode(2) encoding finishes.
Edit2: Well one interesting thing that I remember from the windows error message is that when I looked at the report it mentioned specifically the "avisynth.dll" file.
Edit3: Well I seem to have narrowed the problem down between the avisynth.dll and decomb.dll.
Let me see if the problem occurs using xvid encraw.
Adub
28th January 2007, 03:55
Okay, well a short preliminary test of Xvid encraw produced no errors.
Then I tested the old, 614, version of x264, and the newer, 621, version of x264.
The old one didn't even throw an error, it just sort of paused at 5.1% in the first pass.
621 throw an error, and it was about 12% in to the first pass.
My script is something along the lines of this:
SetMTmode(2)
blankclip(pixel_type="YV12",length=100000).AddGrain(100,0,0)
Colormatrix()
AssumeTFF.Telecide(guide=1).Decimate()
Spline36resize(1280, 704)
Anyone have anything else for me to try? Can anyone reproduce?
Edit: When I remove the setmtmode(2), the script works. And when I remove the deinterlace line, while keeping the setmtmode(2), it works as well. It appears that the two dll's are creating some conflict, or memory leak.
Adub
28th January 2007, 09:34
Okay, I got xvid encraw to crash as well. I used the original Step Up script.
I think it may have something to do with the number of threads set. Atleast, when I ran that preliminary short Xvid test earlier, I was using 3 threads. On the Step Up encode just now, I was using two and this encode produced the error.
So, now that this error occurs on more than one encoder, can anyone confirm?
Edit: It looks as if the threads set in the encoder don't really matter, at least for the blankclip script. For some reason, I can't get the blankclip script to crash with Xvid encraw. It may have something to do with the fact that it is not actually interlaced, so the interlace script is not actually doing anything.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.