Handbrake 0.10 Supports H.265 and VP8 Video Encoding

HandBrake is an open-source video transcoding tool that I use each time I upload a video on YouTube, simply because it will let me crop the beginning or end of a video as needed, can make web optimized videos, has an easy to use user interface, and greatly reduces the size of the video shot with my camera. HandBrake 0.10 has now been released, and it adds H.265 and VP8 encoding support via respectively x265 v1.4 and linbpx, as well as QuickSync video support, but the latter only in Windows. There are also various other changes include OpenCL accelerated scaling.

Handbrake 0.10 Transcoding H.264 to H.265 in Ubuntu 14.04 (Click to Enlarge)
Handbrake 0.10 Transcoding H.264 to H.265 in Ubuntu 14.04 (Click to Enlarge)

Handbrake is available for Windows, Mac OS X, and Ubuntu operating systems. It’s part of Ubuntu repository, but if you want the latest version, and support for MPEG-4 (m4v), you’ll need to install it from a PPA:


I’ve tested with the video I shot yesterday, to see if I could get half size by using H.265 codec instead of H.264. The original video is a 720p QuickTime video using H.264 codec at 25 fps, and that lasts 10 minutes and 20 seconds. I selected the default settings for both H.264 and H.265, as well as “web optimized” MPEG-4 (.m4v) video container. My computer is powered by an AMD FX8350 octa core processor running Ubuntu 14.04. Here are the results.

Original H.264 H.265
Size 1.6 GB 501.5 MB 461.9 MB
Encoding Time N/A 02:40 12:28

The good news is that I get a size reduction with H.265, but by only about 8%, and it take nearly five times longer to encode the video. Since the original video is about 10 minutes long that means H.265 is encoded at less than than real-time. So even if there’s been great progress compared to previous H.265 video encoding tools,  personally, I would not rush to transcode my video library (Handbrake supports batch processing) to H.265 yet, and wait for some more improvement to H.265 support in HandBrake, as the developers stated:

H.265 is now available through x265 1.4. While this encoder is still fairly new, we have seen some promising results come out of it. It’s still under heavy active development and is only going to improve over time!

If you prefer the command line, ffmpeg / avconv also supports H.265 encoding via the same x265 encoder, so performance should be the same.

Via Phoronix

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

ROCK Pi 4C Plus
Subscribe
Notify of
guest
The comment form collects your name, email and content to allow us keep track of the comments placed on the website. Please read and accept our website Terms and Privacy Policy to post a comment.
7 Comments
oldest
newest
Sean
Sean
7 years ago

If you encoded with the same CRF the quality of the x265 one would be of higher quality and lower size than the x264 one.

Adoby
Adoby
7 years ago

Most likely the RF scales are very different. Try to encode a short hight quality clip that is representative of what you usually encode, size and content. For me that would be a short action scene with a lot of switching and moving viewpoints together with a short indoor scene with two fixed cameras on actors and dialogue. 50/50. You will have to do some experimenting and find settings that you subjectively like. For both codecs and for each output size: Using very high output quality, start by filtering away noise and deblocking the video until you notice the filtering… Read more »

hellure
hellure
6 years ago

Handbrake (nightly) currently uses x265 v1.7, and encode times for equivalent settings over Handbrake with x265 v1.5 are pretty dramatically improved. Average Frames Per Second jumped from 15 to 23 (real-time), on my brand new Skylake i5 6600k (stock) system. A Skylake i7 would do even better. FYI, in testing, a higher Constant Quality (25) x265 Medium encode looked better than a lower Constant Quality (27) x264 Very Slow encode, with the same settings where possible, and they now encode at comparably the same average speed (real-time). Unfortunately, all QuickSync tests I completed resulted in absolutely huge and offensively ugly… Read more »

Advertisement