PDA

View Full Version : Computer Locking Up During x264 Encoding


stanjr
19th January 2009, 02:55
Context
I am working with an Ubuntu (Intrepid Ibex, 64-bit) installation on a Q6600 quad-core computer (not overclocked), using scripts to encode H.264 videos from DVD sources using x264. I haven't changed the process that I usually use to rip the DVD material then encode to x264. The only thing that has changed is having gotten the most recent x264 and mplayer update (as of yesterday). I always compile x264 from the most recent source from git and mplayer from the most recent svn (before starting a new encode). The version of x264 that I am trying to use right now is v0.65.1081 201f7ad, the version of mplayer that I am using is r28339-4.3.2.

The Problem
During x264 encoding the video my computer will COMPLETELY lock up. I have to restart the computer to get it unlocked. It is not always at the same point in the video that the lock up occurs. I am assuming that it is an x264 problem, since this lock up only occurs when I am trying to encode with it, but maybe it is something else. I have never gotten farther than ~1180 frames before the lock up occurs, I've seen it occur at about as low as ~430 frames too.

The Question
What could be causing this? Any thoughts?

My Typical Process
1) Rip the VOB I want to encode to x264 from the DVD. 2) Run the VOB through DGIndex via Wine, demuxing the audio at the same time. 3) Since most of the material I encode to x264 is strictly interlaced, I'll deinterlace it with MCBob, crop it, and save it as an ffvhuff avi in a pre-render step (so it won't be a bottleneck when I feed that pre-rendered avi to x264). To do this, I feed an AVS script to mencoder via avs2yuv within a bash script named something like "MCBob.sh"

An "MCBob.avs" that I use:
LoadPlugin(".../DGDecode.dll")
DGDecode_MPEG2Source(".../Video.d2v")
MCBob(sharpness=1.0).SelectEven()
crop(a,b,c,d)

An "MCBob.sh" that I use:
wine avs2yuv.exe -o - MCBob.avs | mencoder - -nosound -cache 8192 -ovc lavc -lavcopts vcodec=ffvhuff:vstrict=-1:pred=2:context=1 -o Video.avi

4) After that pre-render step is complete, I'll feed that deinterlaced/cropped avi to x264 via a pipe with mplayer, using another bash script, named something like x264.sh

An "x264.sh" that I use:
rm -f Video.y4m && mkfifo Video.y4m
mplayer Video.avi -vo yuv4mpeg:file=Video.y4m &
x264 --progress --sar 10:11 \
--pass 1 --bitrate 2145 --level 3.1 --keyint 300 --min-keyint 30 --ref 13 --mixed-refs --no-fast-pskip --bframes 4 --b-pyramid --weightb --direct auto --deblock -2:-2 --subme 9 --trellis 2 --partitions all --8x8dct --vbv-bufsize 14000 --vbv-maxrate 14000 --me esa --merange 64 --threads auto --b-adapt 2 --no-dct-decimate --no-psnr --no-ssim --psy-rd 1.00:0.75 --output /dev/null Video.y4m
mplayer Video.avi -vo yuv4mpeg:file=Video.y4m &
x264 --progress --sar 10:11 \
--pass 2 --bitrate 2145 --level 3.1 --keyint 300 --min-keyint 30 --ref 13 --mixed-refs --no-fast-pskip --bframes 4 --b-pyramid --weightb --direct auto --deblock -2:-2 --subme 9 --trellis 2 --partitions all --8x8dct --vbv-bufsize 14000 --vbv-maxrate 14000 --me esa --merange 64 --threads auto --b-adapt 2 --no-dct-decimate --no-psnr --no-ssim --psy-rd 1.00:0.75 --output Video.mkv Video.y4m
rm -f Video.y4m

That process hasn't failed me before....What else could be possibly locking my computer up only during video encoding?

jeffy
19th January 2009, 05:10
overheating, dust build up, unstable RAM
suggestions for Windows: MemTest, OCCT, Prime95

Ranguvar
28th January 2009, 18:42
I would agree with the hardware problem diagnosis. Under Winblows, I'd believe a lock-up because of a bugged encoder. Not so much under Linux.

That is, unless you roll back to old versions and the problem disappears.