Monday 5 January 2015

Tech Tip: Handbrake part 3

It's been a while since proverbial drinks but I finally have some more information to share, in this case with regards to Handbrake.  Once more I've conducted a huge amount of testing and, while I still can't say that I'm happy with the results, I'm actually quite prepared to share what I consider my final Handbrake settings and the ones I plan on using going forth.

So, if you haven't given up on me yet, allow me to present you with my 3rd attempt at Handbrake settings!

CONFIGURATION

As always, I plan to start from the end and work my way back.  This time, though, I'm going to start off with two different settings.

The first set are for full HD material, and look a little bit like this:

no-fast-pskip=1:aq-mode=2:rc-lookahead=60:ref=4:bframes=6:b-adapt=2:direct=auto:me=umh:subme=8:merange=32:analyse=all:trellis=2

The second set are for SD material, and are similar but just a little bit different:

no-fast-pskip=1:aq-mode=2:rc-lookahead=60:ref=6:bframes=6:b-adapt=2:direct=auto:me=umh:subme=8:analyse=all:trellis=2:aq-strength=0.5

For the most part, those strings match up.  They're also pretty similar to my last offerings but there might be a few bits in there which seem to contradict my previous findings, so allow me to explain.

No-Fast-PSkip is used to assist with subtle fades.  You can leave this out if you want for a small performance gain, but it's only a very small difference in exchange for slightly better encoding.  99/100 times you won't notice the difference in the result with this, but that 1 time it's going to bother you.

AQ-Mode 2 is for the same reasons as last time.  It works well, provided you set the actual AQ strength is set appropriately.  It's this last part which makes the main difference between the F/HD and SD settings.

RC-LookAhead is set to 60 to assist with forward prediction.  Going higher than 60 is pretty well pointless but there's very little performance penalty for doing so if you really insist (unless you go crazy, such as 1,000).  My testing showed this didn't make a lot of difference to the results, but was basically the same speed as 40 and was never detrimental to the results.

Ref(erence frames) are set based on H.264 profiles and levels.  4 is the maximum you can use while staying in High Profile 4.1 with 1080p content, while 6 fits nicely into High Profile 3.2.  You may need to adjust these based on what you plan on viewing the results on.

B-Frames comes from the testing I conducted previously.  Since I found 5 to be about the useful limit of B-frames, I elected to use 6 to cover that last 1%.  You could always set this to 16 if you really wanted to, but it may not provide any real benefit in exchange for massively increasing the encoding time (unless you change B-Adapt to 1).  Note that some playback hardware doesn't support B-Frames, so you may need to set this to 0 as well.

B-Adapt is a pretty straight forward setting.  While Fast (1) is exactly as it sounds (faster), there's no point in trying to use more B-frames than you need.  It sacrifices too much end quality for my tastes and can make playback inconsistent.

Direct [Adaptive Direct Mode] is another straight forward setting.  The default (Spacial) is fine to use for general purpose, but Auto is only fractionally slower for a little extra peace of mind.  You're talking a small enough speed gain that it could just be run-to-run variation, so you may as well use Auto.

ME [Motion Estimation Method] is UMH.  It's only a little slower than the default Hex and generally provides better results.  I haven't found any benefit to going above UMH (ie exhaustive) unless you really, really don't want the encode to finish anytime today.

SubME [Subpixel Motion Estimation] I've decided to finally switch to 8.  With the rest of the options that I've changed over the time, 8 has finally started to produce better results than 7.  However, the caveat is that 8 does take longer than 7, and produces slightly larger files.  If you want faster and/or smaller than use 7 (it's still very good), but 8 generally gives better results.  9 takes a lot longer and doesn't give sufficient benefit to the results, though they are smaller.

MERange is one of those settings which some people think isn't worth touching.  You're free to be one of those people as well as the gains are very small.  My testing suggests it is only just worth changing it based on the resolution of your source.  32 works well for FHD, 24 for HD, and 16 (default) for SD or below.  Note that setting it too high can actually have an adverse effect on the results as it can find something within that range which isn't actually another thing moved.

Analyse [Partition Type] is another self-explanatory setting.  If you're trying to get the best compression possible, let it use as many different patterns as it can.  Most would be fine if you really need that extra speed, but the compression benefits are there from using All.

Trellis, as opposed to my previous post, is now set to 2.  Especially used in tandem with SubME 8, this can produce some fantastic results in exchange for relatively minor performance losses.  The resulting output looks better and is smaller - win/win.  You can set this to 0 if you want but I don't recommend it anymore, and if you're going to set it to 1 than you may as well go whole hog for the speed and size difference.

Lastly, the secret SD sauce.  AQ-Strength being set to 0.5 is almost a necessity for SD material.  You could probably go even lower if you wanted to, but I find 0.5 works for everything I've thrown at it so far.  If you're not doing SD media, leave it alone.  I'll explain more in a moment.

THE SD EPIPHONY

I'll get straight into the bit that pleases me the most about my recent findings: AQ-Strength=0.5.  As an encoder, x264 should be resolution independent.  In other words, it shouldn't matter what resolution you throw at it, the results should be comparable to each other.  Unfortunately, they aren't.  I don't blame the x264 authors for that - when you're talking the difference between almost 2,000,000 (2 million) pixels per frame and 415,000 (415 thousand) than some things are going to be different.

The issue with SD material, as best I can figure, is that more of the scene is going to be occupied by edges.  It's the same visible amount, but a higher percentage of the number of pixels.  Where a fine edge on a 1080p picture might occupy 15 out of 100 pixels, or 15%, that same edge might now be 10 out of 20 pixels, or 50%.  As such, you need to devote more of the data to storing those edges, which x264 seems reluctant to do by default.

You can, however, adjust the AQ strength manually.  Higher values direct more data to "fine detail", while lower values (which I'm using and recommending) focus more on the edges.  As has just been established, SD content has a lot more edges so you really do want to push it that way as much as you can without sacrificing the rest entirely  The results are well worth the small tweak, in my opinion, especially if text overlays (subtitles) are present on the video stream.

CLEANING UP THE MESS

Another helpful feature added to the recent releases of Handbrake is the NL-Means noise filter.  I can't emphasise this enough: This filter is amazing.  There are some demonstration pictures on Handbrake's forums but you really don't appreciate it fully until you've tried it yourself.

However, I cannot recommend using any Tune save for "High Motion".  The sources I've attempted to clean up all require the "Medium" preset, but using a Tune other than HM results in noticeable temporal blurring - or a smearing between frames.  It doesn't seem to matter whether it's FHD or SD source material, or how much action there is or isn't in the frame, it just always smears.  Better to avoid it altogether.

As for performance?  The first build of Handbrake to include NL-Means had a very, very rushed implementation.  My encodes would drop to around 2% of their normal speed, making it pretty much impractical for anything but quick tests.  As of Handbrake SVN 6510, however, I'm very pleased to say the speed is quite acceptable - around 75% of normal encoding speed.  Obviously that will vary from source to source, system to system, but that puts it very much into the "usable" category, and the results are well worth it.

Do note, though, that it is completely indifferent to the source.  Noise that is meant to be there for artistic reasons will be removed the same as noise from bad transfers, so make sure it's what you want before you use it.  When you do remove it, however, expect file sizes to drop significantly - I've seen reductions of more than 60%.

I've since conducted a more thorough testing on something with deliberate noise added, and it does seem to survive the process.  It's muted but it's still there.  It's only the random noise added by things such as film transfers which gets heavily processed.

PUTTING IT ALL TOGETHER

Now that I've shared my recommended advanced settings, it's time to get back to the basics.  After much testing I've finally reached a point where I'm happy with the rate factors I'm using.  As always, unless you have a specific size to conform to (such as a CD or DVD) than it's going to be better to use CRF than a constant bitrate or target size, since some things just require more data than others.

In short, I've found that 22 works well for FHD video, 21 for HD, and 19 for SD.  You want to lower the number as you lower the resolution to increase the quality since you'll probably be watching it back at the same size, but it's got fewer pixels to show it.  For every 5 pixels on an FHD video you only get 1 on an SD video, so they need to be more accurate.

The next thing you'll want to do is to know your source.  While Handbrake's Decomb filter is pretty good, I don't personally advocate its use.  If your source is Interlace than just hit it with the "Slower" Deinterlace preset - it might scrub a little bit of detail, and take a little longer, but it will get rid of all the Interlacing.  I've seen many times where small bits of interlacing (such as around mouths) gets completely missed by the Decomb filter.  Naturally you'll want to turn of Deinterlacing for progressive sources (most HD, FHD and PAL videos are progressive).  Due to limits in some video codecs, you have to manually look for interlacing to be sure - but it doesn't take long to find it.

Also with knowing your source, pay attention to what kind of video it is.  Basic animated content (Sunday cartoons, anime, etc) doesn't require as much data as live-action, renders or top-end animation.  You can probably afford to increase the CRF by as much as 4 (so 23 for SD, 25 for HD, 26 for FHD) without any noticeable visual losses.  For animated content you should also set the AQ-Strength to 0.6 (halve this for SD) and Deblocking to 1,1, and there may even be benefit to doubling your reference frames and adding some more B-frames.

A lower-quality source can also be treated the same.  A big-budget production with quality mastering is one thing, but something shot on smaller equipment without the same post-production attention won't have the same level of detail.  You can afford to up the CRF a little bit - around 2 in my experience - without having any noticeable detriment to your viewing experience.

Finally, if your source is particularly blocky (it looks like it's made of squares that are too big, losing some detail between them) than it is worth using the Deblock filter.  You don't want to turn it up too high, though - 5 (the lowest available setting) is as high as you want to go.  You can go higher than that but it's starting to get beyond repair at that point, so don't expect miracles from the results.

One last little tip in this section, though: enable DXVA Hardware Accelerated Decoding.  It will provide an increase on pretty much any hardware, not just slow hardware.  I've seen gains of around 10%, which is nothing to be sniffed at on an overclocked 4770K.  Slower systems may see even more gains.

FINE TUNING

One thing you have to keep in mind is that a lot of my testing is going to be different to what you're using it for.  My screen might be a different size or a different type, I could (and likely do) have different visual acuity, and my standards are probably different as well.  And that's before you consider that my videos won't be the same as your videos when it comes to content or source.  All of this has come from experimentation with what I have available to me.

If you want to fine-tune the results, don't be afraid to do partial encodes.  There's nothing that says you have to do entire videos - 2-3 minutes is often enough to decide whether you do or don't like a setting, and you can batch up 10 or so of them at once to play with a whole heap of options.  Just make sure you name your files so that you can tell what you've done for each, since that's quicker and easier than looking through logs.

Don't always go straight for the extremes, though.  If you look at my SD findings you might be tempted to drop the AQ-Strength all the way down to 0.  The results may or may not be to your liking, but if they aren't than you'll probably feel slighted by me.  Instead, try 0, but also try 0.1, 0.2, 0.3 and so forth.  It might seem long and tedious - and it is - but you'll learn more for your efforts and get results that are better for you, not some guy who has a blog.


ADDENDUM

After writing this, I stumbled upon another setting which could be worth checking: AQ-Mode 3.  It's an "adaptive AQ mode [like AQ-Mode 2] with a bias towards dark scenes."  Unfortunately I can't find any further information on it, such as whether a dark scene needs to be dark across the frame or if it's just a frame which has a large number of dark elements in it.

Either way, dark areas (with their reduced colour range) still represent one of the worst things to parse with x264, thus Handbrake.  This could be a very, very useful setting to play with when it gets added to Handbrake; assuming that it hasn't already (it's been in "testing" for a while now).  To use it, simply replace the "aq-mode=2" with "aq-mode=3" and give it a go.

3 comments:

  1. This comment has been removed by the author.

    ReplyDelete
  2. Banding is a pain. You handled banding pretty well in Handbrake Part 2. However, the file sizes are pretty large. In Handbrake Part 3 you have cut the file size down considerably. However, banding is quite noticeable especially in dark areas.

    Having tried NLMeans, I am enjoying it. Certainly reduces file size on movies which have a lot of grain. I find "Medium" is too blurry. I prefer "Ultralight" although "Light" is almost as good with improved file size. I tried using it on the settings you provided in Handbrake Part 2 however it reintroduced banding and file sizes were still large.

    If only there was a good way to combat banding whilst maintaining quality compression.

    ReplyDelete
    Replies
    1. I honestly wish I knew a way to deal with it. My understanding is that without switching to either 10-bit or 4:4:4 x264 (which aren't supported by Handbrake) the best, and possibly only way to deal with it is in post. By "in post" I mean using a deband filter either in your codec (FFDShow) or player (PotPlayer) of choice, but that only applies if your software has that facility (like the two I mentioned); assuming you're not using a hardware player.

      If you're using one of those two I mentioned, a threshold of 1.51 and a radius of 16 works wonders.

      As for NLMeans, I agree with you there. Medium introduces a definite spacial blur, which may or may not be too much for some people depending upon how noisy the source was. With a 1080p source it's acceptable for me, but like you I've opted instead for Light or Ultra Light when going below that - always with the High Motion preset (even for animation). I've also found that using Light or higher, I can up the CRF by 1 (eg FHD at 23, instead of 22) and get no relevant visual difference.

      I'd wager that the panacea, though, is going to be x265. It supports both 4:4:4 and 10-bit encoding, plus it results in much lower filesizes. Of course it's as slow as a wet rag and hardware support is almost non-existent, but x264 started out that way in the beginning as well.

      Delete