Handbrake 0.10.0 released | Hacker News Reader

Handbrake 0.10.0 released

handbrake.fr

184 pointschuckreynolds56 comments

> In addition, we have added the FDK AAC encoder for Windows and Linux as a optional compile-time option.

It's a shame that libfdk-aac is also GPL incompatible. It's hands down the best free AAC encoder, but a version of FFmpeg/libav/Handbrake that's compiled against it is not allowed to be distributed.

would distributing a shell script that automated that install/compile process be legal?

Yes it's called FreeBSD ports :-)

(Not sure if this is an option, but could be easily added)

When I used Handbrake, I always had audio sync issues. I could never figure out what I was doing wrong. That was on Windows. Now that I'm on a Mac, perhaps it'll go better, though I don't have the need to use it much anymore.

I've never had any audio sync problems with Handbrake, then again I've never done anything 'exotic' (basically encode my dvd's to x264+audio passthrough) and everything has worked fine.

Back when you wanted to encode a DVD to the size of one (or maybe two) CDs, having audio-passthrough was not an option. You typically re-encoded the data from 384-448kbps (for AC3-surround) down to 128kbps stereo. For that you used MP3 audio.

I also recall the earlier Frauenhofer MP3 codecs incorrectly reported audible length of chunk-sizes (or something like that) causing incremental audio-skew and sync-issues with the corresponding video the longer into the movie you came.

It seemed impossible to fix and was terribly frustrating.

Eventually the tools caught up and patched up the data, or we got better tools (like lame) which didn't produce the faulty artefacts to begin with.

Maybe this is what he's talking about, as the Frauenhofer MP3-codec was very much a Windows-only thing.

During the last three years I have installed Handbrake twice to convert a just created WMV to H.264/AAC. On both occasions Handbrake just failed to do anything for the file and I ended up uninstalling it. Later I created a kilometer long ffmpeg command line and been happily creating files to be used with Flowplayer. Those files have been playing without any issues on iOS, Android, Windows, Linux and MacOSX.

I wonder why this Windows Live Movie Maker output turned out to be problematic for Handbrake, but on the other hand now I haven't needed to start any video conversion GUI for a long time.

"QSV is only supported on Windows" "libav AAC encoder as the new default for Windows" "HandBrake now offers BiCubic scaling on Windows via OpenCL"

Sad that the Mac doesn't seem to get many of the goodies anymore.

OS X's built-in AAC encoder is the best available, so it doesn't need a replacement.

On the other hand, QSV is entirely outclassed by x264 quality-wise, and I could only recommend it for heat/battery power savings (useful for AirPlay Mirroring, not so much for DVD backups).

It is odd that OpenCL programs wouldn't work, but that can't be much more, uh, work.

I think the addition of NLMeans is interesting, since that filter is so slow I've only ever used it for photo processing.

The OpenCL code works on mac too, but it's not available in th e GUI due to a corner width/height case in which the downscale quality gets hideous. HandBrake has got no active developer working on the OpenCL code anymore, so it will stay as it is until someone comes and fixes it.

While still waiting for Daala I've already started encoding my videos in H.265 separately from handbrake, using mplayer. It's been going very well, H.265 will be awesome once it really starts hitting the mainstream. The bitrates are magically small and x265 is pretty fast. mkv container and Opus audio.

I realise this is subjective but how's the quality of x265? What's the encoding speed like in comparison to x264?

It's good for bitrate starved files, but x264 is actually still more efficient for transparent encodes. x265 currently can't handle noise very well.

x265 is also much slower than x264, but it's getting faster all the time.

>It's good for bitrate starved files, but x264 is actually still more efficient for transparent encodes. x265 currently can't handle noise very well.

Yes this is my impression as well from the tests I've made.

>x265 is also much slower than x264, but it's getting faster all the time.

It will remain slower than x264 though, it uses more cpu consuming algorithms in order to cram out more 'quality per bit', that said it likely has a lot of performance improvements left to do.

>It will remain slower than x264 though, it uses more cpu consuming algorithms in order to cram out more 'quality per bit'

At an abstract level, HEVC is AVC + refinement + new algorithms.

Conforming bitstreams aren't required to use all or even most features, so in the long-term, I don't see why an HEVC encoder can't be a simple, straightforward superset of x264 (i.e. same speed for same quality).

Sure, but the whole point behind x265 is to provide better quality per bit than x264.

By noise, do you mean something like a grain filter? If so, that blows up the size of x264 encodes as well -- enough that people will usually go out of their way to remove said grain to improve the encode.

It's early days for H.265, but it's very promising, both in terms of file size and image quality. For encoding 4K video it seems to be an absolute necessity.

This article has a paragraph about H.265 from the standpoint of a professional photographer: http://www.eoshd.com/2014/11/samsung-nx1-review-glory-techno....

The last time I tried x265, about half a year I was really disappointed. For what I tried (a low bitrate encode with a very slow encode, Hi10p profile for x264) x264 was only slightly worse for the same crf (witch x264 and x265 share) - less than 15% worse, but the encoding time for x264 was practical (on my machine about 2 frames per second) while x265 was simply to slow for real-world use for me (about 0.1 fps). My Computer is somewhat old, but I doubt that newer PCs would to so much better. I can't even image how long it takes to encode 8k.

I ran a test using x264 and x265 just about a month ago. The x265 encoding took about twice as long, and was half the bitrate for the same constant quality setting.

However, since all my playback devices (Fire TV w/ XBMC) rely on H264 hardware decoding, I have to stick with x264.

At times I do need an audio/video converter, and it is always a bit of a pain sifting trough all the dubious and low quality freeware programs. Although Handbrake is not really dubious, last time I tried it wasn't very user friendly or easy either. Anyone know why it seems to be hard to make a nice, easy 'convert arbitrary format to something commonplace' program? And since this gets upvoted, is Handbrake considered the current standard?

Adapter (http://www.macroplant.com/adapter/) could be what you're looking for

You could try just using ffmpeg (depending on your definition of easy). In most instances it will simply be a case of something like

  ffmpeg -i input -c:v libx264 -crf 20 -c:a libfdk_aac output.mkv

I second this, I bet most of those freeware programs are just shitty GUIs around ffmpeg anyway. I doubt the developers of those programs care about GPL violations either.

It has a gui with presets I thought was straightforward and a good cli that can be used with batch files. For free software I think it does a good job, if you want to split hairs the contrast in very dark scenes gets "blotchy".

Handbrake could really use some TLC on the GUI. It's so confusing (at least for me) that I was only using it in CLI mode. This ended up being a good thing : I made a script to only convert at night when electricity is cheaper.

This is very interesting! I'm using AWS elastic transcoder, but this as an AMI could be cool too, any thoughts on going that way?

Love the software.

However, still can't do batch convert on a OS? You can convert a whole folder with a few clicks in the Windows version.

Maybe I don't understand what you want to do, but for at least 3 years I've been able to load a video clip in, set up the settings, add to queue, load video, add to queue, repeat. Then process the whole queue overnight.

You can add the whole folder at once and use that "Add all titles to queue" button.

It can batch convert a whole Folder without having to add individual files and always has been. One of the worst ui choices for it though, there is a well hidden menu item called add all. Took me forever to find it

I found it. Thanks!

there are other more professional software out there for automated workflow. An example of this is: http://www.telestream.net/episode/overview.htm

check out this script by Don Melton: https://github.com/donmelton/video-transcoding-scripts

HandBrake uses HTTPS, but Sourceforge doesn't...great.

https://handbrake.fr/checksums.php

This ~prevents people from modifying the binary that you download, but doesn't prevent them from knowing that you downloaded it.

Going to the Handbrake site is a good clue (plus seeing a stream of a few MBs), and HTTPS doesn't protect them from knowing that, since they need to be the only site on that IP and/or use SNI, which sends the hostname in plaintext.

You realize that HTTPS doesn't hide what sites you visit, of course?

But it hides the HTTP request itself - Sourceforge hosts thousands of different projects, if served over HTTPS it'd be considerably harder to tell which download had been requested.

I'm pretty sure an HTTPS GET request to http[s]://iweb.dl.sourceforge.net/project/handbrake/0.10.0/HandBrake-0.10.0-MacOSX.6_GUI_x86_64.dmg would be pretty easy to identify as a HandBrake download. The resource requested is not hidden.

> The resource requested is not hidden.

Your GET request, and the server's reply, is encrypted.

The hostname of your request might leak in SNI, or if your DNS lookup was insecure.

It is also plausible that an eavesdropper could make a solid guess as to what you downloaded by counting bytes, but that's obviously not worth much.

The hostname of your request might leak in SNI, or if your DNS lookup was insecure.

You don't need a DNS leak; if you aren't using SNI, the server(s) replying on that IP can only serve a single cert, so the snooper can usually find out the hostname by simply connecting to it and seeing what it gets.

The exception is if the site is behind something like Cloudflare, which stuff dozens or hundreds of hostnames in a single cert.

You clearly don't understand how HTTPS works.

HTTPS works by first creating a TLS connection, then sending the HTTP request and response through it. Thus, the request (including the path) is encrypted.

That's a common misconception and it's quite easy to fall for. Please read http://www.moserware.com/2009/06/first-few-milliseconds-of-h...

Good read, thanks.

Thanks for the clarification everyone.

It's interesting that this a concern, as this is a greater level of privacy than what we've enjoyed anywhere else. I'm thinking in real world contexts.

Hey guys, someone has a good list of presets to share?

You'll have to spend a great deal of time to beat the presets already used by Handbrake/x264, and you'll only be able to do it on a particular clip. There's a good article[1] on the presets and how they impact quality, which lead me to using slow or slower for pretty much everything.

[1] http://www.videoquality.pl/preset-settings-x264-quality-comp...

VidCoder > Handbrake

"VidCoder is a DVD/Blu-ray ripping and video transcoding application for Windows. It uses HandBrake as its encoding engine." -- 1st sentence on VidCoder's site

I think you mean VidCoder has a better interface for HandBrake on Windows then HandBrake? I haven't had any problems w/ HandBrake's UI on Windows, but I keep it pretty simple so maybe if you want to do more complex things VidCoder is better.

Still no opus?

XMedia Recode [1] can do all this as well. Looks quite similar as well, by the way.

But of course, it's not open-source, while Handbrake is.

[1] http://en.wikipedia.org/wiki/XMedia_Recode

Experts estimate that there are approximately millions [0] of AV converters around. At least, in my experience.

[0] not really

Reply on news.ycombinator.com