How to convert DVB video files to the x264 format
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 more recent codec which would generate smaller files.
Already at the beginning I had 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.