Segfault > IT > How-To's > Convert DVB files to x264

I sometimes record movies or documentary films using my dvd recorder and some time ago, as I was running out of empty DVDs, I thought it would have been nice to transfer the files to a harddisk.
But as I always record using the highest quality settings, each movie was using 4GB of space - quite a lot for a 2-hours movie.
I thought that it was a pity that my dvd-recorder was using the old mpeg2 format to record and I decided to re-encode them using a decent codec which would generate smaller files.

I had already at the beginning in mind to use the modern codec h264 and in the end I opted for its free version, x264.
To encode and play the files I use the excellent programs mencoder and mplayer.
I struggled quite a lot to find in Internet good reports about appropriate encoding settings to be used, but I'm not yet sure I'm using the best ones - quite difficult especially when it's about reencoding stuff. Anyway the encoded files look good and their size is about 1/4 the original size (about 1G instead of 4G).

I wrote a small script to do this job - here it is:


#!/bin/bash
#Syntax: conv2h264 <infile.mpg> <outfile.avi> <bitrate> "<-vf option>"
#Example: conv2h264 infile.mpg outfile.avi 722 "-vf crop=688:336:12:126"

#CROP/-vf PART
#In order to detect the crop part, watch the movie (jump to the real movie avoiding advertisments)
#with the command...
#     mplayer -ss 440 -vf cropdetect=90 infile.mpg
#...see what appears on the last line...
#     Crop area: X: 7..703  Y: 119..465  (-vf crop=688:336:12:126).
#...and try out the setting with...
#     mplayer -ss 440 -vf crop=672:336:16:122 infile.mpg
#...and check if you can see the whole video.

#BITRATE PART
#Compute the bitrate part by multiplying the width and height of the cropped video,
#the fps of the video and as constant 0.125 (for h264 - use 0.25 for xvid and mp4).
#Example: 672*336*25*0.125/1000 = 722kbps

rm divx2pass.log*

#If you choose your options well, you can get a very fast first pass.
#The resulting quality in the second pass will be slightly lower because size
#prediction is less accurate, but the quality difference is normally much too
#small to be visible. Try, for example, adding subq=1:frameref=1 to the first
#pass x264encopts. Then, on the second pass, use slower, higher-quality
#options: subq=6:frameref=15:partitions=all:me=umh

#Uncomment and modify this part if your CPU supports scaling of frequency
#echo "performance" >> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

mencoder -cache 20000 $1 -ovc x264 \
$4 \
-x264encopts \
bitrate=$3:threads=2:turbo=1:pass=1:4x4mv:me=3:frameref=2:bframes=3:b_pyramid:weight_b:subq=1 \
-oac copy -o /dev/null

mencoder -cache 20000 $1 -ovc x264 -x264encopts \
bitrate=$3:threads=2:pass=2:4x4mv:me=3:frameref=5:bframes=3:b_pyramid:weight_b \
$4 \
-oac faac -faacopts object=0:tns:quality=100 -o $2

#Uncomment and modify this part if your CPU supports scaling of frequency
#echo "ondemand" >> /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor


  • As you can see, I reencode the audio part using faac - a lossless compression codec. Why not just do a 1:1 copy? Well some files use compressed mp3, while others use uncompressed PCM and I opted for a global solution.
  • The critical part is getting the right crop area. Try with different cropdetect=XX settings and refine the endresult by hand.
  • You'll have to compile "x264-svn" in order to be able to encode using this codec, and make sure to compile it with the option "threads" to be able to use the threads=2 option.
  • I am using a PC with an AMD X2 4200 dualcore CPU and I get about 30% more performance using two threads. I wasn't able to get more out of the machine by enabling more or less threads than that. I need 4 to 5 hours to encode a 2 hours movie.