Available HEVC/H.265 test encoders

[hajj_3]

Originally Posted by iwod

I actually expect HM to lose badly. I never actually record, in the time of Mpeg 4 vs Mpeg 2, or H.264 Reference vs Xvid, that a reference encoder actually beat the best of previous generation encoder. So we are off to great start. I just hope they wont create another stupid insanely low quality profile where we are forced to use it. ( Like how iPhone limits to MP ).

The profiles are here: http://en.wikipedia.org/wiki/High_Efficiency_Video_Coding#Profiles

[Kurtnoise]

Originally Posted by iwod

( Like how iPhone limits to MP ).

Sorry but iPhones 3G++ are able to play HP as well...

[Sagittaire]

Originally Posted by Kurtnoise

Sorry but iPhones 3G++ are able to play HP as well...

And MP isn't not so bad for quality ...

[mandarinka]

Hmm, I tested it too (against placebo/psy at SD), and visually it gets beaten rather easily (the fixed hierarchical gop structure seemed to hurt a lot in frame-by-frame comparison). So I guess it will only get interesting once there is an encoder with some sort of psychovisual model (and adaptive bframe placement... or well, rate control).

Edit: Oh, it seems to have some psy AQ, based on --help. (going to try -aqps 1 -aq 1 -d 7 -dqr 7 -dqd 3 but it seems to be *very* slow)

[xooyoozoo]

All the recent news about 4K TVs and whatnot prompted me to start playing around with with the HM encoder (r3172).

Originally Posted by mandarinka

Edit: Oh, it seems to have some psy AQ, based on --help. (going to try -aqps 1 -aq 1 -d 7 -dqr 7 -dqd 3 but it seems to be *very* slow)

Based on some quick tests and reading the manual, increasing -d and -dqr together bumps your encode time exponentially by (2n+1)^2. My encodes at n=2 each were ~25x (28x actual) longer, and I think at n=7, you're looking at minimum 2250% encoding time compared to default.

Anyway, I did some runs with the default random access cfg on the 720p50 parkrun and CIF bus sequences, and the HM encoder seems to create significant PSNR swings between alternating frames like a see-saw. Here's an example snapshot. The colors correspond to YPSNR. However at Q28 HM and matched x264 2pass/placebo/psnr bitrates, the HM had a 0.35 db YPSNR advantage.

-d, -dqr appear to mostly mitigate that, so I did a test of CIF bus at Q32 and [-aqps 1 -aq 1 -d 2 -dqr 2] and matched bitrate with 2pass x264 r2230 [-placebo -tune psnr].

HM:
290.9 kbits
30.78 Y-PSNR

x264:
290.7 kbits
30.05 Y-PSNR

HM's color is slightly off, and x264 is a tiny bit sharper in side-by-side images. However, the monument wall is more detailed in the HM encode and is significantly more pleasing in motion there too. I think I prefer the HM version.

[smok3]

Originally Posted by JEEB

Looking at the JCT-VC mailing list, the version of code available in the HM-9.0-dev branch is currently recommended (unlike its name, it is actually what is going to be version 9.1

would this compile on debian (wheezy) and/or osx?

[JEEB]

Originally Posted by smok3

would this compile on debian (wheezy) and/or osx?

Like JM, HM should as well compile on Linux and similar systems. Although by now you would most probably want to use the branch HM-9.1-dev, which will be 9.2 in the end, as many things broken in 9.1 are fixed there by now.

[D3C0D3R]

I've watch for HM for a long time. Since 1.0 released. Doing some tests.
It slooooow. 400 frames of anime 720x400 ~ 1 hour on my C2D clocked 3.3Ghz. But HM.1.0 earlier carve same clip for 7300 seconds.
Also speed greatly depends from qp. QPs like 22 and lower on my C2D slow as hell - 5 times slower that qp 30-35 (seems like exponential nature of full search alhorithms).

As for me eyes HM starts beats placebo x264 on qps higher than 26-30. It loves very low bitrates due larger size blocks.
Striking me fact that egdes looks really good. Thanks to advanced intra prediction with wide range of angles.
But it wash grain - encodes looks clear. So x264 still better in retention of grain and details even when AQ and psy-rd setted to minimal values.
I didnt use any special tuning for test clips and used default tree GOP structure
Same tree scheme as png in attachment. But my gop is tree that contain 8-bframes.

For a two years of development and nine versions HM become twice faster with comparable (almost same) level of compression.
They trуing different methods and proposals and step-by-step left most useful. Removing slow and/or almost useless in terms of compression features.
I tried different slow settings. But they wont help - gived near-negligible effect and even slightly decrease PNSR on same rate. My test-profile was copy of encoder_randomaccess_he10.cfg. And i recommend do not touch anything there except QP and maybe raising IntraPeriod.

Summary: looks very promising. Speed is comparable to JM. I suppose adding shortcuts and x264 prediction features like Mb-tree and Aq make it invincible.

PS> Decoder surpisingly fast. 1024x400 on my cpu running ~ 25fps (single threaded). So even now i can watch HEVC SD content smoothly.

[mandarinka]

The reason edges look good is at least to some extent in the fact that the grain is washed away as you say. It spends little bits on low-contrast backgrounds (that are almost flat, but not really). It leavs them blurry and without detail, ant thus a lot of bits are "saved", which it then uses on those edges.

So it is a really hard to compare HM with x264, because one doesn't know how effective it would be once it started to care about background/textures/flat areas like x264 does (which costs bits).

[xooyoozoo]

As for me eyes HM starts beats placebo x264 on qps higher than 26-30. It loves very low bitrates due larger size blocks.

I was very impressed with some of the 9.0 anchor bitstreams, especially the Q37 ChinaSpeed. The HUD was almost pristine, and if I wasn't paying attention, I might have thought the game footage was just done in really low graphics settings . I also liked BasketballDrive, which looked pretty great for 1080p50 at 1500kbits!

Wish there was a way to get the HEVC test sequences to compare against x264, though. My google-fu got nothing so far.

[D3C0D3R]

The reason edges look good is at least to some extent in the fact that the grain is washed away as you say. It leavs them blurry and without detail, ant thus a lot of bits are "saved", which it then uses on those edges.

No. Straight-line edges and simple geometrical objects looks cool even when bitrate 2-3 times lower than x264's.
As i told its because advanced intra prediction - 32 angles. Hevc spents 5 bits on it.
Details, grain residual with lowers quants, costs much higher than couple of bits for predict angle.

So it is a really hard to compare HM with x264 because one doesn't know how effective it would be once it started to care about background/textures/flat areas like x264 does

Yep. So metrics is only choise to compare. And PNSR surely not ideal for things like that.

[easyfab]

new branch http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git/shortlog/refs/heads/tags/HM-9.2rc1

RC1 : so are the specifications finalized ?

[JEEB]

Not yet. draft version 10 (for FDIS (stage 50)) is being worked upon. Draft 9 had 13 versions or so, so I still expect a couple of versions of draft 10 to be made

That said, 9.2 should be a nice fix-up compared to 9.1 and even more conformance streams could be created with it most possibly

[D3C0D3R]

>RC1 : so are the specifications finalized ?
Look into history. All versions has dev and RC suffixes.
Looks like it justcode cleanups, bugfixes and minor bitstream corrections. But i cant properly decode 9.0 anchor bitstreams with 9.1.
AFAIK JM had bugfixes, that produce incorrect output, even after AVC standart was finally approved.

[JEEB]

The stream format does change between HM versions, so that's not really a surprise, reference software in general has quite large changes during its development until it has hit the finished spec once (I will guess it will take quite some time for it to fully hit the finished spec even after HEVC version 1 will be officially ratified). An example of a bigger change after 9.2 is this flag positioning change, for example. There was plenty of such changes between 9.0, 9.1 and 9.2.

And as far as the specification goes, it (as in, HEVC version 1) seems to have finally been "finalized" according to a congratulatory Facebook post by a Sony employee, which means that either the current d10 version 5, or one in the close future, will be the one pushed towards the ISO for a FDIS ballot. After the FDIS ballot is initiated, it will go on for two months, after which it will either get approved for publication, or referred back to an earlier stage of standard development.

In related news, the libavcodec HEVC decoder with patches by a VTT guy (probably working at the multimedia section in Oulu) seems to decode my HM 9.1-encoded sample fine (although after ~1700 frames it will go into something by the likes of an eternal loop). With the HM 9.2 support patch it seems to work fine with a sample I created with it as well (with a similar problem occuring during one of the frames). In other words, work seems to be done regarding HEVC decoding in the libavcodec framework.

This is still all intra, so it's mainly for the pleasure of having your HEVC streams played back in a player .

[spawnbsd]

Jeeb, I played a lot with your HM9.1 build, could you compile 9.2 and post it ? I would much appreciate it =).

[JEEB]

Originally Posted by spawnbsd

Jeeb, I played a lot with your HM9.1 build, could you compile 9.2 and post it ? I would much appreciate it =).

hm_9.2_r3282_release built and added (contains the configuration files for that revision as well)

[hajj_3]

do we have any info as to when the final version will be ratified? Wiki says january for the past year or so, anyone in the loop? Would be nice for a proper review of the final version comparing 720x400, 1280x720, 1920x1080 and 4096x2160 with avc and hevc to see how much more efficient it is. There is a review like this (excluding 4k) from around 6 months ago but it would be nice to see how good the final version ends up being.

[JEEB]

Originally Posted by hajj_3

do we have any info as to when the final version will be ratified? Wiki says january for the past year or so, anyone in the loop? Would be nice for a proper review of the final version comparing 720x400, 1280x720, 1920x1080 and 4096x2160 with avc and hevc to see how much more efficient it is. There is a review like this (excluding 4k) from around 6 months ago but it would be nice to see how good the final version ends up being.

OK, it seems like you are talking as if about the specification ('ratification' of something), but at the same time you want to compare efficiency, which on the other hand sounds like you want to compare encoders or so (which we still lack, except for HM or so -- which will most probably still have various changes until it catches up with the specification). Or do you want to compare encoding mechanics defined in the specification and their possibilities, which is a much harder and much more theoretical task?

HM will most probably not match the spec for quite a while I would guess, just like JM had issues years after ratification of the standard. Of course, in this case you actually have a public bug tracker for it, as well as a public repository. So that if you see something that could possibly be a problem it can be reported much more easily.

The specification's main decisions have been taken and final bigger editing is being done as we speak (Version 6 of Draft 10 was just released). After that is finished, the final version of the draft gets registered for an ISO FDIS (Final Draft International Standard) ballot, which will then take two months, after which it is either a Go or a No Go. All things so far lead me to think this will be a Go. After FDIS has been approved, only very minor edits will be possible to make until the specification is publicized.

[easyfab]

Originally Posted by hajj_3

do we have any info as to when the final version will be ratified? Wiki says january for the past year or so, anyone in the loop? Would be nice for a proper review of the final version comparing 720x400, 1280x720, 1920x1080 and 4096x2160 with avc and hevc to see how much more efficient it is. There is a review like this (excluding 4k) from around 6 months ago but it would be nice to see how good the final version ends up being.

It's not a final comparaison but could interest you

Comparison of Compression Performance of HEVC Draft 9 with AVC :

http://phenix.int-evry.fr/jct/doc_end_user/current_document.php?id=7109