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

Support CNX Software - Donate via PayPal or become a Patron on Patreon
Advertisements

7
Leave a Reply

avatar
7 Comment threads
0 Thread replies
0 Followers
 
Most reacted comment
Hottest comment thread
4 Comment authors
hellureConverting H.264 Videos to VP9 In Linux / UbuntuAdobycnxsoftSean Recent comment authors
  Subscribe  
newest oldest most voted
Notify of
Sean
Guest
Sean

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
Guest
Adoby

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 effect, and you feel that it degrade the image. Then reduce the strength of the filtering a little so you don’t notice bad effects of the filtering any more.

After that reduce the output quality you find a setting that is borderline acceptable. Then slightly raise the quality.

You should now have optimal settings for minimal file size and good enough quality for you. This will remove a lot of redundant data so the resulting files should not be processed again, just suitable for viewing and storing unimportant media. Important media should be stored uncompressed, or at least unfiltered with very high quality settings.

The strength of the filtering depends on the input dimensions and quality. This filtering has a huge effect on good compression you can get.
The RF setting needed depends a lot on the dimensions of the output. Typically you need higher RF settings for smaller output dimensions to avoid noticable artifacts.

trackback

[…] the upload size, and going with H.265 codec appeared to be a good idea at first. So I tried again H.265 encoding in Handbrake in Ubuntu 14.04, and discovered that adjusting CRF (constant quality factor) to 25 with H.265 was […]

hellure
Guest
hellure

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 files (h264 & h265), so the speed doesn’t matter for much (yet).

Now all we need is for software and hardware vendors to catch up to the HEVC standard. I assume it’ll take another year. Meanwhile most of my stuff can handle it, so I’m going to adopt a 1080p-x265/720p-x264 strategy, then dump the x264 versions when possible.

Advertisements