HandBrake SVN2829 Snapshot

[HandBrake]

It hasn't been that long since the last snapshot binary, but we've got a number of fixes and enhancements for you. Stability should be improving now, snapshot to snapshot. But, well, that's your job to confirm.

This is a snapshot release of SVN revision 2829. It is not stable code. It is unstable (and undocumented) development code which will one day lead to a stable release of HandBrake 0.9.4. But in order for that process to happen, it needs a lot more bug testing.

Download it now.

When you find broken things in this snapshot--which you will--post a thorough bug report in our bugs forum.

A full change log can be found on the Trac.

Core:

• Libx264 bumped to r1259-dd026f2, bringing with it the magic of macroblock tree rate control (mbtree) and a new CRF curve (meaning you will get different, generally lower bitrates at the same RF, with similar quality metrics). Mbtree is disabled when bframes=0 because of a minor bug with fades between camera shots. Can be enabled even then by explicitly putting mbtree=1 in the x264 option string
• Allow DVD sources with no audio
• Libdvdnav patched to perform read error recovery
• Libdvdread patched to allow raw device access in Windows
• Looks harder for aspect ratio info from DV sources
• Tweaks for packaging tools
• Use "utf-8" instead of "utf8" as the string format identifier for SRT
• Libtheora bumped to r16547

Mac:

• Core audio sampling rate fixes
• Fixed 32-bit compilation in Snow Leopard
• Added 10.5 target for use in 10.6

MacGui:

• Use QTX for live preview
• Fixed EyeTV package scanning

WinGui:

• Cleanup / Improved some of the programs options. (Growl, use m4v, drive detection)
• Numerous fixes in the Picture Settings Panel and CLI Query Handling code.
• Several Fixes in the x264 panel related to 8x8dct
• Numerous Usability tweaks.

LinGui:

• Improved "auto" audio selection
• Use .m4v as the default extension for the MPEG-4 container
• Use .m4v when soft subs are enabled
• Decomb/deinterlace toggle
• Alternate angle encoding fix
• Only strips drive letters for Windows builds
• Show correct audio format info when it's been sanitized for incompatibilities
• Preserve chapter list modifications made to queued jobs
• Fixed error when navigating chapter titles with the keyboard

CLI:

• Allow encoding sources with no audio without explicitly stating -a none
• Removed vestigial references to obsolete codecs and containers

An afterword on project focus
As we've had on our roadmap for quite awhile now, one of our goals for version 0.9.4 is to refocus on HandBrake's key strengths and to remove dead weight. As part of this process, several presets, containers, and a codec have been removed from HandBrake.

* AVI: AVI is a rough beast. It is obsolete. It does not support modern container features like chapters, muxed-in subtitles, variable framerate video, or out of order frame display. Furthermore, HandBrake's AVI muxer is vanilla AVI 1.0 that doesn't even support large files. The code has not been actively maintained since 2005. Keeping it in the library while implementing new features means a very convoluted data pipeline, full of conditionals that make the code more difficult to read/maintain, and make output harder to predict. As such, it is now gone. It is not coming back, and good riddance.

* OGG/OGM: HandBrake's OGM muxer is just as out of date. It hasn't been actively maintained in years either, and it too lacks support for HandBrake's best features. It requires conditionals to work around missing functionality too...only this one gets tested so infrequently the conditionals were never even put in the code, so it just fails when you try to do anything advanced. This one is not coming back either. And yes, we're aware of HTML 5. For patent-free muxing, HandBrake still has Matroska.

* XviD: HandBrake, these days, is almost entirely about H.264 video, aka MPEG-4 Part 10. This makes it rather...superfluous to include two different encoders for an older codec, MPEG-4 Part 2. When choosing between FFmpeg's and XviD's, it came down to a matter of necessity. We need to include libavcodec (FFmpeg) for a bunch of other parts of its API, like decoding. Meanwhile, XviD's build system causes constant grief (it's the most common support query we get about compiling, after x264's requirement of yasm). Since we mainly use MPEG-4 Part 2 for testing/debugging, and recommend only H.264 for high quality encodes, Xvid's undisputed quality edge over FFmpeg's encoder is inconsequential, while FFmpeg's speed edge over XviD is important to us.

* Video game presets: There are no more presets for the PSP, PS3, or Xbox 360. Quite frankly, they didn't work well. None of the development team members own the devices, so testing was minimal and support was nonexistent. Keeping up with the firmware vagaries and ambiguous specifications of these devices was not fun -- we get enough of that from Apple's kit, and those we all have around to test on. The new "Normal" preset should work perfectly fine on any device that supports standard Main Profile H.264 with AAC-LC audio in an MP4 file, which the PS3 and 360 ostensibly do.

[Da Man]

With all of the codecs you've dropped, I don't see how you expect to sell many copies of Handbrake in the future.

[Deleted User 11865]

With all of the codecs you've dropped, I don't see how you expect to sell many copies of Handbrake in the future.

Actually, a brand new AVI muxer (combined with an Xvid encoder with advanced options support) is in the works. It will be released as an add-on for HandBrake around the same time HandBrake for iPhone is released (BTW, did I mention HB for iPhone will only encode 1080p and above?)

[Da Man]

I'm glad someone picked up on this for what it was. I had three ways I could have gone for my 'witty' posting of the week-

a) Grand Central / OpenCL - Been done to death both seriously and as humor. Nothing to mine there.

b) Grid/Distributed computing - Meh. The mood didn't strike me.

c) Handbrake as a profitable venture - After the utterly moronic post by someone last week insinuating that Handbrake devs were somehow slyly cashing in on this thankless endevour, I decided that this was my 'fork' in the road.

And for anyone who truly believes that they somehow profit from this, I cannot even get Dynaflash to meet me in a crowded public place for a free beer, let alone somewhere more secluded where I can take the time to overpower him and pick through his wallet and briefcase for hidden bits of unreleased Handbrake source code (the much-rumored and confidential Handbrake for Pre). And we live in the same city. Well, I'm done for the week. Onward and Upward!!!

[dynaflash]

now *that* is some funny [Censored].

[MikeEckman]

With all of the codecs you've dropped, I don't see how you expect to sell many copies of Handbrake in the future.

I actually went out of my way to register on the site to counteract this post and say THANK YOU to the developers who work on this project. I have used Handbrake to conver over 400 of my legitimately owned DVDs to h.264 format for playback on my media center running XBMC. I tried many different programs before stumbling upon Handbrake and I've been happy ever since. The latest builds have been getting me 60+ FPS encoding on my quad core Phenom 9600 (with the TLB bug and all)! I cannot ask for more! I would gladly pay for a program like this that works well and does what its supposed to!

-Mike

[eddyg]

Thanks Mike. Apprecieted. Da Man was actually being sarcastic though, preemting any negative comments

Cheers Ed.

[tFoG]

I also want to thank you guys for an AMAZING program!

The new build is very nice. I see some options there that I find very interesting (such as the ability to add srt subs (at least I think that is what it will do). I was having a problem converting "Sword of Doom" and "Samurai Rebellion". The first would simply never begin (it would start to do the first pass and then just stop immediately). While the second, oddly enough, would go all the way through but would cut out about a 5 min section that was partially made up of the opening credits and a bit into the film right after the opening credits. So far the new build seems to be working (at least on "Sword of Doom").

Question (and really a question and not a critique in disguise): How come you got rid of the high profile "film" setting and replaced it with simply a "high profile" setting. I used to use the high profile film setting to create files for use with Plex.

Also, is it ok to use "core audio" if you are on 10.5.x? I used to switch from passthrough (I think that was the default audio setting in high profile film) to mp3. Not sure if I was creating more problems but I just figured that mp3 was more compatible and perhaps a smaller file. Anyhow, will core audio sound work in 10.5.x and does it make a smaller file? Just curious.

Again, thanks for all the hard work!!!!!!!!!

[jbrjake]

Question (and really a question and not a critique in disguise): How come you got rid of the high profile "film" setting and replaced it with simply a "high profile" setting. I used to use the high profile film setting to create files for use with Plex.

The different HP presets existed because at the time, they weren't using CRF and the filters weren't mature enough. Since TV, animation, and film require different bitrates, when using a bitrate-based encoding method, they required different presets. Since the filters weren't very mature, I wanted them isolated to just those situations when they were necessary -- animation and TV.

Content-targeted x264 settings will return sometime after 0.9.4, in a different form. The HP preset will remain singular, but users will have the option to adjust the x264 settings of *any* preset on a case by case basis by selecting the sort of content being encoded from a pop-up menu.

[nightstrm]

Also, is it ok to use "core audio" if you are on 10.5.x? I used to switch from passthrough (I think that was the default audio setting in high profile film) to mp3. Not sure if I was creating more problems but I just figured that mp3 was more compatible and perhaps a smaller file. Anyhow, will core audio sound work in 10.5.x and does it make a smaller file? Just curious.

I'd definitely recommend using CoreAudio over faac or mp3... it gives you the ability to use higher bitrates than faac which results in a better sounding downmix from AC3 5.1 to DPL2 (imho). Audio tracks contribute so little to the overall file size that you won't see much of a difference.

[maiki]

Hi--

Thanks for the great app Handbrake!

I downloaded and installed SVN2829, and encoded one DVD with it, and don't have much to comment about it yet, except.....

There is something that surprises me.

The DVD is standard 4:3 AR, DVD standard 720:480 resolution.

In the "Picture" tab, I sent Anamorphic to None. Then i put 640 into the width field, with "Keep Aspect Ratio" checked.

With previous versions of Handbrake, including SVN2773, and most other video programs, that would have put 480 into the height field. After all, 640x480 is 4:3.

However, with this 2829 version, the number in the height field changed to 496, rather than 480, when I entered 640 into the width field.

I encoded the video that way. If i open the encoded video in Mediainfo, it lists the aspect ratio of the encoded film as 1.29. (Whereas 4:3 would be 1.3333 (ad infinitum), correct?

Why the extra 16 pixels in the height, changing slightly the AR?

Feature or bug? Just curious.

Thanks again.

[TedJ]

You sometimes see this when the source has been cropped on the left and right sides of frame to remove overscan, and then you rescale back to full width. I'm guessing that the suggested size you were given when you selected "anamorphic none" was 624x480.

[HandBrake]

Locked.

New snapshot: http://forum.handbrake.fr/viewtopic.php?f=6&t=12464