Available HEVC/H.265 test encoders [Archive]

JEEB

30th November 2012, 14:29

I would probably say that the only working'ish implementation at this time is HM, the reference encoder/decoder package. The "x265" project (not really having that much in common with x264) doesn't look like something usable, and prunedtree's encoder was in its very beginnings (not to mention that he has been without internet for some time now because of moving from one continent to another).

Looking at the JCT-VC mailing list, the version of code available in the HM-9.0-dev (http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git/shortlog/refs/heads/HM-9.0-dev) branch is currently recommended (unlike its name, it is actually what is going to be version 9.1).

Also from the mailing list, the currently known bugs in this version of HM are:
...
ticket 845 (http://hevc.kw.bbc.co.uk/trac/ticket/845) (SAO and multiple slices)

ticket 700 (http://hevc.kw.bbc.co.uk/trac/ticket/700) (weighted prediction in Main 10)
Could someone other than the bug reporter have a look at this?

ticket 530 (http://hevc.kw.bbc.co.uk/trac/ticket/530) (deblocking filter and chroma QP offsets)
Not sure whether this still applies after recent changes to the spec.
...

I've been meaning to test out HM at some point, but it has mostly stopped around the fact that GOPs' frame type structure has to be static (at least it looks like that in the configuration files), which would mean that the structure would have to be optimized for every clip -- and that I never got an idea on what features currently mismatch and which don't :V . Oh, and I never got to reading too much of the documentation available, but that I should be able to do soon'ish at least.

If anyone has done any extra testing, I'd be happy to hear about it as well.

mp3dom

30th November 2012, 21:18

There is also the MainConcept implementation that should be available in (early) 2013.

Parabola

3rd December 2012, 23:03

My curiousity has gotten too high, and I want to make some HEVC / H.265 test clips. I'm well aware that there's not any production-caliber implementation yet, but I'd like to try the best of what I could get my hands on.

Anyone done any testing that can make any suggestions? There's always compiling the reference encoder, of course.

Hi Ben,

Last summer I ran a test similar to the following:

Download the HEVC anchor bitstreams, e.g. from ftp://ftp.kw.bbc.co.uk/hevc/hm-9.0-anchors/ This means you don't have to run the HM encoder which takes a LONG time.

Decode the bitstreams to YUV using HM decoder

Download the corresponding uncompressed raw sources (sorry don't have link to hand but someone on jct-vc mail list should be able to help you)

Configure x264 with same GOP pattern and similar Qp offsets as used in the anchors. Batch a whole load of constant Qp encodes on some insane performance setting. Go to bed.

Plot PSNR vs log(bpp)... see the goodness of HEVC

Pick out those x264 bitstreams from your batched set that have similar sizes as the corresponding anchor bitstreams. Use AviSynth to set up side-by-side or butterfly comparisions.... see the goodness of HEVC.

This persuaded me that HEVC really had legs and was worth investing more time and money.

-John

JEEB

4th December 2012, 13:40

HM 9.1 has been released.
With respect to 9.0, it contains mostly high-level syntax modifications, bug fixes, and a new rate-control algorithm.

Version 9.1 is expected to produce the same R-D performance as 9.0 under common test conditions.

There are still a few things missing in the high-level syntax (such as SEIs) and a few bugs (related to cases that are not commonly tested). We expect to have this fixed in the coming few weeks.

Nevertheless version 9.1 should be complete enough to start the exercise of generating conformance bitstreams.

The last sentence certainly got me quite interested, and thus I embarked on my first tryout of using HM. After converting the VC9 solution for VC10 and compiling the applications (TAppDecoder, TAppEncoder), I was greeted with quite the help message.

After first trying to set settings manually, and being greeted by weird errors ("-f Number of frames to be encoded (default=all)", yet it has to be set) and/or division by zero errors due to my settings (minCuSize ending up as zero and so forth), I just ended up trying with the pre-made encoder_intra_main.cfg configuration file as the base, and actually got it to encode.
TAppEncoder.exe -c /cygwin/projects/jctvc-hm/cfg/encoder_intra_main.cfg -i zeroma.yuv -fr 24 -wdt 320 -hgt 180 -f 2155 --CroppingMode 1
(it does warning out with "Unhandled argument ignored: `1'" at the end, but otherwise seems to work --
although CroppingMode 1 seems to have been parsed just fine)
Not that this is much useful, but at least I have some material now to test smarter's libavcodec decoder with (it is intra-only).

Edit: Seems like smarter's libavcodec WIP decoder only supported stuff up until HM 8.2, so that was completely a no-go. That said, a French team of students he has been in contact with seem to have made (https://github.com/OpenHEVC/libav/tree/hm9.0) it at least somewhat HM 9.0 compatible, with work being made to make it more capable overall. This version seems to actually be able to decode some of the intra frames in my stream correctly. This is quite nice, even at such an early stage :)

benwaggoner

4th December 2012, 19:51

HM 9.1 has been released.
Yea!

Is there anywhere to get a binary for Windows (32 or 64-bit) for the Visual Studio impaired?

I spent two years as a maintainence engineer on banking software, and the experience was so scarring I've not been able to write a line of code since 1995 :)...

JEEB

4th December 2012, 20:46

Yea!

Is there anywhere to get a binary for Windows (32 or 64-bit) for the Visual Studio impaired?

I spent two years as a maintainence engineer on banking software, and the experience was so scarring I've not been able to write a line of code since 1995 :)...
Here (http://x264.fushizen.eu/builds/hevc-hm/hm_9.1_r3119_debug.7z)'re the 32bit debug binaries I made with VS2010, and here (http://x264.fushizen.eu/builds/hevc-hm/hm_9.1_r3119_release.7z) are 32bit release binaries.

This way you can basically watch out for possible miscompilations, as well as have the debug symbols useful enough in case anything crashing happens :)

Not like HM is supposed to be fast, anyways (5h+ on my C2D Penryn for 2155 frames' worth of 320x180).

sneaker_ger

4th December 2012, 20:59

Let's hope HEVC will be great at reasonable speeds, too.

benwaggoner

4th December 2012, 21:11

Let's hope HEVC will be great at reasonable speeds, too.

Vanguard announced a realtime 1080p HEVC encoder at IBC that sounds quite promising.

Given the improved tools, I think HEVC should be able to provide better quality at the same encoding time as H.264. A fully-tuned encode might be slower in HEVC, however, as there are more different ways to do things. Also, the decoder is somewhat slower, and that'd be part of the refinement loop in a high-quality encoder.

So, I'd think that quality @ time will be substantially better in HEVC. But a placebo mode would likely be slower than in H.264.

Of course, implementations and tuning make a HUGE different here. I'm sure there will be some HEVC encoders that'll be worse than some H.264 encoders for particular scenarios.

Parabola

5th December 2012, 11:52

Here (http://fushizen.eu/builds/hevc-hm/hm_9.1_r3119_debug.7z)'re the 32bit debug binaries I made with VS2010.

You really don't want to mess with the debug builds if you're encoding. Unless you already have them handy, jeeb, I will build release config of HM 9.1 and PM Ben with URL.

JEEB

5th December 2012, 12:27

You really don't want to mess with the debug builds if you're encoding. Unless you already have them handy, jeeb, I will build release config of HM 9.1 and PM Ben with URL.
Why not? In general, it a) was not /too/ slow b) Makes sure that compiler optimizations do not break anything c) has debugging symbols (although PDB files are a big thing with MSVC)

In other words, it's not really bad -- and if I recall correctly the configuration for HM should not depend on the shared debug CRT (I did check with dependency walker but I might have missed something).

Of course, if someone actually asked for a release build, I was naturally ready to build one as well. I guess I'll compile one and up to fushizen when I get to a workstation with Windows (or home).

Edit: Added release builds into my previous post as they were indeed requested

easyfab

9th December 2012, 11:32

I think HEVC looks promising, here my little test on foreman_cif.yuv clip

- HM9.1 (build commit a0da0c21f34b05bda60e406f991a76b599876a68 ):

TAppEncoder.exe -c encoder_randomaccess_main.cfg -q 26 -fr 30 -wdt 352 -hgt 288 -f 300 -i foreman_cif.yuv -b hevc.bin

hevc.bin : 369 ko

- X264 (2216)

X264 --tune psnr --crf 26.7 --preset placebo

X264.mkv : 370 ko

psnr with MSU Video Quality Measurement Tool :

HEVC : AVG: 37.57242
X264 : AVG: 36.87016

Not bad for HEVC but not 50% better and X264 encode need ~10 sec and HM9.1 746 sec

easyfab

9th December 2012, 11:40

And with x264 --tune psnr --preset medium --crf 28.1 : x264.mkv 366 ko
psnr 35.86

mandarinka

12th December 2012, 14:19

Kurtnoise

12th December 2012, 14:33

Why comparing with x264 ? Just use the H.264 reference encoder, like the HEVC one...

Sagittaire

12th December 2012, 16:25

Why comparing with x264 ? Just use the H.264 reference encoder, like the HEVC one...

Well it's better to compare with x264 ... simply because x264 is best H264 implementation in the area actually for PSNR. Sound promising for HEVC ... ;-)

benwaggoner

12th December 2012, 19:28

And I'd expect HEVC's advantages to improve as frame size goes up. Those big transforms are doing to do a lot more for 1080p and beyond than for 352x288, which is what H.264 Baseline and Main were originally tuned for.

It would be great if someone has the time to try one of those 2160p test sequences :). That'd be a LOOONG encode.

schweinsz

13th December 2012, 10:37

Well it's better to compare with x264 ... simply because x264 is best H264 implementation in the area actually for PSNR. Sound promising for HEVC ... ;-)

To the best of my knowledge, there is the comparison (http://http://infoscience.epfl.ch/record/168259/files/article.pdf) among the VP8, x264 and the HEVC reference software HM x.0 version, it show that the HEVC reference software is better than the x264.

Sagittaire

13th December 2012, 20:33

To the best of my knowledge, there is the comparison (http://http://infoscience.epfl.ch/record/168259/files/article.pdf) among the VP8, x264 and the HEVC reference software HM x.0 version, it show that the HEVC reference software is better than the x264.

certainely ... I say only that x264 is the best H264 implementation in the area for PSNR ... lol

iwod

14th December 2012, 11:53

0.8db PSNR is actually a huge difference (ignoring the fact that it might not be a suitable metric for comparing two different formats). Note that HM isn't a top-notch sophisticated encoder like x264 (not to mention placebo setting). Lots of people would actually expect x264 to win here, given that - despite the h.264 format itself being inferior.

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 ).

hajj_3

14th December 2012, 12:11

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

14th December 2012, 14:34

( Like how iPhone limits to MP ).
Sorry but iPhones 3G++ are able to play HP as well...

Sagittaire

14th December 2012, 20:10

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

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

mandarinka

16th December 2012, 13:51

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

9th January 2013, 22:27

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

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. :D

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 (http://i.imgur.com/d8Me9.png). 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 (http://media.xiph.org/video/derf/y4m/bus_cif.y4m) 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

10th January 2013, 08:53

Looking at the JCT-VC mailing list, the version of code available in the HM-9.0-dev (http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git/shortlog/refs/heads/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

10th January 2013, 10:47

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 (http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git/shortlog/refs/heads/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

10th January 2013, 16:34

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

10th January 2013, 18:20

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

10th January 2013, 20:54

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 (ftp://ftp.kw.bbc.co.uk/hevc/hm-9.0-anchors/bitstreams/ra_he10/), 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

14th January 2013, 17:52

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

19th January 2013, 20:53

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

19th January 2013, 21:24

Not yet. draft version 10 (for FDIS (http://www.iso.org/iso/home/standards_development/resources-for-technical-work/stages_table.htm#s50) (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

23rd January 2013, 21:05

>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

23rd January 2013, 21:39

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 (http://hevc.kw.bbc.co.uk/git/w/jctvc-hm.git/commitdiff/86033a7db1286e3f7b4d6d6b74f1056ed0be0a72), 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

23rd January 2013, 22:58

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

JEEB

23rd January 2013, 23:56

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 (http://x264.fushizen.eu/builds/hevc-hm/hm_9.2_r3282_release.7z) built and added (contains the configuration files for that revision as well) :)

hajj_3

24th January 2013, 01:16

JEEB

24th January 2013, 12:34

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

24th January 2013, 16:19

xooyoozoo

24th January 2013, 20:36

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.

I don't know much about the the JCT's most recent meeting, but in the past, I've noticed that it sometimes took a couple months for changes adopted at a meeting to make their way into the repository.

I've also noticed in the draft text that they added grain flags as an option for the bitstream and that those flags also existed in AVC. Anyone know if there were ever any h264 products that took advantage of those flags? It seems that almost all of AVC's growing pains in the marketplace (plasticky encodes) would have been alleviated with some smart decoding action.

D3C0D3R

25th January 2013, 16:04

Anyone know if there were ever any h264 products that took advantage of those flags?
No. IIRC DarkShikary sayed that it useless. I suppose better to encode clean or filtred source and when playing add deband/grain filters on your taste.

Edit:
http://wiki.videolan.org/SoC_x264_2008
An integral part of the standard... but supported by basically nothing despite its potential usefulness.

paradoxical

25th January 2013, 16:06

Your quote doesn't really back up what you claim. It says "despite it's potential usefulness". If it was "useless" it wouldn't have "potential usefulness".

phate89

25th January 2013, 16:08

No. IIRC DarkShikary says that it useless.

http://wiki.videolan.org/SoC_x264_2008

He doesn't says it's useless. He says that it's potentially useful but not supported.

D3C0D3R

25th January 2013, 16:15

Your quote doesn't really back up what you claim. It says "despite it's potential usefulness". If it was "useless" it wouldn't have "potential usefulness".
Sorry. I didnt found better quote. But i've seen post explaining things like that added rather on behalf of patent holders.

paradoxical

25th January 2013, 16:16

Sorry. I didnt found better quote. But i've seen post explaining things like that added rather on behalf of patent holders.

Yes, that is a bad quote. It says the opposite of your claim. Also:

Film Grain Modelling is a great idea but nearly nobody has implemented it (not even JM), so there's very little to go off of. We'd basically be starting from nothing, and we'd need to implement it in libavcodec too.

Now it's more than possible he's changed his mind since then, but I've found nothing from him through searching that has him saying it's useless.

JEEB

25th January 2013, 17:13

FGM wasn't useless indeed, but its implementation was so limited it was generally very hard to implement it and see if it worked at all. Now-dead HD-DVD did contain support for it, but I'm not sure if any discs actually used it, or if any decoders bundled with HD-DVD players supported it.

JM not supporting it was also a large thing against it, as it often is used to test an implementation. The fact that JM was broken with lossless encoding for ages (the newer thing in High 4:4:4 Profile), and the fact that the specification was (not on purpose) readable in a way that was not meant by the creators of the specification, were the reasons that led to the lossless encoding mode of x264 to be out-of-spec. It still is, and nothing will be done about it because everything else that implements it (libavcodec, CoreAVC etc.) implements it in the way that x264 implemented it (I think it was either in 2010 or 2011 that someone actually found out about the difference in implementation compared to the specification).

Kurtnoise

26th January 2013, 07:11

ITU has approved this codec (http://www.itu.int/net/pressoffice/press_releases/2013/01.aspx#.UQNyyr-zJ8E)...

Companies including ATEME, Broadcom, Cyberlink, Ericsson, Fraunhofer HHI, Mitsubishi and NHK have already showcased implementations of HEVC. The new standard includes a ‘Main’ profile that supports 8-bit 4:2:0 video, a ‘Main 10’ profile with 10-bit support, and a ‘Main Still Picture’ profile for still image coding that employs the same coding tools as a video ‘intra’ picture.

The ITU/ISO/IEC Joint Collaborative Team on Video Coding (JCT-VC) (formerly JVT) will continue work on a range of extensions to HEVC, including support for 12-bit video as well as 4:2:2 and 4:4:4 chroma formats. Another important element of this work will be the progression of HEVC towards scalable video coding. The three bodies will also work within the Joint Collaborative Team on 3D-Video (JCT-3V) on the extension of HEVC towards stereoscopic and 3D video coding.

iwod

26th January 2013, 11:54

What are the use case for 10bit support? Doesn't x264 currently does internal 10bit encoding?

I really hope the Still Picture takes off. I have enough of Jpeg.

I hope there is an x265.

JEEB

26th January 2013, 12:23

ITU has approved this codec (http://www.itu.int/net/pressoffice/press_releases/2013/01.aspx#.UQNyyr-zJ8E)...
Yeah, I just read this as I woke up. And here I thought they'd only decide after it was officially ratified (after the FDIS ballot). I guess not. This just means that I can't tell people not to call it H.265 any more, as it now (finally) is officially set to that number :) (it used to be called ITU-T H.HEVC before).

SeeMoreDigital

26th January 2013, 12:34

ITU has approved this codec (http://www.itu.int/net/pressoffice/press_releases/2013/01.aspx#.UQNyyr-zJ8E)...
That's great news... I wonder how quickly we'll see hardware decoding (and encoding) support?

Limit64

26th January 2013, 13:08

According to Golem.de (http://www.golem.de/news/hevc-itu-gibt-videostandard-h-265-frei-1301-97168.html) devices with Broadcoms HEVC decoder chip are planed for mid 2014.

hajj_3

26th January 2013, 17:56

Nearly ratified then :) Lets hope that nvidia and AMD add decoding support into the programmable areas of their gpus like they did with h264 before they created dedicated silicon in their gpu's for h.264. I reckon intel will probably have dedicated silicon in their chips within 18 months as they have a lot of cash to throw at it.

Now someone go do an in-depth test on how good it's compression is at 720x400, 1280x720, 1920x1080 :)

Limit64

26th January 2013, 18:24

Before you can run useful tests you need a good implementation for the new codec. Perhaps x264 will be extended to support the new codec.

Kurtnoise

28th January 2013, 10:13

Looks like x265 project (not related to x264 though) has been updated few days ago (http://code.google.com/p/x265/downloads/list)...

--- Status ---
The final version is 201209, these source will upload at Q3 2013.
The latest source is 201206.

Currently, the project is suspend.

I will working on my commercial version(GPU based) late, and I will come back after the Chinese New Year of 2013.
My attempt of GPU Intra failed, the NVidia Kepler GPU switch so slower, I will continue try it.

Excuse me, I am busy now, so the executeable is up to date, but the source have delay released about 6-9 months.
The SDK will upload after HM-N.0 has released, the latest SDK match to HM-9.0

I am wait a week, but there are no HM-9.2, so I sync to HM-9.2rc1

The code is develop on my x86 platform.
The x64 platform is not office support now
If you use the x64 system, please change UInt32 and Int32 from "int" to "long" in file config.h by youself.

I will decide next year's whereabouts during January, I have no more time to wasting.
I guess it comes down to a simple choice: Get busy living, or get busy dying.

Last Update: 26th Jan, 2013

edison

28th January 2013, 10:32

hm_9.2_r3282_release (http://x264.fushizen.eu/builds/hevc-hm/hm_9.2_r3282_release.7z) built and added (contains the configuration files for that revision as well) :)

The TAppDecoder.exe does not work to me. I did tried it on Win8/Win7 x64 .

hm_9.2_r3282_release>TAppDecoder.exe -b ChinaSpeed_1024x768_30_qp37.bi
n -o 123.yuv

HM software: Decoder Version [9.2rc1][Windows][VS 1600][32 bit]
Assertion failed: uiCode == 3, file ..\..\source\Lib\TLibDecoder\TDecCAVLC.cpp,
line 657

JEEB

28th January 2013, 14:12

The TAppDecoder.exe does not work to me. I did tried it on Win8/Win7 x64 .
WorksForMe with a HM 9.2-encoded stream.

TAppDecoder.exe -b zeroma_HM9.2.hevc -o zeroma_HM9.2.yuv

HM software: Decoder Version [9.2rc1][Windows][VS 1600][32 bit]
TDecCavlc::parsePPS(): m_bUseWeightPred=0 m_uiBiPredIdc=0

POC 0 TId: 0 ( I-SLICE, QP 20 ) [DT 0.006] [L0 ] [L1 ] [:,,,(unk)]
...

xooyoozoo

28th January 2013, 20:46

The TAppDecoder.exe does not work to me. I did tried it on Win8/Win7 x64 .

hm_9.2_r3282_release>TAppDecoder.exe -b ChinaSpeed_1024x768_30_qp37.bi
n -o 123.yuv

HM software: Decoder Version [9.2rc1][Windows][VS 1600][32 bit]
Assertion failed: uiCode == 3, file ..\..\source\Lib\TLibDecoder\TDecCAVLC.cpp,
line 657

You have to match the decoder revision with whatever was used to encode the bitstream.

Kurtnoise

29th January 2013, 13:57

Except the reference decoder and the libav experimental branch, is there a free decoder available yet ?

JEEB

29th January 2013, 19:41

No idea about exact details, but smarter did note that the OpenHEVC (https://github.com/OpenHEVC) folk were also making their own decoder, and using HM + smarter's decoder to test results against.

...
< JEEB> openhevc
< JEEB> some french project of some uni
<@BBB> they're doing an encoder?
< JEEB> they're just using HM as far as I can see
< JEEB> using it as a lib
<@BBB> so what are they using his code for then?
< JEEB> they're using it as the decoder it seems
<@BBB> maybe hm is too slow
< smarter> nop, they're doing a decoder for http://orcc.sourceforge.net/
...

sl1pkn07

29th January 2013, 21:24

hi

im build on my linux

588K ene 29 21:04 TAppDecoderStatic
3,3M ene 29 21:04 TAppDecoderStaticd
1023K ene 29 21:04 TAppEncoderStatic
4,5M ene 29 21:04 TAppEncoderStaticd
26K ene 29 21:04 annexBbytecountStatic
95K ene 29 21:04 annexBbytecountStaticd
89K ene 29 21:04 convert_NtoMbit_YCbCrStatic
398K ene 29 21:04 convert_NtoMbit_YCbCrStaticd

what is need and what diference between "d" and without "d"?

and "found" this:

http://hevc.info/
svn -> https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/trunk

its different branch?

greetings

paradoxical

29th January 2013, 21:32

With "d" means debug build. Without "d" means release build.

JEEB

29th January 2013, 21:32

TAppDecoder is the decoder, and TAppEncoder is the encoder, annexBbytecount seems to be some test app and convert_NtoMbit_YCbCr helps you convert raw YCbCr streams' bit depths it seems. You will mostly need the encoder and decoder I would guess.

I would guess the ones with a 'd' are debug binaries, and the static at the end means they've been statically linked as opposed to shared linking.

That SVN repository should be the same thing, also hosted over at the BBC, as well as having a git mirror over at the BBC. I felt that the git mirror was simplest to use, so I picked it :)

sl1pkn07

29th January 2013, 21:59

oks, thanks for all guys (the static is obious XD, but with D have doubts)

mandarinka

30th January 2013, 01:12

BTW I noticed that DivX announced they will be jumping on H.265 too, apparently they will have some transcoding application (based on Mainconcept) and likely decoder too. No idea when they plan to release, if it is soon, it might be useful for some time before FOSS land reacts :)

xooyoozoo

31st January 2013, 03:31

Took some time, but finally started trying to build this ( http://i.imgur.com/MQhJgT2.png ) up using the HEVC bitstreams as reference points. I haven't gotten around to all the encodes yet, but I doubt the comparative numbers would change much beyond what you see now. You can read the cells in light green as "HEVC will reduce bitrate by [x]", and their story is fairly similar to all the "official" HEVC-AVC comparisons seen so far. (Edit: I assume that 8bit x264 would 5-10% worse? Anyone know?)

I thought about doing a SSIM comparison too, but I don't think that would tell us much other than that reference encoders are really naive (Edit: HEVC actually gets higher SSIM; I just haven't charted it), which is entirely par for the course.

The spreadsheet with its underlying equations were shameless copied from the JCT-VC docs site, btw.

Last edit: Looking at published results, PSNR difference between reference h264 encoder and x264 High10 veryslow|tune-psnr is irrelevantly small. No more of this "it's just the JM" business. ;)

edison

2nd February 2013, 09:46

Took some time, but finally started trying to build this ( http://i.imgur.com/MQhJgT2.png ) up using the HEVC bitstreams as reference points.

hmm, can you tell me how to measure the PSNR (maybe SSIM too) when the origin file is 8-bit and the encoded file is 10bit ?

xooyoozoo

2nd February 2013, 21:54

hmm, can you tell me how to measure the PSNR (maybe SSIM too) when the origin file is 8-bit and the encoded file is 10bit ?

The PSNR is reported by the encoder?

Beyond that, I'd argue "downsampling" to 8bit creates a strictly accurate measurement in this scenario as any decoder would have to do the same thing for 99% of devices.

Also, this ( http://qpsnr.youlink.org/ ) app depends on libav to decode images. I haven't tested it, but it should be fairly flexible as a result.

edison

5th February 2013, 04:34

The PSNR is reported by the encoder?

Beyond that, I'd argue "downsampling" to 8bit creates a strictly accurate measurement in this scenario as any decoder would have to do the same thing for 99% of devices.

Also, this ( http://qpsnr.youlink.org/ ) app depends on libav to decode images. I haven't tested it, but it should be fairly flexible as a result.

My results:

ChinaSpeed_1024x768_30.yuv

H.265 JCT-VC HM 9.2 r3282 build-in_cfg: ra_main (2,734,212 bytes): 0.9506898 SSIM (500 frames)
H.264 x264 0.129.2230 "megui anime toons insane 2-pass" 1370kbps (2,830,294 bytes): 0.9420076 SSIM (500 frames)
H.265 JCT-VC HM 9.2 r3282 build-in_cfg: ra_he10 (2,720,498 bytes) decoded as 8-bit (I420 YUV): 0.9510426 SSIM (500 frames)

I don't know how to input 10-bit I420 into avisynth script that I used for SSIM value measure(http://forum.doom9.org/showthread.php?t=167103).

JEEB

5th February 2013, 08:01

HM 10.0 final was released last night, here (http://x264.fushizen.eu/builds/hevc-hm/hm_10.0_r3352_release.7z) is a build for it.

There is a bug fix for HM 10.0 rc1 that basically makes rc1-encoded files undecode'able with it, just so you know (in addition to previous version's streams probably failing with it, too).

MasterNobody

10th February 2013, 19:19

I did my own little codec comparison on the first 201 frames of park_joy 1080p sample (http://media.xiph.org/video/derf/y4m/park_joy_1080p50.y4m). Sample was encoded as 25fps instead of 50fps for easier watching during comparison (so it is 2x slowed down).

For comparison this versions of encoders was used (used_bin.zip (http://www.mediafire.com/?a5zx3x1rrxm869r) or mirror (http://www.sendspace.com/file/bwd5k1)):
HM-10.0 git-538e6fe
VP8/VP9 Encoder v1.2.0-1570-g7f5e4fd
x264 0.129.2245 bc13772

Encoding params: park_joy_params.txt (http://privatepaste.com/49a4ffcc26)
Encoded samples: encoded_samples.zip (http://www.mediafire.com/?nddua2977kzzon7) or mirror (http://www.sendspace.com/file/qrjm33)
Screenshots of frame #100: screenshots.zip (http://www.mediafire.com/?a4ux3rohmsyk7e8) or mirror (http://www.sendspace.com/file/f9j9l6)

Note: VP9 missed target bitrate of ~7000 kbit/s so it have little bit smaller file size but I doubt difference was significant enough to change anything in results. Also I didn't have time (8 hours) to remake sample with higher target bitrate (without confidence that it wouldn't miss it again).

APSNR_YUV:
H.265/HEVC 31.2758
VP9 30.2742
VP8 29.7419
x264_qp 30.5967
x264_crf_cqp 30.4806
x264_crf 30.7392
x264_crf_psy 29.9721
OPSNR_YUV:
H.265/HEVC 31.1003
VP9 30.0838
VP8 29.5136
x264_qp 30.4833
x264_crf_cqp 30.2792
x264_crf 30.6451
x264_crf_psy 29.8869

SSIM_YUV:
H.265/HEVC 0.8638
VP9 0.8359
VP8 0.8214
x264_qp 0.8277
x264_crf_cqp 0.8289
x264_crf 0.8596
x264_crf_psy 0.8502
SSIM_YUV (dB):
H.265/HEVC 8.6582
VP9 7.8489
VP8 7.4811
x264_qp 7.6371
x264_crf_cqp 7.6674
x264_crf 8.5263
x264_crf_psy 8.2448

And now my subjective opinion:
H.265/HEVC - impressive. It is definitely visually better than H.264. I would say quality of HM-10.0 better then what x264 can do without varying QPs on MB-level with AQ/MBTree (x264_crf_cqp), on par when you allow such varying (x264_crf), and little bit worse if you will allow x264 to use psy optimizations also (x264_crf_psy).
VP9 - not really impressive. Yes, it is better than VP8 but that is all. Quality is worse than H.265/HEVC or x264 (x264_crf or x264_crf_psy). While quality is better than x264_crf_cqp I wouldn't call such comparison correct because VP9 wasn't limited to one QP per frame as H.265/HEVC was. And if they didn't take advantage of such thing in VP8 I doubt they will/can do in VP9.

P.S. Both HM-10.0 and VP9 are unbelievable slow (7-9 hours for this 201 frame 1080p sample). That is probably 10 times slower than x264 without asm-optimizations and with single thread.

Selur

10th February 2013, 19:59

the mediafire download of the used binary has been removed for violation :(

Snowknight26

10th February 2013, 20:13

All of them have.

MasterNobody

10th February 2013, 20:27

Added sendspace mirrors. btw mediafire links work ok for me so dunno what wrong with them (may be something new in there sharing policy).

easyfab

10th February 2013, 21:51

Can you also add JM h.264 reference encoder to see difference between hevc and avc reference encoder . Because x264 is alot better than JM and I think futur Hevc encoder will be better than HM

edison

11th February 2013, 03:28

MasterNobody

11th February 2013, 06:39

hmm... why use HM10 QP32 vs x264 QP35 ?
Because we compare quality at the same bitrate/size and not at some abstact QP value that doesn't have any meaning outside of used codec.

iwod

11th February 2013, 13:19

Exciting time. In fact there has never been a Reference Encoder that beats its previous best implementation. HEVC is the first.

I am not sure if we could get a gigantic leap like we did from H.264 reference to x264. But if we do then HEVC is looking great, along with its Picture Format. Hopefully we can finally get rid of jpeg for good.

xooyoozoo

15th February 2013, 06:37

It occurred to me that subjective comparisons of encoders at the same filesizes are a bit limiting because there's really no intuitive link between relative fidelity and relative bitrates. To partially address that (and to humor my curiosity ;)), here's a little exercise: what happens if you accept all the purported bit savings and act accordingly? As in, how would x264 perform at half of MPEG2's bitrate and double HEVC's?

I'm going to take the QP32 versions of two 1080p HM10 bitstreams, Kimono and BasketballDrive (ftp://ftp.kw.bbc.co.uk/hevc/hm-10.0-anchors/bitstreams/ra_main/), and compare it against x264, ffmpeg MPEG-4, ffmpeg MPEG-2 at 200%, 300%, 400% of HEVC's bitrate, respectively. I'm also throwing in VP9, and based on some other results (http://forum.doom9.org/showthread.php?p=1614397#post1614397), I'm going to assume that VP9 can handle itself at 170% of HEVC's bitrate. Theoretically, all of these clips should be equally preferable.

All encoders had key intervals set to match HEVC's one per second and, where possible, open GOP was set. VP9 was also built using yesterday's latest experimental branch and with switched on experiments to get a sense of its bleeding edge code. Here's some exact details on that, along with command line settings (http://privatepaste.com/82e5c8e646) for everything else.

Kimono 1080p24
1068 HEVC (https://mega.co.nz/#!bJcEGJYZ!WQUXZj3Rzx5rcbmKdfFeDmhruYwFi8CRJFnD_zoHrjg) playable*
1815 VP9 (https://mega.co.nz/#!uJEjgLhZ!CJcHKFhBeCmQrETru2kusjQwor0MYgp2_XyZG9xtVL4) playable*
2138 x264 (https://mega.co.nz/#!PUdlFJII!AafgVgXQQt5j5B0dI6X20ywm3NwW4MfGamG0KlgSxPI)
3207 MPEG4 (https://mega.co.nz/#!6EUUFLxC!ErC12zvL6pWeekQlh8pWhUcR1KA2gnYEuWXX6bP22EQ)
4276 MPEG2 (https://mega.co.nz/#!bMdH3YaB!TElDtk064CQcHLq9CuFgA3yA5nk8aWlLUFVfL3eQ1QI)

BasketballDrive 1080p50
2807 HEVC (https://mega.co.nz/#!qFdWSIJT!e2J8Pz8cMVKGsGUXLfwUxg3clqwhXs_e3xl4PjBFPDo) playable*
4770 VP9 (https://mega.co.nz/#!aMcG2JyC!QnlXQmuOYgmc5sPyi014PySrvslNHxyEpNoYBfLTiso) playable*
5614 x264 (https://mega.co.nz/#!2d1xRapL!BSz4YQXIWjpQDkXNn5HYAVcDv7woENtrPMPGltY_TK4)
8421 MPEG4 (https://mega.co.nz/#!mQEGHRKb!VY34rDzCMb1lAt6qDOEjAFTDZvVEx7HWLhOU9W8KIto)
11228 MPEG2 (https://mega.co.nz/#!zBl1FYyJ!XTfZVyDyXU0cwr5bWKbNAjEAmRRsMouEDOLCux2LJ_U)

*You're gonna have to trust me that being reencoded with CRF12 x264 is transparent to the original :D. If not, HM10 bitstreams are in the usual place, and you can build specifically for the VP9 ones (https://mega.co.nz/#!rJNzEI6a!bAbF_TPvbKvrbP9JMq5GQUduxchmywWjvdEASX6U35Y).

My own impressions:
HEVC is by far the cleanest, and in my opinion the most natural looking, with noise I'd have to squint to see and almost no temporal artifacts, which is a killer for the others. Note that this does comes at a cost of lowered details in the background, but of course, this is by far the most naive and stupid of the encoders used here.

x264 is then the opposite of the above, where its image has the most detail at the cost of large distortions. Notice the flickering in the bush leaves' motion and the shimmering surfaces in the basketball court.

VP9 is a mixture and averaging of the above situations.

MPEG4 and MPEG2 perform roughly as expected, with MPEG4 doing a bit worse than MPEG2. I guess I now see why the industry stuck with MPEG2 for so long. Also of note is that I originally used ffmpeg's libXVID but then discovered that its internal MPEG4 library is visually superior with my settings.

Overall? With HEVC at 100%, VP9 should be bumped slightly lower to maybe 150% (Edit: on second thought, past experience tells me that VP9 does start to pick up lots of distortions; it's likely good as is, but we can do 167% to get nice ratios). x264 and MPEG2 are in good spots relative to each other (1:2), but MPEG4 needs to move a bit closer to MPEG2. The latter three all need to move farther away from HEVC. Maybe x264 can start at 250%.

adkalkan

22nd March 2013, 12:57

Hello Im new to this forum and I would like to ask something

I built the HM-10.0 on VisualStudio2010 32bit Win7 laptop
Specs: Intel Core 2 duo @2.4Ghz each and 2GB RAM

I downloaded the sample bitstreams from ftp://ftp.kw.bbc.co.uk/hevc/hm-10.0-anchors/bitstreams/

I decoded the RaceHorses416x240_30_qp22.bin clip for all profiles and the results I got are:

i_main 300frames 166secs (1.80fps)
ld_main 300frames 82secs (3.65fps)
lp_main 300 frames 75secs (4fps)
ra_main 300frames 70 secs (4.2fps)

Do these figures seem OK?
My goal is to improve the Reference Decoder so that it reaches the target >30fps for mobile devices and Im trying to estimate roughly the quality of code of the Reference Decoder(how much is optimized, how much can it be optimized)

geoyo

27th March 2013, 02:06

pieter3d

28th March 2013, 05:56

Kurtnoise

1st April 2013, 07:19

Found an optimized reference HEVC encoder (http://mnhevc.com/request/)...

http://mnhevc.com/wp-content/uploads/2012/09/IPPP-Time_130304.png

xooyoozoo

1st April 2013, 20:53

What are these numbers? 1068 1815 2138 4276? Where explanation? :)

Those are the bitrates for each encoder.

posdnya

10th April 2013, 14:24

xooyoozoo

10th April 2013, 18:57

Would be glad to compare with the best possible encoding made by x264 at the same bitrates.
GOP structure: IBBBPBBBP, Intra period 32 frames, open GOP

Was this encoded with reference HM or Elecard's own solution? If the latter, does it do things current AVC encoders would do, like scene-detection, adaptive quant, weighted pred (though I think this is in HM but defaults to off), etc?

Lastly, there's already pre-made 360p/720p BBB versions off of the main Xiph Derf download page (http://media.xiph.org/video/derf/). Is it right to assume that the Elecard versions were made off of those instead of off the original 1080p uncompressed plus ad-hoc downscaling?

Edit: to answer my own questions: elecard, i think; nope; dunno but the embedded logo makes it non-worthwhile to find out for more precise metric testing

foxyshadis

11th April 2013, 01:30

Was this encoded with reference HM or Elecard's own solution? If the latter, does it do things current AVC encoders would do, like scene-detection, adaptive quant, weighted pred (though I think this is in HM but defaults to off), etc?

Lastly, there's already pre-made 360p/720p BBB versions off of the main Xiph Derf download page (http://media.xiph.org/video/derf/). Is it right to assume that the Elecard versions were made off of those instead of off the original 1080p uncompressed plus ad-hoc downscaling?

Edit: to answer my own questions: elecard, i think; nope; dunno but the embedded logo makes it non-worthwhile to find out for more precise metric testing

I've considered hacking external frame-type files into the TAppEncoder, then generate them with x264's excellent decisions, to see how it would handle real shows. It already has qpfile and custom quant file support, not sure why they didn't include that.

I probably should have filed a bug for it back when things were still in the early stages. Kind of late now.

xooyoozoo

11th April 2013, 05:41

Would be glad to compare with the best possible encoding made by x264 at the same bitrates.
GOP structure: IBBBPBBBP, Intra period 32 frames, open GOP

Did a comparison versus x264 with typical comparison settings (2pass veryslow --open-gop -I 32), and x264 was unmistakably better. Then, I decided to make things more "fair" by also matching frame decisions (--no-scenecut -b 3 --b-adapt 0). I was still unimpressed by the Elecard-HEVC encode...

The main problem is that the Elecard encode is more macroblock-friendly. These two pictures summarize the issue fairly well: (nevermind)

x264 has its own issues. The hides of the animals sometimes 'shimmer', which I suspect is mostly from psy-rd overextending itself. However, it's much less noticeable and doesn't scream compression as much as blocky images.

Here's a visually transparent (x264 10bit CRF10), arbitrarily chosen scene from BBB done in the style of the two snapshots above: (nevermind). The visual examples all used the "handicapped" x264 encode.

posdnya

11th April 2013, 06:19

Was this encoded with reference HM or Elecard's own solution? If the latter, does it do things current AVC encoders would do, like scene-detection, adaptive quant, weighted pred (though I think this is in HM but defaults to off), etc?

Lastly, there's already pre-made 360p/720p BBB versions off of the main Xiph Derf download page (http://media.xiph.org/video/derf/). Is it right to assume that the Elecard versions were made off of those instead of off the original 1080p uncompressed plus ad-hoc downscaling?

Edit: to answer my own questions: elecard, i think; nope; dunno but the embedded logo makes it non-worthwhile to find out for more precise metric testing

It's HM 10 encoder, not Elecard. There is no scene dection, adaptive quant, weighted prediction. Encoding was made on pre-made 720p.
Sorry for logo, but I was going to do measurements by myself, just asking to prepare well done encoding with x264

posdnya

11th April 2013, 06:21

Here's a visually transparent (x264 10bit CRF10), arbitrarily chosen scene from BBB done in the style of the two snapshots above: (96 MB) (https://mega.co.nz/#!PJ8xxAhA!Xyyi7yaeCa-uFHqHG6VjrWZ6Rx0a6Y0VrabcLQKCHEw). The visual examples all used the "handicapped" x264 encode.

Thank you very much. I'll do comparisons and will post my conclusions.

xooyoozoo

11th April 2013, 06:33

Thank you very much. I'll do comparisons and will post my conclusions.

(nevermind)

x264 2pass --preset veryslow --no-scenecut -b 3 --b-adapt 0 --open-gop -I 32 -B 1039

Edit: the macroblocking thing is quite interesting then. I was ready to believe the clip was from a non-HM encoder because in my own tests (http://forum.doom9.org/showpost.php?p=1620230&postcount=62) with scenes from BBB, blocks were a non-issue. However, those tests also had HM's included-but-disabled adaptive quant settings activated; I recall the JCT-VC docs on those settings claiming that the switches help with blocking/distortions in flat areas (which BBB has lots of), but I've never bothered to compare those claims versus default HM.

posdnya

12th April 2013, 11:01

the macroblocking thing is quite interesting then. I was ready to believe the clip was from a non-HM encoder because in my own tests (http://forum.doom9.org/showpost.php?p=1620230&postcount=62) with scenes from BBB, blocks were a non-issue. However, those tests also had HM's included-but-disabled adaptive quant settings activated; I recall the JCT-VC docs on those settings claiming that the switches help with blocking/distortions in flat areas (which BBB has lots of), but I've never bothered to compare those claims versus default HM.

The issue is that simple - it was encoded with no deblock :-(
Will upload new encodings shortly

xooyoozoo

17th April 2013, 10:31

The issue is that simple - it was encoded with no deblock :-(
Will upload new encodings shortly

Ahh that explains it then.

Visually looks significantly better then AVC at the same PSNR.

This also applies to x264 vs HEVC with perceptually-tuned metrics, as they favor x264 quite a bit when tune-ssim is activated. Consequently, when matching metric output, comparative visual results suffer. Vanilla SSIM is the worst with this (because it favors x264 the most), followed by MS-SSIM, then PSNRHVSM.

I've done some tests where the process is conceptually* along the lines of:
encode HEVC at QP x
interpolate equivalent x264 bitrate using x264 veryslow 'tune ssim' encodes and 1+ metrics (averaged)
encode x264 2pass veryslow no-tunings and visually compare

Haven't kept all the results, but here's two: (sintel (https://mega.co.nz/#!bM1ihDYL!VJr1qV8HPtsQ7Rl-iNIZJBYwXlwD3z1saVagr9h9q4E)) (lupo (https://mega.co.nz/#!TI9GmBAa!Qe0x23kW19qaP2tgwYEigjl8utExPGJFsp8idYnX9fI)) (side by side cropping and composition made post-encode. Re-encoded CRF10 for transparency)

First one is with HEVC-QP29 and matched MSSSIM+PSNRHVSM (+67% bitrate). Second one is with HEVC-QP35 and matched PSNRHVSM (+100% bitrate). The first clip clearly favors HEVC, while the second clip leaves more room for debate. However, I generally prefer artifacts that don't move of their own free will.

*The process assumes x264 no-tunings has strictly better visual performance than tune-ssim, which should be true with these clips.

JEEB

27th April 2013, 15:48

Some time ago HM 10.1 was released. I built a 32bit Windows binary, and it is available here (http://x264.fushizen.eu/builds/hevc-hm/hm_10.1_r3419_release.7z) (configuration file folder included).

sl1pkn07

27th April 2013, 16:34

any fix to build with gcc 4.8?

http://sl1pkn07.no-ip.com/paste/view/53ffb394

foxyshadis

4th May 2013, 03:24

Use -Wno-array-bounds?

sl1pkn07

4th May 2013, 03:53

oks, adding that flags on CPPFLAGS on build/linux/common/makefile.base fix my build issue

thanks foxyshadis for giving me light

greetings :)

IgorC

4th May 2013, 23:24

couple HM 10 samples http://www.elecard.com/en/download/videos.html
SD - 563 kbps, average Y-PSNR - 39.60, UV - 43.5
720p - 1039 kbps, average Y-PSNR - 41.87, UV - 46

Original uncompressed: http://media.xiph.org/BBB/

HEVC Player sample for Windows (alpha): http://www.elecard.com/en/technology/researchlab/hevc-player.html
Indepth analisys tool: http://www.elecard.com/en/products/professional/analysis/hevc-analyzer.html

At the same PSNR as JM bitrate is lower then JM approx at 20% and 40% for SD and 720p respectively.
Visually looks significantly better then AVC at the same PSNR.

Would be glad to compare with the best possible encoding made by x264 at the same bitrates.
GOP structure: IBBBPBBBP, Intra period 32 frames, open GOP

I have tried to play "Big Buck Bunny" HEVC 1080p video. It was playable on 3770k @ 3.7 GHz except a few scenes where CPU load was 50-70% and frame rate was slowed down and accelerated later to synchronize with audio. The decoder still needs a performance optimizations.

Overall the quality is good but there are visual blocks and scene detection isn't handled (as xooyoozoo have already mentioned). The picture is sharp and detailed, the details are a bit simplified but acceptably.

qwddn

14th May 2013, 11:03

I wonder know when the finalized HEVC spec released, anyone knows?

thanks very much ~

JEEB

14th May 2013, 16:25

pieter3d

14th May 2013, 23:23

yes, see my thread (http://forum.doom9.org/showthread.php?t=167081) for the link to the spec. Be warned, if you aren't familiar with HEVC, or video spec in general, this will be a tough read!

qwddn

15th May 2013, 03:16

yes, see my thread (http://forum.doom9.org/showthread.php?t=167081) for the link to the spec. Be warned, if you aren't familiar with HEVC, or video spec in general, this will be a tough read!
thanks for your information~

qwddn

15th May 2013, 03:27

ITU-T's Last Call only takes a month so ITU-T Recommendation H.265 (http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=11885) is already published and available for buying since around middle of April. ISO/IEC's FDIS ballot takes two months, so the same specification should become available as ISO/IEC 23008-2 (http://www.iso.org/iso/catalogue_detail.htm?csnumber=35424) (MPEG-H Part 2 [HEVC]) around 22nd (?) of May.

So yeah, HEVC version 1 has already been "out there" for quite a while already. Even longer if you take into mention the point of time when the last draft was uploaded onto JCT-VC's document tracker :) By now you could even start grabbing the "Editors' proposed corrections to HEVC version 1" documents for an even newer version of the text.

First, thanks for your kindly help.
I go ITU HEVC website( http://www.itu.int/rec/T-REC-H.265-201304-P ), it seems that the pre-published spec is only available for TIES users and Subscribers... The newest version I have is JCTVC-L1003 (version 34), So could you please tell me where I can download HEVC-version-1 ? is it free to download now ?

thanks again~

JEEB

15th May 2013, 07:52

it seems that the pre-published spec is only available for TIES users and Subscribers...
Yes, because it's currently available for purchase? With AVC/H.264 the current spec was only available for one to buy for the first six or so months, after which it was released to be available for free. No idea if they will keep such an official free way of distribution with HEVC/H.265.
The newest version I have is JCTVC-L1003 (version 34)
That is what I noted as the "last draft (that) was uploaded onto JCT-VC's document tracker", that was pushed onto the ITU-T Last Call and ISO/IEC FDIS ballot.
So could you please tell me where I can download HEVC-version-1 ? is it free to download now ?
If you want the thing that came out of the ballots, and not the one that went into the ballots, I have already linked you the ITU-T page from which you can already buy it from. No, it is not free to download now, but might become in six months or so depending on if ITU-T and ISO/IEC will do the same thing they did with AVC/H.264 regarding free publication.

In any case, this is IMHO enough spec-specific talk on the "Available HEVC/H.265 test encoders" thread, there is a generic HEVC/H.265 thread (http://forum.doom9.org/showthread.php?t=165673) around as well :P

qwddn

15th May 2013, 15:20

Yes, because it's currently available for purchase? With AVC/H.264 the current spec was only available for one to buy for the first six or so months, after which it was released to be available for free. No idea if they will keep such an official free way of distribution with HEVC/H.265.

That is what I noted as the "last draft (that) was uploaded onto JCT-VC's document tracker", that was pushed onto the ITU-T Last Call and ISO/IEC FDIS ballot.

If you want the thing that came out of the ballots, and not the one that went into the ballots, I have already linked you the ITU-T page from which you can already buy it from. No, it is not free to download now, but might become in six months or so depending on if ITU-T and ISO/IEC will do the same thing they did with AVC/H.264 regarding free publication.

In any case, this is IMHO enough spec-specific talk on the "Available HEVC/H.265 test encoders" thread, there is a generic HEVC/H.265 thread (http://forum.doom9.org/showthread.php?t=165673) around as well :P

thank you for your info.
I will post my question in the right thread!soooorry~:D

SeeMoreDigital

15th May 2013, 16:55

Is there any information yet regarding container support for HEVC/H.265?

By-the-way, when it comes to the .MKV container. It looks as though Mosu could do with a hand (http://forum.doom9.org/showthread.php?p=1623148)...

JEEB

15th May 2013, 17:15

Is there any information yet regarding container support for HEVC/H.265?
GPAC is implementing HEVC-in-"mp4", which is an extension of 14496-15 (AVC File Format, the mapping of AVC in "mp4") as we speak, but they seem to be the only ones with the up-to-date specs. I've poked smarter about it since he seems to be in contact with those guys, and the response I've gotten via him is that the draft (http://x264.fushizen.eu/random/29n13120t.pdf) that used to be publicly available is by now outdated, and that only they have access to MPEG's "secret stashes" where the current version lies.

L-SMASH and libavformat are both interested in implementing it for obvious reasons, but this kind of "co-operation" doesn't work, because GPAC has always been known for at times not doing things "by the book". The HEVC addition to 14496-15 should be finalized by July 2013.

There's also "Transport of HEVC video over MPEG-2 systems", which is basically a HEVC mapping for MPEG-2 TS/PS. Also to be finalized in July.

By-the-way, when it comes to the .MKV container. It looks as though Mosu could do with a hand (http://forum.doom9.org/showthread.php?p=1623148)...
I did start a thread (http://lists.matroska.org/pipermail/matroska-devel/2013-April/004440.html) on matroska-devel about it... it should have plenty of references for people interested in these things.

SeeMoreDigital

15th May 2013, 17:29

Many thanks JEEB. Your information is most reassuring :)

Kurtnoise

16th May 2013, 17:20

The DivX labs (http://labs.divx.com/node/127884) has published a draft (http://labs.divx.com/system/files/DivX_HEVC_Video_Profiles_DRAFTMay2013.pdf) mentioned the new HEVC Video Profiles (4K, 1080p, 720p) from their next products...

mandarinka

24th May 2013, 02:52

Hmm, main profile...
Seamless resolution switching is great, however mod8 being mandatory is just sloppy.
I think it is shortsighted from them to ignore 48 Hz as a framerate. True, eventually that speed might not be adopted for real, but it seems that content is already being produced with it.

SubJunk

30th May 2013, 05:28

I think The Hobbit series will be the only films ever made with 48Hz. Other high framerate films will likely be 60Hz instead, like James Cameron has stated.

benwaggoner

30th May 2013, 18:59

I think The Hobbit series will be the only films ever made with 48Hz. Other high framerate films will likely be 60Hz instead, like James Cameron has stated.
Yes, the Lightstorm demos make an excellent case for 60 over 48. And 60 is certainly a lot more compatible with existing display hardware. I expect it'll become the dominant HFR standard over time.

But there is at least one other film announced to be in 48: Andy Serkis's adaption of Animal Farm.
http://www.hollywoodreporter.com/news/andy-serkis-animal-farm-381314

Also, AFAIK Unexpected Journey was the 2nd film shot at 48p, after the IMAX HD film Momentum. Which I remember being blown away by as a teenager at the Vancouver BC Expo '86.
http://en.wikipedia.org/wiki/Momentum_(IMAX_film)

Back to HEVC, we know that HEVC's bits-per-pixel requirements drop a lot more as frame size goes up compared to older codecs. I wonder if HEVC will be better than past formats at higher frame rates?

SeeMoreDigital

6th June 2013, 22:03

Yes, the Lightstorm demos make an excellent case for 60 over 48. And 60 is certainly a lot more compatible with existing display hardware. For North America (and Japan) maybe... But 50p already works perfectly in Euroland ;)

mandarinka

6th June 2013, 22:52

Hmm, 48 Hz also has the downside that it doesn't match properly on a 120 Hz screen, unlike 24, 30 and 60 fps. Aw (25/50 Hz are also trouble of course).

SubJunk

7th June 2013, 00:52

25p and 50p can't die soon enough! Thankfully it's being phased out.

benwaggoner

11th June 2013, 18:20

25p and 50p can't die soon enough! Thankfully it's being phased out.
For production, maybe. 24p, 60p, or higher are the only things anyone should be shooting for content with any meaningful lifespan.

But as long as people still watch Doctor Who or Top Gear, we'll still need 25/50 for playback. So, forever.

I get annoyed when 18 fps isn't explicitly supported for encoding, since that's what the first decades of pre-sound cinema are all in.

SeeMoreDigital

11th June 2013, 18:25

Thankfully it's being phased out.Says who?

SubJunk

11th June 2013, 22:28

For production, maybe. 24p, 60p, or higher are the only things anyone should be shooting for content with any meaningful lifespan.

But as long as people still watch Doctor Who or Top Gear, we'll still need 25/50 for playback. So, forever.Yeah you're right, Downton Abbey too. I just hope those shows can start being done at 24p instead in the future.

Says who?I live in a PAL country and all our DVDs are 25FPS but the blu-rays are at their native framerate (almost always 24p), as are all the web downloads and films at the cinema. Since a lot of stores are either stopping selling DVDs in favour of blu-rays, or shutting down because people are downloading/streaming everything, it seems to me that it's going to be hard to find 25FPS content for sale soon since 99.99+% of it was converted from NTSC. Real 25p content might not go anywhere though, I just hope it does.

benwaggoner

11th June 2013, 23:57

Yeah you're right, Downton Abbey too. I just hope those shows can start being done at 24p instead in the future.
Sure, but I'd still want to be able to watch the PAL content at its original frame rate, and thus its original speed.

I live in a PAL country and all our DVDs are 25FPS but the blu-rays are at their native framerate (almost always 24p), as are all the web downloads and films at the cinema.
Web downloads? Since almost all web/IP clients can support arbitrary frame rates, I'd expect a lot more content to remain in native frame rate.

We certainly deliver 25p content as 25p in NTSC countries, and 24/30 content as 24/30 in PAL countries.

SubJunk

12th June 2013, 00:22

Yeah same here, I agree with you. My main complaint about 25p is that it's almost always converted from 24p. Native 25p content should not be converted.

JEEB

14th June 2013, 11:43

HM 11.0 has been released. I built a 32bit Windows binary of the decoder and encoder, and they are available here (http://x264.fushizen.eu/builds/hevc-hm/hm_11.0_r3513_release.7z) (configuration file folder included).

The biggest change now is that the configuration files actually contain the profile and level. Before this, unless you actually remembered to add those two, your streams would be invalid.

Compared to the release candidate we decided to revert a patch that caused problems with conformance test bitstreams. We also made a change to only warn when profile and level are not set instead of failing.

Compared to HM 10.1, HM 11.0 contains changes for rate control and a number of bug fixes. Performance in the common test conditions is not changed. We will still provide updated anchors with valid profile/level values within the next days.

Please note, that there are still quite a few open issues in the bug tracker. Most of them are related to high level issues like parameter set handling and reference picture sets.

Any help with fixing these issues and reviewing patches, especially regarding conformance issues, are highly appreciated.

For details see:

https://hevc.hhi.fraunhofer.de/trac/hevc/report/16

RBF

3rd July 2013, 07:56

Strongene HEVC/H.265 Encoder (http://xhevc.com/en/downloads/downloadCenter.jsp)

fumoffu

4th July 2013, 05:11

Strongene HEVC/H.265 Encoder (http://xhevc.com/en/downloads/downloadCenter.jsp)

the readme.txt file in encoder wasn't displaying for me correctly, I fixed character set and google translated from Chinese. Result in attachment..

war59312

8th July 2013, 22:29

I really don't understand how to use it.

I successfully installed it and all three show up. See attachment please.

But MPC-HC simply states "Cannot render the file" when I try and play the sample H265 videos from http://xhevc.com/ .

Update: OK it's just FLV files that have this problem even though it says the current decoder supports them, it seems it does NOT.

afd_720p.hm10 and afd_1080p.hm10 play back just fine now in MPC-HC. :) Note: Resuming does NOT work yet.

afd_1080p.hm10 (full-screen), uses around 6.5% of my Intel Core i7 930 CPU. Not bad at all.

edison

9th July 2013, 18:23

Here is a guide for the encoder : http://www.cnbeta.com/articles/244065.htm.

Sagittaire

11th July 2013, 16:55

Well I test Strongene HEVC/H.265 Encoder and first result for this implementation is:
- H265 is unable to produce same quality than x264 at half bitrate (metric)
- H265 is able to produce same quality than xvid at half bitrate (metric)

It's already really impressive H265 implementation for a first test. H265 is really better visualy than x264 at same bitrate and by far. The most impressive is IMO the temporal stability for H265.

SeeMoreDigital

11th July 2013, 17:18

Sagittaire,

Out of interest... Did you view your HEVC test files using a dedicated HEVC decoder - if so, which one? Or did you convert your HEVC test files to a lossless video format before viewing?

Sagittaire

11th July 2013, 18:29

I use Strongene HEVC/H.265 decoder DSFilter with compatible DSFilter like MPC or WMP ...

fumoffu

11th July 2013, 18:45

Well I test Strongene HEVC/H.265 Encoder and first result for this implementation is:
- H265 is unable to produce same quality than x264 at half bitrate (metric)

I'm experimenting with this encoder too.
Did you compared it with x264 1pass?
also I suspect HEVC advantage is bigger if there is a lot of movement, like hand held camera (95% of porn ;p) or FPP game footage.

Sagittaire

11th July 2013, 19:15

I'm experimenting with this encoder too.
Did you compared it with x264 1pass?
also I suspect HEVC advantage is bigger if there is a lot of movement, like hand held camera (95% of porn ;p) or FPP game footage.

I use x264 10 bits in crf mode with placebo setting (extreme and best possible situation for x264)
I use H265 in quantizer mode.

At same bitrate H265 is clearly better in absolutly all the situations. I test with various trailer (slow motion, high motion, anime ...). Anyway H265 is really unable to approch x264 quality at half bitrate. H265 marketing say 50% for bitrate reduction ... but it's more something like 25 or 30% actualy with this implementation. The best H265 implementation will be (perhaps) able to make that in future but certainely after many years.

lainiwaku

12th July 2013, 11:28

Sagittaire

12th July 2013, 16:46

i hope so , because people said h265 is for 4k,
but when i see that most of people think x264 still too much big file for 1080p content
h265 will just be acceptable size for 1080p file, 4k will still too big even with h265

well H265 will be not only for 4k movie. Moreover x264 work really well for 1080p movie: I think that it's possible to encode 90% of movie in DVD5 with really high quality if you use good filtering and good profil for codec (adaptative avisynth filtering, aac 5.1 in vbr mode, good x264 profil).

benwaggoner

12th July 2013, 17:12

well H265 will be not only for 4k movie. Moreover x264 work verry well for 1080p movie: I think that it's possible to encode 90% of movie in DVD5 with really high quality if you use good filtering and good profil for codec (adaptative avisynth filtering, aac 5.1 in vbr mode, good x264 profil).
First, if I may be allowed a bit of pedantry.

4K (http://en.wikipedia.org/wiki/4K_resolution)is a film industry specification, for 4096 wide video in post and digital projection.
For TVs it is properly "Ultra high definition television (http://en.wikipedia.org/wiki/Ultra_High_Definition_Television)" - UHD or UHDTV. UHD today is 3840x2160. While the 14% difference in pixels isn't going to be material from a quality perspective, these are different formats. UHD also mandates support for Rec. 2020 color as well (although that requires 10-bit sources anyway).

People call UHD 4K often as a shorthand, but I think we're better off being more specific in what we're talking about.

But back to the point, as far as bitrates required go, UHD is going to need a lot fewer bits per pixel than 1080p. First, detail isn't fractally dense, and 4x the pixels doesn't make anywhere near 4x the detail or 4x the high frequencies.

Second, and a bigger deal, viewers simply aren't going to be close enough to the screen to keep pixels at the same portion of the visual field as they do today. And even today most people are a lot farther than the THX recommended distance from their displays. Encoded at the same bitrate, only a minority would even notice the difference in film/video moving image content between 720p and 1080p on their 1080p display. For a 1080p 55" display, optimal viewing distance is about six feet. For a 1080p 55" display, optimal viewing distance would be three feet. That's just uncomfortably close because it requires head movement to track motion at the corners of the screen.

UHD might need maybe twice the bitrate of 1080p in H.264 to provide the available quality improvement in real-world viewing environments.

Given HEVC's better compression efficiency, particularly at higher frame sizes, a mature HEVC encoder might well be able to deliver UHD content at today's H.264 1080p bitrates.

Sagittaire

12th July 2013, 18:41

But back to the point, as far as bitrates required go, UHD is going to need a lot fewer bits per pixel than 1080p. First, detail isn't fractally dense, and 4x the pixels doesn't make anywhere near 4x the detail or 4x the high frequencies.

I post a good model for calcul that many years ago on doom9:
http://forum.doom9.org/showthread.php?t=95122&highlight=quality%2Fpixel

with this model you can expect have the same quantizer encoding (aka same mathematical quality/pixel for the codec) in these situation:

|----------------|--------------------|--------------------|--------------------|
| | files sizes | bit/(pel*fps) | bit/(pel^0.75*fps) |
|----------------|--------------------|--------------------|--------------------|
| q20 3840*2160 | 11128 Kbps | 0.056 bpf | 3.00 sci |
| q20 2560*1440 | 6057 Kbps | 0.068 bpf | 3.00 sci |
| q20 1920*1080 | 3934 Kbps | 0.079 bpf | 3.00 sci |
| q20 1280*720 | 2141 Kbps | 0.097 bpf | 3.00 sci |
| q20 720*400 | 896 Kbps | 0.129 bpf | 3.00 sci |
| q20 640*360 | 757 Kbps | 0.137 bpf | 3.00 sci |
| q20 512*288 | 541 Kbps | 0.153 bpf | 3.00 sci |
| q20 480*270 | 491 Kbps | 0.158 bpf | 3.00 sci |
| q20 320*240 | 332 Kbps | 0.160 bpf | 3.00 sci |
|----------------|--------------------|--------------------|--------------------|

theorical exemple with x264 at constant quantizer q20

Second, and a bigger deal, viewers simply aren't going to be close enough to the screen to keep pixels at the same portion of the visual field as they do today. And even today most people are a lot farther than the THX recommended distance from their displays. Encoded at the same bitrate, only a minority would even notice the difference in film/video moving image content between 720p and 1080p on their 1080p display. For a 1080p 55" display, optimal viewing distance is about six feet. For a 1080p 55" display, optimal viewing distance would be three feet. That's just uncomfortably close because it requires head movement to track motion at the corners of the screen.

UHD might need maybe twice the bitrate of 1080p in H.264 to provide the available quality improvement in real-world viewing environments.

Given HEVC's better compression efficiency, particularly at higher frame sizes, a mature HEVC encoder might well be able to deliver UHD content at today's H.264 1080p bitrates.

Yes IMO 2160p will be not really big revolution for video. 1080p is already really high resolution for medium user. IMO in the futur the revolution will be (and must be) high temporal resolution (48p or 60p) with better space color than 4:2:0 YV12. IMO 1080p60 YUY mean really higher quality improvement than 2160p24 YV12. Anyway it's not a good deal for materiel constructor because the actual 1080p TV are potentialy compatible with this format.

benwaggoner

12th July 2013, 19:29

Yes IMO 2160p will be not really big revolution for video. 1080p is already really high resolution for medium user. IMO in the futur the revolution will be (and must be) high temporal resolution (48p or 60p) with better space color than 4:2:0 YV12. IMO 1080p60 YUY mean really higher quality improvement than 2160p24 YV12. Anyway it's not a good deal for materiel constructor because the actual 1080p TV are potentialy compatible with this format.
Yes, absolutely. 50/60p offers a huge quality improvement and is compatible with lots of existing devices. UHD will offer much smaller benefits with a lot more work.

I'm not sold on >4:2:0 being that helpful for 1080p, though. Chroma subsampling artifacts are really hard to see at high resolutions, and are essentially invisible with natural moving images.

>8-bit is good, because it reduces dithering.

Extra colors seem like they could be awesome if we had sources that actually did stuff with those colors. As it is I've not seem many real world examples. But Rec. 2020 is capable of doing a lot more than xvYCC in this category. I'm hoping and pushing for HEVC Main 10 to become the baseline for UHD devices so that Rec. 2020 support can be assumed.

It would be great to get 12-bit HEVC eventually so the high dynamic range (superbrights) feature of Rec. 2020 could be used. That is something that can really pop with the right sources and the right display technologies.

fumoffu

12th July 2013, 19:43

I use x264 10 bits in crf mode with placebo setting (extreme and best possible situation for x264)
I use H265 in quantizer mode.

At same bitrate H265 is clearly better in absolutly all the situations. I test with various trailer (slow motion, high motion, anime ...). Anyway H265 is really unable to approch x264 quality at half bitrate. H265 marketing say 50% for bitrate reduction ... but it's more something like 25 or 30% actualy with this implementation. The best H265 implementation will be (perhaps) able to make that in future but certainely after many years.

I have been reencoding some clips with Strongene encoder at Slow preset and bitrate 1200kbps for 720p and I must say I often prefered the output from what I have been getting from x264 at about 3000kbps (slow preset with subme 9 5-bframes and trellis disabled, crf20-21).
Yes, the some edges are a bit blurry but nice blurry, while x264 at low bitrates gives fuzzy edges. And I found that HEVC even at much lower bitrates better preserved delicate gradients. I guess perceived quality is a subjective thing...

I also have a quick question: I didn't try CQP mode yet - are the quantizer values the same as in x264 for given quality? (yes I know x264 uses CRF by default)

Sagittaire

12th July 2013, 20:02

I have been reencoding some clips with Strongene encoder at Slow preset and bitrate 1200kbps for 720p and I must say I often prefered the output from what I have been getting from x264 at about 3000kbps (slow preset with subme 9 5-bframes and trellis disabled, crf20-21).
Yes, the some edges are a bit blurry but nice blurry, while x264 at low bitrates gives fuzzy edges. And I found that HEVC even at much lower bitrates better preserved delicate gradients. I guess perceived quality is a subjective thing...

I also have a quick question: I didn't try CQP mode yet - are the quantizer values the same as in x264 for given quality? (yes I know x264 uses CRF by default)

well it's not valid comparison because you use really different RC for your test. Perhaps that your clip done better overall result with cbr. Use quantizer mode with H265 and compare with crf or quantizer mode with x264. I you want absolutly use cbr mode with H265 then use cbr mode with x264.

Sagittaire

13th July 2013, 09:31

I also have a quick question: I didn't try CQP mode yet - are the quantizer values the same as in x264 for given quality? (yes I know x264 uses CRF by default)

crf N for x264 and quantizer N for H265 produce similar bitrate ... ;-)

zerowalker

13th July 2013, 18:18

So does HEVC support 12bit?

I know 10bit can improve quality/size a lot in some cases where there are good gradients, and dark scenes etc.
Will 12bit be another leap?

I am guessing diminish returns.

sneaker_ger

13th July 2013, 19:10

So does HEVC support 12bit?

It's not standardized yet AFAIK, but it will probably come in the future (2014?). H.264 already supports up to 14 bit. I think the new BT.2020 directed at post-FullHD equipment even needs at least 10 or 12 bits to be fully used.

I know 10bit can improve quality/size a lot in some cases where there are good gradients, and dark scenes etc.
Will 12bit be another leap?

I am guessing diminish returns.

According to a post by Dark_Shikari that seems indeed to be the case. 10 bits would - compared to 8 bits - already reduce rounding errors by 75% (9 bits 50% - you get the idea...) and that also seems to be a sweet spot for speed optimizations. Plus H.265 has at least one additional tool against banding even at lower depths. (http://forum.doom9.org/showthread.php?p=1614299#post1614299)

Getting away from the numbers: just comparing 8 bit to 10 bit with the eyes, 10 bit encodings usually make the leap to transparency already. It can not get more than transparent. Maybe 12 to 16 bit can milk a few more percent quality/compression, but it will not be as astonishing as going from 8 to 10 bits.

JEEB

26th August 2013, 14:48

Whoops, seemingly didn't notice at all that HM 12.0 got released during the last two weeks. Not sure if there was an e-mail on the JCT-VC regarding it. In any case, 32bit Windows binaries of the decoder and encoder are available here (http://x264.fushizen.eu/builds/hevc-hm/hm_12.0_r3541_release.7z) (configuration file folder included).

filler56789

26th August 2013, 15:20

Thanks a lot, JEEB

:thanks:

xooyoozoo

5th September 2013, 20:27

"Rovi Launches DivX 10 (http://www.rovicorp.com/company/news-center/pressreleases/1434_17431.htm)" with HEVC decode/encode. The download link doesn't seem to be live yet?

JEEB

5th September 2013, 20:56

"Rovi Launches DivX 10 (http://www.rovicorp.com/company/news-center/pressreleases/1434_17431.htm)" with HEVC decode/encode. The download link doesn't seem to be live yet?
If you check the installer you get here (http://www.divx.com/downloads/divx/1), you will already get a DivX 10 installer, which also seems (http://puu.sh/4jMlD.png) to (http://puu.sh/4jMvJ.png) contain the HEVC plugin.

In other words, it indeed seems to be out :)

Too bad they're using their ad-hoc HEVC-in-Matroska thing specified here (http://labs.divx.com/node/127907). Matroska-devel more or less decided to wait for 14496-15 AMD2 (HEVC FF) to copy the extradata off of. And that still hasn't been pushed out for the last ballot :/ . Last I heard there really weren't any changes done to it for like over a month or so, either. It's just not being pushed out :s .

fumoffu

5th September 2013, 21:37

Thanks for the heads up. I'm testing it now. First thing I noticed is that the encoder uses only about 160MB of RAM (I'm re-encoding 720p wmv clip), which is pretty low and I'm not sure if this is a good sign... I'm guessing it must be using Wavefront Parallel Processing? Speed wise it's similar to Strongene encoder, and uses 90% of the CPU (4 cores), with rather small fluctuations. Quality - don't know I'm waiting for output...

Edit:
Quality is ok but I don't have time now to do serious x264 or Strongene HEVC comparison.
But the funny thing is that DivX player apparently needs over 800MB RAM for 720p playback... Memory leak? Bad optimization? Large decoder buffer? Might be the last one because CPU usage fluctuates between 0-10% (on 4 core i5 @4GHz).

xooyoozoo

6th September 2013, 09:22

Spent some time with the divx converter and its 'HEVC 1080p' preset on the astronaut Crew and Soccer (ftp://ftp.tnt.uni-hannover.de/pub/svc/testsequences/) clips. Note that the HEVC-MKV demuxer JEEB linked to only works when you compile it yourself. Currently, the prebuilt binary complains with divx's output.

There's definitely scene detection, though the detection is a bit too enthusiastic on the Crew clip. Keyints are at 5 secs, and the frame cadence resembles IBBBP (w/ fewer Bs when necessary). They also seem to have limited CTU size to 32x32, but that maybe that's automatic based on source resolution. At lower bitrates, the image sometimes has distinct block edges, which suggest they tweaked the loop filters.

Encoding speed is roughly half that of x264-veryslow. I wasn't impressed at all by visual quality, but I'll try testing the encoder with more clips some time later.