[MEncoder-users] Encodes for slow laptop

[Stella-Terra Clemens]

Ok, I think I've basically found what I was looking for.  I wrote a small
script to help with automation, let me know if there is anything glaringly
wrong here.  It's based on h264enc script, RC's suggestions, and a couple of
gentoo dvd rip pages.

#!/bin/bash

TITLE="The Princess Bride"
IN_FILE="movie.vob"
OUT_FILE="thePrincessBride.mkv"
CROP="704:464:10:6"
SCALE="384:256"
VF_FRAMECONVERT=""
#VF_FRAMECONVERT="pullup"
FPS="24000/1001"
BITRATE=800
AID=128

# Video
mencoder ${IN_FILE} -o /dev/null -ofps ${FPS} -vf
${VF_FRAMECONVERT}crop=${CROP},softskip,scale=${SCALE},harddup -nosound -of
rawvideo -ovc x264 -x264encopts
pass=1:bitrate=${BITRATE}:turbo=2:me=umh:me_range=24:nodct_decimate:nointerlaced:8x8dct:nofast_pskip:trellis=1:partitions=none:mixed_refs:bime:keyint=240:keyint_min=24:frameref=4:bframes=16:b_adapt:b_pyramid:weight_b:direct_pred=auto:subq=6:brdo:chroma_me:nocabac:nodeblock:nossim:nopsnr:threads=auto

mencoder ${IN_FILE} -o movie.264 -ofps ${FPS} -vf
${VF_FRAMECONVERT}crop=${CROP},softskip,scale=${SCALE},harddup -nosound -of
rawvideo -ovc x264 -x264encopts
pass=2:bitrate=${BITRATE}:me=umh:me_range=24:nodct_decimate:nointerlaced:8x8dct:nofast_pskip:trellis=1:partitions=none:mixed_refs:keyint=240:keyint_min=24:frameref=4:bframes=16:bime:b_adapt:b_pyramid:weight_b:direct_pred=auto:subq=6:brdo:chroma_me:nocabac:nodeblock:nossim:nopsnr:threads=auto

# Audio
mplayer movie.vob -aid ${AID} -ao pcm:fast:waveheader:file=audio${AID}.wav
-vc null -vo null
oggenc audio${AID}.wav

# Container
mkvmerge --title "${TITLE}" -o ${OUT_FILE} --default-duration 0:${FPS}fps
movie.264 audio${AID}.ogg


In the future there will be a cleanup section after the end, but only after
I have confidence in the process.  As you can see, it's set up for The
Princess Bride, and I also did The Matrix without having to change anything
other than the settings at the top.  The Matrix went off without a hitch,
but The Princess Bride came out with the audio 200 ms in front of the
video.  This wasn't a big problem.  Even if I could no longer get at the
source files, I was able to change the timing using mkv merge and the
existing streams, and even failing that I could just press the minus key
twice and things would be alright, but it would be great if there could be a
way to prevent this in the future.
Btw, after a lot of testing it seems that the number one factor in
decodeability was resolution.  So my new rule of thumb is: try to put on the
screen around 100k pixels at a time, and no more than 115 (that is to say
the width times the height should not exceed 115,000.)  I made a small
program in c that takes in post-crop res as input and then asks for a
distortion tolerance and then spits out all the possible resolutions that
are mod16.  It's handy! ~_^
As for the quality, I'd say it looks pretty darn good, considering the
bitrate and resolution.  I might mess around with that, or some of the
things I turned off in x.264, but I'm pretty happy with it as is.  I'm going
on a 3 day train trip with a friend of mine in about 2 weeks, so I've got to
have everything ripped and stored soon, so I've got to stop messing with the
settings at some point.  I thank my lucky stars for bash automation: I'ma
just set this script up to work on a loop and encode the entire first season
of Kids in the Hall this weekend.
Thanks again, to everyone who gave input, and for those who might yet!
Stella