Available HEVC/H.265 test encoders

[benwaggoner]

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.

[JEEB]

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]

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

[Parabola]

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]

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]

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]

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]

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

[benwaggoner]

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]

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]

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]

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]

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

[mandarinka]

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.

[Kurtnoise]

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

[Sagittaire]

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]

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]

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]

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]

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]

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]

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

[Sagittaire]

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


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]

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]

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]

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 (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]

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 (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]

>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 (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]

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

[JEEB]

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]

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]

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]

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

[xooyoozoo]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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