Post subject: Help with mencoder / x264 encoding bug...
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
I'm trying to re-encode a video with mencoder using 2-pass x264 encoding like this:
mencoder input.avi -o output.avi -oac mp3lame -lameopts abr=128 -ovc x264 -x264encopts bitrate=1500:pass=1
mencoder input.avi -o output.avi -oac mp3lame -lameopts abr=128 -ovc x264 -x264encopts bitrate=1500:pass=2
It works if input.avi is short, but if it's quite long (haven't measured the exact threshold, as x264 encoding is slooooow...) I'm getting a bug. At the very end of the second pass I get this error: x264 [error]: Incomplete MB-tree stats file. x264_encoder_encode failed and then mencoder hangs completely (the only way to kill it is with "kill -KILL", no other signals will stop it). The resulting avi is broken, as it lacks an index. Even if a rebuild an index using mplayer's -idx option, the video file is broken (it issues tons of errors of the form "[h264 @ 0x890f040]number of reference frames exceeds max (probably corrupt input), discarding one" and the video becomes full of artifacts.) This is clearly some kind of bug in the x264 encoder, but since I know encoders here are using multipass encoding with it (and with quite long videos) without problems, I wonder if anyone would have any hint about why I am getting this problem. Google is unhelpful. It seems I'm not the only one having this exact same problem, but nobody in the universe seems to know why it happens or how to avoid it. The mplayer version string seems to be "MPlayer dev-SVN-r29796-4.3-openSUSE Linux 11.0 (i686)-Packman (C) 2000-2009 MPlayer Team".
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
start /wait x264.exe "mixed.avi" --stats "./bothumh.stats" --deldup 20 --versioninfo --ssim --pass 1 --bitrate 320 --keyint 500 --ref 15 --mixed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --mbtree --weightb --direct auto --subme 10 --trellis 2 --partitions all --me tesa --merange 64 --threads 2 --8x8dct --no-dct-decimate --output "encodedboth.mp4"
start /wait x264.exe "mixed.avi" --stats "./bothumh.stats" --deldup 20 --versioninfo --ssim --pass 3 --bitrate 320 --keyint 500 --ref 15 --mixed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --mbtree --weightb --direct auto --subme 10 --trellis 2 --partitions all --me tesa --merange 64 --threads 2 --8x8dct --no-dct-decimate --output "encodedboth.mp4"
This is the script I previously used, but I doubt it's compatible with Mencoders's x264 encoder. This is the version of x264 I used instead, I've found it to be pretty reliable. Just uh, be aware that the above script is incredibly slow, painstakingly slow...
start /wait x264.exe "mixed.avi" --stats "./bothumh.stats" --deldup 20 --versioninfo --ssim --crf 20 --keyint 500 --ref 15 --mixed-refs --no-fast-pskip --bframes 16 --b-adapt 2 --mbtree --weightb --direct auto --subme 10 --trellis 2 --partitions all --me tesa --merange 64 --threads 2 --8x8dct --no-dct-decimate --output "encodedboth.mp4"
I suggest using this one instead, adjusting the crf value as needed. It's pretty similar to what Aktan also uses (But he somehow has an even tougher script, no doubt he increased the keyint value). The thing is, these all need external muxing, so... yeah.
Player (36)
Joined: 9/11/2004
Posts: 2631
Is this a bug in x264 or in mencoder's avi encapsulation?
Build a man a fire, warm him for a day, Set a man on fire, warm him for the rest of his life.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Given that other people seem to be having the exact same problem with other software which use the same x264 decoder as mplayer, I think that the problem is in the decoder itself. Anyways, I noticed that there's a newer version of mplayer in the Suse repository, and I also fiddled a bit with the x264 settings, and now the encoding succeeded. I don't know which one affected this. Perhaps updating mplayer.