x265 - Work already started?

[K.i.N.G]

Hype victim.

There are very few people willing to spend a week on a movie.

Not really, if the gains are big enough.

Do you know how long it takes to render a photorealistic image for some architecual design (what i partially do for a living), not to mention render special effects for some movie or an entire CG movie?

It always makes me smile when i see some comments on here from ppl complaining about 2fps encodes on their laptops.

A movie only needs to be encoded once for disc distribution. After that its just copies. So what even if it takes a whole weekend. Is that really such a big problem??

Sure, broadcasting and other areas where realtime encodes might be required is another story but i dont think thats the current target they have in mind. H264 is still more than capable (as mentioned many times here already). Its not because there is H265 that you suddenly arent allowed to use H264 anymore... And when the hardware catches up, switch to H265 if you want.

[kolak]

Few days is way to long. One night is maximum.

[kidjan]

There were more than a billion VCRs sold when DVD came out. There were more than a billion DVD players sold when BluRay came out. Did you fight against those things coming out as well? I really don't see how it's a different scenario other than you've just made an arbitrary line. H.264 deserves no special place of being considered irreplaceable versus any other video codec or format.

You're talking about the past. I'm talking about now. Apples and oranges.

Facts:

1. H.264 is still technically advanced--we're not talking about VCR or DVD quality, and to the best of my knowledge, very few people complain about well-encoded H.264 at 1080p. 4k, sure, whatever, but we're reaching a point of pretty significant diminishing returns, in my opinion. I don't get the impression the typical consumer cares.
2. H.264 has royalty issues. Those go away if you wait long enough. For how long are we planning on letting MPEG-LA hold companies over a barrel? At what point does optimizing along codecs no longer matter when bandwidth and storage space are consistently becoming less of an issue? (and if you think this is nonsense, consider nobody's really seriously cared about updating JPEG for a solid twenty years--because the savings simply don't justify the pain of updating the world)
3. Unlike previous codecs, H.264 really does enjoy an unprecedented amount of support. I cannot think of a previous format that is as ubiquitous. That alone makes it very hard to migrate away from: moving to something with effectively zero support while still maintaining support for old products isn't trivial.

I think over time, yes, H.265 and/or VP8 and/or VP9 will enjoy hardware support, but given the proliferation of H.264...codified as a standard among Windows 7, OSX, iOS, android, blue-ray formats, and so on....that's going to be a lot more difficult than it's previously been, particularly given that the value-add (making already great looking video look....better?) is hard to communicate to a typical customer.

My point really boils down to: there's a diminishing return on investment with these video codecs, particularly given some realities about royalties, network speeds, storage requirements and so forth. I feel we're already near it with H.264, and at some point....it's just a royalties carrot on a stick.

[benwaggoner]

1. H.264 is still technically advanced--we're not talking about VCR or DVD quality, and to the best of my knowledge, very few people complain about well-encoded H.264 at 1080p. 4k, sure, whatever, but we're reaching a point of pretty significant diminishing returns, in my opinion. I don't get the impression the typical consumer cares.
Consumers don't even know about bitrate directly. However better compression makes for better quality at given bandwidth (which can enable new features like 3D and 4K), or lower bandwidth at the same quality, or a mix of the two. As metered and capped bandwidth becomes more common, more efficient compression will always be useful.

HEVC will also bring 10-bit decoding mainstream; a quality improvement that H.264 High Profile can't deliver at any bitrate.

2. H.264 has royalty issues. Those go away if you wait long enough. For how long are we planning on letting MPEG-LA hold companies over a barrel? At what point does optimizing along codecs no longer matter when bandwidth and storage space are consistently becoming less of an issue? (and if you think this is nonsense, consider nobody's really seriously cared about updating JPEG for a solid twenty years--because the savings simply don't justify the pain of updating the world)
H.264's royalty issues are primarily theoretical and philosophical. I'm not aware of any business and usage models that haven't emerged due to the MPEG-LA licensing terms. Clearly the H.264 licensing costs are far, far less important than the cost savings from more efficient encoding. Otherwise Theora would have mattered.

3. Unlike previous codecs, H.264 really does enjoy an unprecedented amount of support. I cannot think of a previous format that is as ubiquitous. That alone makes it very hard to migrate away from: moving to something with effectively zero support while still maintaining support for old products isn't trivial.
MPEG-2 was more ubiquitous than any codec before or since. It probably counted for >98% of eyeball hours of digital video last decade. DVD+cable+sat+ATSC+DVB were all MPEG-2, and are still mainly MPEG-2.

MPEG-2 will still be widely used alongside H.264 and HEVC throughout this decade.

I think over time, yes, H.265 and/or VP8 and/or VP9 will enjoy hardware support, but given the proliferation of H.264...codified as a standard among Windows 7, OSX, iOS, android, blue-ray formats, and so on....that's going to be a lot more difficult than it's previously been, particularly given that the value-add (making already great looking video look....better?) is hard to communicate to a typical customer.
Again, it's not something that the customer would even know about. How many people know what Profile @ Level their handsets support today :)? But if you're a wireless carrier and blanching at the CAPEX predictions to handle the huge growth of wireless video, you're going to want every handset on your network to be able to consume the lowest bandwidth streams possible. Same with content distributors, who drop support for devices with less-capable decoders whenever they can get away with it.

Plus it's cheap to add another decoder to GPUs and processors, and getting cheaper every generation. Adding HEVC would increase device COGS by way less than higher clock speed or extra cores. The days of $100+ deadicated MPEG-2 cards is way gone. All video decoders take up a really small and shrinking area of the silicon on today's chips.

My point really boils down to: there's a diminishing return on investment with these video codecs, particularly given some realities about royalties, network speeds, storage requirements and so forth. I feel we're already near it with H.264, and at some point....it's just a royalties carrot on a stick.
If compression efficiency doesn't matter, how come the industry is continuously making big investments to improve their existing MPEG-2 and H.264 encoders? A 10% compression efficiency improvement is 10% more channels for Comcast, Dish, etcetera, and that makes for significant revenue for them.

Honestly, the H.264 royalties are barely a rounding error compared to what a content delivery company pays for their encoders, service, staff to maintain them, bandwidth, etcetera. HEVC royalties could be 10x as much as H.264 and would still be a huge net payoff just from bandwidth and storage savings.

The critical thing is that per-decoder license fees stay reasonable.

[kieranrk]

I agree to an extent but I don't think the addressable market will be anywhere as big as with MPEG-2 or AVC. Only green-field deployments and 4K are going to use it for DTH broadcasting, though a few European governments are mandating it.

Only web (including mobile) are going to be big consumers of HEVC and arguably the web doesn't have serious video bandwidth restrictions anyway. ARPU for web video is very low anyway.

HEVC won't bring 10-bit mainstream. There's a huge push against it from hardware manufacturers.

HEVC royalties could be 10x as much as H.264 and would still be a huge net payoff just from bandwidth and storage savings.
This is definitely not the case for operator-loaned STBs.

[benwaggoner]

I agree to an extent but I don't think the addressable market will be anywhere as big as with MPEG-2 or AVC. Only green-field deployments and 4K are going to use it for DTH broadcasting, though a few European governments are mandating it.
For OTA, broadcasting, sure. Huge decoder switching costs, which is why most of that is MPEG-2. South Korea has already done two rounds of OTA HEVC 4K already, though.

I think OTA is a pretty small and shrinking slice of viewership, though.

Only web (including mobile) are going to be big consumers of HEVC and arguably the web doesn't have serious video bandwidth restrictions anyway.
That is an argument you'd have to actually make. Until everyone in a household can reliably get 15 Mbps streams simultaneously, the web has serious bandwidth restrictions.

HEVC won't bring 10-bit mainstream. There's a huge push against it from hardware manufacturers.
Citation? That's not what I'm hearing for living-room devices. Mobile doesn't seem to have nearly as much taste for 10-bit, certainly.

This is definitely not the case for operator-loaned STBs.
Huge switching costs there, which is why they're mostly still getting MPEG-2 anyway. The bandwidth savings of MPEG-2 -> HEVC could make STB replacement cost-effective, however.

But video decoder license fees are a small fraction of a STB's cost, and are a lot higher and uncapped for MPEG-2 anyway. If license fees were a big deal, people would have stopped shipping MPEG-2 decode a long time ago (note that it's not in Win8 by default now). VC-1 and H.264 were both much, much cheaper at the time.

[kieranrk]

For OTA, broadcasting, sure. Huge decoder switching costs, which is why most of that is MPEG-2. South Korea has already done two rounds of OTA HEVC 4K already, though.

I think OTA is a pretty small and shrinking slice of viewership, though.

That is an argument you'd have to actually make. Until everyone in a household can reliably get 15 Mbps streams simultaneously, the web has serious bandwidth restrictions.


Improved compression isn't holding back any major product developments that will cause a significant revenue stream for web video (though perhaps so for mobile) - it's why a lot of places are happy sending the junk from Elemental "GPU" encoders after all. Apart from being an incremental improvement, what new revenue streams will HEVC bring in? H.264 brought in HD video on the web but in my opinion HEVC brings no new products to the table. I guess there's a possibility for 4K but I would imagine Hollywood would want to charge a premium for that and not give it away to Netflix. It's the same with MPEG-DASH; deployment is sluggish since the benefits don't appear to be financially worthwhile.

In most of the world STBs last for ~10 years or so; Korea is the special case in that there is a short upgrade period. All the more so when people have a lot of PVR'd recordings that can't be easily moved between STB (Device specific DRM).


Citation? That's not what I'm hearing for living-room devices. Mobile doesn't seem to have nearly as much taste for 10-bit, certainly.


I think it's public knowledge that there's a row going on about this in DVB, which will in effect set the global agenda for living room devices.


Huge switching costs there, which is why they're mostly still getting MPEG-2 anyway. The bandwidth savings of MPEG-2 -> HEVC could make STB replacement cost-effective, however.

But video decoder license fees are a small fraction of a STB's cost, and are a lot higher and uncapped for MPEG-2 anyway. If license fees were a big deal, people would have stopped shipping MPEG-2 decode a long time ago (note that it's not in Win8 by default now). VC-1 and H.264 were both much, much cheaper at the time.

Codec licensing fees are still not insignificant and are the basis of a lot of the audio codec STB wars (Dolby/DTS/AAC). Even on modern platforms there is still a lot of legacy MPEG-2. It's different in Win8 because end-users purchase the product, whereas STBs are given away for free and so a few dollars saved across millions of devices is worth saving, nobody is going to notice a few extra dollars on Win8 RRP.

[phate89]

I don't know when it was added, but one of the mirrors of x264.nl is http://x264.x265.net/

[mandarinka]

Because the guy who has that mirror booked the domain for future use by any FOSS x264-like HEVC encoder - it is explained if you go straight to x265.net.

[lucassp]

Here's something: https://bitbucket.org/multicoreware/x265/wiki/RoadMap

[Selur]

"Development of x265 began very recently (March 2013)" shouldn't this be March 2012 ?

[jkauff]

There's an article on Slashdot today about the release of a pre-alpha version of x265. It includes links to evaluations by Tom's Hardware and Extreme Tech.

http://tech.slashdot.org/story/13/07/23/164228/next-gen-video-encoding-x265-tackles-hevch265

[Guest]

Interesting. Thanks for the heads up!

[anonymlol]

Thanks for the link.

Here's a build: x265 23.07.2013 (x86).zip (https://mega.co.nz/#!fF51VYiD!VBnffARHirnKbDI7GrP9aAdKzEBU5Dl-7-BUjzChlwE)

[filler56789]

Thanks for the link.

Here's a build: x265 23.07.2013 (x86).zip (https://mega.co.nz/#!fF51VYiD!VBnffARHirnKbDI7GrP9aAdKzEBU5Dl-7-BUjzChlwE)

Your intention is good, but that URL does not work with Opera, nor with Internet Explorer 8.

[Bigmango]

Your intention is good, but that URL does not work with Opera, nor with Internet Explorer 8.

Link is working fine here with latest versions of Internet Explorer, Chrome, Firefox.

Seriously, who is using outdated browsers like IE 8 in 2013, and then posting on forums to complain about it?

Thanks for the links.

[mandarinka]

I saw some articles about x265 already, today. I guess the era of rapture has begun! :D

There is a piece written by Tom's hardware (http://www.tomshardware.com/reviews/x265-hevc-encoder,3565.html) and another one that is in czech language, so not much use unless you like google translate or something (link is here (http://www.cnews.cz/pristi-tyden-prijde-x265-oficialni-naslednik-enkoderu-x264-pro-format-h265) for those who understand that language.)

[xooyoozoo]

There's an article on Slashdot today about the release of a pre-alpha version of x265. It includes links to evaluations by Tom's Hardware and Extreme Tech.

http://tech.slashdot.org/story/13/07/23/164228/next-gen-video-encoding-x265-tackles-hevch265


From the Tom's Hardware article:

We could have used the --tune psnr switch to generate higher values, though this negatively affects subjective quality compared to the settings used here.

Which means that they didn't use tunings. By one line, they forwent any real analysis and trivialized their entire article, which can now be summarized as "why yes, this is a multithreaded HEVC encoder".

I forget how bewildering rookie codec comparisons can be.

Edit: Having issues compiling this on OSX 10.9 DP. Oh well, I'm gonna try the linked binary above on a Windows rig later.

[filler56789]

Link is working fine here with latest versions of Internet Explorer, Chrome, Firefox.

Seriously, who is using outdated browsers like IE 8 in 2013, and then posting on forums to complain about it?

Opera is NOT an outdated browser, and I did mention it.
But thanks for your pointless reply anyway.

[Selur]

from the "x265 Evaluation Guide 07-23-13.pdf":
SYSTEM REQUIREMENTS
Hardware: AVX capable CPU recommended
At least 8GB of RAM
Software: Win7/8 x86_64
Microsoft Visual C++ Redistributable Update 3assuming this is correct -> no x265 for me , since my i7 875k doesn't support AVX.

[mandarinka]

Oh, I missed that at first, but there is already an announcement (http://forum.doom9.org/showthread.php?p=1637971) in the news section of the forum.

from the "x265 Evaluation Guide 07-23-13.pdf":
assuming this is correct -> no x265 for me , since my i7 875k doesn't support AVX.

That's a recommendation - I'm pretty sure they won't explicitly require anything higher than SSE2 (SSSE3 at worst?).

[Guest]

Opera is NOT an outdated browser, and I did mention it.
But thanks for your pointless reply anyway. I'm not sure why you are trying to stir up trouble here, but if you continue there will be consequences. Please take any reponse to PM. Thank you.

[foxyshadis]

Wow, I completely missed that x265 was being commercially funded now, no wonder it's getting up to speed so quickly. The bleeding edge looks very promising, I just hope they can integrate Avisynth soon; at least they have Y4M, so you can use an ffmpeg intermediary instead of straight raw video.

[mandarinka]

I sort of got used to avs2yuv already (10-bit filtering, testing of VP9), so as long as that is supported, I guess it is relatively fine, input-wise.

[lainiwaku]

http://x265.org/

is it project from developer of x264 ??
or from the chinese guys project ??
https://code.google.com/p/x265/

[sneaker_ger]

is it project from developer of x264 ??
or from the chinese guys project ??

Neither. This seems to be from MulticoreWare as discussed a few posts above. Looks like many people want to benefit from x264's fame to promote their own project.

http://forum.doom9.org/showthread.php?p=1637971

/edit:
I stand corrected (see below).

[Dark Shikari]

MultiCoreWare's project is being made with the (very tentative) blessing of the x264 team. Unlike the others, as far as I know, it will actually be based on x264's source and algorithms and be a publicly developed open source project (e.g. something I could/might commit to). In other words, it exists as an open source project because I said "yes" to it :p (the alternative was a closed-source project unrelated to x264).

The intent is to link up with Videolan and friends, and there's already been quite a lot of back-room discussions, but it largely wasn't mentioned in the announcement because MCW didn't want to prematurely decide anything (they can only speak for themselves, not anyone else).

[smegolas]

is it project from developer of x264 ??
or from the chinese guys project ??
https://code.google.com/p/x265/

Neither. This seems to be from MulticoreWare as discussed a few posts above. Looks like many people want to benefit from x264's fame to promote their own project.

http://forum.doom9.org/showthread.php?p=1637971

Im pretty sure it is the Chinese guys project, and Multicoreware have gotten involved and/or made some code contributions.

[Sagittaire]

work here but it's really slow. Strongene_Lentoid_HEVC_Encoder work at ~1 fps on 1080p with C2D Q6600 at 2.4 Ghz.

[sneaker_ger]

Im pretty sure it is the Chinese guys project, and Multicoreware have gotten involved and/or made some code contributions.

I think lainiwaku wanted to know about x265.org, later mentioning "https://code.google.com/p/x265/" in the context of "the chinese guys project". "https://code.google.com/p/x265/" should indeed be from "the chinese guy" but I have not seen anything that lets me believe the two projects/sites are related to each other in any way (except being H.265 projects and sharing the same name). Then again I had no idea the MulticoreWare guys were in contact with the x264 and videolan teams...

/edit:
I stand corrected (see below).

[nevcairiel]

There are a bunch of commits from the "chinese guy" in the MCW x265 repository, so either they are working together, or they recycled some of his changes while keeping attribution.
However, it looks like they started with the HM encoder as a base, not the gcode x265

[sneaker_ger]

There are a bunch of commits from the "chinese guy" in the MCW x265 repository, so either they are working together, or they recycled some of his changes while keeping attribution.

Ah, I overlooked those. Would be great if we end up with a collaboration that results in a good free encoder.

[STaRGaZeR]

MultiCoreWare's project is being made with the (very tentative) blessing of the x264 team. Unlike the others, as far as I know, it will actually be based on x264's source and algorithms and be a publicly developed open source project (e.g. something I could/might commit to). In other words, it exists as an open source project because I said "yes" to it :p (the alternative was a closed-source project unrelated to x264).

The intent is to link up with Videolan and friends, and there's already been quite a lot of back-room discussions, but it largely wasn't mentioned in the announcement because MCW didn't want to prematurely decide anything (they can only speak for themselves, not anyone else).

So who's the project leader, or the one who decides what makes it to the repository and what not? Since there's a company and money involved...

[Dark Shikari]

It's kind of unclear at the moment; from what I recall they intend to add a few external committers and use a more x264-esque development model now that the code is released, but really, I suppose we'll basically wait and see what happens. Hence the tentative endorsement!

[dapperdan]

There are a bunch of commits from the "chinese guy" in the MCW x265 repository, so either they are working together, or they recycled some of his changes while keeping attribution.

Both projects (the google code one and the Multicoreware one) are using a dual GPL with a commercial licence option, so they can't use his changes unless they've come to some arrangement with him.

[turbojet]

It's nice to see the 3 parties trying to work together instead of fighting over the name 'x265'. It looks like Multicoreware has projects focused on opencl/cuda which brings some hope to achieving high quality, higher speed encoders in the future.

[x265_Project]

Hello everyone! I'm sorry for showing up late to the discussion, but I just created this account on Friday, and there is a 5 day waiting period before you can post messages.

As sborho (our lead developer) posted in the News section, MulticoreWare is excited to lead this project.

It is quite challenging to balance the needs and demands of our commercial customers (who are funding the development work) with the needs and desires of the open source community, but we are hopeful that we can manage the project in a way where everyone can benefit.

We will do our best to listen and learn, and answer questions to the extent possible.

Tom Vaughan
MulticoreWare

[Guest]

Welcome to the forum and thank you for your contributions!

[BadFrame]

It is quite challenging to balance the needs and demands of our commercial customers (who are funding the development work) with the needs and desires of the open source community, but we are hopeful that we can manage the project in a way where everyone can benefit.

We will do our best to listen and learn, and answer questions to the extent possible.

Here's hoping you will be able to provide this encoder under the same conditions as that of x264, fully open development and free to use according to an open source licence with additional licencing available for proprietary needs.

Thanks and good luck with the project, I will certainly enjoy following it.

[x265_Project]

Thank you for the warm welcome!

We are committed to offering x265 under both commercial and GPL 2 licenses, following the successful business model of x264. We will manage the open source side of the project in a way that is as fair and open as is reasonably possible.

MulticoreWare and developers have contributed to and managed a number of open source projects, and we are confident that the rest of the open source development community will appreciate the way that we manage this project. We welcome talented developers to join the project, and we will support them fully.

Tom
MulticoreWare

[xooyoozoo]

I got some time to test x265 on an old Windows Core 2 Duo using the ref pdf's settings (and bframes) and using a couple 1080p JCTVC test clips. There hasn't been any qualitative comments on x265, so I'll offer a few cursory ones.

Quality via MS-SSIM is roughly mid-teens percentage worse than anchor HM11 (parkscene, cactus). MS-SSIM quality versus VP9-cpu-0 on same clips (w/ 1 sec keyints) is strictly better. Subjective quality versus VP9-cpu-0 is distinctly better at QP32, mainly through temporal stability.

Speed on 2-thread x265 is comparable to single-threaded VP9-cpu-1 (https://groups.google.com/a/webmproject.org/d/msg/webm-discuss/bbMo00Gvops/-WyXm5dZQI4J), which is then comparable to multithreaded x264 placebo on this system.

All in all, I'm quite impressed by initial results. :)

Edit:

Ignoring the reference pdf's speed-focused switches will bring x265 almost right on top of anchor HM11 quality. On dual core, speed is now ~halfway between VP9-cpu-0 and cpu-1. Oh, and these were built with latest 8/2/13 commits.

[Sagittaire]

x265 is pre-alpha build. You can't use multithread encoding because quality will be very lower in this case. With best quality profil, x265 must have higher quality than HM11 ...

PS: Which decoder are you using? which muxer are you using? thank's

[xooyoozoo]

Well, I was purposefully vague because everything here is still quite transient. My fluffy definition of "almost right on top" quality-wise was low single-digit percents. According to the docs, that should more than account for WPP's slight quality cost (http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=2740) (<1% for 1080p).

I've had a good experience with GPAC for muxing/playing, but for the above, I've been using reference HM decoder, which also seems to match x265's internal yuv dump.

[gnaggnoyil]

I've just got MultiCoreWare's x265 source code and built a 8bit version successfully using i686-pc-mingw32 and x86_64-w64-mingw32 on win 7. However there is no "install" instuctions in the makefile generated by cmake. So what execuatables, libraries and headers should I copy in order to "install" it, I mean, to use the x265 library just like how x265.cpp use it? Or x265 just isn't planning to offer a library for other developers to use right now?

BTW: Why the file size of the x265 executable generated by mingw/gcc and MSVC differ so much? The former is about 4-5MB file size and the latter is only about 1.5MB file size...

[easyfab]

I think MSVC is shared ( you need Microsoft Visual C++ Redistributable Update 3 ) and MinGW is static.
Perhaps try to select STATIC_LINK_CRT in cmake to see the difference

[gnaggnoyil]

I think MSVC is shared ( you need Microsoft Visual C++ Redistributable Update 3 ) and MinGW is static.
Perhaps try to select STATIC_LINK_CRT in cmake to see the difference

I can make sure that crt is static linked using MSVC. STATIC_LINK_CRT is set true and the generated executable can run without Microsoft Visual C++ Redistributable.

And the executable is just 1.5MB file size.

https://photos-1.dropbox.com/t/0/AACr1e2PDITSI42j017RAFcF5eEWVrf7sVZ-ZURb-3QnpQ/12/18877564/png/2048x1536/3/1375729200/0/2/snapshot1.PNG/Il5CrnT8u--kX5iRI4-h_TOwDTJTyjOZUJIkA7r-_Uc

[Guest]

Isn't x265 GPL? If so you have to supply the source code as well, per GPL. Failure to comply will result in your posts being deleted. Also, no foreign languages in your signature. Thank you.

[nevcairiel]

He just created a vanilla build with a special flag on the build command line, how does that require sources? o.O

[gnaggnoyil]

Isn't x265 GPL? If so you have to supply the source code as well, per GPL. Failure to comply will result in your posts being deleted. Also, no foreign languages in your signature. Thank you.

sorry i didn't thought that it is a kind of "redistribution". i've uploaded a screenshot instead.

[foxyshadis]

sorry i didn't thought that it is a kind of "redistribution". i've uploaded a screenshot instead.

It is, but the GPL actually only requires "source code on request"; pointing to the exact git revision on bitbucket would satisfy the requirement, unless you applied any patches.