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 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:
|
1 2 3 |
sudo apt-add-repository ppa:stebbins/handbrake-releases sudo apt-get update sudo apt-get install handbrake-gtk |
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
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
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.
@Sean
OK. I set Constant Quality with slidebar set to RF:20 for both. (default settings).
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.
@Adoby
It’s been a while, but you’re right that CRF for H.264 and H.265 are not exactly on the same scale.
According to https://trac.ffmpeg.org/wiki/Encode/H.265:
“default CRF of 28. The CRF of 28 should visually correspond to libx264 video at CRF 23, but result in about half the file size”
@cnxsoft
So using a 18 second test video, H.265 RF20 took 44 seconds generating a 17.9MB file, while H.265 RF25 took 28 seconds to generate a 5.0MB file with still decent quality. So adjusting RF will also affect the encoding speed.
For reference, my camera file size was 108.6MB, and H.264 RF 20 would generate a 15.9MB file.
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.