While the Baldur's Gate game runs at a measly 640x480 screen size, it has a lot of dithering which can easily be washed out / muddied up by a low bitrate. So when encoding with x264, I recommend a decent CRF value (I'm currently using CRF 24). The major problems that you'll see are where a fireplace is present in a dithered / shadowed area (such as inside the Candlekeep Inn).
On the upside, a large portion of the screen rarely changes due to the large buttons along the left / right / bottom edges. So that simplifies the encoder's job.
The bitrate for the final file usually ends up in the 550-660 kilobits/sec range. Which is about 167:1 to 200:1 over the original FRAPS footage. At the upper end, that's around 4.8 megabytes per minute of footage (the lower end is 4.1 megabytes/minute). That includes a 130Kbps AC3 audio track, so the video portion is compressing down nicely.
Update: Later encodes are more in the range of 800-950Kbps due to lots of panning in outdoors areas. Which is more in the range of 5.5 to 6.7 megabytes per minute of footage. Or about 400MB per hour at the upper-end.
On my aging quad-core Phenom 2.5GHz machine, I'm seeing encoding speeds of 30-45 frames/sec which is a bit better then real time. However, the major impediment to maxing out all 4 cores seems to be disk accesses. So the CPUs are only working about 75-85% during the video encoding portion of the task. That's with a 750GB 7200RPM SATA drive. It would go faster if I was using a 10k RPM drive or a RAID-0 or RAID-10 array.
Just some very (VERY) rough approximations of encoding times with StaxRip. Source material is FRAPS AVI files (1600x900, ~30 FPS), output is 720p (1280x720) x264 MKV files. Encoding system is a quad-core AMD Phenom 9850 (2.5GHz) with 3GB DDR2 RAM. Source and destination disks is a 750GB SATA drive.
Generally speaking, the main part of the encode does a good job of maxing out all of the CPU cores at 80-95% and uses about 800-900MB of RAM. The earlier parts where it demuxes the streams and encodes the audio tend to be more disk intensive. Here are some sample times for the "Slow" preset.
That's too few samples to draw any big conclusions about. And it's too soon to say whether the 3.3x result is out of the ordinary or not. I'm also switching over to the "Slower" preset in StaxRip, so my encoding times are going to go up.
Offhand, I'd say you can count on 3.0x encoding times (3 minutes to encode per minute of source), give or take 10%, for the "Slow" setting.
Slower is definitely slower, 50-100% longer encoding times over "Slow". I suspect some of the variation might depend on the source material's complexity, but there's not enough data to draw any hard conclusions yet. However, out of the CRF:23 samples, the 7.0x encode was the largest bitrate (5470Kbps) compared to the 2500-3500Kbps of the other encodes.
The command line that I'm using with slower looks like:
What you see here is that a CRF of 18 results in very high quality encodes, but with larger bitrates. The one sample ended up at 9840 Kbps, which is huge for my purposes. Setting the CRF to 24 results in a file that is about 60% the size of a CRF 20 encode. Which is a sizeable savings. For archive quality encodes of game video, setting the CRF to 18-22 is probably a good choice, depending on your source footage. For cases where you care more about file size, set the CRF to around 24. Although at CRF 24, you'll start to see blockiness in dark shadowy areas.
Most official sources indicate that you should pick a CRF between 15 and 25, depending on your needs. Which puts the default x264 value of 23 at the upper end of the scale. Most folks talking about movies and TV encodes fall into the 18-20 range, with 22 used for cases where you're willing to compromise image perfection in exchange for file size. Stuff in the 15-17 range seems to be the realm of perfectionists who want zero artifacts.
Of course, for the real fun, the CRF value is not the only determining factor in video quality. Plus, the x264 developers periodically change the math which means that your optimal CRF value may shift a point or three in either direction when you update x264.
Me? I'm going to roll with CRF 23 for the moment for my archived FRAPS footage.
I'm getting ready to switch my FRAPS captures from XVid to H.264 (x264). What I'm finding is that in GTA3: San Andreas, where I capture at 1600x900, encoding to XVid results in a lost of fine detail (even at 2.8-3.0 Mbps settings). The H.264 codec seems to do a much better job at preserving the fine detail while staying at a reasonable bitrate.
StaxRip - This is a very good tool for using in conjunction with FRAPS. If you separate your raw FRAPS AVI files into separate directories prior to encoding, it becomes very easy to merge the AVIs together.
x264 settings - A page at the MeGUI wiki regarding what the different x264 settings are. Pay close attention to "profile", "preset", "tune" and "level".
The Bottom Line Everybody should be encoding HD content (1080p, 720p) to Profile High @ Level 4.1. For smooth playback, "--level 4.1" should be used to mark the file as compatible when encoding. The best MeGUI profile for x264 is the DXVA-HD-HQ profile.
And the following quote from that page about standard-def content:
Everybody should be encoding SD content (576p, 480p, or less) to Profile High @ Level 3.1 For smooth playback, "--level 3.1" should be used to mark the file as compatible when encoding. The best MeGUI profile for x264 is the DXVA-SD-HQ profile.
Note: StaxRip doesn't seem to have an equivalent profile for hi-def encoding. However, using the "Slower" preset takes care of the majority of settings. You'll just have to set the following:
Analysis (Partitions): All enabled except for P4x4" Frame Options (Misc): Set Reference Frames to 4 Rate Control (VBV): Buffer Size and Max Bitrate to "50000" Command Line (Custom Switches): Add "--level 4.1"
Which should result in a command line similar to the following:
