DynaFlash Tech

As of this HandBrake svn commit and its corresponding Nightly Build, HandBrake is no longer overriding x264′s default of b-pyramid being on. Previously HandBrake would internally turn off b-pyramid by initializing it to 0 as it caused issues with the version of QuickTime that existed at that time. QuickTime has progressed and can handle b-pyramid just fine … except for the modified 7.0 version found in the AppleTV (much like weightp addressed prevously). At any rate using b-pyramid on the current AppleTV firmware will not only screw up your encodes … but will in fact freeze the AppleTV which only a restart can correct. So the way to fix this is by adding:

b-pyramid=none
to all of your custom presets advanced panel *if* you are using any HandBrake nightly after svn 3424 (NOTE: this does not affect the last public release of HandBrake 0.9.4 however in fact there is no reason not to add it if using 0.9.4 in the interest of “future proofing”). This also does not affect the AppleTV built in presets as that is also added in the commit. So only critical for your custom presets if using a version after 3424.

The advance custom string discussed in HandBrake AppleTV Hi Profile Setting: Part 2 has been changed accordingly to:

mixed-refs=1:b-adapt=2:b-pyramid=none:trellis=0:weightp=0:vbv-maxrate=5500:vbv-bufsize=5500

This post is a follow up on a previous post HandBrake AppleTV Hi Profile Setting which includes what constant quality settings to use, etc. If not familiar with it maybe read it as this expands upon that post. A couple of pertinent facts:

1. As of AppleTV OS 3.0 extensive testing has shown that the AppleTV can handle weightb just fine.

2. As is said in the Edit comment from the previous post the AppleTV can not handle weightp. So weightp=0 MUST be included in any AppleTV custom preset. This is because the AppleTV as of this writing uses a modified version of QuickTime 7.0 which did not handle that option at all. Horrible blockiness and artifacts will show especially on fades.

3. When encoding High Definition sources (1080p, 720p) to a proper AppleTV preset extreme bitrate spikes can cause the AppleTV to drop frames. Therefore for safety Video Buffer Verifier (known as VBV) options need to be put in place as safeguards for just this event.

4.[Edit] As of this HandBrake svn commit and its corresponding Nightly Build, HandBrake is no longer overriding x264′s default of b-pyramid being on which I discuss here. Using b-pyramid on the current AppleTV firmware will not only screw up your encodes … but will in fact freeze the AppleTV which only a restart can correct (NOTE: this does not affect the last public release of HandBrake 0.9.4 however there is no downside to adding it to your custom presets as you update HandBrake you will be “future proof” as far as b-pyramid is concerned).

Trimming the fat off the option string (removing unnecessary options):

First we start off with the advanced options string from the first post:
ref=3:mixed-refs=1:bframes=3:me=hex:subq=7:b-adapt=2:8x8dct=1:weightb=0:trellis=0:weightp=0

As per item number one the current AppleTV can handle weightb just fine as well bframes=3, me=hex, subq=7 and 8x8dct are all default in hb’s x264 encoding library so we slim the options string down to:

mixed-refs=1:b-adapt=2:trellis=0:weightp=0

As per number 4 above regarding b-pyramid we want to make sure its turned off by adding:
b-pyramid=none
So we now have:
mixed-refs=1:b-adapt=2:b-pyramid=none:trellis=0:weightp=0

Now having said that as per number three above I am adding vbv parameters to control very high bitrate spikes which are:
vbv-maxrate=5500:vbv-bufsize=5500

This now results in a new advanced option string for the Hi Profile AppleTV preset which looks like this:
mixed-refs=1:b-adapt=2:b-pyramid=none:trellis=0:weightp=0:vbv-maxrate=5500:vbv-bufsize=5500

A few words about video buffer verifier (vbv) settings:
Some playback devices have published video buffer specs in which case setting the vbv is pretty easy. We would know the maximum rate and the size of the video buffer that can be filled. However as usual the AppleTV is a bit of a black box when it comes to any published specs and even the spec that are published are notoriously conservative. So these settings were determined through a lot of testing … and testing … and retesting using some of my toughest material. The idea is to put a cap on peak bitrates so that the AppleTV does not drop frames during tough scenes, yet keep the cap high enough so that for most material the encoder can use as much bitrate as it needs to keep quality up. Currently these have been bullet proof over many tests. For what its worth these vbv settings will allow a .75 second spike as high as 12,833 kbps. The AppleTV publishes a peak bitrate of 13,000 kbps though fails to mention on what duration that spike can be maintained. At any rate using the settings above with rf 22 causes most HD sources to stay well below that so the cap is never hit. But, if its needed its better to cap some bitrate than drop frames. Frankly the effect of the capped bitrate is all but indistinguishable when it happens.

In the end … I suggest that if you use these advanced options with this x264 option string in the HandBrake advanced panel you should be more than happy with your AppleTV encodes especially considering the file size / bitrate tradeoff for visual quality.

NOTE: As of 4/18/2010 Developer Snapshots have been replaced by the Nightly Builds.

So, while the latest HandBrake public release 0.9.4 is now coming up on its 5 month anniversary it is worth mentioning that the HandBrake project is … less than regular or even prompt with public releases. This is obvious to any regular HandBrake users. Part of this is due to the fact that in true OSS fashion HandBrake is developed by volunteer developers on their own free time … time which is pretty much limited to whenever they can find it which can be sporadic at best. It is also further complicated by trying to coordinate three Graphical User Interfaces (gui’s) … ie Mac, Linux, Windows and one Command Line Interface as well as the associated documentation that is expected of a “Public Release”. Coordinating all of this is rather monumental for a project with limited resources like HandBrake however what most people do not realize is that there are things going on “behind the scenes” that the average HandBrake user might not be aware of.

The HandBrake Trac: I suspect that most users are not aware of the Trac which is available for anyone to read. This documents everything that is changed in the HandBrake codebase. As you can plainly see by viewing the trac link above, HandBrake developers are actually quite busy advancing the software …. sometimes contrary to popular opinion.

Developer Snapshots: While anyone is welcome to compile the latest HandBrake svn revision (would be the most recent Trac commit) from source, it was recognized that A.) many users do not know how to compile code and B.) really do not want to. So the HandBrake Devs decided to create Developer Snapshots and announce them on the HandBrake forums . These are ready to download binaries of HandBrake in all of its flavors sans up to date documentation. The idea was that these might be unstable but were quicker to put out than public releases and would give developers valuable feedback for bugs … etc. ( though in common practice tend to be more stable than the last public release but as usual your mileage may vary). These “Developer Snapshots” are svn revisions decided by the HandBrake Devs to be pretty much stable and having general UI parity so deemed stable enough to release to the users. This also means however that some developer agreement and coordination is necessary to produce these.

Nightly Builds: As of late it was realized that the very cutting edge of HandBrake code was still not available to those wishing to run HandBrake on the “ragged edge” of development. So, in response the HandBrake project now has nightly builds available to the public. Now these builds are computer generated by the HandBrake servers each night from the latest code committed to the svn. This is as close to current HandBrake as you can get without actually compiling the code for yourself. It’s exciting but also can be risky as it will have the latest code with all of its improvements but also with all of its faults ( usually corrected in the next nightly).

I can tell you that I do all of my personal video encoding using the latest HandBrake svn ( which is pretty much mirrored in the nightlies) and rarely if ever have trouble. Having said that as it says in the nightly post … do not expect support for nightlies. They are computer generated at a given time (4 am. in France) and may or may not contain errors, issues or whatnot.

My Point: Given the rather large time spans between “Official Public Releases” of HandBrake do not draw the conclusion that the project is languishing or dead … in fact far from it as is evidenced by the Trac Timeline. If you wish to play it safe then use the latest public release. However if you wish to “walk on the wild side” the HandBrake project aims to offer what you want … Good, Bad or Otherwise!

Edit: As of HandBrake 0.9.4 you must add weightp=0 to any encode to be used on the AppleTV as weightp will introduce horrible blockiness and artifacts especially during fades. The option string below has been modified accordingly.

So, for some time now I have been using my own custom HandBrake settings when encoding for the AppleTV. I have two eSata modded AppleTV’s and by and large these HandBrake settings have been stellar. They have also been used by other HandBrake testers and fervent users on stock AppleTv’s with much success. So I figured I would post them here now.

Having said that though, I suggest these settings be used with one of the snapshots posted on the HandBrake forums. HandBrake 0.9.3 is almost a year old and the current HandBrake snapshots produce much smaller files with better quality than the older 0.9.3 public release.

1. To start, pick the Apple > AppleTV preset in HandBrake which is built in.

2. Instead of the built in presets constant quality of RF 20, slide the slider up so you get RF 19.25 ( RF goes lower as your quality gets higher, much like in golf ). One word of warning: constant quality is determined based on the source file. 19.25 is proven for SD DVD. Now if you are doing HD sources like say a 720P or 1080p mkv or whatever, then try more like RF 23 or so as 19.25 on HD sources will give you a pretty high bitrate depending on the source file.

3. Click on the Advanced panel and paste this string into the ” Advanced Options String ” textbox at the bottom (note the crappy code box.. gotta work on it but functions just fine):

ref=3:mixed-refs=1:bframes=3:me=hex:subq=7:b-adapt=2:8x8dct=1:weightb=0:trellis=0:weightp=0

Thats about it.

You should find that you’re encodes are smaller, and the quality higher than the built in HandBrake preset.