Monday, November 02, 2009

H.264 (x264) Encoding times with StaxRip

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.

Clip: 4m 15s (255s) - CRF: 22 - 10m 40s (640s) - (2.5x)
Clip: 8m 11s (491s) - CRF: 22 - 23m 18s (1398s) - (2.8x)
Clip: 9m 46s (586s) - CRF: 22 - 32m 27s (1947s) - (3.3x)
Clip: 11m 4s (664s) - CRF: 22 - 30m 12s (1812s) - (2.7x)
Clip: 15m 37s (937s) - CRF: 22 - 49m 51s (2991s) - (3.2x)
Clip: 29m 25s (1765s) - CRF: 22 - 87m 49s (5269s) - (3.0x)

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:

Clip: 15m 58s (958s) - CRF: 23 - 59m 45s (3585s) - 3.7x
Clip: 07m 18s (438s) - CRF: 23 - 39m 32s (2372s) - 5.4x
Clip: 05m 11s (311s) - CRF: 23 - 25m 30s (1530s) - 4.9x
Clip: 12m 17s (737s) - CRF: 23 - 60m 28s (3628s) - 4.9x
Clip: 15m 13s (913s) - CRF: 23 - 72m 44s (4364s) - 4.8x
Clip: 07m 48s (468s) - CRF: 23 - 54m 56s (3296s) - 7.0x
Clip: 12m 03s (723s) - CRF: 23 - 70m 58s (4258s) - 5.9x
Clip: 04m 15s (255s) - CRF: 24 - 16m 22s (0982s) - 3.8x
Clip: 06m 27s (387s) - CRF: 24 - 40m 33s (2433s) - 6.3x
Clip: 11m 04s (664s) - CRF: 24 - 49m 25s (2965s) - 4.5x
Clip: 04m 15s (255s) - CRF: 26 - 15m 07s (0907s) - 3.6x
Clip: 06m 27s (387s) - CRF: 26 - 40m 52s (2452s) - 6.3x
Clip: 11m 04s (664s) - CRF: 26 - 43m 02s (2582s) - 3.9x

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:

--preset slower --partitions p8x8,b8x8,i4x4,i8x8 --vbv-bufsize 50000 --vbv-maxrate 50000 --level 4.1 --output "" ""

I tested CRF for 3 samples. The impact of CRF values on bitrates (shown in Kbps) is as follows:

18: 4820 5130 9840
20: 3267 3864 7100
22: 2520 2975 5260
24: 1970 2320 4050
26: 1515 1770 2940

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.

Labels: 2009, FRAPS, VideoEncoding, x264

posted by Wuphon's at 7:42 AM (0 comments)

Monday, September 29, 2008

AMD Phenom 9850 and XVid Encoding

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 -

So for every minute of source material, I need

Labels: 2008, FRAPS, VideoEncoding, XVid

posted by Wuphon's at 1:34 PM (0 comments)

Tuesday, February 26, 2008

Converting FRAPS captures to XVid

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).

Labels: 2008, FRAPS, VideoEncoding, XVid

posted by Wuphon's at 12:01 PM (0 comments)