Musings on my own ignorance - or, what I learned about CRF

[rhester]

It wasn't that long ago that I was utterly ignorant of the finer points of video transcoding. In fact, I originally discovered HandBrake almost two years ago as a n00b Windows user looking for some way - *any* way - to convert DVDs to my then-new iPod Video 5G. At the time, it was the only tool that worked...sort of. It was good enough for government work, at least.

Later on, firmware 1.2 was released, and suddenly we could do "high-res" encodes...if you knew the magic incantation (that was later discovered, thanks to doom9, to be the UUID atom).

I worked with another gentleman for a few weeks to hack together some source changes to HandBrake 0.7.1 - notably 640x480 support and the UUID atom.

We quickly discovered that it was a challenge to keep our work together and integrated, especially when we were exchanging code snippets by e-mail and FTP. This led to the thinking that, if we were going to do much to it beyond this, we probably ought to consider a more real solution.

To make a long story short in that regard, this thought pattern led to the creation of a local copy of the HandBrake SVN repository, a support web site, and eventually an entire replacement infrastructure to host the HandBrake project, since the original had largely been abandoned by the author. Beyond that, we forked the project, then unforked, and finally returned to our ancestral home here at m0k.org, coming full circle. =)

In that time, I made what was (for me) a rather unintuitive discovery - when encoding video as ABR (target bitrate), resolution has absolutely nothing to do with filesize. Filesize is directly controlled by bitrate alone, so if you increase the resolution without increasing the bitrate, you're going to wind up with a very poor-looking, "muddy" and blocky encode. (It was this discovery that led to my realization of why 320x240 iPod rips look better than their 640x480 brethren...yes, part of it has to do with the smaller resolution, but it's mostly because you can do 768K @ 320x240 and only 1500K (or so Apple says) @ 640x480...you're increasing the resolution by a factor of 4 (active pixels) but the bitrate only by a factor of 2 (so your quality literally drops by half).

So what does all this have to do with CRF, you might ask? Well, let's take a moment to examine the effect that tweaking various x264 parameters has on a target bitrate encode.

Say my target bitrate is 1500K - well, that's what it's going to be (assuming the source material is complex enough and the resolution is large enough). So why do things like play with subme, me and the like? Because you want to pack as much quality into the limit number of bits as you possibly can - so you enable as many options as you can get away with (and have patience for) in order to maximize use of your most precious resource, limited bitrate.

Now that I'm playing around with CRF encodes for next-generation iPods, I finally understand what I'm sure is old hat to many of you, but I personally found quite surprising - changing of things like subme and me have absolutely no effect on the perceived visual quality of the output. None at all. You can tweak settings for a decade, and the output will still look no different at all from the bare x264 defaults when encoding to CRF. In fact, it makes no difference if you use baseline profile, main - whatever you like. It will look just the same.

How can this be? Because CRF attempts to encode to a specific visual quality, and does whatever is necessary in terms of bitrate to meet that desired quality.

So what, then, is the role of all the advanced x264 options when using CRF that normally make such a difference in quality on target bitrate encodes? They control the amount of bitrate required to meet your quality goal. That's it. Encode with CRF using the defaults, you might have a final average bitrate of, say, 4000kbps. Turn on a higher level of subpixel motion estimation, it could go down to 3200kbps but still look exactly the same visually. Turn on more advanced options (if properly chosen), the bitrate will drop even more...but the video will still look the same.

This is a heady concept, because it means things like pre-encoding temporal filtering become even more advantageous with CRF than they are with ABR. It's an entirely different way of looking at and thinking about video encoding.

Just wanted to take a moment to share my discovery and thoughts with the general populace, just in case there's one other person like me who had never really explored CRF and didn't really understand what it's all about. Trust me...once you use it, you won't look back. =)

Rodney

[qwerty123]

Hi Rodney,

I came at it from exactly the other end of the telescope. My first dip into this puzzled me how people were all talking about target bit rates and file size limits. I guessed this came about from a history of squeezing stuff onto CDs for storage.

I realised that I needed different bit rates for different material and so was frustrated by the need to twiddle about with settings. I just wanted to settle on what my eyes liked and be done! Let the computer do what it does best and leave me to do the interesting human stuff - like watching the actual entertainment.

Along came CRF at just the right time for my AppleTV. Cav and Dynaflash did some cool experiments, that I couldn't better despite tweaking for hours. Lovely! My Cav preset gets much use.

But now I've got my iPod Classic. Damn. Re-encode time. Sounds like you want to head the same way for iPod as they did for the ATV. Now the other boys aren't too bothered by iPod, so my crutch has been kicked from beneath me. The general received wisdom seems be to keep away from CRF on iPod as the bit rate spikes are a [Censored] to predict. Not really made any progress myself as life's too short for piddling about too much on this stuff. But I would like to avoid having to have two sets of files or compromise on performance on ATV for iPod compatible files.

I suspect the is some mileage in the extended specs of the new Classic you posted - but I've yet to read up on the current state of the art... So at the moment it's two sets of encodes to look after with Smart Playlists - I suspect the annoyance of that, will spur me into action at some point.

Anyway, Happy Christmas
Dave

[rhester]

You're right - we share the same goal but attacked from completely opposite ends.

The good news is that my next-gen iPod research is slowly grinding to a successful conclusion, which may mean acceptable (not ideal, jbrjake presets that work well for both 2nd-generation video-capable iPods and Apple TV alike. Time will tell...

Rodney

[nightstrm]

I've begun to play around with CRF encodes for iPhone and AppleTV, and have been very impressed with the results so far. I'll post more once I have some more testing done, but the iPhone has played every CRF encode (using x264b30) I've tried so far.

[royone]

I also came around to the CRF way of thinking, but have found that there's some variability from source to source in what setting I find acceptable. The most obvious place to look for problems in an encode is in flat, shadowy areas. The Matrix is a good example. Most movies look fine to me at quality setting 56, but The Matrix has a lot of scenes where the walls appear to crawl at that setting. Similarly, A Christmas Story looks fine, except for when the smoke comes billowing out of the vent. The smoke is all blocky.

In both of those cases, I had to re-encode. For The Matrix, I just added 30% to the file size and encoded to that target size. For A Christmas Story, I encoded the furnace-smoke scene at increasing quality settings until it looked good, and then did the movie at that setting.

I'm wondering whether it would be possible to adjust the encoder to compensate for the dark-block effect, so that CRF would be more consistent. This isn't even a pony, because I don't know whether it's even technically possible.

The other area where CRF might disappoint is in noisy source. The Great Muppet Caper has a lot of film grain. Encoding at 56 turned out a 1.6 gig file for a 96-minute movie. That seemed excessive, and I was sure that it was due to the grain. I played with denoising settings, but ultimately I just decided to try encoding to a 1.1 gig target size and see what I got. It was fine.

One other anecdote: I did a grayscale encode of Charlie Chaplin's Modern Times at quality=56. Again, it's around 100 minutes. The file was 2.6 gig! I hadn't even considered that it could be interlaced, because why would it be? It's a pre-television film. But it was, inexplicably, interlaced. A "slower" de-interlace yielded excellent results in image quality and compression at the same quality setting.

So basically, remember to look at your source and review your result, and consider that you may have to make adjustments to your favorite quality setting to compensate for peculiarities, especially if you're trying to ride pretty close to the file-size/quality edge.

[rhester]

Blockiness in dark areas (notably black and blue) can largely be mitigated through use of adaptive quantization - but it is very much a WIP by several x264 hackers that will not likely make an appearance in HandBrake for some time (as they've collectively worked on it for 3 years already with no one-size-fits-all solution).

Rodney

[jbrjake]

adaptive quantization - but it is very much a WIP by several x264 hackers that will not likely make an appearance in HandBrake for some time (as they've collectively worked on it for 3 years already with no one-size-fits-all solution).

Actually, we have the v.1 AQ patch applied to our copy of libx264 -- that's not Shikari's AQ, it's Haali's original with some b-rdo fixes from last summer.

[Cavalicious]

You need to denoise A Christmas Story...Trust Me!

[cvk_b]

...once you use it, you won't look back.

So true.