H.265/HEVC specification released, any decoders/encoders in sight?

[thebombzen]

Hi, According to Wikipedia, the H.265/HEVC spec was released on 7 June 2013, which I found for free on ITU-T's website:

http://www.itu.int/rec/T-REC-H.265-201304-I/en

Now that HEVC has been officially finalized and released, corporations (ATEME, DivX, maybe not Google) will be jumping up and down to quickly put forth their own HEVC decoders and encoders. However, as history has shown, open-source software often beats proprietary software. Look at x264, OPUS, nothing has wider support than FFmpeg, and Linux servers are an industry standard.

While on Wikipedia it says that many companies are now putting their feet forward in the HEVC market, does anyone have an estimation for free and open-source (BSD, (L)GPL, etc.) decoders or encoders? Note that X265 doesn't count, as it's most likely a "lite" version:


Currently, I working on my commercial version, it is cooperation with a China university, we improvement the compress performance and try more advanced feature (many-cores, taskpool, GPU, etc).


Also, is this move going to kill x264? It seems that does happen for software, for example, the Blender3D Cycles rendering engine effectively killed Luxrender. Codecs for inferior formats such as LAME still live but notice that LAME's last stable release was in 2011 (2 years ago) and probably still exists only because there's no good free as in freedom encoder for AAC (FFmpeg's is terrible, so is vo-aacenc, FAAC and fdk-aac are nonredistributable and Nero's and Apple's are not open-source, etc.).

[qyot27]

I can't comment on the rest of it, but
Also, is this move going to kill x264? It seems that does happen for software, for example, the Blender3D Cycles rendering engine effectively killed Luxrender.
IMO, probably not. One of the reasons that x264 eclipsed Xvid as quickly as it did (which still took several years; Xvid's apex period was ca. 2003-2005, with a slow declining drop-off for a couple more years after that) is because MPEG-4 ASP was never as deeply entrenched as MPEG-2, which is still used - most obviously for DVD, but also as an option on (mostly older) Blu-ray discs, and it's still widely used for DTV broadcast (although H.264 is in the process of replacing it for this).

H.264 is arguably even more ubiquitous than MPEG-2 ever hoped to be, so I'd wager it'll still take several years for HEVC to become the dominant format, and then you also have to factor in the amount of time it will take for those in the FOSS community to implement and optimize an encoder for it (that is, if development of rival formats like VP9 or Daala don't throw a wrench into the works), while it still has to compete with x264 being as long-mature as it is.

In perspective, H.264's specs arrived in early 2003, and hdot264 appeared sometime afterward. x264 appeared some time in (late?) 2004, didn't start getting a lot of attention until 2005, and H.264 as a format didn't start dominating over MPEG-4 ASP or SP until 2007 or 2008 in tangible online distribution*. The almost wholesale transition of streaming media to H.264 from the variety of formats they were using before didn't really start to coalesce until what, 2009 or 2010? I'm not really sure when MPEG-2 and VC-1 use on Blu-ray started to drop off, but it was still somewhere in there.

*take Apple and iTunes as examples: many/most of the trailers and music videos available through them prior to formally starting the iTunes Video Store were in either MPEG-4 SP (music videos) or Sorenson 3 (trailers). The Video Store explicitly moved its offered content to H.264, and it was around the same time that the trailers site both mostly moved to H.264 and started distributing 720p and 1080p versions. That's just one example (and probably the only one that matters, at least legally).

There are of course going to be early adopters that like the bleeding edge, but you've got to contend with a lot more standalones and mobile devices that support H.264 and not HEVC, which will impact its rate of adoption in the short term. Active development on Xvid didn't start tapering off until it was in its twilight years, so unless there's just this tidal wave of adoption for HEVC, I'd say that H.264 as a format - and x264 as its premier encoder - still have at least a good 5 years before HEVC's rising level of dominance begins to seriously impact it, at which time the use case will shift more to legacy support for things like disc formats or using H.264 as the 'plays on almost anything and/or not-so-powerful machines' solution that MPEG-4 ASP still manages to hold onto. The 5-year point also is likely to mirror the shift to UHDTV or a new generation of Blu-ray, where HEVC will naturally have broad use.

[benwaggoner]

IMO, probably not. One of the reasons that x264 eclipsed Xvid as quickly as it did (which still took several years; Xvid's apex period was ca. 2003-2005, with a slow declining drop-off for a couple more years after that) is because MPEG-4 ASP was never as deeply entrenched as MPEG-2, which is still used - most obviously for DVD, but also as an option on (mostly older) Blu-ray discs, and it's still widely used for DTV broadcast (although H.264 is in the process of replacing it for this).
Plus cable, which is almost entirely MPEG-2 yet. I doubt we've hit the crossover point where even 50% of eyeball-hours are H.264 instead of MPEG-2.

H.264 is arguably even more ubiquitous than MPEG-2 ever hoped to be, so I'd wager it'll still take several years for HEVC to become the dominant format
MPEG-2 was the first widely used video codec. Since we're now in a mode of multiple coexisting codec generations, I doubt anything will ever have the market share that MPEG-2 had in, say, 2004.

and then you also have to factor in the amount of time it will take for those in the FOSS community to implement and optimize an encoder for it (that is, if development of rival formats like VP9 or Daala don't throw a wrench into the works), while it still has to compete with x264 being as long-mature as it is.
I don't see VP9 or Daala competing with resources with HEVC. VP9 is almost entirely a Google-developed effort, and Daala is a long way from having a locked-down bitstream spec. FOSS developers looking for a mainstream audience are going to be choosing between H.264 and HEVC for the most part.

In perspective, H.264's specs arrived in early 2003, and hdot264 appeared sometime afterward. x264 appeared some time in (late?) 2004, didn't start getting a lot of attention until 2005, and H.264 as a format didn't start dominating over MPEG-4 ASP or SP until 2007 or 2008 in tangible online distribution*. The almost wholesale transition of streaming media to H.264 from the variety of formats they were using before didn't really start to coalesce until what, 2009 or 2010? I'm not really sure when MPEG-2 and VC-1 use on Blu-ray started to drop off, but it was still somewhere in there.

*take Apple and iTunes as examples: many/most of the trailers and music videos available through them prior to formally starting the iTunes Video Store were in either MPEG-4 SP (music videos) or Sorenson 3 (trailers). The Video Store explicitly moved its offered content to H.264, and it was around the same time that the trailers site both mostly moved to H.264 and started distributing 720p and 1080p versions. That's just one example (and probably the only one that matters, at least legally).
I'd say that VC-1/WMV was the dominant legal online format 2004-2008. That's what Amazon Unbox, Zune, Xbox Video, Netflix, CinemaNow, and most of the other early online video companies other than Apple were using. WMV had the only widely available Hollywood-approved DRM and hardware-accelerated decode. Apple was rather unique, as they had their own DRM that didn't even try to be interoperable and didn't have HW accelerated decode for anything for a long time.

There are of course going to be early adopters that like the bleeding edge, but you've got to contend with a lot more standalones and mobile devices that support H.264 and not HEVC, which will impact its rate of adoption in the short term. Active development on Xvid didn't start tapering off until it was in its twilight years, so unless there's just this tidal wave of adoption for HEVC, I'd say that H.264 as a format - and x264 as its premier encoder - still have at least a good 5 years before HEVC's rising level of dominance begins to seriously impact it, at which time the use case will shift more to legacy support for things like disc formats or using H.264 as the 'plays on almost anything and/or not-so-powerful machines' solution that MPEG-4 ASP still manages to hold onto. The 5-year point also is likely to mirror the shift to UHDTV or a new generation of Blu-ray, where HEVC will naturally have broad use.
Blu-ray 4K is still going to be H.264, for example. The rapid rate of mobile device turnover suggests H.264-only devices should be in the minority by end of 2016. But living room devices live a lot longer; <=2013 TVs, STBs, game consoles, etcetera will be in use way past 2016.

I can imagine HEVC starting to see practical use in 2014 and account for a majority of IP streams in 2016. I don't see H.264 being dominant in 2018 overall, but it will certainly still be widely used for popular devices and formats. Heck, MPEG-2 will still be significant in 2018. It'll be a heterogeneous era. But given the dominance of IP delivery by then, I don't see a variety of codecs as being a major problem.

[edison]

all the next gen gpu(for example:nvidia maxwell) will include a h.265 decoder/encoder.

[wanezhiling]

all the next gen gpu(for example:nvidia maxwell) will include a h.265 decoder/encoder.
btw where did you get the info?

[HerpaDerp]

Blu-ray 4K is still going to be H.264

Are you talking about "mastered in 4k" or some futuristic Blu-ray product?

I can't imagine why HEVC wouldn't be used for 4K / 8K footage. Variable block sizes used in HEVC would mean 4K and 8K footage would look vastly superior when compared to H.264.

Can somebody shed some light on this?

[iwod]

I wonder why x264 folks hasn't shown any interest in HEVC. Are they going to making HEVC leverage some of their work in x264?

[sneaker_ger]

Maybe they just haven't made their interest public?

Also, even if they are working on an h265 implementation in the background, you can't be sure it will be free and/or open-source. The current main dev joined the existing open-source x264 project as a student IIRC, so he might now want to make more money with his experience. Of course getting an x264-grade implementation that is available through multiple licenses (one being open/free) would be awesome, but that's not for us to decide.

[thebombzen]

Variable block sizes and blocks up to 64x64 (I think, correct me if I'm wrong) and other features give HEVC way more flexibility than H.264. If x264's methods are ported to HEVC then it won't be a state-of-the-art encoder because HEVC gives so much more freedom than H.264.

[mandarinka]

It seems that Mainconcept SDK with HEVC encoding support is also out.

[thebombzen]

I can't comment on the rest of it, but
x264 appeared some time in (late?) 2004, didn't start getting a lot of attention until 2005

That's about 2-ish years since H.264 was released, so should we expect about two years for a good free & open-source HEVC encoder, if at all? Sooner?

[paradoxical]

While on Wikipedia it says that many companies are now putting their feet forward in the HEVC market, does anyone have an estimation for free and open-source (BSD, (L)GPL, etc.) decoders or encoders?

You mean other than HM which is both free and open source?

[thebombzen]

You mean other than HM which is both free and open source?

HM is from the Fraunhofer institute IIRC (I downloaded mine from hhi.fraunhofer.de), and I don't expect Fraunhofer products to remain free as in freedom, at least for binaries. I'm not a license expert so if anyone can correct me on this topic then please do, but fdk-aac binaries are nonredistributable and Fraunhofer even went so far as to try to require distributers of MP3-format files to pay royalties. I'm not sure exactly if HM binaries are redistributable (I'd be thrilled if HM was as free as x264) and when I said "free and open-source" I mean as free as it gets as in x264, FFmpeg, or the Linux Kernel. If HM really is this free, then that's a bonus but to the best of my knowledge this is not the case.

[Dark Shikari]

HM is free as in freedom, as far as I know (patents aside); more practically though, it's about 3-4 orders of magnitude too slow to be useful and missing a lot of user-facing features.

[thebombzen]

HM is free as in freedom, as far as I know (patents aside); more practically though, it's about 3-4 orders of magnitude too slow to be useful and missing a lot of user-facing features.

HEVC was originally supposed to be only around 1/2 to 3 times more computationally complex than H.264, which begs the question of why HM is so slow compared to H.264 implementations. Even though Modern H.264 implementations have had 10 years, I've seen x264 encode literally 100 times faster than HM, which is a far cry from the three-times-the-complexity target. It doesn't make sense that it's this slow, even though it's so new.


The preliminary requirements for NGVC was the capability to have a bit rate reduction of 50% at the same subjective image quality compared to the H.264/MPEG-4 AVC High profile and computational complexity ranging from 1/2 to 3 times that of the High profile. NGVC would be able to provide 25% bit rate reduction along with 50% reduction in complexity at the same perceived video quality as the High profile, or to provide greater bit rate reduction with somewhat higher complexity.

[nevcairiel]

HM is a reference encoder, its not optimized much at all. Comparing it to x264 is rather pointless, if you want you can compare it to JM (the H264 reference encoder), but even that may not be a useful comparison, depending on implementation details.

[qyot27]

HM is free as in freedom, as far as I know (patents aside)
Specifically, it's under the 3-clause BSD. Right from the code itself:
http://hevc.kw.bbc.co.uk/svn/jctvc-a124/trunk/COPYING

HM is a reference encoder, its not optimized much at all. Comparing it to x264 is rather pointless, if you want you can compare it to JM (the H264 reference encoder), but even that may not be a useful comparison, depending on implementation details.
Have there been any comparisons between the performance of HM vs. JM? Or is that just too masochistic to think about?

I'd be surprised if HM is actually faster, but if that's true, the development model it has may have affected that. Considering that it took upwards of 15 minutes to generate 360-some-frame, 848x480, 14-bit samples with JM, and that was on a Core i5 and only after breaking the video up into four separate pieces so it could be run in parallel. At that kind of performance level, describing the speed as 'glacial' counts as a bit of a compliment.

[pieter3d]

HEVC was originally supposed to be only around 1/2 to 3 times more computationally complex than H.264, which begs the question of why HM is so slow compared to H.264 implementations. Even though Modern H.264 implementations have had 10 years, I've seen x264 encode literally 100 times faster than HM, which is a far cry from the three-times-the-complexity target. It doesn't make sense that it's this slow, even though it's so new.

HM is slow to encode, but a fast HEVC decoder can certainly be written. I've seen a pure-software decoder smoothly playing 1080p30 on an iPhone5.

[benwaggoner]

Guys/gals, the discussion is a good one, but there's no need to get personal. Please keep it on topic. Thanks.

Yeah.

All, bear in mind x264 devs have contributed x264 technologies and techniques to x262, xvid, and xvp8. In my experience with them, including DS, they are much more pragmatic than religious, and care more about making ever-better looking video than about any particular bitstream or feature.

I would be startled if at least some core x264 contributors weren't already making plans around HEVC. And lots of the good things about x264 are quite applicable to HEVC. A lot could be done just by swapping out parts of the reference encoder with adapted x264 bits. It wouldn't be a fully optimized encoder, but it certainly wouldn't take years to have an encoder that reliably gives better quality than x264 at non-glacial encoding speeds.

[Guest]

I have moved the trolling and related discussion to this (closed) thread:

http://forum.doom9.org/showthread.php?t=168116

Please do not troll or feed trolls in this thread because at this point any followups to it here would likely violate rules 3, 4, 11, and/or 16.

Thank you for your understanding.

[thebombzen]

Thank you.

Anyway, how much gain can we really expect from CTUs dividing into CUs in practicality, rather than in theory? I found a good description of CTUs/CTBs/CUs/CBs on this PDF from the HHI, if it helps:
http://iphome.hhi.de/wiegand/assets/pdfs/2012_12_IEEE-HEVC-Performance.pdf

Will 32x32 and 64x64 CTUs improve compression that much? Or will most of the gain come from the additional encoder flexibility with variable-size non-grid CUs within CTUs? Also, will the additional encoder flexibility allow for encoders which are much, much better than the bitstream format devs expected? x264 is a very good encoder for H.264, better than the H.264 devs expected, but I'm worried it's reached a point where it doesn't have any additional bitstream flexibility to allow it to improve (the x264 devs can give me an opinion on this, I'd be glad to be wrong.)

TL;DR: How much difference does the additional flexibility really make?

[benwaggoner]

Thank you.

Anyway, how much gain can we really expect from CTUs dividing into CUs in practicality, rather than in theory? I found a good description of CTUs/CTBs/CUs/CBs on this PDF from the HHI, if it helps:
http://iphome.hhi.de/wiegand/assets/pdfs/2012_12_IEEE-HEVC-Performance.pdf
Overall, there's no One Big Thing that makes HEVC so much better. It's the aggregation of lots of little things.

Will 32x32 and 64x64 CTUs improve compression that much? Or will most of the gain come from the additional encoder flexibility with variable-size non-grid CUs within CTUs? Also, will the additional encoder flexibility allow for encoders which are much, much better than the bitstream format devs expected? x264 is a very good encoder for H.264, better than the H.264 devs expected, but I'm worried it's reached a point where it doesn't have any additional bitstream flexibility to allow it to improve (the x264 devs can give me an opinion on this, I'd be glad to be wrong.)

Those big CTUs are likely to be quite helpful for 4K/UHD resolutions.

[dapperdan]

When the trolling got cut out, we also lost a link to a blog comparing hevc and x264, which wasn't particularly interesting in itself but had a link to this recent paper which was:

https://ece.uwaterloo.ca/~z70wang/publications/vpqm13.pdf

The basic gist is that all the standard objective frame by frame analysis methodologies (psnr, ssim etc.) may systematically, and substantially, underrepresent the improvements in HEVC over its predecessor.

[Bathrone]

This bloke has updated his posts and says that this month he will have a new code release out:

https://code.google.com/p/x265/

[benwaggoner]

Can we please have some comments from Dark Shikari and/or akupenguin (or other appropriate x264 developers) regarding if they are already working on an open-source H.265 encoder?
Do note that if one or both are doing something, it could well be under NDA, and thus they might not be able to respond one way or another.

[Dark Shikari]

There is something in the works, and hopefully you're hear about it soon. Keep in mind that this is going to take years to produce a good encoder if ever, just like with x264. It's not going to be ready to displace H.264 by Christmas.

I also kind of don't feel like engaging trolls, so...

[Dark Shikari]

"Using x264 as a base" is not a magic silver bullet that makes developer-years of work go away. It might be called x265; last I recall the domain and trademark had been taken care of.

[phate89]

"Using x264 as a base" is not a magic silver bullet that makes developer-years of work go away. It might be called x265; last I recall the domain and trademark had been taken care of.

Sure but years of experience (especially with psychovisual enhancements) with x264 is a better start point right?
Are you planning some in-depth analysis of the standard like you did with vp8 in your diary of x264 dev?

[thebombzen]

Sure but years of experience (especially with psychovisual enhancements) with x264 is a better start point right?
Are you planning some in-depth analysis of the standard like you did with vp8 in your diary of x264 dev?

My guess it is will help some but not as much as everyone would like. HEVC is not H.264 so different enhancements might still look good but some other equivalent quality enhancement will compress much better. That's what this kind of encoder research is for :D

[Dark Shikari]

Years of experience gives some guidance in experimentation and optimization, but you still have to build the software in the first place and make it fast, clean, and efficient, and that alone is many developer-years of work. Applying smart algorithms and knowledge gleaned from x264 comes after that, and still, it's just guidance; H.265 is very different from H.264.

[easyfab]

I agree It will take years for a good H.265 encoder ( i.e ~50% bitrate for the same H.264 quality )
But I hope the first generation of H.265 encoder will quickly at least be as good as current H.264 encoder in bitrate/speed/quality.

[Dark Shikari]

Keep in mind that it took until 2007-2008 for x264 to consistently beat Xvid (the previous generation), and H.264 came out in 2003. I don't want people to get their hopes too high, or else everyone's going to be disappointed.

[Bathrone]

Heres a group with a free HEVC software decoder for windows:

http://xhevc.com/en/hevc/decoder/download.jsp

Divx have a patch out for mkvtoolknix to add their divx HEVC profiles to the toolset. They also reckon they are close to releasing a HEVC decoder and their own encoder.

[JEEB]

Heres a group with a free HEVC software decoder for windows:

...
I think these are the guys that kierank caught using libavcodec stuff without properly dealing with it even under the LGPL. I wouldn't give these guys too much publicity here.

Also, I really didn't want to put the same stuff in a yet another thread (we already have HEVC general (http://forum.doom9.org/showthread.php?t=165673) and Available HEVC/H.265 test encoders (http://forum.doom9.org/showthread.php?t=166586) threads, as well as some other random ones...), but there is a libavcodec HEVC decoder (https://github.com/smarter/libav/commits/hevc) by smarter that is by now in a pretty good condition. It has been forked by OpenHEVC (https://github.com/OpenHEVC/libav/commits/hevc), and is also developed there (in a somewhat chaotic form).

OpenHEVC is then used by GPAC for their Osmo4 "mp4" player. GPAC happens to have one of the 14496-15 AMD2 (HEVC File Format, aka HEVC-in-"MP4") editors on their team, so they are currently the only ones who can implement it until the last draft is published (the newest draft currently public is from May 2012, and there seem to have been plenty of changes since). Since GPAC is not historically well known for implementing things well/correctly, no-one is copying their implementation, but instead waiting for the last draft to be published to implement it.

Divx have a patch out for mkvtoolknix to add their divx HEVC profiles to the toolset. They also reckon they are close to releasing a HEVC decoder and their own encoder.
They have a patch out for a WIP first draft of HEVC-in-Matroska. You can see the discussion related to it here (http://lists.matroska.org/pipermail/matroska-devel/2013-June/thread.html). I really should have noted that they should have also added the EXPERIMENTAL flag there, since so many people want to grab the extradata format from 14496-15 AMD2, which does not have its current draft released yet. Thus one should NOT think that HEVC-in-Matroska produced with their patched binaries will be compatible with what will end up being specified as the official mapping for HEVC in Matroska. Same warning of course goes for using the GPAC implementation of 14496-15 AMD2, as that can have bugs as well as the draft in general can change with time until the final draft gets published for the final ballot.

[iwod]

Keep in mind that it took until 2007-2008 for x264 to consistently beat Xvid (the previous generation), and H.264 came out in 2003. I don't want people to get their hopes too high, or else everyone's going to be disappointed.

Yes, sometimes i wish throwing in money would speeds things up a lot, then we could do a Kickstarter project.

[Bathrone]

I think these are the guys that kierank caught using libavcodec stuff without properly dealing with it even under the LGPL

Thanks for that. If they are abusing open source and it's a proven situation then those abusers should be named and shamed.

The topic of this thread is about HEVC decoders/encoders so its ontopic to discuss various implementations of that. I'm excited mate to hear about the libavcodec decoder and I'm a regular with ffmpeg so thats great :)

[BadFrame]

This bloke has updated his posts and says that this month he will have a new code release out:

https://code.google.com/p/x265/

Sounds interesting, there's mentioning of a commercial version, do you know if will this be like x264 where everything is open source but there is an option to purchase a proprietary licence, or will this be two versions where the commercial one is better?

Anyway, great hearing that the x264 devs have something cooking for h265, their track record speaks for itself.

[kentaru]

DivX has released their HEVC decoder.

http://labs.divx.com/node/127919

[smok3]

divx say they used this encoder;
https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/tags/HM-10.1/
(sources)

[clsid]

It only works in their crappy player and does not even support seeking yet.

[hajj_3]

meditek has support for hevc and vp9 in their future chips:

http://juggly.cn/wpjuggly/wp-content/uploads/2013/07/MediaTekMT6593.jpg

Mass production is in november so expect phones/tablets to have them early next year.

[mandarinka]

These things will usually be courtesy of other IP vendors, mainly the integrated GPU.

Imagination (PowerVR GPUs) already announced their decoder, and the interesting thing is that it is supposed to be capable of Main 10 (10-bit!) + 4:4:4 (http://www.imgtec.com/news/release/index.asp?NewsID=780).

[nevcairiel]

I didn't think HEVC even had a 4:4:4 profile yet.

[RBF]

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

[fumoffu]

There is also new encoder version from those guys http://code.google.com/p/x265/

I compiled the source with Visual Studio 2012, not sure if I did everything right but it seems ok. It's attached to this post if anyone wants to try it out. I'm a noobie in command line encoding (I have been doing everything in StaxRip so far) and have no idea how to use this ;P

[Selur]

isn't that one based on some old code and 'only' HM 8.0 compatible?

[fumoffu]

isn't that one based on some old code and 'only' HM 8.0 compatible?

yes it seems so, not sure why because some previous previews were HM 10.1
btw. it might by silly question but what is the difference between those HM? are they backward compatible? is this different version of a draft? I can't find any info on this.

[Selur]

it might by silly question but what is the difference between those HM?
https://hevc.hhi.fraunhofer.de/trac/hevc/query?group=status&milestone=HM-10.1 might help to shed some light on that
(browse the changelogs of the other milestones to see the other changes since HM 8.0; since some mention 'non-conforming bitstream' I would say that the bitstream of HM 8.0 isn't always standard conform.

[JEEB]

Sounds interesting, there's mentioning of a commercial version, do you know if will this be like x264 where everything is open source but there is an option to purchase a proprietary licence, or will this be two versions where the commercial one is better?

Anyway, great hearing that the x264 devs have something cooking for h265, their track record speaks for itself.
Just to note since some people seem to have trouble noting this:
The google code "x265" project has nothing to do with the x264 project, or most of its developers. It was started by a person who has a couple of commits (http://git.videolan.org/?p=x264.git;a=search;s=Min+Chen;st=author) in x264 from 2004, and looking at the repository logs it is a one-man-thing.

If there will/would be a "successor" to x264, it would be licensed under the same GPL + proprietary scheme that x264 has been licensed under for some years now. Which means that every change that goes into libx264 by a licensee must be provided to the developers, and these patches in most cases end up on a pastebin somewhere (and, if they are deemed generally useful, on the mainline repository of the project).

The idea is to not make it possible to make a closed source x264 that would be better than the GPL version. This project hosted on google code clearly goes against that idea, and mostly serves as a personal resume/CV for possible employers/buyers, with a fancy name that makes people think it's related to x264 :)

divx say they used this encoder;
https://hevc.hhi.fraunhofer.de/svn/svn_HEVCSoftware/tags/HM-10.1/
(sources)
Yes, MainConcept/DivX does have its own encoder as well, but HM was used for the currently available test clips IIRC. Reminds me that I haven't checked if their test clips actually contain Profile/Level information, as HM 10.1's example configuration files conveniently didn't have that set, and HM still was dumb enough not to warn about those fields not being set :) .

Missing those fields would pretty much make the stream(s) not compliant to the specification.

yes it seems so, not sure why because some previous previews were HM 10.1
btw. it might by silly question but what is the difference between those HM? are they backward compatible? is this different version of a draft? I can't find any info on this.
Because the person is not interested in releasing sources for his current stuff, that's all.

HM is the reference encoder/decoder implementation developed as an open source solution by multiple parties. Patches are generally welcome from all people. It usually lagged somewhat behind the current specifications (drafts), and was incompatible with the final bit stream until after the release of version 9.2. Version 10.1 was generally "OK" as long as you remembered to add the Profile and Level settings, and version 11 is the current release. Thus, an encoder that is "compatible with HM 8" hasn't been really useful for quite a while now :) .

I have been pushing out Win32 binaries of HM releases built with MSVS 2010 on the "available test encoders" thread (http://forum.doom9.org/showthread.php?p=1632870#post1632870), which also contain the versions of the standard configuration files for that release.

Strongene HEVC/H.265 Encoder
I linked that on a libavcodec-related channel yesterday, and it resulted in kierank seemingly sending another angry message towards these guys.

[BadFrame]

Just to note since some people seem to have trouble noting this:
The google code "x265" project has nothing to do with the x264 project,
Ah, yes, reading my post I realize that it may come across as being confused, however I was fully aware that the 'x265' project which was linked had nothing to do with the h265 project which DarkShikari of x264 fame mentioned is being developed/planned.


This project hosted on google code clearly goes against that idea, and mostly serves as a personal resume/CV for possible employers/buyers, with a fancy name that makes people think it's related to x264 :)
Yeah, my question was directed at this project, with reference as to how the x264 devs does it (as you aptly described above), judging from what you say this project doesn't seem to follow that (x264's) principle, also a bit cheap to use the x26(x) name.

Very much looking forward to following the development of the x264 devs upcoming h265 implementation, here's hoping that in 3-4 years we can state that their h265 encoder is 'best in class' just like their h264 encoder is now.