HandBrake

First, let me say that I am NOT trolling. Also when I refer to "QuickTime", I mean QuickTime used through external applications, e.g. MPEG Streamclip.

I sincerely believe that the idea of x264 being a superior encoder has been way over hyped. From a huge amount of testing from countless DVDs, I have NEVER been able to reach the same quality through HandBrake when encoding at baseline profile that QuickTime can produce. I will admit without shame, x264 is far superior when encoding at main and high profiles, but when it comes to baseline, no combination of settings I have tried could produce as high quality files with as low file sizes. I have compared many videos I have encoded through HandBrake and MPEG Streamclip, and MPEG Streamclip has consistently produced videos with better image quality in both edges of objects and also in "flat" macroblocks, while handling high-motion sequences with ease, whereas with HandBrake, you seem to either have the choice of having good quality in edges OR "flat" macroblocks, or both but with an excessively high bitrate.

As developers of the HandBrake project, it seems natural that you have strictest confidence in the capabilities of x264 and believe that under all situations it is the best H.264 encoder available. If so, then show me! Give me a baseline profile preset that will have the same compatibility, and better quality than what QuickTime produces. You can literally test any source. I have uploaded an extract from Spirited Away, which has a lot of detail in the background and also "flat" macroblocks. Use this to test for animation. For a real life source, feel free to use anything from a DVD. I have tested on such a wide variety of sources that to upload something for them would just be a waste.

Extract - http://www.mediafire.com/?r4b5qu37zvt41ry
Notice the blockiness in her hair and the sub par quality in the curtain behind her in HandBrake exports. Also notice the lack of such bad features in MPEG Streamclip's output. Note that according to MediaInfo, MPEG Streamclip's files only have 1 reference frame.

To include the QuickTime encoder in HandBrake would systematically make encoding for devices which require baseline profile so much simpler and also vastly reduce the amount of users inquiring about how to get the best quality output for their Apple Devices (the latter is just an example).

If, throughout all your testing, you manage to create settings that will outshine QuickTime, then feel free to post them. Otherwise, if throughout your testing, you do not find a way to outshine QuickTime, then please consider including it as an alternative H.264 encoder in HandBrake. There is excellent documentation on including QuickTime in your applications here, so if you're interested, knock yourself out.

The settings I'm using in MPEG Streamclip, and what I'm trying to replicate in HandBrake are: H.264, Multipass, 1500kbps, 640x480 displayed at 854x480 (no MPEG Streamclip does not do anamorphic, but that's besides the point - set the width as 640).

Yes I do realise that it's an open source project and that the developers only include features if that feature interests them, but what I'm trying to do here is interest you enough so that this can happen. I don't mean to sound condescending at all. Thank you.

I'll take the high road and say that I really don't see this becoming an option since QT is not available on the Linux platform.

A little hypocritical there considering the CoreAudio codec is only available on the Mac platform, but fair enough...

Ah, the difference here being that everybody agrees that faac is bloody awful.

Your sample appears interlaced. So you're also testing the quality of the deinterlacer.

Rodeo wrote:Your sample appears interlaced. So you're also testing the quality of the deinterlacer.

The parts I'm looking at have no movement in them (her hair, the curtain), so that shouldn't be a problem.

Ah, the difference here being that everybody agrees that faac is bloody awful.

and has license issues. So we have to move away from it. Just waiting on an alternative for win/lin


and no, QT encoding will not be added.

So I ran some tests on the samples you provided (this one, and the grain and high motion samples from the other thread).

In order to eliminate the effect of scaling and filters (as well as to work around the fact that QuickTime's MPEG-2 component crops 8 pixels on each side, even if you set zero cropping in Streamclip), I created intermediate lossless encodes of the files (with HandBrake and x264 CRF 0), scaled down to 640x480 (no cropping) and using decomb default.

Notes:
I originally intended to create the intermediate files using Streamclip and x264Encoder, but the two samples from the other thread don't open in Streamclip* (tried the Mac versions 1.9.2, 1.9.3b2, 1.9.3b3, 1.9.3b4).
Also, since x264's lossless mode outputs High 4:4:4 Predictive Profile H.264 (which QuickTime's H.264 decoder doesn't support), you need Perian to open and transcode the intermediate files with Streamclip.

* MD5 checksums for my local copies of the files (downloaded twice): I then re-encoded the intermediate files with Streamclip (1.9.3b4) and HandBrake (svn 3576), leaving the frame size at 640x480 (unscaled) and disabling any filters. For Streamclip I used Export to MPEG-4, H.264, 1500 Kbps average bitrate, Multipass, and B-frames disabled (obviously).

For HandBrake I used the MP4 container, 2-pass 1500 Kbps average bitrate, and the three following combinations of x264 settings:

1: the iPod Legacy presets' x264 options (with weightp=0 for good measure, though in current code disabling bframes turns it off anyway)
(Turbo first pass enabled) 2: x264 defaults, with only the changes required for iPod 5G compatibility (Baseline Profile, 1 ref, vbv settings)
(Turbo first pass enabled) 3: the equivalent of x264's placebo preset modified to be compatible with the iPod 5G
(Turbo first pass disabled)
(forgot no-fast-pskip and rc-lookahead 60, but they only have a minimal effect) Here are my encode times (on a Quad i5 iMac for a queue/batch of the 3 intermediate sources): I'm comparing the QuickTime encode against x264 settings (2) in HandBrake. First, let's look at Grain.mpg (from left to right: x264/HandBrake, Lossless Temp Source, QuickTime):



This is all subjective of course, but both encodes (HandBrake/264 and QuickTime) look comparable. The QuickTime encode looks a bit grainier than the x264 encode (perhaps closer to the source in that respect).

Then, VTS_18_1.m2v (from left to right: x264/HandBrake, Lossless Temp Source, QuickTime):



Again, I'd say all three encodes look comparable, with the source and the QuickTime encodes being grainier.

However, in this case, I find the QuickTime encode to be even grainier than the source, to the point where the patterns on the curtains are less distinguishable. I'm tempted to argue that it's closer to noise than grain retention.

Also, if you look at the logs, you'll notice that the average quantizers for the frames in the x264 encoders are around 12-14, which means the encoder is close to saturated. You could probably reduce the bitrate by 20-30% will minimal quality degradation (it would be interesting to see what QuickTime's encoder gives at said lower birates, though that's not relevant to you particular scenario).

Moreover, the x264 settings I used are all-around settings; if you'd like to retain as much grain as possible, you should use x264's film or grain tunings (add this to your x264 options - trellis must be enabled, and you must be using a recent x264 version supporting CAVLC trellis - the latest nightly build will do):
(film tuning) (grain tuning, much stronger and probably unadvisable for non-grainy sources)

Finally, High Motion.mpg (left is x264/HandBrake, right is QuickTime):











IMO, there's no need to look at the source to see the x264 encodes preserve a lot of detail where QuickTime outputs a blurry and/or blocky mess.

More testing should probably be done but I'm fairly confident in my conclusion: for easy sources where 1500 Kbps is plenty, QuickTime's encoder can match x264's Baseline Profile encodes, with arguably better grain retention (meh). But for more difficult sources where 1500 Kbps is a bit short, x264 trumps QuickTime's H.264 encoder.

You can download the intermediate lossless sources, the screen captures, and the Streamclip/HandBrake encodes (including logs):

Grain.mpg
http://www.mediafire.com/file/2b9a5t3r7 ... ncodes.zip

VTS_18_1.m2v
http://www.mediafire.com/file/216lsaizd ... ncodes.zip

High Motion.mpg
http://www.mediafire.com/file/2u5a66mox ... es.zip.001
http://www.mediafire.com/file/nuw6n4ipk ... es.zip.002
http://www.mediafire.com/file/5bsc576js ... es.zip.003

MD5 checksums:

Rodeo wrote: I'm comparing the QuickTime encode against x264 settings (2) in HandBrake. First, let's look at Grain.mpg (from left to right: x264/HandBrake, Lossless Temp Source, QuickTime):



This is all subjective of course, but both encodes (HandBrake/264 and QuickTime) look comparable. The QuickTime encode looks a bit grainier than the x264 encode (perhaps closer to the source in that respect).

Then, VTS_18_1.m2v (from left to right: x264/HandBrake, Lossless Temp Source, QuickTime):



Again, I'd say all three encodes look comparable, with the source and the QuickTime encodes being grainier.

However, in this case, I find the QuickTime encode to be even grainier than the source, to the point where the patterns on the curtains are less distinguishable. I'm tempted to argue that it's closer to noise than grain retention.

This is pretty interesting. It looks like QT or Streamclip is applying some sort of grain filter or psychovisual optimization which actually adds significantly more grain/noise. The visual effect isn't bad, though inaccurate to the source. Wonder if it's a recent improvement in QT, or a feature that's been around for ages.

Since the quantizers for x264 are saturated, x264 isn't making full use of the bitrate to preserve all grain possible (which is a little disappointing coming from it). Tweaking grain-related options like aq-strength, psy-rd and qcomp will definitely help, but it shouldn't be necessary for such a good encoder...

Rodeo, thank you for your outstanding reply. I'm curious as to why you didn't compare against the modified placebo preset instead of the modified default preset, though. Would it give much better results? Or would you use that purely for the "placebo" effect?

Also it would be good to note that although MPEG Streamclip's output is 1500 kbps average, it can sometimes go way above that. Something that's interesting is that for some QuickTime encodes, like the full episode of the high motion sample, MediaInfo reports a maximum bitrate of 6500 or so. Because of that, I think it would be alright to heighten the vbv-maxrate and vbv-bufsize settings in x264 (or completely remove them? Would removing them be a bad idea?).

And something I think you have cunningly avoided, is the brown-green blocky effect on the girl's hair in the animation sample that Streamclip doesn't seem to produce. Sure, you could say that that's because of the noise effect, but it seems like x264 isn't handling these subtle changes in colour as best as it could.

Also file sizes seem to still be smaller for QuickTime in comparison with modified placebo settings (1.33 MB as opposed to 1.53 MB; this means a considerable difference in output file size in full length movies). Is there anything you can do to further decrease file size? I've tested using umh instead of tesa, and you get considerably smaller file sizes (1.45 MB as opposed to 1.53 MB) and faster encoding time. What exactly about tesa is making the huge jump in file size? Would I be losing quality if I used umh instead of tesa?

LonestarOrison wrote:Also file sizes seem to still be smaller for QuickTime in comparison with modified placebo settings (1.33 MB as opposed to 1.53 MB; this means a considerable difference in output file size in full length movies). Is there anything you can do to further decrease file size?

If you're using Average Bit Rate, then both encoders should provide output of roughly equal size. Whichever deviates further from what you intended it to be isn't doing its job properly. Instead of decreasing file size it should be increasing quality. If you want the file size to be smaller, then decrease the average bit rate.

LonestarOrison wrote:Rodeo, thank you for your outstanding reply. I'm curious as to why you didn't compare against the modified placebo preset instead of the modified default preset, though. Would it give much better results? Or would you use that purely for the "placebo" effect?

Mostly because the output of the medium setting seemed good enough for what I wanted to show.

LonestarOrison wrote:Also it would be good to note that although MPEG Streamclip's output is 1500 kbps average, it can sometimes go way above that. Something that's interesting is that for some QuickTime encodes, like the full episode of the high motion sample, MediaInfo reports a maximum bitrate of 6500 or so. Because of that, I think it would be alright to heighten the vbv-maxrate and vbv-bufsize settings in x264 (or completely remove them? Would removing them be a bad idea?).

These settings may be a bit convervative. You may want to take a look at:

http://forum.handbrake.fr/viewtopic.php?f=7&t=3859

This suggests you could probably change the maxrate to 2500 Kbps, and use 2 reference frames. Maybe getting rid of the vbv settings would actually work for most videos. I don't have an iPod 5G, but I assume you have one, so you can always give it a try.

LonestarOrison wrote:And something I think you have cunningly avoided, is the brown-green blocky effect on the girl's hair in the animation sample that Streamclip doesn't seem to produce. Sure, you could say that that's because of the noise effect, but it seems like x264 isn't handling these subtle changes in colour as best as it could.

I don't think I see it.

LonestarOrison wrote:Also file sizes seem to still be smaller for QuickTime in comparison with modified placebo settings (1.33 MB as opposed to 1.53 MB; this means a considerable difference in output file size in full length movies). Is there anything you can do to further decrease file size? I've tested using umh instead of tesa, and you get considerably smaller file sizes (1.45 MB as opposed to 1.53 MB) and faster encoding time. What exactly about tesa is making the huge jump in file size? Would I be losing quality if I used umh instead of tesa?

There are two issues here:

1) the QuickTime encoder missed the specified target bitrate by about 200 Kbps (which explains why it's smaller).

2) the HandBrake encodes all seem to be within 30 Kbps of the requested bitrate, which explain the slight file size differences.

In either case, I don't think you can assume this will scale linearly to longer encodes - it's just that the source sample is quite short.

x264 on the left, QT on the right...



But, like I said, it could just be considered the noise effect, but like we concluded earlier... it doesn't look bad.

And sorry, can't post an image of the source because I'm on Win without Perian, but you have that on your HD anyway, and the brown/green blocks are non-existent in there.

Also, if it's possible to use QT through HandBrake on Win, then isn't it also possible to use QT's audio codec in HandBrake? Or would that operate in a fundamentally different way that wouldn't allow correct A/V sync or something?

All arguements you've posted aside. I just don' t think you get it. You posted a Feature Request for the Quicktime Encoder and it was rejected. Good , Bad or Otherwise thats how it is right now. Not sure what you're trying to prove.

The images I posted were in response to Rodeo's "I don't think I see it" comment. I'm not arguing anymore, I'm just tying up loose ends.

On a different, unanswered note, would it or would it not be possible to use QT as an audio encoder for Win? I think we can agree here that it beats faac.

I think that CoreAudio is part of Mac OS, not part of QuickTime, so it's unlikely to make it over to Windows.

jamiemlaw wrote:I think that CoreAudio is part of Mac OS, not part of QuickTime, so it's unlikely to make it over to Windows.

No, it's available under Windows too (the audio encoder). But, IIRC, it's more difficult to add it under Windows (and the fact that the Windows builds are built with mingw is not really helping). Not to mention there would need to be a runtime check to make sure QuickTime is installed before encoding.

Ah, I see.

Even if we wanted to add QuickTime h.264 encoder, it would be a waste of time. QuickTime 7 is 32bit only and deprecated. And QuickTime X has got no public api for encoding.

So, no QuickTime for you