Now H.264 is the main standard used for video compression, and most devices that can support video playback feature an SoCs capable of H.264 hardware video decoding. Since 2004, however, work has been done to improve H.264, and a new standard called High Efficiency Video Coding (HEVC), also referred to as H.265, will eventually replace H.264, even though this will take a few more years to really gain traction.
HEVC will be able to double the data compression ratio compared to H.264 with the same quality, or improve the quality using the same bitrate, and it can support 8K UHD (Ultra High Definition) with a resolution of 7680×4320 (4320p). This new video codec is a big deal for those who pay for video bandwidth (80% of internet traffic according to Ericsson), and it should also be welcomed by consumers, as it will magically double their storage device capacity, and they may say farewell to buffering messages while watching online videos. I still have to watch YouTube videos @ 360p to get a reasonable experience here…
The High efficiency video coding (HEVC) standard will be ratified in January 2013, but Qualcomm already showcased H.265 decoding on a SnapDragon at MWC 2012, Ericson unveiled the SVP 5500 H.265 Encoder for broadcasters at IBC2012, and a few other companies also announced H.265 solutions.
Fully optimized solutions should be available at the end of 2013, and broad use is bound to take a few more years, as was the case when content moved from MPEG-2 to MPEG-4/H.264. Ericsson uploaded an interesting video about the new standard, explaining why HEVC was being developed, and Jacob Strom (Ericsson Research) compares several images encoded with H.264 and H.265 using the same bitrate, and it clearly shows improved quality with the new codec.
You can read Overview of the High Efficiency Video Coding (HEVC) Standard. (19 pages PDF), If you are interested in the theory and technical details behind HEVC/H.265.
If you are adventurous, Fraunhofer provides reference software capable of encoding and decoding to/from HEVC. The main goal of this software is to provide a tool to experiment by the new codec, and it’s not particularly efficient or speedy, as you’ll discover below. As a user, it is actually a complete waste of time to do that, since, AFAIK, the most used players do not support the standard yet. But let’s go for it anyway.
All information you need is on Fraunhofer’s High Efficiency Video Coding (HEVC) page, but to get started with the software, you just need to download the documentation. I’ll document the steps I’ve followed to encode a short sample of Big Buck Bunny to H.265 in Ubuntu 12.04. You can also build and run the programs in Windows if you prefer.
First, checkout the code, and build the reference software:
svn co https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk
The build should complete within a short time, and you’ll have 8 binaries in ../../bin directory, but we’ll only use 2:
- TAppEncoderStatic – The release version of the H.265 / HEVC encoder
- TAppDecoderStatic – The release version of the H.265 / HEVC decoder
Before we can use the tools, we need a video file in YUV format. If you don’t have one, you can convert any video file (I’ll use big_buck_bunny_480p_H264_AAC_25fps_1800K_short.MP4) to YUV with
ffmpeg avconv (ffmpeg is deprecated, and we should use avconv instead).
First, install the package containing ffmpeg/avconv, if you don’t have it already:
sudo apt-get install libav-tools
Convert the file to YUV, and get the width, height, framerate and number of frames with avconv:
avconv -i big_buck_bunny_480p_H264_AAC_25fps_1800K_short.MP4 big_buck_bunny_480p_25fps_short.yuv
Now let’s encode this yuv file to h.265:
./TAppEncoderStatic -i big_buck_bunny_480p_25fps_short.yuv -wdt 856 -hgt 480 -fr 25 -f 100 -c ../cfg/encoder_intra_main.cfg
- wdt – Indicates the width of the video (avconv reports 854, but since frame width must be a multiple of the minimum CU size, I’ve set it to 856).
- hgt – Indicates the height of the video
- fr – Sets the frame rate
- f – Number of frame
- c – Refers to the config file to be used. You main noticed config file name with “main” and “he10”, those correspond the “main” and “main 10” profiles of the standard, which allows respectively 8-bit and 10-bit color depth (Over one billion colors)
Encoding took 966 seconds with this config file, which corresponds to around 10 seconds per frame on my machine (Intel Core 2 Duo @ 1.8 GHz). The file name is str.bin by default, but if you want to set your own file name add something like “-b big_buck_bunny_480p_HEVC_25fps_short.h265”. I also tried another config (encoder_lowdelay_P_main.cfg) which took 1 hour for 50 frames. So I’d recommend just using a few frames (even just one) for testing. The resulting HEVC file was bigger than the original H.264 file most probably because of different quality settings. There are many settings, and you may have to spend some time to understand them.
Now let’s decode our file back to YUV:
./TAppDecoderStatic -b str.bin -o big_buck_bunny_480p_recontructed.yuv
Decoding was much faster as it just took 12 seconds for 100 frames.
Now let’s check the encoding/decoding process worked properly, by downloading YUV Player and opening big_buck_bunny_480p_recontructed.yuv.
Nice! It works!
There’s also x265 project, an implementation that targets “embedded, FPGA, GPU and MultiCores systems”, but it has recently been suspended due to lack of free time of the developer.
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.
19 Replies to “H.265/HEVC (High Efficiency Video Coding) Status and How-To Encode Videos to H.265”
What about the patent situation?
I don’t really know but one sentence in Wikipedia HEVC entry (http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding) reads as follows:
“On June 26, 2012, the MPEG LA announced that they would start the process of making a joint license for HEVC patents.”
How to select the prediction method weather its intra or inter.
And on what basis we select the prediction method.
I don’t exactly know the answer to your questions. But to find out the different options, you can check the available options by running: ./TAppEncoderStatic, and have a look at the existing config files in cfg directory.
To really understand what you’re doing you’d have to read the standard, or at least the overview I mentioned in the post.
hello, I executed my encoder and it displays the following warning before starting encoding process.. please could any one help. I am a newbie in this field but so much interested.
HM software: Encoder Version [10.0][Linux][GCC 4.7.2][32 bit]
** WARNING: –SEIDecodedPictureHash is now disabled by default. **
** Automatic verification of decoded pictures by a **
** decoder requires this option to be enabled. **
x265: Open-Source H.265/HEVC Video Encoder
you are right about Rockchip with sw decoder
it is nice that quadcore can handle ( 848×360 25fps)
I would like to see cpu load.
I checked libav/ffmpeg for h265 decoder
and current implementation don’t use any NEON instructions
I hope that we will see rockchip contribution to libav 🙂
I just did some benchmarks on ARM cortex-9 dual core 1,5GHz
libav with h265 support from
./avconv -threads 1 -benchmark -i ~/test/Sintel_272p_logo.265 -f null /dev/null
Stream #0.0: Video: hevc, yuv420p, 640×272, 25 fps
frame= 1550 fps= 48 q=0.0 Lsize= 0kB time=62.04 bitrate= 0.0kbits/s
frame= 800 fps= 94 q=0.0 Lsize= 0kB time=32.04 bitrate= 0.0kbits/s
benchmarks with 720p25 content
./avconv -threads 2 -benchmark -i ~/test/surfing.265 -f null /dev/null
frame= 126 fps= 8 q=0.0 Lsize= 0kB time=5.12 bitrate= 0.0kbits/s
than PAL(720×576) should be fine on dual core
Maybe we’ll get 720p support on dual core once NEON support is added.
Actually I fall into your same problem. So may I know if you managed to pass it and if yes, how?
Thank you in advance.
That logo HEVC…….. the text ‘Efficiency’ spelling is all wrong !?!?