x265 HEVC Encoder

[zerowalker]

Okay, thought as much, will however wait with that, as --rd 6 is extremely slow, will take ages for my to try to find the CRF setting to reach similar bitrates.

[fumoffu]

hmm I'm getting some small artifacts with LoRd_MuldeR build but foxyshadis version seems to working fine.

[xooyoozoo]

On Ubuntu 14.04 + gcc-4.9, I'm also getting artifacts.

[foxyshadis]

Okay, thought as much, will however wait with that, as --rd 6 is extremely slow, will take ages for my to try to find the CRF setting to reach similar bitrates.

Instead of trial and error, a quicker way to test is to two-pass it. Test once with your favorite crf, then use the final bitrate of that to plug into the two-pass bitrate of every future test. Then at least you're not wasting extra encodes.

[vivan]

but... it still doesn't support 2-pass mode :)

[kypec]

but... it still doesn't support 2-pass mode :)
Really? What a shame, average bitrate controlled mode is a must nowadays I'd guess....

[x265_Project]

but... it still doesn't support 2-pass mode :)
It's not a trivial effort to support two pass encoding; at least, not if you want to do it the right way. As always, patches are welcomed. :)

We have higher priorities for our near-term development backlog... improving existing rate control modes (ABR, VBV), improving the visual quality produced by the all of the encoding algorithms we've developed, developing new algorithms for visual quality (psycho-visual optimizations), and improved performance.

[xooyoozoo]

Getting hash mismatches with the recent x265 commits and `-p slower --psy-rd 1`.

The hash mismatches stop if I change line 109 of TComRdCost.h from

`width = height = 1 << (size * 2);`

to

`width = height = 1 << (size + 2);`

[Daemon404]

We have higher priorities for our near-term development backlog... improving existing rate control modes (ABR, VBV), [...]

Is it even worth it to put so much time into ABR?

[x265_Project]

Is it even worth it to put so much time into ABR?
Well, I know you're an offline guy, but there is a whole world of low latency real-time encoding applications that need ABR and its derivatives... VBV, HRD, CBR.

[foxyshadis]

Is it even worth it to put so much time into ABR?

Real-time encoding is the only place the money is anymore, at least until a new disc or download standard includes HEVC support. Youtube, Netflix and the like stick to x264 or their own codecs for their offline encoding needs. (So far.)

[x265_Project]

Real-time encoding is the only place the money is anymore, at least until a new disc or download standard includes HEVC support. Youtube, Netflix and the like stick to x264 or their own codecs for their offline encoding needs. (So far.)

I wouldn't go that far. We focused on offline encoding for the longest time, as the priority was always on the encoding algorithms and we didn't want to complicate matters. But as you know, our business model is to fund the development of x265 privately. There are several classes of companies backing the project, including commercial licensees (companies that distribute the codec in their product) and strategic partners (semiconductor or platform companies).

Fortunately, a number of companies that could otherwise choose to freeload (use x265 for free under the terms of the GPL) have wisely chosen to back the project. Companies whose business is centered on video (streaming video services, movie studios, etc.) recognize that...

HEVC is a very powerful technology, and the benefits will soon outweigh the costs of implementation
To remain competitive they need to lead when it comes to implementing HEVC
It is in their long-term interest for x265 to be their HEVC encoder of choice
It makes sense to fund the project to drive the development priorities in their direction, to meet their specific deployment requirements


We're generally getting good feedback from our customers and potential customers. Interest from the real-time space has certainly ramped up in recent months as companies compare the available options and see what x265 is capable of. As more real-time companies fund our development efforts, you'll see us develop more real-time features.

Note... I don't mean to use the term "freeload" in a derogatory manner. Using x265 for free is a legitimate option for many companies. The free-rider problem (http://en.wikipedia.org/wiki/Free_rider_problem) is an inherent part of our dual open source / commercial license business model. Our challenge is to convince companies that could otherwise pay nothing that it is in their best interest to back the project. Fortunately, we're succeeding in those efforts.

[foxyshadis]

Bug report from r6864:

- double *qp_offset = IS_X265_TYPE_B(frames[b]->sliceType) ? frames[b]->qpAqOffset : frames[b]->qpOffset;
+ double *qp_offset = (frames[b]->sliceType = X265_TYPE_B) ? frames[b]->qpAqOffset : frames[b]->qpOffset;

I'm assuming this should be ==? Or is that intentional? (The docs for this function also mention MB-tree instead of CU-tree.)

****

In other news, psy-rdo is committed, it's now disabled by default but otherwise no algorithm changes from the previous build. I checked, --subme 4 is also the minimum to enable it at all (preset veryslow).

Thanks for the clarification, x265_Project.

[LoRd_MuldeR]

In other news, psy-rdo is committed, it's now disabled by default but otherwise no algorithm changes from the previous build. I checked, --subme 4 is also the minimum to enable it at all (preset veryslow).

I'm still getting heavy artifacts (http://www.mediafire.com/download/o8bdyoru0hy9mr3/Test.rar) with "--preset veryslow --psy-rd 1.0", while just using "--preset veryslow" seems to be okay.

(Straight-forward MSVC 2013.2 build of 1.0+62, no patches or anything)

[zerowalker]

Instead of trial and error, a quicker way to test is to two-pass it. Test once with your favorite crf, then use the final bitrate of that to plug into the two-pass bitrate of every future test. Then at least you're not wasting extra encodes.

That's true.

Is it possible to Automate 2 pass?
Or will i have to do 2 commands?

[LoRd_MuldeR]

Is it possible to Automate 2 pass?
Or will i have to do 2 commands?

x265 does not currently support 2-Pass encoding.

http://forum.doom9.org/showpost.php?p=1680789&postcount=808

[Daemon404]

x265 does not currently support 2-Pass encoding.

If you have copious amounts of CPU-time and/or time, you could use Newton–Raphson (http://en.wikipedia.org/wiki/Newton%27s_method) or Brent's Method (http://en.wikipedia.org/wiki/Brent%27s_method) with x265's CRF mode, which should be more or less equivalent to its upcoming 2pass, if it follows x264's 2pass ratecontrol (aside from stuff like reference reordering, of course).

SciPy makes it pretty easy, e.g. for x264:


from scipy.optimize import brentq
import subprocess
import re

def f(x):
x264 = subprocess.Popen(['./x264', '--preset', 'placebo', '--crf', '%f' % x, '-o',
'/dev/null', '../v3.yuv', '--input-csp', 'i420', '--fps', '50',
'--input-res', '3840x2160', '2>&1'],
stdout=subprocess.PIPE, stderr=subprocess.STDOUT)
for line in iter(x264.stdout.readline,''):
line = line.rstrip()
if re.match('encoded', line):
return float(re.sub('encoded \d+ frames, \d+\.\d+ fps, (\d+\.\d+) kb/s', '\g<1>', line)) - 5892.3


print(brentq(f=f, a=25, b=30, xtol=0.05))

Particularly useful since the vast amount of encoding libraries which exist have terrible ratecontrol.

Well, I know you're an offline guy, but there is a whole world of low latency real-time encoding applications that need ABR and its derivatives... VBV, HRD, CBR.

Not entirely, no. Some interesting things are CRF mode with VBV and a max CRF value, which I think x265 already supports, as of recently (kudos).

The idea of CBR being needed seems rather silly, though ABR+VBV is certainly useful for a livestream environment (while simultaneously sending off chunks to 2pass in the background, for use with e.g. MPEG-DASH or HLS or whatever). YouTube has something like this IIRC.

What exactly is the usecase of CBR?

Note... I don't mean to use the term "freeload" in a derogatory manner. Using x265 for free is a legitimate option for many companies. The free-rider problem (http://en.wikipedia.org/wiki/Free_rider_problem) is an inherent part of our dual open source / commercial license business model. Our challenge is to convince companies that could otherwise pay nothing that it is in their best interest to back the project. Fortunately, we're succeeding in those efforts.

Some companies prefer to contribute in the form of patches/bug fixes/features/at-scale-fuzzing/etc, which I do think is a valuable thing for an open source project which may otherwise not have access to such developer time and/or that scale of testing (FFmpeg/Libav get a lot of this, and a bunch of x264's features were contributed this way as well). This would apply less to x265, I suppose, as it started life as a commercial venture.

[x265_Project]

Some companies prefer to contribute in the form of patches/bug fixes/features/at-scale-fuzzing/etc, which I do think is a valuable thing for an open source project which may otherwise not have access to such developer time and/or that scale of testing (FFmpeg/Libav get a lot of this, and a bunch of x264's features were contributed this way as well). This would apply less to x265, I suppose, as it started life as a commercial venture.
True. This is a key competitive advantage of our business model, vs. all of our fully proprietary competitors.

[LoRd_MuldeR]

x265 1.0+74 still produces strong artifices when Psy-RD is enabled.

Binary (vanilla MSVC 2013.2 build):
http://www.mediafire.com/download/uops57uebg5pcbq/x265.win-x64-8bit.2014-05-19.rar

Command:
x265.exe --preset veryslow --psy-rd 1.0 -o psytest.hevc foreman_cif.y4m

Result:
http://www.mediafire.com/download/n379fbcl74rr7dr/psytest.2014-05-19.rar

[benwaggoner]

x265 1.0+74 still produces strong artifices when Psy-RD is enabled.
I see several psy-rd fixed were checked in on Friday. Do you know if they were included in your build?

This one in particular sounds significant https://bitbucket.org/multicoreware/x265/commits/f3f3eecd28f120716c531ba2e18c88d26dc54374

[LoRd_MuldeR]

I see several psy-rd fixed were checked in on Friday. Do you know if they were included in your build?

This one in particular sounds significant https://bitbucket.org/multicoreware/x265/commits/f3f3eecd28f120716c531ba2e18c88d26dc54374

Yeah, I saw those fixes. That's why I made a new build (v1.0+74) today, but the problem remains. As explained in my previous post.

(Note: I only tried MSVC 2013.2, x64, 8-Bit)

[benwaggoner]

Yeah, I saw those fixes. That's why I made a new build (v1.0+74) today, but the problem remains. As explained in my previous post.
Oh well. Early days yet for this feature.

[foxyshadis]

Yeah, it looks like psy-rd is badly broken. On a frame-by-frame, I constantly get big fat sharp squares a little offset from where they should be, which fade away as the next couple frames compensate, bringing the overall quality way down. More in the 8-bit than 16-bit, and they're never the same from encode to encode. --noasm does not seem to fix it. (using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX)

Without psy-rd, foreman looks amazing at 400k; with it, it's a flickery mess even at a much larger size.

[x265_Project]

Oh well. Early days yet for this feature.
Yes, it will take some time to optimize psy-rd for HEVC.

Yeah, it looks like psy-rd is badly broken. On a frame-by-frame, I constantly get big fat sharp squares a little offset from where they should be, which fade away as the next couple frames compensate, bringing the overall quality way down. More in the 8-bit than 16-bit, and they're never the same from encode to encode. --noasm does not seem to fix it. (using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX)

Without psy-rd, foreman looks amazing at 400k; with it, it's a flickery mess even at a much larger size.
We appreciate the feedback from everyone. I wouldn't say it's broken... it's just not finished. Like most encoding features, we first implement the basic logic, and then we tune the algorithm, adapting it to HEVC. We thought it might be useful to expose the initial (untuned) implementation as an optional feature to get some feedback. We'll keep working to tune this up.

[LoRd_MuldeR]

I wouldn't say it's broken...

I would ;)

It's clear that any "psy" optimization has its pros and cons. And that finding a good trade-off is challenging. But those flashing "out of place" blocks we currently see with Psy-RD enabled certainly look much more like there's a serious bug somewhere in the code than just side-effects of the algorithm.

http://i.imgur.com/FDnsLSM.png

[x265_Project]

I would ;)

It's clear that any "psy" optimization has its pros and cons. And that finding a good trade-off is challenging. But those flashing "out of place" blocks we currently see with Psy-RD enabled certainly look much more like there's a serious bug somewhere in the code than just side-effects of the algorithm.
Yeah... I should have included bug fixes in my description of "tuning" above. Certainly, there may be bugs in the current early implementation... in fact, it's likely. But we know we have a lot of tuning left also.

[LigH]

I did not see any issues with my MSYS build of v1.0+74 on a Phenom-II (SSE2). Does it depend on the compiler, on the resolution ... on CPU instructions?

[xooyoozoo]

I did not see any issues with my MSYS build of v1.0+74 on a Phenom-II (SSE2). Does it depend on the compiler, on the resolution ... on CPU instructions?

Just to be clear, this is with psy-rd turned on? It's off by default.

[LigH]

Gosh, I wonder why I made my computer science graduation... ;) — Yes, all presets with additional '--psy-rd 1.0'.

-o tos_60s_360_%preset%.hevc --preset %preset% --psnr --ssim --log 3 --csv tos_60s_360_%preset%.csv --psy-rd 1.0

OK, in the Sintel trailer, there are shaky and flaky areas when there is little, slow motion. The parkrun should provoke some too...
__

P.S.: Uploaded (https://www.mediafire.com/folder/6lfp2jlygogwa/HEVC) 720p50 parkrun veryslow, with and without "--psy-rd 1.0"; with is much bigger, and movement is choppy (especially look at the umbrella).

[Romario]

@ x265_Project

What is with x265 optimizations ? I mean an SSE3 and others instructions set, newest. Is newest x265 1.0, at least in part, optimized for Intel Haswell ? When can we expect better optimisation ?

Thank you for answer.

[LigH]

Already for several versions, x265 supports optimized algorithms for e.g. SSE2, SSSE3, SSE4.1, AVX, FMA...; speed optimizations are constantly arriving, not only in assembler, but also for more general algorithms. Wouldn't you be rather surprised if it was not the case?

[foxyshadis]

Sadly, the sa8d fix didn't solve the psy-rd problem on low-motion scenes, and doesn't even seem to have made a dent in it: https://www.dropbox.com/s/4u2a9tz6vnpzyib/foreman-psyrd-fix.hevc

x265_10 --crf 30 --preset veryslow --psy-rd 1.0 --input foreman_cif.y4m foreman-psyrd-fix.hevc

[x265_Project]

Sadly, the sa8d fix didn't solve the psy-rd problem on low-motion scenes, and doesn't even seem to have made a dent in it: https://www.dropbox.com/s/4u2a9tz6vnpzyib/foreman-psyrd-fix.hevc

x265_10 --crf 30 --preset veryslow --psy-rd 1.0 --input foreman_cif.y4m foreman-psyrd-fix.hevc
Yes, we are aware of the issues, and the team is working on it.

[x265_Project]

The psy-rd bug is still bugging us. The team is making progress, but we're not there yet. Please hold off testing psy-rd for now.

Thanks,
Tom

[Chengbin]

Out of curiosity, how many full time developers are there that are working on x265? Steve Borho seems to be doing most of the commits, but it seems hard to believe (and incredible) if there's only 1 full time developer for x265.

[x265_Project]

Out of curiosity, how many full time developers are there that are working on x265? Steve Borho seems to be doing most of the commits, but it seems hard to believe (and incredible) if there's only 1 full time developer for x265.

There are many developers, but only a few people have commit rights. You can see author of each patch on Bitbucket, or on the development mailing list.

[LigH]

Some test results of the "noise reduction" (encoded with x265 v1.0+103) are being uploaded (http://www.mediafire.com/?6lfp2jlygogwa): tos_60s_fast_nr[0|100|1000].mp4

My first impression is that it can give a smaller file with a cleaner image and less motion-shaky artefacts.

[Atak_Snajpera]

I think it is time to take a look at settings used in presets. I've tested those presets with first 10 min of Drive movie (http://www.imdb.com/title/tt0780504/?ref_=nv_sr_1).
Frame size after cropping: 1920x800
My CPU: Intel Xeon E5-2690 ( 8C / 16T )
Common command line: --crf 20 --min-keyint 24 --keyint 240
NOTE: In order to achieve max cpu usage and encoding speed in x265 I was encoding two 1 min chunks at the same time. (10 chunks total)

http://i.imgur.com/rV4FQGi.png

As you can see difference in encoding speed is marginal between superfast and fast. Also there is huge drop from fast to medium (almost 2x)

and for comparison ...

http://i.imgur.com/XAFTyUj.png

[x265_Project]

I think it is time to take a look at settings used in presets.
I've been thinking the same thing, and we're looking at this. We run a full sweep of tests on a wide range of video sequences every week, on multiple machine types. In general we still see a good trade-off of speed vs. quality, but we want to make sure that the presets represent the highest possible points, spread out along the speed vs quality (efficiency) curve.

Tom

[Atak_Snajpera]

I think you should change for example ME in superfast preset to DIA like in x264. merange should be also reduced in superfast and veryfast. Settings from medium preset should be moved to slow preset. New Medium preset should use old fast preset settings and so on.

[qyot27]

Since we're talking about the presets, IMO the zerolatency and fastdecode tunings should be rolled into ultrafast - especially since both of those tunings contain settings that speed things up (or disable default things that I honestly think ultrafast should be disabling anyway, like B-frames), but since you can only enable one tuning at a time, it requires the user to put the rest of the settings in manually. Similarly, other settings could be turned down to the bare minimum needed for them to make sense, or turned off completely, as the logic behind ultrafast is pretty much to just go as fast as possible, accuracy:filesize ratio be damned.

For comparison, x264's zerolatency and fastdecode tunings are included in its ultrafast preset, for the most part.


The patch I've been using locally to do this, for example:
diff --git a/source/common/param.cpp b/source/common/param.cpp
index c6fb9d5..989c8d4 100644
--- a/source/common/param.cpp
+++ b/source/common/param.cpp
@@ -246,10 +246,13 @@ int x265_param_default_preset(x265_param *param, const char *preset, const char

if (!strcmp(preset, "ultrafast"))
{
- param->lookaheadDepth = 10;
- param->scenecutThreshold = 0; // disable lookahead
- param->maxCUSize = 32;
- param->searchRange = 25;
+ param->lookaheadDepth = 1;
+ param->scenecutThreshold = 0;
+ param->maxCUSize = 16;
+ param->searchRange = 16;
+ param->maxNumMergeCand = 1;
+ param->rdLevel = 0;
+ param->bframes = 0;
param->bFrameAdaptive = 0;
param->subpelRefine = 0;
param->searchMethod = X265_DIA_SEARCH;
@@ -258,8 +261,10 @@ int x265_param_default_preset(x265_param *param, const char *preset, const char
param->bEnableEarlySkip = 1;
param->bEnableCbfFastMode = 1;
param->bEnableSAO = 0;
+ param->bEnableLoopFilter = 0;
param->bEnableSignHiding = 0;
param->bEnableWeightedPred = 0;
+ param->bEnableWeightedBiPred = 0;
param->maxNumReferences = 1;
param->rc.aqStrength = 0.0;
param->rc.aqMode = X265_AQ_NONE;
--
1.9.1

[xooyoozoo]

Since we're talking about the presets, IMO the zerolatency and fastdecode tunings should be rolled into ultrafast - especially since both of those tunings contain settings that speed things up (or disable default things that I honestly think ultrafast should be disabling anyway, like B-frames), but since you can only enable one tuning at a time, it requires the user to put the rest of the settings in manually. Similarly, other settings could be turned down to the bare minimum needed for them to make sense, or turned off completely, as the logic behind ultrafast is pretty much to just go as fast as possible, accuracy:filesize ratio be damned.

For comparison, x264's zerolatency and fastdecode tunings are included in its ultrafast preset, for the most part.


The patch I've been using locally to do this, for example:


The main presets should still be pareto optimal (http://en.wikipedia.org/wiki/File:PareoEfficientFrontier1024x1024.png) and reasonably spaced, so although your assumptions may be correct, testing is needed to make sure the changes are worth it. For example, it would be silly if changing lookaheadDepth lowers quality by 10% but only increases speed by 0.1%.

[qyot27]

The main presets should still be pareto optimal (http://en.wikipedia.org/wiki/File:PareoEfficientFrontier1024x1024.png) and reasonably spaced, so although your assumptions may be correct, testing is needed to make sure the changes are worth it. For example, it would be silly if changing lookaheadDepth lowers quality by 10% but only increases speed by 0.1%.
A 0.1% speed increase in general wouldn't really qualify as a reason to turn something off/down, though.

It may be worth considering architecture constraints too - if you're encoding on a Sandy Bridge or Haswell, then it might be a 0.1% speed increase vs. 10% quality drop, but on an Orleans or Yorkfield it could boost speed far more than 0.1% because those can't take advantage of the higher SIMD sets. Also that the -fast presets would generally tend to be used more with older CPUs like those.

[x265_Project]

A 0.1% speed increase in general wouldn't really qualify as a reason to turn something off/down, though.

It may be worth considering architecture constraints too - if you're encoding on a Sandy Bridge or Haswell, then it might be a 0.1% speed increase vs. 10% quality drop, but on an Orleans or Yorkfield it could boost speed far more than 0.1% because those can't take advantage of the higher SIMD sets. Also that the -fast presets would generally tend to be used more with older CPUs like those.

Yes, there are lots of complicating factors when it comes to picking 10 performance presets, including the hardware and the type of content. We welcome input / test results / analysis on this topic.

In general, I'd like to see our medium (default) preset get faster without any appreciable impact on encoding efficiency (quality@ a given bit rate). I think that this is possible, but we haven't had a chance to run the kind of tests that we want to run.

I'd also like to see our Ultrafast get faster, if possible, but I don't view Ultrafast as a "max speed at any cost" setting. My view is that these presets are for users who don't want to mess with the individual options, and I want to protect these users from doing something that strays too far from the normal speed vs efficiency tradeoff.

Of course we'd like to see our highest quality presets (veryslow, placebo) become even more efficient, but with these settings we've got every algorithm dialed up to "full on". So, I don't think that it's possible today to improve these presets much with the current build, but I'd love it if someone could prove me wrong! We've got a number of algorithmic improvements designed to produce higher visual quality still in development, and I think that this is how we will move these presets in the right direction.

Ideally, we would like to see the 10 performance presets somewhat evenly spaced along the speed vs. efficiency curve, but generally that isn't possible. When you turn certain things on or off you can see a big impact on encoding speed, and so you get a bigger difference in speed between these presets. At the high-quality end, as everyone knows, there are diminishing returns on efficiency as you spend more time looking for the optimal way to encode.

Tom

[benwaggoner]

I've seen a TON of psy-rd related commits come in over the last week, related to the new m_totalPsyCost parameter.

This latest seems like perhaps the culmination of that:https://bitbucket.org/multicoreware/x265/commits/306d3e6b5185da57b7d9200329626cc7bfac92be

Is psy-rd in a good point for evaluation right now, or are there more important fixes coming in the next few days?

Doing my UHD encodes, and with psy-rd requiring rd-mode 5/6, psy-rd commits are coming faster than my encodes complete :).

[x265_Project]

I've seen a TON of psy-rd related commits come in over the last week, related to the new m_totalPsyCost parameter.

This latest seems like perhaps the culmination of that:https://bitbucket.org/multicoreware/x265/commits/306d3e6b5185da57b7d9200329626cc7bfac92be

Is psy-rd in a good point for evaluation right now, or are there more important fixes coming in the next few days?

Doing my UHD encodes, and with psy-rd requiring rd-mode 5/6, psy-rd commits are coming faster than my encodes complete :).
We're not quite there yet Ben. We'll let everyone know when our tests show positive results.

Tom

[x265_Project]

Heads up... we will be adjusting our performance presets.

The default setting (the medium preset) will be adjusted to include the --no-rect and --no-amp options, becoming faster (on average, about 70%, but as much as 90%), with a very slight (~ 1 - 4%) impact on encoding efficiency. Expect a few additional adjustments going forward.

Tom

[zerowalker]

Wait, does disabling does increase speed by 70-90% but decrease encoding efficiency only by 1-4%?

Isn't that colossal, it's nearly double the speed for next to no disadvantage, sounds to good to be true.

[EncodedMango]

Isn't that colossal, it's nearly double the speed for next to no disadvantage, sounds to good to be true.
Sounds like how it is for presets in x264, the slowest ones only add up to very low compression efficiency %age

[x265_Project]

Wait, does disabling does increase speed by 70-90% but decrease encoding efficiency only by 1-4%?

Isn't that colossal, it's nearly double the speed for next to no disadvantage, sounds to good to be true.
It's true, but only the medium, fast and faster presets are affected by the change. Veryfast, superfast and ultrafast haven't used --rect or --amp. The slow, slower, veryslow and placebo modes will continue to use --rect and --amp.

We've made a lot of changes since we last configured the performance presets, and it's definitely time for a few adjustments. The --rect function enables rectangular coding units (CUs), but it takes a lot more time to test all of these possibilities, and at the default (medium) setting, the benefit was very small.