x264 halts at 87%

[charleski]

First time I've seen this: x264 halts 87.3% into the 2nd pass. The commandline and output is shown below.

C:\MyVideos>"C:\Program Files\VideoApps\x264\x264.exe" --pass 2 --bitrate 1100 -
-stats "C:\MyVideos\Macbeth.stats" --ref 8 --mixed-refs --bframes 3 --b-pyramid
--subme 6 --b-rdo --weightb --trellis 1 --analyse all --8x8dct --sar 141:100 --
progress --no-psnr --output "C:\MyVideos\Macbeth.mp4" "C:\MyVideos\Macbeth.avs"

avis [info]: 704x560 @ 25.00 fps (129943 frames)
x264 [info]: using SAR=141/100
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
mp4 [info]: initial delay 2 (scale 25)
encoded frames: 113441/129943 (87.3%), 3.15 fps, eta 1:27:12
C:\MyVideos>
The input is an MPEG2 TS cut and demuxed with ProjectX. I applied some standard noise filters, cropping and resizing in avisynth, nothing fancy. The script used was:# Created with Gordian Knot
#
# http://gknot.doom9.org

# PLUGINS
LoadPlugin("C:\PROGRA~1\GORDIA~1\DGMPGDec\DGDecode.dll")
#LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\decomb.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\KernelDeInt.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Deen.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\UnDot.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Unfilter.dll")
#LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\dgbob.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Convolution3d.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\FluxSmooth.dll")
#LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\TomsMoComp.dll")
#LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\VSFilter.dll")
#LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\SimpleResize.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\RemoveGrain.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\MaskTools.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\DCTFilter.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Unfilter.dll")
loadplugin("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\plugins\masktools.dll")
loadplugin("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\plugins\tdeint.dll")
loadplugin("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\plugins\leakkerneldeint.dll")
loadplugin("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\plugins\avisynth_c.dll")
loadcplugin("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\plugins\smartdecimate.dll")
loadCplugin("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\plugins\ibob.dll")

LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\LoadPluginEx.dll")
LoadPlugin("C:\PROGRA~1\GORDIA~1\AviSynthPlugins\Dustv5.dll")

# load the needed functions
import("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\restore24.avs")
import("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\LimitedSharpen.avs")
import("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\Deblock_QED.avs")
#import("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\PixieDustPP.avs")
import("C:\PROGRA~1\GORDIA~1\AviSynth 2.5\FunkyDeblock.avs")

# SOURCE
mpeg2source("C:\MyVideos\Macbeth.d2v",cpu=4,iPP=true)

# TRIM
#trim(startframe,endframe)

# IVTC
#Telecide(order=1,guide=1).Decimate()
# or use
#IVTC(44,11,95)
#GreedyHMA(1,0,4,0,0,0,0,0)

# DEINTERLACING (1)
#FieldDeinterlace()
#FieldDeinterlace(blend=false)
#TomsMoComp(1,5,1)

# DEINTERLACING (2)
#KernelDeInt(order=1,sharp=true)
# or maybe
#DGBob(order=1,mode=0)

# DEINTERLACING (3) - special requests
#GreedyHMA(1,0,0,0,0,0,0,0)
#Telecide()
#SeparateFields()

# CROPPING
crop(2,0,716,574)

# SUBTITLES
#VobSub("FileName")

# RESIZING
LanczosResize(704,560)

# DENOISING: choose one combination (or none)
Undot()
Unfilter(-5,-5)
#Deen()

# 1) little noise
#Temporalsoften(2,3,3,mode=2,scenechange=6)
#mergechroma(blur(1.3))
#FluxSmoothST(5,7)

# 2) medium noise
#Temporalsoften(3,5,5,mode=2,scenechange=10)
#Convolution3d("moviehq")
FluxSmoothST(7,7)

# 3) heavy noise
#Temporalsoften(4,8,8,mode=2,scenechange=10)
#Convolution3d("movielq")
#FluxSmoothST(10,15)

# BORDERS
#AddBorders(left,top,right,bottom)

# COMPRESSIBILITY CHECK
# !!!!Snip Size now has to be 14 for use in GKnot!
#SelectRangeEvery(280,14)

# FOOL CCEnc
#empty = BlankClip()
#AudioDub(last,empty)


I first tried doing this in MeGUI. The first pass went fine, the 2nd pass terminated with an error notice in MeGUI's job window (for some reason MeGUI has never saved logs on my system, so I can't paste what it said, but it wasn't informative - first pass seemed to go fine). I then took the commandline for the 2nd pass from the MeGUI config dialog and just ran it from a shell, producing the result above.

I looked at the stats file to see if it was corrupt. The last line goes
in:129941 out:129942 type:b q:16.00 itex:0 ptex:2 mv:5 misc:169 imb:0 pmb:1 smb:1539;.So it seems to have got all the way to the end (I'm guessing so as the last 'out' value is No.frames-1).

x264 reports its version as
x254 core:40 svn-365M (built by Sharktooth)

Any idea what the problem is? A memory-leak somewhere? (after terminating my commit charge was normal, though I didn't look at it during the encode). This is a bit frustrating, especially given the length of time the 2nd-pass takes.

[hpn]

Similar crashes have been reported with the newest options lately. Until the code gets tweaked, just don't use --b-rdo, --trellis or --subme 6/7 for long encodes. You can also check this:
http://forum.doom9.org/showthread.php?t=102770

[akupenguin]

Has anyone with any debugging capabilities ever reproduced these crashes? Because the they aren't going to fix themselves just by waiting.

[Sharktooth]

i cant reproduce it...
however, as a general note, please ensure your hardware is ok (run prime95, memtest86 and other stress tests) and try to do the same exact things on another computer before reporting a potential bug.

@hpn: i still cant reproduce those crashes and i encoded at least 40 movies...
however the "experimental" options do work, but "maybe" AQ is the cause (i never needed AQ for my encodings).

[falcon2000eg]

Similar crashes have been reported with the newest options lately. Until the code gets tweaked, just don't use --b-rdo, --trellis or --subme 6/7 for long encodes.

Yes i have the same problem with two diffrent movies but i do not use --subme 7 or AQ and --subme 6 is fine.
only with --b-rdo AND --trellis

[charleski]

The previous crash reports seemed to happen with the use of AQ or high scale/rate factors, neither of which apply here, though the root cause of the bug may be the same. I'll try encoding again without trellis to see if this narrows things down.

Has anyone had this happen closer to the start of the encode on one of the latest builds? Given that it took over 10 hours to get to the crash-point with an optimised build I'm not too keen to redo it in a Debug version, heh.

[Sharktooth]

Trellis is in SVN... it's not "experimental"...

[lexor]

Trellis is in SVN... it's not "experimental"...
doesn't mean it's infalable... having said that I've never had x264 crash on me (I use your HQ-Slow and Slower profiles for megui and encode a bunch of episodes).

[hpn]

Here is a fast (at frame 11) reproducible crash for those who want to try and report back if they can reproduce it. It's not the perfect choice cause the source is a mov file, but it crashes fast (not at frame 100'000 or so) with some sets of options and does not crash with other sets, so I guess it's a good choice to debug.

Trailer:
http://movies.apple.com/movies/wb/harry_potter_goblet/harry_potter_goblet-tlr2_h1080p.mov
(183'277'882 bytes)

Rename from
harry_potter_goblet-tlr2_h1080p.mov
to
harry_potter_goblet-tlr2_h1080p.mov.mp4

(note: the only reason to rename it is because Yamb can't "see" the mov extension)

then extract track ID 1 to MP4 file with Yamb-1.3.2 (installer version) from
http://forum.doom9.org/showthread.php?t=93927&highlight=yamb

Now we have
harry_potter_goblet-tlr2_h1080p.mov_track1.mp4 (176'555'616 bytes)

Install the latest Haali splitter
http://haali.cs.msu.ru/mkv/
and AviSynth 2.56a
http://sourceforge.net/project/showfiles.php?group_id=57023&package_id=72557&release_id=366697

Avs:

DirectShowSource("F:\x264_tests\harry_potter_goblet-tlr2_h1080p.mov_track1.mp4", fps=23.976, pixel_type="YV12")
#original size 1920x816
#to obtain mod16:
trim(120,2302)
crop(0,8,1920,800)
LanczosResize(960,400)
(dont' forget to put the correct path to the trailer in the first avs line)

Now encode with ST's x264-Lite_r367A

x264.exe -p 1 -B 2632 -r 5 -b 2 --b-rdo --b-pyramid -m 7 -t 2 -w -A all -8 --progress -o NUL b.avs

crash at frame 11

Other scenarios:
"-m 6 -t 2" no crash.
"-m 6 -t 1" crash at frame 11.
"-m 7 -t 2" but without --b-rdo - no crash
..and so on.

When I say "no crash" I only mean during the first few hundred frames, cause I haven't waited for each test to complete.

[Sharktooth]

Have you tried with avisynth 2.5.5?

[bob0r]

Have you tried with avisynth 2.5.5?


I just did, it keeps crashing with 2.55 or 2.56

2.55 b.avs:

DirectShowSource("I:\screener\harry_potter_goblet-tlr2_h1080p.mov_track1.mp4", fps=23.976)
#original size 1920x816
#to obtain mod16:
trim(120,2302)
crop(0,8,1920,800)
LanczosResize(960,400)
ConvertToYV12()


--b-rdo and m6
--b-rdo and m7
do crash

trellis (-t) or not makes no difference.

Probably --b-rdo bug, Alex_W will be notified, right Sharktooth? :)

[Sharktooth]

right.

[hpn]

I also tried with avisynth 2.5.5. Because "pixel_type" is a newly added option to DirectShowSource in 2.5.6 and is not available in 2.5.5 (check this (http://www.avisynth.org/ChangeList_25)), I had to remove pixel_type="YV12" from the avs scrypt like this:

DirectShowSource("F:\x264_tests\harry_potter_goblet-tlr2_h1080p.mov_track1.mp4", fps=23.976)
#original size 1920x816
#to obtain mod16:
trim(120,2302)
crop(0,8,1920,800)
LanczosResize(960,400)
(you may or may not add ConvertToYV12() to the avs for the tests)

The same crash occured. Seems it's not avisynth that crashes, although one never knows. If someone has VS 2005 Express Editions (http://msdn.microsoft.com/vstudio/express/default.aspx) installed (free now) he can try to trigger the debugger (it's triggered authomatically in case of such crashes) and post the crash log. I'm not sure if the free VS EE includes such extra tools though (still haven't tried it), but I suppose it at least has a debugger :)

EDIT: Just for a test I changed the avs to "fps=25" and this time
x264.exe -p 1 -B 2632 -r 5 -b 2 --b-rdo --b-pyramid -m 7 -t 2 -w -A all -8 --progress -o NUL b.avs
doesn't crash, but now
x264.exe -p 1 -B 2632 -r 5 -b 2 --b-rdo --b-pyramid -m 7 -t 1 -w -A all -8 --progress -o NUL b.avs
crashes at frame 16 (the only change is -t 2 -> t 1)

In case of all these early crashes (frames 11, 16) the x264_2pass.log.temp files are always empty. I have no idea if the crashes have something to do with it or because x264 buffers the log output and does not write to the stat file at each frame, so in this case x264 crashes before the first write or something.

[charleski]

I'm currently trying the example you gave, but avisynth is giving me "the filter graph manager won't talk to me" errors, even though the file renders with graphedit, grrr (same result if I feed DShowSource the graph file, sigh). Anyway, I'll see if it can get it working, I have VStudio installed.

[berrinam]

I managed to reproduce hpn's results with a self-compiled build of x264. I used rev367, and applied the first four of the patches on ST's sticky (Adaptive quantization V5, RD patch V9, RDO for B-Frames patch V4, Experimental RD pskip V1).

If I build normally (no debug options), the crash happens, exactly as hpn says, and it can be opened in the VS debugger, which shows disassembly (no debug info), and an Integer divide by zero exception. If I build with --enable-debug, then it doesn't crash.

[Sharktooth]

Alex_W fixed b-rdo and commited it to the SVN.
Please TRY with revision 368 builds.

[AlexB17]

I have same problem some time ago in VFW ver. - when i turn on 2 threads on my P4 Northwood with HT - coding stops on 2-nd pass after ~128K frames. With 1 thread everything went fine. Maybe this is the same problem?

[hpn]

Revision 368 seems to fix the crashes. Thank you, Alex_W :)

[AlexW]

Revision 368 seems to fix the crashes. Thank you, Alex_W :)

No problem :)
now lets just hope i didn't b0rk anything else ;)