[Rejected] QuickTime Encoder

Archive of historical feature requests.
Please use the GitHub link above to report issues.
Forum rules
*******************************

Please be aware we are now using GitHub for issue tracking and feature requests.

- This forum is now closed to new topics.
- Existing topics will remain open for a short while as the transition over occurs.
*******************************
Post Reply
LonestarOrison
Posts: 46
Joined: Fri Jul 23, 2010 2:17 am

[Rejected] QuickTime Encoder

Post by LonestarOrison » Fri Oct 08, 2010 12:20 pm

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.
Last edited by LonestarOrison on Fri Oct 08, 2010 1:01 pm, edited 1 time in total.

nightstrm
Veteran User
Posts: 1887
Joined: Fri Mar 23, 2007 5:43 am

Re: QuickTime Encoder

Post by nightstrm » Fri Oct 08, 2010 12:25 pm

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.

LonestarOrison
Posts: 46
Joined: Fri Jul 23, 2010 2:17 am

Re: QuickTime Encoder

Post by LonestarOrison » Fri Oct 08, 2010 12:59 pm

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

TedJ
Veteran User
Posts: 5388
Joined: Wed Feb 20, 2008 11:25 pm

Re: QuickTime Encoder

Post by TedJ » Fri Oct 08, 2010 1:14 pm

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

User avatar
Rodeo
HandBrake Team
Posts: 12115
Joined: Tue Mar 03, 2009 8:55 pm

Re: QuickTime Encoder

Post by Rodeo » Fri Oct 08, 2010 2:06 pm

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

LonestarOrison
Posts: 46
Joined: Fri Jul 23, 2010 2:17 am

Re: QuickTime Encoder

Post by LonestarOrison » Fri Oct 08, 2010 10:06 pm

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.

User avatar
s55
HandBrake Team
Posts: 9461
Joined: Sun Dec 24, 2006 1:05 pm

Re: QuickTime Encoder

Post by s55 » Fri Oct 08, 2010 10:11 pm

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.

User avatar
Rodeo
HandBrake Team
Posts: 12115
Joined: Tue Mar 03, 2009 8:55 pm

Re: [Rejected] QuickTime Encoder

Post by Rodeo » Fri Oct 08, 2010 10:15 pm

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

Code: Select all

MD5 (Grain.mpg) = ab21a88f9ab43934d6b93b5b56903b0d
MD5 (High Motion.mpg) = 3088451c416f82c10a7da05d9a4f5c17
MD5 (VTS_18_1.m2v) = eef101c7eecae4af17d99005ca201966
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)

Code: Select all

level=30:bframes=0:cabac=0:ref=1:vbv-maxrate=1500:vbv-bufsize=2000:analyse=all:me=umh:no-fast-pskip=1:psy-rd=0.0,0.00:subq=6:8x8dct=0:trellis=0:weightp=0
2: x264 defaults, with only the changes required for iPod 5G compatibility (Baseline Profile, 1 ref, vbv settings)
(Turbo first pass enabled)

Code: Select all

ref=1:bframes=0:cabac=0:8x8dct=0:weightp=0:vbv-maxrate=1500:vbv-bufsize=2000
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)

Code: Select all

ref=1:bframes=0:cabac=0:8x8dct=0:weightp=0:me=tesa:merange=24:subq=10:analyse=all:trellis=2:vbv-maxrate=1500:vbv-bufsize=2000
Here are my encode times (on a Quad i5 iMac for a queue/batch of the 3 intermediate sources):

Code: Select all

HandBrake: iPod Legacy Modified Medium (2)                    1m37s

HandBrake: iPod Legacy Modified (1)                           1m38s

Streamclip: QuickTimeT H.264 Multipass                        4m45s

HandBrake: iPod Legacy Modified Slowest (3)                   6m06s
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):

Image Image Image

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

Image Image Image

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

Code: Select all

psy-rd=1.0,0.15:deblock=-1,-1
(film tuning)

Code: Select all

aq-strength=0.5:psy-rd=1.0,0.25:deblock=-2,-2:no-dct-decimate=1:qcomp=0.8:deadzone-inter=6:deadzone-intra=6:ipratio=1.1:pbratio=1.1
(grain tuning, much stronger and probably unadvisable for non-grainy sources)

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

Image Image

Image Image

Image Image

Image Image

Image Image

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:

Code: Select all

MD5 (Grain Encodes.zip) = 7b03709ccf2376220cbd30a7e8937acd
MD5 (High Motion Encodes.zip.001) = e4e580ef0c98edbef95edd56f40abcf5
MD5 (High Motion Encodes.zip.002) = 073b0b1e3b9c7ed46007e1dcae55e03b
MD5 (High Motion Encodes.zip.003) = d20ad48435831205a0908110f8aa8dc4
MD5 (High Motion Encodes.zip) = 2696a6f33d0d1f4db11b3440a6060c8a
MD5 (VTS_18_1 Encodes.zip) = 2e985c44588657897a1834e8d1e4831b

creamyhorror
Regular User
Posts: 134
Joined: Mon Jan 04, 2010 2:00 pm

Re: [Rejected] QuickTime Encoder

Post by creamyhorror » Sat Oct 09, 2010 6:53 am

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

Image Image Image

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

Image Image Image

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

LonestarOrison
Posts: 46
Joined: Fri Jul 23, 2010 2:17 am

Re: [Rejected] QuickTime Encoder

Post by LonestarOrison » Sat Oct 09, 2010 9:04 am

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? :P

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?

jamiemlaw
Veteran User
Posts: 536
Joined: Thu Sep 17, 2009 4:52 pm

Re: [Rejected] QuickTime Encoder

Post by jamiemlaw » Sat Oct 09, 2010 4:00 pm

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.

User avatar
Rodeo
HandBrake Team
Posts: 12115
Joined: Tue Mar 03, 2009 8:55 pm

Re: [Rejected] QuickTime Encoder

Post by Rodeo » Sat Oct 09, 2010 5:46 pm

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? :P
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.

LonestarOrison
Posts: 46
Joined: Fri Jul 23, 2010 2:17 am

Re: [Rejected] QuickTime Encoder

Post by LonestarOrison » Sun Oct 10, 2010 4:21 am

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

Image Image

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

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?

dynaflash
Veteran User
Posts: 3820
Joined: Thu Nov 02, 2006 8:19 pm

Re: [Rejected] QuickTime Encoder

Post by dynaflash » Mon Oct 11, 2010 10:47 pm

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.

LonestarOrison
Posts: 46
Joined: Fri Jul 23, 2010 2:17 am

Re: [Rejected] QuickTime Encoder

Post by LonestarOrison » Tue Oct 12, 2010 3:05 am

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.

jamiemlaw
Veteran User
Posts: 536
Joined: Thu Sep 17, 2009 4:52 pm

Re: [Rejected] QuickTime Encoder

Post by jamiemlaw » Tue Oct 12, 2010 8:49 am

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

User avatar
Rodeo
HandBrake Team
Posts: 12115
Joined: Tue Mar 03, 2009 8:55 pm

Re: [Rejected] QuickTime Encoder

Post by Rodeo » Tue Oct 12, 2010 12:44 pm

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.

jamiemlaw
Veteran User
Posts: 536
Joined: Thu Sep 17, 2009 4:52 pm

Re: [Rejected] QuickTime Encoder

Post by jamiemlaw » Tue Oct 12, 2010 1:09 pm

Ah, I see.

User avatar
Ritsuka
HandBrake Team
Posts: 1049
Joined: Fri Jan 12, 2007 11:29 am

Re: [Rejected] QuickTime Encoder

Post by Ritsuka » Thu Oct 14, 2010 9:26 am

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 :P

Post Reply