x265 HEVC Encoder

[Tommy Carrot]

I am not sure I agree with that, my memories of the beginning years of x264 involve a lot of people worried about detail loss compared to Xvid. We also thought x264 might never be able to keep detail as well as Xvid. If is funny how these x265 vs x264 comparisons seem almost identical to how I remember the early x264 vs Xvid comparisons. Déjà Vu ;)

How many years did it take x264 to be better than Xvid at all bitrates? I remember long periods of only speed improvements for x264 as well.
Sure, it couldn't compete with xvid for a long time, but as far as i remember it always improved bit by bit. I don't think there was such a long period of time when the efficiency/quality didn't improve at all.

[benwaggoner]

I think the reason some of us is a bit 'sceptical' about x265 is because the efficiency/visual quality just hasn't improved for a long time. When i compare the quality of the latest build to several month old ones, it just isn't conclusively better (with the psy-rd off, it often loses to more than a year old builds). I get that improving the visual quality of something as complex as HEVC is a very difficult task, but x264 was always steadily improving quality-wise in the first few years (albeit from a lower starting point).
I've found x265 get a LOT better over the last 12 months for some core scenarios of interest to me.

For example, UHD encoding of film content. Quality of encodes with heavy grain are enormously better than even three months ago with the addition of --tune grain and other lower-level improvements.

I find x265 very consistently produces substantially higher quality than x264 at the same bitrate for UHD resolutions.

[easyfab]

Ok x265 can greatly improve in future but is there also possible that H.264/x264 encoder can improve (a little) more, like mp3/lame years latter. I know x264 team doesn't commit quality improvement recently but in theory could quality be even better than current placebo preset ? is there some new approach/method from newer standard than can be backport without breaking H.264 compatibilty?

[Tommy Carrot]

I've found x265 get a LOT better over the last 12 months for some core scenarios of interest to me.

For example, UHD encoding of film content. Quality of encodes with heavy grain are enormously better than even three months ago with the addition of --tune grain and other lower-level improvements.

I find x265 very consistently produces substantially higher quality than x264 at the same bitrate for UHD resolutions.

I guess x265 benefits from the larger transform sizes the most for very high resolution content, so it's quite possible that it's capable of beating x264 there, but for usual SD/HD content, they have much lesser effect, that's why x265 is less impressive there. Things like --tune grain helps a bit in some cases, but not enough to beat x264.

I've tested x265 mainly on dvd sources, 720p videos and a few short 1080p samples (i'm using veryslow and placebo presets because i'm currently interested in what's the maximum quality/efficiency x265 is capable of, and these are very slow at higher res). And in my tests, unfortunately i didn't see any real improvement in quality for a long time.

[x265_Project]

I guess x265 benefits from the larger transform sizes the most for very high resolution content, so it's quite possible that it's capable of beating x264 there, but for usual SD/HD content, they have much lesser effect, that's why x265 is less impressive there. Things like --tune grain helps a bit in some cases, but not enough to beat x264.

I've tested x265 mainly on dvd sources, 720p videos and a few short 1080p samples (i'm using veryslow and placebo presets because i'm currently interested in what's the maximum quality/efficiency x265 is capable of, and these are very slow at higher res). And in my tests, unfortunately i didn't see any real improvement in quality for a long time.
I wouldn't interpret Ben's comments to mean that x265 is only beneficial at UHD resolutions. We see consistent benefits over H.264 encoders at all resolutions for all types of content.

The big difference between what you are doing and what Ben is doing is that a professional over-the-top streaming video service will typically receive a very high quality (lossless or near-lossless) version of each title. We work with movie studios and streaming movie services, and we often receive samples of the content they are encoding. Typically these are either very high bit rate ProRes encodes (very little compression) or losslessly encoded files (JPEG-2000 lossless still image sequence). The quality of these source files is astonishing. The file size is also astonishing.

With source content compressed (with MPEG-2 or H.264) to consumer bit rates, you will be feeding x265 a distorted version of the original. Although you can compare different encoders this way, it's not ideal, as x265 will not have the level of spatial detail and motion accuracy needed to do accurate motion-compensated prediction (where encoders get the vast majority of their efficiency). In effect, x265 will be trying to accurately encode all of the artifacts left by the first encoding process. If you want to run some x264 vs x265 comparison tests at lower bit rates, it would be best to start with higher quality material (either high bit rate content in a camera format like DV or AVCHD, or uncompressed source from a site like media.xiph.org (http://media.xiph.org/)). A Blu-ray rip wouldn't be a bad source, as it is fairly high bit rate. But the best source for testing encoders is a high quality scanned image sequence from analog film or an acquisition format straight from a high quality video camera (HDCAM SR, HDCAM, DVCPRO HD 100, XDCAM HD, XDCAM, XAVC, HDV, AVCHD, etc.).

[Tommy Carrot]

I'm using lossless y4m samples (from xiph.org and from some other sources) and fairly high quality VOBs. I don't think the quality of the sources is the problem here. X265 is artifact-free, but the fine details are smoothed out, the video looks "too clean", as Stargazer said, almost like a low-pass filter. X264 has some artifacts, but it preserves the fine details better.

Of course there are some instances where x265 is better, like cartoons (where the lack of ringing is a huge asset), or very low bitrate encodings, or, as Benwaggoner said, 4k content, but for ordinary uses, i cannot say that to be true.

But anyway, that's not my point. I'm perfectly fine with the fact that x265 in this phase cannot beat x264 in every circumstances. My issue is the lack of improvements in visual quality. I see in the changelog that x265 is very actively developed, there are hundreds of commits every week, but still, when i compare the latest build with the older ones, the quality just doesn't seem to be improving. It seems most of the efforts are going for speed/memory optimizations. Which are very good, no doubt, but i think if you want x265 to be widely used, it needs to beat x264 convincingly, so in my opinion quality/efficiency improvements should be the main priority.

[x265_Project]

I'm using lossless y4m samples (from xiph.org and from some other sources) and fairly high quality VOBs. I don't think the quality of the sources is the problem here. X265 is artifact-free, but the fine details are smoothed out, the video looks "too clean", as Stargazer said, almost like a low-pass filter. X264 has some artifacts, but it preserves the fine details better.

Of course there are some instances where x265 is better, like cartoons (where the lack of ringing is a huge asset), or very low bitrate encodings, or, as Benwaggoner said, 4k content, but for ordinary uses, i cannot say that to be true.

But anyway, that's not my point. I'm perfectly fine with the fact that x265 in this phase cannot beat x264 in every circumstances. My issue is the lack of improvements in visual quality. I see in the changelog that x265 is very actively developed, there are hundreds of commits every week, but still, when i compare the latest build with the older ones, the quality just doesn't seem to be improving. It seems most of the efforts are going for speed/memory optimizations. Which are very good, no doubt, but i think if you want x265 to be widely used, it needs to beat x264 convincingly, so in my opinion quality/efficiency improvements should be the main priority.
Hi Tommy - sorry if I misunderstood how you're doing your tests. Certainly, H.265 is a very different coding method than H.264, and we're working with larger block sizes which could have more of a tendency to reduce detail than smaller block sizes. But I think if you're using a sufficient psy-rd strength (at least 0.3), you shouldn't see any lack of detail vs. x264. Let us know if this is not the case.

[Boulder]

To me it seems that --tune grain brings x265 closer to x264 what comes to detail retention. I tested --psy-rd 0.3 --psy-rdoq 1.0 shortly with my Hot Fuzz sample but it still showed a too clean image compared to x264.

[jlpsvk]

Try --psy-rd 0.5 and --psy-rdoq 5.0, looks much better I think.

[LigH]

Coming x265 versions will support zones for bitrate distribution tuning:

--zones startframe,endframe,{q=quant|b=bitrate_factor}[/…]
__

HEVC (https://www.mediafire.com/#6lfp2jlygogwa) / x265 1.4+417-a0c084eff60f (https://www.mediafire.com/download/v5qebxazcb96eqv/x265_1.4+417-a0c084eff60f.7z)

[VelleX]

i agree to Boulder

I downloaded a lossless y4m 2160p50 sample and encoded it to 1080p50 with x264 and x265.
x264 with crf22 still has more grain at almost same bitrate than x265 with crf20 --veryslow --tune grain (which results in psy-rd=0.50 / psy-rdoq=30.00)

Also tested with my 300 Bluray with about the same result. x265 image is too clean compared to x264.

[benwaggoner]

i agree to Boulder



I downloaded a lossless y4m 2160p50 sample and encoded it to 1080p50 with x264 and x265.

x264 with crf22 still has more grain at almost same bitrate than x265 with crf20 --veryslow --tune grain (which results in psy-rd=0.50 / psy-rdoq=30.00)



Also tested with my 300 Bluray with about the same result. x265 image is too clean compared to x264.


Can you share the command lines you used for each?

And also a link to the source, if you can share that.

For noisy UHD content, I've found --pay-rd 1.0 can work better at UHD frame sizes.

Also, tune-grain is for quite noisy content, it's not the equivalent of x264 --tune film. Which would be a great addition to x265...


-Ben Waggoner (via TapaTalk)

[stax76]

I just wanted to let everybody know that StaxRip's x265 support is now completed
with 80+ GUI supported switches, it has an edge over MeGUI here. :D

http://forum.doom9.org/showthread.php?p=1707154#post1707154

[LigH]

Well, nice, but ... which x265 version do you refer to? Tomorrow there may be 2 or 3 different switches, who knows. ;)

But glad to see you are (still|again) in business. :)

[stax76]

Well, nice, but ... which x265 version do you refer to? Tomorrow there may be 2 or 3 different switches, who knows.

There is a apps dialog that lists all apps with version, I thought it would be interesting for people to know exactly what's in so for x265 currently it displays '1.4+285 - MSVC 1800 - x265.ru' and includes 4 different builds 64/32/10/8 bit, that what requested a lot. It's easy to replace the included build, the x265 page in the apps dialog has a toolbar button to open the folder where it's located, once it's replaced with identical filename StaxRip will report an issue because it validates it's date but there is a hidden feature, F12 (documented with F1) brings up a input box to modify the version string and update the stored date.

Once the GUI was completed I've saved the documentation it was based on (http://x265.readthedocs.org/en/default/cli.html) so I can use a diff tool to catch changes. Changing my code then will be simple because everything related to a switch is defined in one place, GUI, command line and help are then generated and wired together automatically. I hope to get some feedback about changes and issues and that it's not too limiting the GUI is built dynamically/automatically and not handcrafted, the x264 GUI looks good but was tedious to build with a lot more code, 5000 lines code for 66 switches, every switch has code in 8 different locations, compared to 1500 lines code for 80 switches with every switch defined in one place for x265. Building a complete handcrafted GUI with that many switches would be a boring to death task.

But glad to see you are (still|again) in business.

Glad to see many doom9 veterans still around too. :)

[Kurtnoise]

It's useless imo to give access to all available switches. This is not a job for a GUI in this case. There are presets for that. That's more simple. Period.

Also,
I thought it would be interesting for people to know exactly what's in so for x265 currently it displays '1.4+285 - MSVC 1800 - x265.ru' and includes 4 different builds 64/32/10/8 bit, that what requested a lot.
Really ? Give me a link for that or a reference please...just curious because, I'm pretty sure that people don't know exactly what this entry ['1.4+285 - MSVC 1800 - x265.ru'] means. Even if they know, it's not useful for encoding.

Moreover, if some people create some builds within 12/16 bits support, do you think you will add them alsot ? Come on, it's a wasting time.

[LigH]

Another weekly build: x265 1.4+424-2b93cf2a5ac8 (https://www.mediafire.com/download/dqcy6bc746fnmf2/x265_1.4+424-2b93cf2a5ac8.7z)

[stax76]

@Kurtnoise

Not all of this makes sense to me either but I acknowledge it might make sense to somebody else and as long as it don't hurt me I let everybody use there bits, switches, GUI, religion or whatever. Glad to see you still around too btw. though I've seen you in better mood before.

[Carpo]

How viable would you say x265 is at this time for replacing x264 for use in a personal backup work flow? I see some companies are already using it for some streams/videos, or would you be better of waiting for a few present/up coming options to be tweaked first?

I haven't looked too deeply into it yet, but did a quick test with a music video from my of my dvd's (it's short and doesn't take long to encode, even when using QTGMC) and it did look cleaner with better colour's, to my eyes anyway, is two pass implemented yet, if not any idea of when that might be?

[Farfie]

Hey there,
Using the build from builds.x265.eu, from the 25th of this month, x64 10bit:
As the scene pans down, follow the text as it crosses from the wall to the floor. This was --preset veryslow --psy-rd 1.2
https://mega.co.nz/#!aVV1WRiB!YK87AIHylNi81wODJYbqh1aHRyPh7-3JMPBLY_mmGxI

Of course, even x264 still does this to a degree, but it looked particularly bad at one point.

Cheers.

[Ge'in]

Your psy-rd value is too high at this low bitrates.
Try with lower value, something around 0.3-0.5

[foxyshadis]

How viable would you say x265 is at this time for replacing x264 for use in a personal backup work flow? I see some companies are already using it for some streams/videos, or would you be better of waiting for a few present/up coming options to be tweaked first?

I haven't looked too deeply into it yet, but did a quick test with a music video from my of my dvd's (it's short and doesn't take long to encode, even when using QTGMC) and it did look cleaner with better colour's, to my eyes anyway, is two pass implemented yet, if not any idea of when that might be?

The lower you want to push the bitrate, the more useful it'll be to you. If you're looking for visually identical to the source, my experience is that they both take up a lot of room to get there. If you're looking to save a lot of space and don't mind some artifacts, especially for HD, x265 will let you go a lot lower to look similar.

[Farfie]

Your psy-rd value is too high at this low bitrates.
Try with lower value, something around 0.3-0.5

Using .5 helped a lot, I didn't know these options mingled like this, but I'd still say it has a ways to go. Thanks though, seems like the x264 days will haunt me forever. :thanks:

[Carpo]

The lower you want to push the bitrate, the more useful it'll be to you. If you're looking for visually identical to the source, my experience is that they both take up a lot of room to get there. If you're looking to save a lot of space and don't mind some artifacts, especially for HD, x265 will let you go a lot lower to look similar.

I tend to do 2 pass encodes as I need a trade off between quality and size, most 1080p encodes I do are around the 10gb mark

[benwaggoner]

How viable would you say x265 is at this time for replacing x264 for use in a personal backup work flow? I see some companies are already using it for some streams/videos, or would you be better of waiting for a few present/up coming options to be tweaked first?

I haven't looked too deeply into it yet, but did a quick test with a music video from my of my dvd's (it's short and doesn't take long to encode, even when using QTGMC) and it did look cleaner with better colour's, to my eyes anyway, is two pass implemented yet, if not any idea of when that might be?



Decoder support is still the weakest aspect of the ecosystem, although that will change a LOT in 2015.



Also, x265 is still improving pretty rapidly in speed and quality. So I'd probably put off doing a big personal backup project for a few more months if there's no urgency. You could probably get it done a lot faster and at lower bitrates.



But definitely experiment and share your feedback!

[zerowalker]

Does x265 (at it's current state) offer improvement over x264 in 720p at around 1000 bitrate?
(Guessing not, will do tests if it's not an obvious answer).

[LigH]

Certain answer: "Depends."

There will be material where the advantage of x265 is obvious, and other material where an advantage is disputable. It also depends on the expectations. And the frame rate (720p is often broadcasted in double rate for smooth motion, which is harder to compress; the efficiency of both encoders is still not able to stay obviously below double bit rate requirement for double frame rate).

I wonder myself if a long shot of a soccer game or tennis match may work around 1 Mbps; probably to a degree that you can tell apart the players clearly, but don't expect to be satisfied with detailed lawn showing every blade of grass.

Indeed, a test with a specific sample is very recommended before guessing into the blue... Maybe today (ARD, Wolfsburg vs. München).

[zerowalker]

It's a digital recording from my 360. So it's no Noise (It's on the Menu and stuff), Clean and Sharp.

So it should be very good for the Encoder. Simple Colors, Text (some detailed stuff and gradients in the background etc, Depends on location).

Example (http://i61.tinypic.com/k48307.png) (This is the worse place, stuff going on in the back etc)

[LigH]

Mostly steady and clean content? Then x265 will probably have some advantage, being able to use larger units for low detail areas, and being more efficient in finding very similar areas. If you are able to provide a losslessly compressed sample (Ut, FFV1, lossless x264 or similar, maybe down to CRF 6), we could take part in the comparison and give hints about tweakable parameters. MEGA or MediaFire should offer a quite large storage.

[zerowalker]

Here is a short sample (UT Video Codec): https://drive.google.com/uc?export=download&id=0B_UKJFH8rbiNWXZWaG9tTTZtWXM

It shows an example of Simple stuff in the beginning, then the worse stuff later.
(Mostly i think it's simply stuff as i am going around in menus and not really at Title Menu).

Currently encoding x264 Very Slow 10bit at 1mbps to see how it looks.

[LigH]

Hehe, finally a reason to test ABR and CBR modes of x265.

ABR (1275.93 kbps):

x265 -o Xbox360_x265_abr1m.hevc --bitrate 1000

ABR + VBV (1256.46 kbps):

x265 -o Xbox360_x265_abr1mv.hevc --bitrate 1000 --vbv-maxrate 1500 --vbv-bufsize 6000

CBR + VBV (1275.18 kbps):

x265 -o Xbox360_x265_cbr1mv.hevc --bitrate 1000 --vbv-maxrate 1500 --vbv-bufsize 6000 --strict-cbr

All ABR/CBR modes seem to fill the buffer rather carefully (starting around 400 kbps), so the visual quality obviously increases during the first second.

2-pass VBR (1063.47 kbps):

x265 -o Xbox360_x265_vbr1m.hevc --bitrate 1000 --pass {1|2}

Here the visual quality is quite constant from the beginning.

Find HEVC and CSV files (log level 3) in my HEVC samples on MediaFire (https://www.mediafire.com/folder/ldwl20fppplbx/samples) (unfortunately, filtering doesn't seem to work, so use your browser's search for "Xbox").

[zerowalker]

I can't access your MediaFire i just get to my own account.

EDIT: In the original file there are a lot of still images. (I reboot and stuff which then just show "No Signal" for 10+ seconds).
And also some loading stuff are completely still i think (no hourglass and stuff, just a bar that moves at intervals).

Is Bitrate setting good at this kind of videos, or should i try to use CRF which is normally a favorite?

[LigH]

^ URL updated.

For streaming over a limited bandwidth network, a rather constant bitrate is useful.

If the video is downloaded first and later played from a faster medium, CRF is certainly recommended.

[zerowalker]

I am only reducing size for storing on my Computer.
So i guess CRF is the way to go.

Hmm, problematic as it's so slow, will do some x264 tests to see what quality i need to get "1mbps".
Then i guess i can do an x265 test with the same quality (Is there any parameter for x265 CRF X = x264 CRF X?)

EDIT:

Compared your 2pass x265 with my x264 10bit.
x265 filters out quite a bit, it looked better at first glance, but it removes details (along with some artifacts which is why it looked good at first).
Guess it's about the Block things, 720p isn't a high enough resolution to have advantage of those features.

[LigH]

It's hard to point at one specific reason why x265 reduced details a lot more; but there are still a few command line parameters not yet used to tweak the quality. To begin with, it was just a "medium" preset. And I missed a detail, I only used the 8 bit depth version of x265, unfair to compare directly against a 10 bit depth x264 with such low-detail color ramps.

Still, HEVC and AVC are quite different in their behaviour, so comparing their CRF results is meaningless, they remove a different kind of details from the video, which may look more or less annoying in different cases. So, I am sorry, but I can't take all the testing efforts from you...

[zerowalker]

Understandable, and as you say 10bit does it's thing.

I enjoyed the testing you did and it helped giving a glance of the situation.

I will most likely use x264 10bit for this as it's sure to work.
HEVC doesn't have use of it's full power in this situation i think, even if you can tweak out some details here and there.
If this was 1080p at 1mbps or lower i think there would be more of a difference, and above 1080p it's most likely a sure win.

Still interesting as this wasn't a "grain with small details" example, it did handle it quite well.
I can really see HEVC shine on Cartoons/Animé.

Many Thanks:)

[ramprasad85]

Sorry if this is not the right place to post the following compilation issue...

I downloaded the latest source code. Compilation using msvc (i tried vc9 and vc11) failed with the error
1>..\..\..\source\encoder\frameencoder.cpp(808) : error C3861: 'InterlockedAdd': identifier not found

It worked by changing InterlockedAdd to InterlockedExchangeAdd in x265/sources/common/threading.h line 67 as mentioned here (http://stackoverflow.com/questions/14603407/why-interlockedadd-is-not-available-in-vs2010).

Thanks

[LigH]

Possibly one premature patch, another should follow ... I remember that there is a very recent addition regarding VS and XP.

The best place to tell about such issues is the mailing list for developers.

[LigH]

One of the last x265 v1.4 before v1.5 will start: x265 1.4+465-e2c958ff874e (https://www.mediafire.com/download/f08ls04hu864f3c/x265_1.4+465-e2c958ff874e.7z)

Because they are fast enough in assembler, Psy-RD and Psy-RDOQ are enabled by default now (if applicable, based on the RD mode). Return codes are documented.

[x265_Project]

Although we've added some logic to reduce psy-rd strength when QP values go high (in other words, at relatively low bit rates), I think the current default psy-rd strength is about 3x too high. So if you're running a fresh build from the development tip, expect psy-rd to be toned down before we tag version 1.5. The current thinking is a default of psy-rd 0.3, psy-rdoq 1.0.

As always, we welcome your feedback (from your experience with psy-rd and psy-rdoq, especially from tests you might run with the latest development build).

Tom

[stax76]

When --psy-rd and --psy-rdoq are enabled now by default, how can they be disabled? Any other CLI and default value changes lately?

[LigH]

By setting their value to 0.0

[NikosD]

Decoder support is still the weakest aspect of the ecosystem, although that will change a LOT in 2015.


Could you explain it a little more ?

Do you compare the maturity of decoders vs encoders or something else ?

[x265_Project]

Could you explain it a little more ?

Software HEVC decoders such as MulticoreWare's UHDcode and similar offerings from all the usual suspects have matured to the point where they can run at peak performance on a variety of platforms. UHDcode, for example, is optimized for x86 (with hand-tuned assembly code for performance critical functions), accelerated with OpenCL on various GPU platforms, and is being ported to 3rd generation game consoles (PS3, XBOX 360) and ARM devices. We're working to make UHDcode available more widely... please stay tuned.

Hardware decoder designs are also maturing and shipping in many new mobile SOCs (System on a Chip - the integrated CPU+GPU+Image Signal Processor+Cell/Wifi/BlueTooth Radios, etc. in mobile devices) from Qualcomm, Samsung, MediaTek, Apple, Marvell, etc. Some of these companies design their own HEVC decoders, and some license the hardware design from one of the many companies that design hardware IP. HEVC hardware decoders are already available in many TVs, and they are starting to roll out in the latest generation cable/satellite/over-the-top set-top boxes. Samsung even has a DSLR that can encode video in HEVC (with a hardware encoder + decoder).

PC chipsets are starting to support HEVC in hardware this year. NVIDIA is already shipping a hardware HEVC encoder (Maxwell 2), and they've released APIs for a hybrid HEVC decoder. AMD has announced that their next-generation APU, Carizzo (http://www.anandtech.com/show/8855/amd-demonstrates-working-carrizo-laptop-prototype), will include a 4K hardware HEVC decoder. Intel has already released a hybrid HEVC decoder API (GPU accelerated), and there are reports (http://www.cpu-world.com/news_2014/2014060901_Some_features_of_Skylake_graphics_architecture.html)that their next generation platform, Sky Lake, will include hardware HEVC encoding and decoding. So, by the end of 2015, it wouldn't be a stretch to say that most new high-end video capable devices will have full hardware support for HEVC. Certainly, if you're in the market to buy a new PC, camera, TV, mobile phone, tablet or set-top box, it's something you should be looking for.

Tom

[nevcairiel]

NVIDIA is already shipping a hardware HEVC encoder (Maxwell 2), and they've released APIs for a hybrid HEVC decoder.

Actually, the recently released NVIDIA GTX 960 has a full hardware decoder for Main and Main10 at 4K, no more hybrid!
Its the same decoder chip the next Tegra is going to have on mobile.

[x265_Project]

Actually, the recently released NVIDIA GTX 960 has a full hardware decoder for Main and Main10 at 4K, no more hybrid!
Its the same decoder chip the next Tegra is going to have on mobile.
Yes, you're right... http://www.anandtech.com/show/8923/nvidia-launches-geforce-gtx-960

[NikosD]

x265_Project

Thanks for the thorough reply, I was just asking why the decoders are the weakest aspect of the ecosystem.

From your reply, obviously they aren't.

[x265_Project]

x265_Project

Thanks for the thorough reply, I was just asking why the decoders are the weakest aspect of the ecosystem.

From your reply, obviously they aren't.

No problem. Any new format change has a "chicken and egg problem"; which comes first, the encoders or the decoders? No one wants to encode to the new format if they (or their customers) can't easily decode the content. Decoders are required to make the ecosystem viable. HEVC decoders are quickly becoming available everywhere they are needed, but of course it takes time to roll out across the ecosystem. In some cases, devices (with programmable hardware with enough processing power) can download a software update. In other cases, we have to wait one replacement cycle for the installed base to upgrade.

[Asmodian]

x265_Project

Thanks for the thorough reply, I was just asking why the decoders are the weakest aspect of the ecosystem.

From your reply, obviously they aren't.

I do not get that from x265_Project's reply. Now that there is a reasonably mature encoder the main limiting factor for widespread use is decoder support.

There is still a lot of new hardware being sold that cannot play HEVC but can play AVC.

With only the very newest of devices having full hardware decoding and because software decoding of HEVC requires a lot of CPU power even with an optimized decoder I think it is fair to say decoder support is currently an issue for HEVC.

2015 is likely to change this, for all the reasons x265_Project mentioned, but that does not change the fact that currently HEVC is not universally or even widely supported on mobile devices or Smart TVs.

[NikosD]

The reason of low penetration of HEVC in the consumer world of TVs, Home Cinemas etc or even mobile devices, is not the immaturity of decoders.

It's the low supply of HEVC content, because of many other reasons than decoders.

The level of maturity of the encoders and decoders is about the same.

The one is following the other.

In the PC world, the ffmpeg decoder for HEVC files exists since 2013.