HEVC – A first look at h.265 video compression

High Efficiency Video Coding (HEVC) is poised to make some big reveals this year with many software developers showing demos of their individual HEVC implementations.  In particular Divx,  MainConcept, and Ateme all have beta HEVC encoders that should be available before the close of  2013 and there are plenty of other companies that have at least put out press releases that they’re working on similar implementations.  There have also been a host of decoders released so far and promises for many more.

HEVC is the successor to the h264 video format and promises similar quality at 50% of the bitrate you would need with h264 video.  Further, HEVC is targeted for high resolution video and should see even greater gains when dealing with 4K video and beyond.  A detailed look at how HEVC works is available here – be prepared for your brain to hurt if you’re a layman like me.

As wonderful as the promises of HEVC may be we still don’t have much software to evaluate at this point, let alone content making use of the new format.  But as I’ve always had an interest in video compression on an abstract level I’ve decided to do a series of articles here looking at what software IS available now, how it performs, and hopefully get an idea of how this new format works.

So to begin with let’s look at the software we can use right now to create and view HEVC video streams.  And if you readers happen to know of any further software that should be added to this list please leave a comment with a link so that we can start to figure out this great new format together.

HM10.1 Reference Encoder


For encoding there is only one solution I’m aware of right now that the average user can get their hands on – the HM10.1 reference encoder.  This is the encoder that was used to proof-of-concept the bitstream and has very little in the way of optimization for speed or quality.  For reference, when the h264 Mpeg4 AVC reference encoder first launched it produced files of worse quality than the leading Mpeg4 ASP encoders of the time such as Xvid.  So you can’t expect this software to show ALL of what HEVC can do, but we can use it to create some initial bitstreams and get an idea of HEVC’s potential.  In particular I’d note that the reference encoder does not have any psychovisual optimizations at this point which has really been the main refinement in h264 video over the past several years.

I’ve uploaded a build of the HM10.1 reference encoder here: http://www.mediafire.com/download/owe7i0hwgn86btb/hm_10.1_r3419_release.7z  This build was pulled from this forum post if you’d like to get it from the source.

Using the reference encoder is a bit tricky as there aren’t many tools to support it at the moment and the configuration settings are not well documented.  I’ll be doing further posts detailing the workflow to make use of the reference encoder in the future.

For Playback we have several options available at the moment.

GPAC Osmo4 Player

HEVC anime in Osmo4

HEVC anime in Osmo4

The Osmo4 player is a standalone video player which supports playback of HEVC streams in the .mp4 container.  Of the test decoders linked here it seems to be the slowest at decoding HEVC video but is the only solution that supports playing HEVC streams from a container.  This means it’s the only player that will let you mux audio with your video if you’d like to have a complete experience with your content.  So overall this is the player I would recommend at the moment and you can grab it here: http://gpac.wp.mines-telecom.fr/player/

Elecard HEVC Player (Alpha)

HEVC anime in the Elecard HEVC Player (Alpha)

HEVC anime in the Elecard HEVC Player (Alpha)

Elecard HEVC player (Alpha) is a standalone player that only supports reading raw .hevc bitstreams.  So you can’t mux audio with your video using this solution, and they plaster a bunch of watermarks on the output so I can’t recommend this software for general use, though it may be useful for testing purposes: http://www.elecard.com/en/technology/researchlab/hevc-player.html

Strongene Lentoid HEVC decoder

HEVC anime with the Strongene Lentoid HEVC decoder

HEVC anime with the Strongene Lentoid HEVC decoder

Strongene Lentoid HEVC decoder is a directshow filter (I think?) that allows you to decode HEVC bitstream files through Windows Media Player.  It’s a bit strange in that it only decodes HEVC bitstream files with the extension .hm10, but you can easily encode examples with TAppEncoder and rename them from out.hevc to out.hm10.  This is probably the best solution as far as performance goes with faster seeking and smoother playback than the other two solutions but again it can’t playback .hevc files muxed with audio.  You can download it at: http://xhevc.com/en/hevc/decoder/download.jsp  You also may want to take a look at their sample video files.

That’s the basic usable software that I’ve found available today.  The other option is that you could compile your own HEVC decoder from OpenHEVC or libav Smarter Fork.  For myself, I never have luck in building such solutions so I can’t test them here.  I will note, however, that the maintainer of lavfilters has stated that lavfilters will support HEVC once libav Smarter Fork makes it into libav Main (which I guess is pretty obvious).  Here’s hoping that happens sooner than later.

So – these are exciting times for armchair video compression hobbyists!  Now that we have some tools to create and view HEVC files, next time we’ll look at actually creating some content.  Until then!

*update* A newer version of the reference encoder has been released.

11 thoughts on “HEVC – A first look at h.265 video compression

  1. Pingback: HEVC – Making your first HEVC bitstream | optavisse

  2. Hello!

    I’m a german student and I work with the HEVC Codec. My task is the use of long gop structures for various video definitions, HD 720p, HD1080p, 2K and 4K. At work with that software many questions have appeared.
    I have carried out some test on sequences which are available in the internet.
    But the results are rather poor in quality. Now I want to ask you if I may missed something oder did something wrong.
    I used a yuv test sequence called “FourPeople.yuv” which is free available on the uni hannvoer website. The frame width is 1280, height 720, framerate 60fps, input bitdepth 8, 600 frames, subsampling 4:2:0 und data size 810Mbyte.

    The parameters that I’ve changed in the configuration file “encoder_lowdelay_main.cfg” are

    IntraPeriod: 8
    GOPSize: 4

    # Type
    Frame1: B
    Frame2: B
    Frame3: B
    Frame4: P

    TargetBitrate: 10000000
    QP: 10

    The parameters in the GOPSize table (POC, QPoffset, QPfactor and so on) I have not changed.
    Was that a mistake? Have these parameters to be varied too? If so, could you help me?

    My current result is that very strong “pixelation” occur when these people move in this sequence.

    Which GOP Size und GOP Lenght (Intra period) the hevc can be realized with. The software means that the GOP size have to be a mulitple of 2.

    I hope that you can help. I’m sorry for the bad english I wrote. Thank you very much!


    • You’re not doing anything wrong by not changing those options in your config file – I changed them in my tests mainly so that they couldn’t be viewed as a separate variable when testing individual features of the encoder. In my tests I’ve found that encoder_lowdelay_main.cfg provides very good output so it’s a good choice for what you’re doing.

      The reason you’re getting poor results in your encode is because you’re using the ratecontrol option in TAppEncoder. I haven’t mentioned it in my posts but ratecontrol is very poor in this release of the HM10.1 such that it will give you very poor results.

      In my tests I found that I could encode a video at a specific QP – QP18 in my case – and get a certain bitrate out. Then I could enable ratecontrol with DOUBLE the bandwidth I used on the original encode and the result would still be much worse as far as PSNR and subjective viewing goes. And it would often undershoot the desired bitrate on top of that.

      If you watch the frames as they’re encoded you’ll note that the encoder tends to first be very conservative with bitrate and then suddenly very wasteful. So in my encodes I’d get something like QP 15 (very good quality), then the encoder panics and realizes it used a lot of bitrate so the next 10 frames are QP 30+ which creates a very jarring difference in visual quality. I would imagine that this is what you’re experiencing because a QP10 encode would create output that is subjectively indistinguishable from the source in most cases.

      I’d recommend not using ratecontrol and just doing a few encodes to try to get near your target bitrate.

      If you’re dead set on using ratecontrol there are a few further options you might want to test, though. From this document the following options may be helpful:

      MaxDeltaQP – Specifies the maximum QP offset at the largest coding unit level for the block-level adaptive QP assignment scheme. In the encoder, each largest coding unit is tested multiple times by using the QP values in the range [ MaxDeltaQP; MaxDeltaQP], and the best QP value is chosen as the QP value of the largest coding unit.

      Maybe this would restrict the QP changes in the file making it more visually consistent? I haven’t tested it, add it to your config file in the ‘Quantization’ section and I’d recommend a value of 1 or 2.

      AdaptiveQpSelection – Specifies whether QP values for non-I frames will be calculated on the fly based on statistics of previously coded frames.

      Again, I haven’t tested this setting but it sounds as though it would let the encoder choose arbitrary QPs for frames without being bound by the target QP + QPoffset settings?

      I’d be interested to hear your results if either of those options are effective. Happy encoding!

      • Thank you for your quick support! I’ll try it in the next few days.
        Did my mistakes have nothing to do with the P-Frame I chosen for the Frame 4?
        I hope my results will be better!

        • I don’t think that using a P-frame will have any great effect on your encode. In my testing when using encoder_lowdelay_main.cfg changing all frames to P-frames resulted in a very minor increase in bitrate and PSNR. encoder_lowdelay_main.cfg doesn’t actually do any bi-directional coding even if you use b-frames so they wind up being treated very similarly.

          If you do your encode again without rate control I’m sure it will come out better, but I’d say that using QP10 is going to give you a huge filesize. Here’s an example of a brief 55 second gameplay clip of World of Warcraft at 1920×1080@30fps, QP 20: http://www.mediafire.com/download/4a6eoy9esg5i3en/wowtest.hevc It weighs in at 8659kbps.

          • Thank you very much for helping me. I encoded my video with these QP and B-Frames parameters and it looks very good.
            Now I have another question. How can I get the information of the videobitrate? My YUVplayer doesn’t show me. Does the HEVC show me this information by using a certain command?
            I searched for it in the internet but I did not find anything to show me the videobitrate of my yuv sequences.
            Is there maybe an option of the software “ffmpeg.exe”? This software I’ve used for changing my BMP-pics to yuv 4:2:0 videos.

          • I don’t know of any specific commands that will give you that information. The only easy ways I know of getting the bitrate are recording it from Tappencoder when the encode finishes or muxing into .mp4 with mp4box and checking the file properties.

            Aside from that you could use any old bitrate calculator to get a ballpark bitrate, though most calculators try to guess container overhead and won’t be completely accurate. For example: http://www.3ivx.com/support/calculator/

            Or just do it longhand – bytes * 8 / runtime / 1000.

    • I’m not sure. The only things I can think of are that you may have a corrupt or improperly formatted hevc file (i.e. using a pre-HM9.0 test encoder) or an outdated version of mp4box before hevc support was added.

      Are you using a current version of mp4box? Does the file play back with other hevc decoders?

      • All software I used is downloaded from your post:


        Installed GPAC from this post, and c/p MP4Box.exe to my test folder. I cut first 359 frames of video with VirtualDub, edited test.cfg (FrameRate : 24, SourceWidth : 640, SourceHeight : 360, FramesToBeEncoded : 359) , remaining parameters left unchanged. From 118MB yuv file, it generated hevc file weighting about 150KB……So can you upload me up-to-dated encoder and mp4box?

        • Hmmm…all the software I linked does work. I’ve redone the linked tests and all seems fine for me. Are you sure your source is 359 frames? Maybe if your source is less than 359 frames but you set the encoder to encode that many it puts garbage at the end of the file which is causing your errors? Or try to cut your source at a multiple of 4 in case it’s causing some sort of GoP error…I frankly don’t know.

          As a side note, you should start using the HM11.0 encoder rather than the HM10.1 – 10.1 streams are not -technically- outputting correct bitstreams because they don’t define a profile level in the config file. Or try out x265 which is faster but offers fewer setup options.

Comments are closed.