x265 HEVC Encoder

[foxyshadis]

x265-1.4+57 (https://dl.dropboxusercontent.com/u/54412753/doom9/x265-1.4%2B57.7z) (Needs VC12 runtime.) Some interesting experimental changes just since LigH's build: psy-rdo now influences mode decision and bidir decision (which frames to make b-frames and which blocks to use forward references on).

[LigH]

MediaInfo 0.7.71:

...
+ HEVC: Support of Pixel Aspect Ratio in VUI, thanks to Kurtnoise
...

[LigH]

Only loosely related to x265, but probably interesting for cross-platform developers using CMake:

I just renewed my building environment and got some warning from CMake v3.1.0-rc1. Note: CMake is going to disallow uncommon characters in identifiers.

This belongs to a detection in source/cmake/FindVLD.cmake which searches several locations for the installation of the "Visual Leak Detector". It also uses the environment variable in a 64-bit Windows which points at the common installation path of 32-bit applications: %ProgramFiles(x86)%

If such a string is included in a double-quoted string in a CMake script, it may be used as literal, but not as identifier; unfortunately, the function $ENV{} which evaluates its parameter as environment variable uses this rather as identifier than as literal, and you can probably neither escape the parentheses nor "in-string-quote" it.

The current solution is to create CMake script variables with the name of the environment variable as literals, and nest evaluation functions.

I provided a snippet which should become available as patch soon. In the meantime, CMake up to v3.0.2 won't complain (but possibly not find a VLD installation by searching the x86 path).

[NikosD]

Interesting...A little competition
http://labs.divx.com/node/127941

[Sagittaire]

Interesting...A little competition
http://labs.divx.com/node/127941

well not interessing in fact because:

1) DivXHEVC propose just constant quantizer mode or abr 1 pass mode. x264 propose crf mode and abr N pass mode by far better for rate control and metric/visual quality. at same bitrate and comparable speed, x265 outperform DivXHEVC and by far.

2) x265 introduce now HVS psy optimisation and DivXHEVC not. x265 is by far better for grain and detail retention.

3) HEVC is interessing codec with complete functionality but high speed profil for x265 and DivXHEVC don't propose complete functionality. At these high speed for HEVC, H264 produce comparable quality in slow mode. If I want compare HEVC codec, I make comparison with all functionality to have really better codec than H264: imply slow mode for x265 and DivXHEVC.

[lotusgg]

Is it normal to be this slow (http://i.imgur.com/kdGetzT.png)?

[x265_Project]

Is it normal to be this slow (http://i.imgur.com/kdGetzT.png)?
Using --preset veryslow at --crf 15, yes, I'm not surprised. The higher the quality (bit rate), the slower x265 will run, as more bits require more entropy coding (the last step in the compression process) and decoding (to create the reference pictures needed for motion prediction).

[LigH]

Furthermore, setting max. 16 consecutive B-frames and 16 reference frames is "homeopathy" (placebo forte). Presets exist for a specific reason, to suggest sane options in reasonable relations.

[Sagittaire]

Is it normal to be this slow (http://i.imgur.com/kdGetzT.png)?

your setting are simply useless:

1) 16 bframes and 16 ref spend high and really useless time, reduce at 3 pyramidals bframes and 5 refs for exemple.

2) rect and amp are usefull functionality for quality if you compare with really useless 16/16 b/ref.

3) crf 15 is really high quality (something like BD quality). Imply really high bitrate for 1080p source. Really high bitrate imply really heavy CABAC CPU cycle. Use 16/16 b/ref and preset veryslow is simply even more useless at this quality level.

Like Ligh say, if you don't know the utility for each functionality, don't touch the profil ...

[lotusgg]

your setting are simply useless:

1) 16 bframes and 16 ref spend high and really useless time, reduce at 3 pyramidals bframes and 5 refs for exemple.

2) rect and amp are usefull functionality for quality if you compare with really useless 16/16 b/ref.

3) crf 15 is really high quality (something like BD quality). Imply really high bitrate for 1080p source. Really high bitrate imply really heavy CABAC CPU cycle. Use 16/16 b/ref and preset veryslow is simply even more useless at this quality level.

Like Ligh say, if you don't know the utility for each functionality, don't touch the profil ...

I am actually encoding blu-ray, and an anime source to be more specific. 16b/ref has proven to be beneficial to this kind of source, and the point in no-rect no-amp is that its impact in speed is just too high for the little quality gain it provides.

[LigH]

Then you probably missed the warning about "level 5 and NumPocTotalCurr". 16 references are too much to be hardware compliant, whenever a HEVC consumer player may be released.

Furthermore, I doubt that you will recognize any difference between "up to 16 consecutive B frames" (think about the meaning of that video stream attribute) and a sane number at CRF 15, quality-wise. The assertion to be beneficial for cartoon content was probably made in relation to coarser quantizations.

[Sagittaire]

I am actually encoding blu-ray, and an anime source to be more specific. 16b/ref has proven to be beneficial to this kind of source, and the point in no-rect no-amp is that its impact in speed is just too high for the little quality gain it provides.

proven by what? You have test to prove that 16 ref vs 5 ref is more beneficial than rect/amp actived for anime source? IMO it's completely false. Moreover, you make HEVC encoding certainely with higher quality than your H264 BD source (max bitrate is 40 Mbps for BD and you have certainely an H264 source at 20-30 Mbps in average). Your encoding is simply waste of time ... :helpful:

Use simply crf mode at crf 18~20 with slower profil.

[LigH]

Another "weekly" build: x265 1.4+70-27d36c4b4a27 (https://www.mediafire.com/download/6bogkrbaoby1927/x265_1.4+70-27d36c4b4a27.7z); probably interesting: tuned VBV predictor factors.

[lotusgg]

proven by what? You have test to prove that 16 ref vs 5 ref is more beneficial than rect/amp actived for anime source? IMO it's completely false. Moreover, you make HEVC encoding certainely with higher quality than your H264 BD source (max bitrate is 40 Mbps for BD and you have certainely an H264 source at 20-30 Mbps in average). Your encoding is simply waste of time ... :helpful:

Use simply crf mode at crf 18~20 with slower profil.

I'm aiming for near-perfect BD rips, it's improbable the use of crf higher than 16 or anything worse than veryslow.
I did tests in the past about refs and b-frames in anime source, but I lost them.
Well, going to test again.
This time with --preset veryslow --tune grain --crf 15 --bframes 5 --ref 5 --no-b-intra, it's even slower (http://i.imgur.com/8pRbQG6.png).

[LigH]

In general — probably important to know: To get the complete help output, you have to use the following combination now:

--log-level full --help
__

@ lotusgg:

Is it important for you to change the number of B and reference frames, instead of relying on the presets' defaults?

And by the way, did you try enabling parallel motion estimation and mode decision (--pme --pmode)? In contrast to the other parameters you were interested in by now, these may optimize speed in elaborate presets.

But somehow, all your cores appear to be utilized well, already. As if there is something else calculating heavily besides x265.

[lotusgg]

In general — probably important to know: To get the complete help output, you have to use the following combination now:

--log-level full --help
__

@ lotusgg:

Is it important for you to change the number of B and reference frames, instead of relying on the presets' defaults?

And by the way, did you try enabling parallel motion estimation and mode decision (--pme --pmode)? In contrast to the other parameters you were interested in by now, these may optimize speed in elaborate presets.

But somehow, all your cores appear to be utilized well, already. As if there is something else calculating heavily besides x265.

I didn't tried --pme and --pmode because the cores are already on stress, and 98% are of x265 works. 2% are browsers and torrent client.
About specifying the numbers, it is just an habit.

[huhn]

proven by what? You have test to prove that 16 ref vs 5 ref is more beneficial than rect/amp actived for anime source? IMO it's completely false. Moreover, you make HEVC encoding certainely with higher quality than your H264 BD source (max bitrate is 40 Mbps for BD and you have certainely an H264 source at 20-30 Mbps in average). Your encoding is simply waste of time ... :helpful:

Use simply crf mode at crf 18~20 with slower profil.

Japanese anime disc have usually a AVG bit rate of 35 mbit or more a disc with AVG 39 mbit isn't rare at all.

used 8+ ref frames are not that rare in x264 encodes with animes you can see these information at the end of the encode as you most likely better know than me.

[xooyoozoo]

used 8+ ref frames are not that rare in x264 encodes with animes

Doing the same with HEVC invites compatibility problems.

If you tell the x265-cli to conform to any decoder level, it'll cap --ref to 7 or less.

.

edit: But seriously, if you go beyond the well-trodden path, please set the appropriate Profile and Level. Future you and/or customers/friends/family will appreciate it.

[lotusgg]

Seems that the CLI proposed produced slower a bigger output.
http://prntscr.com/57e915
I need to compare screenshots now, but I can't get it out of the ded. server ATM.

[huhn]

Doing the same with HEVC invites compatibility problems.

If you tell the x265-cli to conform to any decoder level, it'll cap --ref to 7 or less.

.

edit: But seriously, if you go beyond the well-trodden path, please set the appropriate Profile and Level. Future you and/or customers/friends/family will appreciate it.

i would use 10 bit anyway so hardware compatibly is nothing i would care about. my point is only that higher ref frames are not that useless.

[foxyshadis]

Yes, it's normal. I'm confused as to why someone would essentially choose preset placebo (other than rect/amp) and CRF 15, and then care about encoding time and file size. It's like the situation with x264 in 2007; we're just spoiled by how much faster CPUs have become in the meantime.

If you care about file size, pick a higher CRF. (Makes a much larger difference than slower settings.) If you care about encoding time, pick a faster preset. If you're blindly bringing your x264 settings over to x265, that's a recipe for disaster, because the CRF scale is quite different, and as you've seen, speed is much slower.

[upyzl]

seems he want to achieve very high quality (~transparency of input) [high priority], then smallest size [medium], last consider encode time for adjust a little params [low]

[kamineko]

So after all the recent and wildly different suggestions, what would be a recommended commandline with the latest x265 development version for

encoding BluRays with archival quality (near-transparent)?
encoding DVDs with archival quality (near-transparent)?


I think it would be beneficial to have different settings for 2D-animated and non-animated, normal content (standard movies or 3D-animation).

I am not striving for perfection, if, let's say, only the trained eye can spot differences under the best of circumstances, that would be good enough for me. It doesn't have to be 100% perfect.

Priorities are

Quality (near-transparency of input)
File size (differences of less than 2% can be disregarded)
Encoding time (preferably > 1 fps on current systems with a Passmark result of 15,000 or more, example Xeon E5 2640)


The whole command line should be robust enough to cope with 95 - 98% of the material, finetuning with something like -tune grain is acceptable. Fiddling with psy values for each different source would not be acceptable, since this would defeat the purpose of a broadly applicable setting.

If anyone is interested, you could also add a recommendation for mobile devices, where the priority list is reversed and the quality needs to be only good enough for a 6" - 10" screen (phone or tablet). Encoding time of at least 6 fps strongly desired here.

[Sagittaire]

I'm aiming for near-perfect BD rips, it's improbable the use of crf higher than 16 or anything worse than veryslow.
I did tests in the past about refs and b-frames in anime source, but I lost them.
Well, going to test again.
This time with --preset veryslow --tune grain --crf 15 --bframes 5 --ref 5 --no-b-intra, it's even slower (http://i.imgur.com/8pRbQG6.png).

Well the problem is that you don't know really how work x265 and certainely x264 too.

1) your (re)encoding at crf 15 with x265 will have bitrate near your H264 BD source. If you want perfect ripp, extract simply the H264 stream from BD ... it will be impossible to do more perfect.

2) crf for x264 don't work like crf for x265. The bitrate scaling is not the same.

3) crf is itself quality level based on quantizer. crf 15 in fast mode will produce equivalent quality at crf 15 in placebo mode. The difference will be simply time encoding and final average bitrate. cfr 15 with 3/5 bframes/ref will produce exactly same final quality for your eyes (and metric too) than 16/16 bframes/ref with simply little higher bitrate (IMO something like <5%).

I repeat: make encoding like that is simply waste of time.

[x265_Project]

First, choose your desired level of quality. There are 2 basic ways to do this. The easiest is to use CRF. Lower CRF=Higher Quality (but larger file sizes). Another way is to use average bit rate (--bitrate). If you use ABR, I would suggest using 2 pass encode (repeat your same command line twice, with --pass 1 on the first pass and --pass 2 on the second pass, and if desired, use --stats on both passes to specify where to write and read the stats file). Both CRF and 2 pass ABR give similar compression efficiency and overall speed. CRF is easier to use while 2 pass ABR gives you control over the resulting bit rate (file size).

Next, you need to need to decide whether you want x265 to take its time, producing more compression efficiency (bit rate at your desired quality level), or if you would like x265 to get the job done faster. This basic speed vs. efficiency tradeoff is why we have 10 performance presets (for example, --preset medium). If you want the smallest file size for your chosen CRF setting (or highest quality for your chosen --bitrate), use the --veryslow preset. If this is too slow for you, use a faster preset (slower, slow, medium, fast, faster, veryfast, superfast, or ultrafast).

[x265_Project]

You'll notice that adding --pme and --pmode can have a very positive effect at higher quality presets, but a negative effect when you're trying to use faster presets. In fact, for most people under most circumstances, --pme will just slow things down at any preset. --pmode will be beneficial at slower presets, but it will slow things down for faster presets.

We are still working to improve how we parallelize and schedule threads, and so we haven't added --pme or --pmode to our performance presets yet. Both functions are safe to use (you'll get identical or nearly identical output to what you would get without them), but only --pmode is likely to help things go faster, and generally the performance benefits from --pmode will diminish with fewer processor cores/threads, or with high pixel resolutions (UHD). To summarize, using x265 v1.4, if you're not encoding UHD/4K, and you have at least a 4 core processor, and you're using higher quality (slow, slower, veryslow) presets, you'll probably see a benefit from adding --pmode to your command line today.

[kamineko]

To summarize, using x265 v1.4, if you're not encoding UHD/4K, and you have at least a 4 core processor, and you're using higher quality (slow, slower, veryslow) presets, you'll probably see a benefit from adding --pmode to your command line today.
Thanks. This is the kind of information I am looking for. What would you recommend as -crf value for the different types of archival? In other words, what would you feel comfortable with for an archival of a BluRay or DVD?

Recommended values differ wildly already for x264; for x265, I have no idea at all.

[LigH]

It is hard to tell for every user because the subjective quality impression is different for people too. Some are satisfied with CRF 18, others complain about visible artefacts and recommend at most CRF 15 for x264.

And it is even harder to rate a relation between x264 and x265. The default values are CRF 23 for x264 and CRF 28 for x265; but that does not mean that the degree of subjective loss is comparable for the majority, because the appearance of artefacts differs, they look "differently annoying".

And it is not guaranteed that the difference of 5 is similar for another range. But if it was the case ... then you should have a quite "transparent" quality already for CRF 20 with x265. But check for yourself. Are you satisfied with CRF 20 or 18 already? Then you will not need CRF 15.

[foxyshadis]

Until you get familiar with your tastes, it's a good idea to make a collection of CRF encodes of 5 minutes apiece: 15, 18, 21, 24, 27.... Trailers are commonly used for this. It could run overnight if you use preset medium or fast, and you can assume a slower preset would be some % smaller. (Might be handy to make a chart of how much you can expect filesize to change, there are no current ones.)

Now, it's no guarantee that one preset's CRF quality will actually be comparable to another preset's CRF quality, but in general it's pretty true. Starting fast and wide should let you quickly home in on roughly where you feel size and quality are an adequate tradeoff, then you can tweak it by going as slow as you can handle to shave a few more percents off.

[Kurtnoise]

Divx265 vs x265, the last comparison (http://labs.divx.com/node/127941)... it seems like this guy doesn't tuned psnr encoding w/ the x264/x265. :rolleyes:

[LigH]

PSNR tuning doesn't make much sense if you are interested in subjectively good results; PSNR is known to be not an optimal metric. But I won't insinuate an attempt to reduce the advantage of competitors... :rolleyes:

[a5180007]

What's surprising in this comparison, is that DivX265 Balanced 8b and 10b are on par quality-wise, whereas x265 fast 10b falls well behind 8b.

[Sagittaire]

Divx265 vs x265, the last comparison (http://labs.divx.com/node/127941)... it seems like this guy doesn't tuned psnr encoding w/ the x264/x265. :rolleyes:

Well this test is correct ... in fast mode with constant quantizer mode ... !!???

Anyway x265 have actually more advanced functionality than DivX265 like crf mode. In fact x265 with crf mode outperform and by far DivX265 in all speed preset mode for metric and for eyes.

[Gravitator]

We continue to wait grain and 2-pass from DivX265 > X265-vs-DivX265 (videohelp.com) (http://forum.videohelp.com/threads/365634-X265-vs-DivX265?p=2357537&viewfull=1#post2357537)

[Kurtnoise]

We continue to wait grain and 2-pass from DivX265 > X265-vs-DivX265 (videohelp.com) (http://forum.videohelp.com/threads/365634-X265-vs-DivX265?p=2357537&viewfull=1#post2357537)
did you read carefully ? It's off-topic here...

[LigH]

Another weekly build: x265 1.4+116-3c6f703f94ea (https://www.mediafire.com/download/u7ad5ewb7b5a58m/x265_1.4+116-3c6f703f94ea.7z)

[oopsipoo]

finally the 5 day retarded rule has passed. anyway, anyone here know how to update the x265 encoder in ripbot?

[vood007]

finally the 5 day retarded rule has passed. anyway, anyone here know how to update the x265 encoder in ripbot?

Replacing the exe´s in "<ripbotdir>\Tools\x265\" while keeping the original names (ie rename your x64 build to "x265_x64.exe") should do the trick.

[oopsipoo]

Replacing the exe´s in "<ripbotdir>\Tools\x265\" while keeping the original names (ie rename your x64 build to "x265_x64.exe") should do the trick.

any idea where i can get the new files from

[HWK]

any idea where i can get the new files from

http://www.mediafire.com/download/u7ad5ewb7b5a58m/x265_1.4%2B116-3c6f703f94ea.7z
or
http://forum.doom9.org/showthread.php?p=1700654#post1700654

[Metaphor]

This very thread.

Look 5 posts up.

:confused:

[lotusgg]

or here (http://builds.x265.eu/).

[oopsipoo]

i did look into that before i registered and waited 5 days!

one of the zip has a ddl, and the other one has 8 and 10 bit.

i is confuse

[LigH]

Weekly: x265 1.4+151-5ee693e4b5fa (https://www.mediafire.com/download/k7i90t6o4rhcd9z/x265_1.4+151-5ee693e4b5fa.7z)

Has a new "cbr" tuning.
__

You are probably interested in the Win32 or Win64 EXE with 8 bit internal resolution. The higher resolution versions need high bitdepth video sources most converters don't provide.

[x265_Project]

Ara Rezaee posted on our x265 Facebook page (https://www.facebook.com/x265project)... x265 has a HUGE banding issue, you guys need to do something about that...
It's probably better to have discussions about technical issues here, where there are other users and experts who provide valuable tips and feedback.

Banding is an issue that is very dependent on the source content and how it was captured and originally encoded/processed by the camera. It shows up in areas of the picture where there are gradual color gradients (a gradual transition from one color to another), particularly in areas with low light levels. It's a challenging problem, as banding is a phenomenon that happens across large areas (spatially), and a video encoder, at its core, is designed to analyze and process video in smaller blocks. HEVC will describe your video using larger 64x64 pixel block sizes, and so there are differences in the way AVC and HEVC encoders handle different types of content. Anyhow, we agree that there is room for improvement in terms of what can be done to reduce banding in HEVC encodes.

Of course, 10-bit color sample depth largely solves the banding problem (and 12 bit puts it to rest entirely). But it's not a simple solution to say "just use 10 bit". Your source content would need to have been captured with 10 bit sample depth. 10 bit capable decoders are harder to find than 8 bit decoders, and 10 bit encoding takes longer than 8 bit.

Ara - it would be best if you could post a sample of your source content and share your x265 settings.

[ara.armagedon]

Ara Rezaee posted on our x265 Facebook page (https://www.facebook.com/x265project)...
It's probably better to have discussions about technical issues here, where there are other users and experts who provide valuable tips and feedback.

Banding is an issue that is very dependent on the source content and how it was captured and originally encoded/processed by the camera. It shows up in areas of the picture where there are gradual color gradients (a gradual transition from one color to another), particularly in areas with low light levels. It's a challenging problem, as banding is a phenomenon that happens across large areas (spatially), and a video encoder, at its core, is designed to analyze and process video in smaller blocks. HEVC will describe your video using larger 64x64 pixel block sizes, and so there are differences in the way AVC and HEVC encoders handle different types of content. Anyhow, we agree that there is room for improvement in terms of what can be done to reduce banding in HEVC encodes.

Of course, 10-bit color sample depth largely solves the banding problem (and 12 bit puts it to rest entirely). But it's not a simple solution to say "just use 10 bit". Your source content would need to have been captured with 10 bit sample depth. 10 bit capable decoders are harder to find than 8 bit decoders, and 10 bit encoding takes longer than 8 bit.

Ara - it would be best if you could post a sample of your source content and share your x265 settings.

Well hello there!

I was playing with the newest version (1.4) for the first time when I ran into this problem, I made 4 samples for you, 1. x264 fastest preset, 2. x264 slowest preset 3. x265 fastest preset and then its slowest preset.

--Now as I dug a little more into the settings I realized that the problem will (almost entirely) be solved if you just change the default aq-mode from 2 to 1 (the strength is dependent on your bit rate).
--------
Here are the samples: (The source is the physical bluray disk)

Godzilla x265 fastest default preset (http://www.mediafire.com/download/kt8upcucwb2z1o9/Godzilla+x265+fastest.mp4)

Godzilla x265 slowest default preset (http://www.mediafire.com/download/1iavx87tfx5s3ps/Godzilla+x265+slowest.mp4)

Godzilla x264 fastest default preset (http://www.mediafire.com/download/60bbyig5vjp4x2b/Godzilla+x264+fastest.mp4)

Godzilla x264 slowest default preset (http://www.mediafire.com/download/bw4gl4x3cxx62b4/Godzilla+x264+slowest.mp4)

As you can see the "x264 slowest" is much better than the x265 when it comes to banding issues, this problem is solvable if you change the default aq-mode to 1 (but sadly that would decrease the quality a bit...)

[xxxxx]

Ara Rezaee posted on our x265 Facebook page (https://www.facebook.com/x265project)...
It's probably better to have discussions about technical issues here, where there are other users and experts who provide valuable tips and feedback.

Banding is an issue that is very dependent on the source content and how it was captured and originally encoded/processed by the camera. It shows up in areas of the picture where there are gradual color gradients (a gradual transition from one color to another), particularly in areas with low light levels. It's a challenging problem, as banding is a phenomenon that happens across large areas (spatially), and a video encoder, at its core, is designed to analyze and process video in smaller blocks. HEVC will describe your video using larger 64x64 pixel block sizes, and so there are differences in the way AVC and HEVC encoders handle different types of content. Anyhow, we agree that there is room for improvement in terms of what can be done to reduce banding in HEVC encodes.

Of course, 10-bit color sample depth largely solves the banding problem (and 12 bit puts it to rest entirely). But it's not a simple solution to say "just use 10 bit". Your source content would need to have been captured with 10 bit sample depth. 10 bit capable decoders are harder to find than 8 bit decoders, and 10 bit encoding takes longer than 8 bit.

Ara - it would be best if you could post a sample of your source content and share your x265 settings.

Finally you respond this issue, it's comes up every month since this makes this superb codec unusable. I make a topic a few months ago you can find some samples there if you interested in.
http://forum.videohelp.com/threads/367339-HEVC-test-samples
I just tested the 1.4 version but the banding is still on.
I really hope you solve this issue soon:)

[ara.armagedon]

Finally you respond this issue, it's comes up every month since this makes this superb codec unusable. I make a topic a few months ago you can find some samples there if you interested in.
http://forum.videohelp.com/threads/367339-HEVC-test-samples
I just tested the 1.4 version but the banding is still on.
I really hope you solve this issue soon:)

Hi! I took a look at your link, It seems that we have found the same solution! change the aq-mode! although can't agree with you on the strength yet, I believe it is highly subjective and is dependent on the bitrate. Anyhow in your last post there, you mentioned yet another problem I've faced... Have you tried 2-pass? that made a big difference for me...

[LigH]

New features in x265 1.4+174-35d086074bb5 (https://www.mediafire.com/download/7h8421j2a0h8h07/x265_1.4+174-35d086074bb5.7z): different Noise Reduction values for Inter and Intra CUs, and a published parameter for bitrate control tolerance (internally already used for the CBR tuning).

[Atak_Snajpera]

I wonder why aqmode 2 is still default in x265? Even x264 does not use mode 2 by default and as users (me as well)say aqmode 1 gives better subtective quality.