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:
So I've been using my new AMD Phenom 9850 quad-core CPU to do a bunch of FRAPS conversions to XVid. The source video is typically 1576x984 (not quite 1680x1050) at 30fps. The output is 1280x720p, XVid format, at around 2.8Mbps with 160Kbps MP3 audio. I'm doing 2-pass encoding for the XVid, which gives superior results over a single-pass style.
Unfortunately, Virtual Dub won't use (currently) more then 2 CPUs, so the Phenom ends up a bit underutilized. So the CPU utilization is only around 50-55% during the first pass and 60-65% during the second pass. (A value of 100% would be running all 4 cores at full utilization. So the 2nd pass is using almost 3 cores.) But since the Phenom 9850 is the 2.5GHz CPU, it's at least doing a passable job at getting the encoding done quickly.
Source video - 30m 59s Pass 1 - finished in 46 minutes (1.5x more then real-time) Pass 2 -
I've been playing around with my FRAPS video captures this week. FRAPS allows you to capture gameplay (even for full-screen games) into an AVI file. The compression is (what looks like lossless) fairly loose for the captured AVI files (figure 4GB per 2-3 minutes of gameplay).
Obviously, I can't keep lots of 4GB files sitting around. Even though they're very pretty at 1600x900 or 1280x720, they take up a LOT of room. For instance, a 21m 11s video of my priest running around World of Warcraft last September is 10 files and 36.5GB of space (roughly 250Mbps). So I need to pack them down into something more manageable.
Last year, my preference was to convert them to DVD-sized MPEG2 (around 7000-8000Kbps) and stick them on DVDs with about 50-75 minutes of gameplay per disc. That actually worked pretty well, but I soon ended up with dozens of game footage DVDs to keep track of. Which works well if I want to hand a sample of gameplay to someone on a portable format, but a 720x480 image fails to capture a lot of the detail from the original 1600x900 or 1024x768 gameplay. Some games work wonderfully in DVD format (Monkey Island series, Grim Fandango, etc), others suffer from the smaller size where you can't read the text.
(Why save this stuff? I'm a digital packrat and it will be useful in 10-20 years to be able to pull up a clip from a game that can no longer be run on modern systems. It's a way of being able to look back at what game technology was like in the past. It's also a way to show friends / family bits from a game that currently has capture my interest.)
This year, my preference is to go with something a little tighter then MPEG2. Preferably an MPEG4 generation format (DivX, XVID, etc. or maybe H264). While MPEG2 requires a reduction in the video size as well as a lot higher bitrate, MPEG4 (and H264) encoders can work with larger resolution videos yet still pack things down into a tigher bitrate. The downside is that there are no one-step tools out there that convert multiple AVI files into two-pass XVid. I was definitely spoiled by the easy use of TMPGEnc's encoder and batch tools. Still, I can do the enodings using VirtualDub, I just have to be more careful about the process (easier to make mistakes).
What I've settled on is 1280x720p XVid (I think it's progressive), which is a standard HDTV resolution. These AVI files are readable on a variety of systems (such as Ubuntu, and OS X with a bit of work). I'm using the standard "HDTV" XVid Profile to create the AVIs, which will hopefully give me more portability. The 1280x720p resolution is also good enough that I can always downconvert to DVD later if I need to.
The trick then, is to figure out what bitrates work best for 1280x720p game footage. There are no hard and fast rules for this, so it requires a bit of experimenting and deciding what bitrate results in acceptable quality the majority of the time. If I go with too low of a bitrate, certain types of gameplay videos will starve for bits and come out blocky or smeared. Too high, and I'm simply wasting space. So here's what I've figured out. I've been working with a variety of sources (2 FPSs, FEAR and Call of Duty 2 and a MMO, World of Warcraft) and doing a good bit of trial and error.
The audio side of the equation is easy... MP3 audio at 128Kbps (but I'll probably use 160Kbps).
The video side of the equation is less simple. Some of the output quality depends on which XVid decoder you have installed on your system. The older decoders will result in blocky or smeared video output, while newer versions of the decoder will give you much higher quality output from the same AVI file. So when you're testing, make sure that you check the video out on a few different systems. Or simply make sure that you have the latest version of XVid installed.
1280x720p @ 650Kbps -- This is what I originally thought I was going to use. It seems like a generous bitrate (and it is for 640x480 content), but it frequently ends up blocky/smeared for 1280x720. Which makes sense, because 1280x720 has 3x more pixels then 640x480, so the bandwidth needs to be a good bit larger. Not necessarily 3x larger, but probably at least 2x larger. Figure on 6MB per minute of video (around 700 minutes on a regular DVD-R). If I was storing standard-def 640x480 video, I'd probably pick a bitrate around 825Kbps with 160Kbps for the MP3 audio (7.2MB/min or 600 minutes per regular DVD-R).
1280x720 @ 1Mbps -- This works modestly well, unless there is a lot going on with background detail. Then it falls over flat and goes blocky/smeary. Even with 2-pass encoding, a video that is very busy for most of the time results in no "slack" that can be used by the encoder to shore up the bitrate in the really busy parts.
1280x720 @ 1.4Mbps -- This *almost* works for very busy clips. As long at least 1/4 of your video is "quiet" moments (very little camera movement, little backround changes), the compressor might have enough spare bits for the busier sections. Assuming 128Kbps MP3 audio, this results in about 11 MB/min (almost 400 minutes on a normal DVD-R).
1280x720 @ 1.75Mbps -- Works for most situations. Which makes sense since it's about 3x the bitrate of the 650Kbps stream that worked for 640x480. Only the most "busy" of videos will saturate this bitrate level into blocks/smears. Assuming 128Kbps MP3 audio, this uses up around 13.5 MB/min (a bit over 300 minutes on a normal DVD-R).
1280x720 @ 1.9Mbps -- This is the top-level quality. You'd have to work really hard and feed it an extremely nasty video in order to blow out this bitrate. When you include the 160Kbps MP3 audio, you're looking at a bitstream that is right around 2Mbps. A nice round number. A bit under 15 Mb/min (around 300 minutes on a normal DVD-R). If you really want to pack 300 minutes on a regular DVD-R, you should probably trim the bitrate down to 1850Kbps.
I'm probably going to settle in on 1850Kbps video with 160Kbps audio for 16:9 footage. Which should be fat enough to store all of my 1280x720 footage without starving for bits even on the nastiest source videos. I'll scale back to 825Kbps for 4:3 640x480 footage (NTSC source material).
...
Update: While 1850Kbps video works well for some sources, I'm finding that Elder Scrolls IV: Oblivion FRAPS captures aren't quite as forgiving. I've had to step all the way up to 2850Kbps in order to keep the video from going blocky (reliably).
Playing with the noise reduction features in TMPGEnc a bit more. Specifically, the Spatial NR Setting and the Temporal NR Setting. This is just a first pass. I encoded 33m40s worth of footage using the following settings:
Spatial 20/small Temporal 20/small - 2:10:25 - 3.8x Spatial 30/small Temporal 30/small - 2:14:33 - 4.0x Spatial 50/small Temporal 50/small - 2:10:40 - 3.8x Spatial 75/small Temporal 75/small - 2:14:18 - 4.0x - these were all within margin of error of each other
Changing the size / duration of the spatial/temporal filters had the biggest effect (as expected). CPU utilization on my dual-Opteron 246 system was not always 100%, so you should set the bach encoder to process 2 projects at the same time on a dual-CPU machine.
Still trying to come up with my preferred encoding filters for TMPGEnc 3.0 XPress. I used to use VirtualDub to do my filtering, but since I switched over to capturing via DV files, I now just use the filters in TMPGEnc 3.0 XPress.
Here's the current filter that I use. It's not quite as clean as I like, but it does clean up some of the minor noise that you get from a S-VHS recording. It was a bit of a trade-off between quality/speed.
Crop top 4, bottom 4, black mask turned on for top/bottom
Noise Reduction Spatial NR Setting - intensity 20, noise detection area Small (fastest) Temporal NR Setting - intensity 20, range Short (fastest)
Audio Correction Volume Change - Audio Normalization to 90% level
Upgraded to the new version of TMPGEnc (an MPEG2 encoder) this week. The newer interface is nice. They've broken the batch encoding tool out to a 2nd application, which can run in the background while you prep additional files to be encoded. They've also fixed some problems with the old UI and you can now encode audio straight to AC3 (which makes the disk estimates accurate).
I'm still doing some benchmarking, but speed-wise it seems to be around the same. On my AthlonXP 1800+ box (PC2100 memory), encoding with "High" motion search precision and DAC of 10 bits, a 720x480 clip takes the following timings:
143 minutes in 16.5 hours (PCM audio only) or around 6.9 minutes to encode 1 minute of video. That's pretty close to the old v2.5 (which I used to estimate at 7 minutes to encode 1 minute). I didn't have the AC3 plug-in installed when I did that test which is why the output audio was PCM. Encoding to AC3 will probably add 30 minutes or so (not much).
A second session (this time encoding to AC3 audio) managed to encode 145 minutes in 17.6 hours of CPU time (or around 7.3 minutes per minute of source).
A third session (720x480 at 4000VBR + 224AC3) encoded 115 minutes in 13.5 hours (around 7.0 minutes per minute of source).
Testing out some more filtering per a discussion over on the DVDRHelp forums.
On a side note, I've gone back to only putting (3) hour-long TV episodes on a DVD (roughly 133 minutes once commercials are removed). The 2900kbps video rate seemed to be too noisy. Doing a VBR average rate of 3750kbps, the disc only came out to 3.78Gb, leaving a goodish amount free. Allowing for 45min per ep (135min total), that should work out to 3.84Gb. My goal is to fill the disc up to the 4.2Gb point (leaving 0.17Gb free for QuickPar PAR2 recovery data). So I have room to bump my average bitrate up by 9% to 4100kbps.
I still might try out the lower bitrate again in order to fit (4) on each disc - now that I've tweaked TMPGEnc to give better results. (That bitrate will probably be 3100kbps.)
FYI, I found a good scene that illustrates (somewhat) what happens when you have too low of a bitrate or the motion search precision (MSP) is off. This is from the start of a Law & Order episode and is a shot of the river with lots of little ripples reflecting the blue sky against the dark water. The effect is much easier to see when watching the clip, which was encoded at 2900kbps using an MSP setting of "Motion Estimate (fast)". Still, if you look closely, you'll see the blockiness around the highlights where the macro blocks weren't able to flesh in the details.
(right side shows a little of the artifacting)
(look left and below the dark bump in the upper left to see some blocky areas)
Benchmarking some different "motion search precision" settings in TMPGEnc Plus. I was just using "Motion Estimate (fast)", but while encoding some anime, I've found some motion errors on certain frames. The error looks like bleed-over from the next/previous frame, different then an interlace artifact (which looks like a comb). Interestingly, looking at some screen captures from my Key the Metal Idol DVD, I see a good number of motion errors on there as well.
TMPGEnc has (6) settings for the "motion search precision". These were all done on 720x480 30fps source material (MJPEG Q20), variable bitrate at 6500kbps avg, and 10bits of precision. The test clip was 1 minute 51 seconds in length (call it 1.85 min for rough guess) and the system is an AthonXP 2600+ with DDR266 RAM (PC2700) CL 2.5.
So High Quality is roughly 6:1 (6 min to encode 1 min of source). It's about 50% worse then the "Motion Estimate" method that I was using, but gives nicer results.
On the P4 1.6Ghz laptop, it ends up being more like 12:1 or 13:1, but that's at 75% CPU utilization. Since I just queued up around 180 minutes of source material, that CPU will be busy until sometime Wednesday (oh boy!). Some days I seriously consider getting a dual-CPU box for when I fall behind. This is my 3rd attempt at encoding these 8 episodes and it's eating up a ton of space that can't be freed until I push it out to DVD-R and check it.
Update: If you go into TMPGEnc's "Environmental Setting: CPU" dialog, there's a way to provide TMPGEnc with a cache for the 2-pass VBR data. Apparently, without the cache, TMPGEnc only records a single "Q" value for the entire frame, but with a cache it can go much finer. Or something like that... I'm rather fuzzy on the details. However, enabling the cache and setting the cache limit to a decent value like 15Gb (3 hours or so) will speed up VBR-style encoding. (Some folks say +30%.) On the laptop, I set it to 4Gb since I'm always encoding short 5-25 minute clips (which only needs 1-3Gb or so); the desktop got set to 12Gb since I use that box to encode very long clips.
Trial and error isn't too bad, but with a 3:1 encode time (3 min to encode 1 min of source), it's not trivial either. My first few attempts resulted in non-compliant MPEG2 files, so I've had to go back to square one and figure out what I did wrong (re-starting with the provided DVD (NTSC) template.
