x265 HEVC Encoder

[Jamaika]

Thanks. Now I know what means non deterministic.
I can only say that for 220 frames is the difference 23kb file size.(6000kbps,25fps)

[Ma]

I use three codecs X265 1.9+183 different authors (WAW/Ligh /Selur) and received three different results in the binary HEX. (Veryslow/tune grain /hightier/pass2)
Is it possible?

Yes, it is. Problem is known -- you can read last sentence at page https://bitbucket.org/sborho/test-harness

If you read second sentence in Performance TODOs at page https://bitbucket.org/multicoreware/x265/wiki/TODO it will be the solution.

There is even a patch proposal -- https://patches.videolan.org/patch/13186/

At page www.msystem.waw.pl/x265 for GCC builds I've weakened optimization level (from -O3 to -O2) for file encoder/sao.cpp and all builds from this site should produce bit exact result (with exception for compiler name).

[Jamaika]

At page www.msystem.waw.pl/x265 for GCC builds I've weakened optimization level (from -O3 to -O2) for file encoder/sao.cpp and all builds from this site should produce bit exact result (with exception for compiler name).
SAO is reportedly off for tune grain.:)

[Ma]

SAO is reportedly off for tune grain.:)

I don't use '--tune grain', so maybe my builds produces the same output only with "my" settings. Could you specify your command line? I will check if there is something else to do for bit exact output.

[Jamaika]

ffmpeg.exe -loglevel verbose -i "orginal.MP4" -r 25000/1000 -ss 14.320 -vf scale=1920x1080:flags=lanczos+accurate_rnd,format=yuv420p -an -sn -f yuv4mpegpipe - |
x265_ml.exe --y4m --info --limit-modes --tune grain --preset veryslow --high-tier --no-open-gop --no-hrd --input-depth 8 --input-res 1920x1080 --input-csp i420
--output-depth 8 --fps 25000/1000 --keyint 60 --bitrate 6000 --vbv-bufsize 10000 --vbv-maxrate 10000 --pass 2 --stats x265_2pass_1.log --colormatrix bt709 --colorprim bt709 --transfer bt709 --output "film1.h265" -

[Ma]

Thanks! I confirm that VS 2015, GCC 6.1 and GCC 6.1 32-bit builds produce different outputs with your settings. So I'm starting investigation...

[nandaku2]

Thanks! I confirm that VS 2015, GCC 6.1 and GCC 6.1 32-bit builds produce different outputs with your settings. So I'm starting investigation...

Any VBV encode is non-deterministic (same binary, same commandline run twice on the same machine) will produce slightly different results, due to non-deterministic thread synchronization of wpp rows.

That apart, different machines will produce different results (different #threads and sync points), different compilers will produce different results (due to differences in FP operations). Apart from these, our automated tests track all output changing commits in the test-harness repo.

[Jamaika]

Any VBV encode is non-deterministic (same binary, same commandline run twice on the same machine) will produce slightly different results, due to non-deterministic thread synchronization of wpp rows.
You're right. VBV can be turned off and the file size is deterministic. However, I am surprised that the error tolerance file size for low VBV is ±23kb.
That apart, different machines will produce different results (different #threads and sync points), different compilers will produce different results (due to differences in FP operations). Apart from these, our automated tests track all output changing commits in the test-harness repo.
I understand that this means the old processors with threads=4 throw out. HEVC is too large differences in results. I think it is impossible to compare films eg. in amounts streaks or grains.

[nandaku2]

You're right. VBV can be turned off and the file size is deterministic. However, I am surprised that the error tolerance file size for low VBV is ±23kb.

The file size as a metric is meaningless. The percentage change in bitrate is designed to be really low.

I understand that this means the old processors with threads=4 throw out. HEVC is too large differences in results.

What are you comparing against?

[Jamaika]

The percentage change in bitrate is designed to be really low.
Indeed, you're right. It can be the difference in file size, but the bitrate allocation is the same.;)

Insert two pictures.
http://i63.tinypic.com/t7fo90.png
http://i67.tinypic.com/2dsh1lc.png

PS The percentage change in bitrate one frame I is 0%.
The percentage change in bitrate one frame P is 0.59%.(x47)
The percentage change in bitrate one frame B is 0.26%.(x168)

You're right. VBV can be turned off and the file size is deterministic. However, I am surprised that the error tolerance file size for low VBV is ±23kb.
Sorry. I add bufsize 10000kbps but codec change parameter to 33000kbps. My reasoning was from outer space.

PS After many tests, I reach to the conclusion that for vbv=30000kbps codec LigH something wrong counts. The rest accepted.

[Selur]

Got a dual Xeon E5640 system and I wonder what I could do to boost the cpu usage during x265 encoding

atm. I use:
265 --preset slow --pme --input - --output-depth 10 --y4m --profile main10 --no-high-tier --level-idc 4.1 --amp --no-open-gop --weightb --crf 18.00 --psy-rdoq 15.00 --vbv-maxrate 20000 --vbv-bufsize 20000 --range limited --colormatrix bt709 --output "D:\09_02_06_7310_02.265"
and run two encodes in parallel, but cpu usage still is just around 65%. Input and output are inside a RAM disk and decoding also isn't the bottleneck, so the problem is with the x265 settings. (I get ~5fps per encoder instance)

adding different --pools settings just caused the encoding to be even slower.
using different --frame-threads counts doesn't seem to help either
using --pmode additionally to --pme doesn't help
using msvc instead of mingw builds doesn't help (version I use is 1.9+183)

-> Is there some recommendations on what to do, to utilize the CPU on multi socket systems better?

Cu Selur

Ps.: I know that the system isn't new and only MMX2 SSE2Fast SSSE3 SSE4.2 optimization is used, but it's really bugging me that the only way to get a proper cpu usage and cumulative speed is to run 3 or more encodes at a time,.. (nowadays I only encode one file a week or so ;))

[MeteorRain]

Got a dual Xeon E5640 system and I wonder what I could do to boost the cpu usage during x265 encoding

atm. I use:
265 --preset slow --pme --input - --output-depth 10 --y4m --profile main10 --no-high-tier --level-idc 4.1 --amp --no-open-gop --weightb --crf 18.00 --psy-rdoq 15.00 --vbv-maxrate 20000 --vbv-bufsize 20000 --range limited --colormatrix bt709 --output "D:\09_02_06_7310_02.265"
and run two encodes in parallel, but cpu usage still is just around 65%. Input and output are inside a RAM disk and decoding also isn't the bottleneck, so the problem is with the x265 settings. (I get ~5fps per encoder instance)

1. What's your source? Is it source related performance issue?
2. Here on i7, it maxes out my 4c8t so easily on -F 1 --pools 6, with pme and pmode off. Doesn't make sense for 65% on parallel encoding.

[Selur]

Source is HD, the source resolution I feed to x265 an SD resolution. Source decoding isn't the issue since I can easily run multiple decoder instances and they all still produce 200fps with no real cpu usage.
On my i7 4770k, cpu usage is maxed out too and encoding speed is way higher, but it's a single socket system and a lot newer. ;)

[LigH]

@MeteorRain: But you don't have any dual-socket mainboard with two separate CPUs? That's the point of interest here.

@ Selur: Frame dimensions will be interesting here. I remember from a console notification that some features are disabled for small frame heights, probably because it wouldn't make sense to divide the frame into such small slices.

[Selur]

@LigH: afaik lookahead-slices should be the only thing that gets disabled with source height < 720p.
Typically the resolution I use is 704x576 or 704x480.
Using ~35% per encode with the given command line simple seems way to low for me. (and no, on a single socket system this issue does not appear, all my single socket system always have 85+% usage for a single encode using the same settings,... )
My single socket systems also use way more cpu optimizations, since the cpus are newer (typically MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2), so it might be that some CPU features are needed to properly use x265,...

[MeteorRain]

@MeteorRain: But you don't have any dual-socket mainboard with two separate CPUs? That's the point of interest here.
True.

So, @Selur, maybe you can try to disable one socket using CPU affinity, and see how it goes?

Options,
1) --pools +,-
2) Change the cmd.exe affinity to only use first sockets, then from that cmd window, run your command with --pools 8
3) Unplug one CPU and see how it works

[Selur]

@MetorRain: and to avoid some blind testing I thought it might be easier to ask here, since iirc a bunch of other users here use multi socket systems and probably encode a bit more then I do nowadays ;)

---

Only thing that seems to help with the cpu usage, is to use a 720p or higher resolution where the --lookahead-slices are not disabled,.. :(

[pradeeprama]

True.

So, @Selur, maybe you can try to disable one socket using CPU affinity, and see how it goes?

Options,
1) --pools +,-
2) Change the cmd.exe affinity to only use first sockets, then from that cmd window, run your command with --pools 8
3) Unplug one CPU and see how it works

We recently found some issues with the way in which x265 runs on multi-socket windows machines (I'm assuming you're using windows). There is an outstanding patch that should fix this problem - https://patches.videolan.org/patch/13436/. Can you see if this helps you out? You should see better multi-socket utilization.

Pradeep.

[Selur]

Yes, I'm on Windows. -> will try the patch
failed to apply the patch, so would be nice if someone could make a numa enabled build with the patch applied,..

[Ma]

Yes, I'm on Windows. -> will try the patch
failed to apply the patch, so would be nice if someone could make a numa enabled build with the patch applied,..

There is a small bug in this patch. Instead of:
int popCount(uint64_t x)
should be:
static int popCount(uint64_t x)

Compiled multilib version: www.msystem.waw.pl/x265/x265-1.9+183+p13436+static.7z

[Selur]

Thanks Ma!
Using that version cpu usage fluctuates a lot more and when running two encodes in parallel average boost usage to 85%+ :)

[pingfr]

Looks like we're getting closer and closer to a newer milestone release to me once that NUMA patch gets merged in the main tree.

- Presets tinkered a bit further: Done.
- Implementation of the --[no-]recursion-skip and --slow-firstpass features: Done.
- Tune grain improvements: Done.
- Docs cleaned out: Done.
- Multi-pass tweaks: Done.
- Full UNICODE support: Done.
- NUMA systems optimization: Done.

Now all we need is to get rid of that nasty "purple ghosting" effect users have reported in the previous pages and it sounds like we have a good candidate for a x265-2.0 release. ;)

That's just an assumption from my end, nothing else. It would just seem silly to bump the 1.9 version further forever "a la" x265-1.9+64829173.

Time to let go 1.9 and shoot for x265-2.0 boys! :)

[Leo 69]

The codec got much better with the latest release in terms of visual quality but the encoding speed slowed down drastically. Fully keeping the original film grain and sharpness is still an issue with any settings one can imagine.

[littlepox]

Looks like we're getting closer and closer to a newer milestone release to me once that NUMA patch gets merged in the main tree.

- Presets tinkered a bit further: Done.
- Implementation of the --[no-]recursion-skip and --slow-firstpass features: Done.
- Tune grain improvements: Done.
- Docs cleaned out: Done.
- Multi-pass tweaks: Done.
- Full UNICODE support: Done.
- NUMA systems optimization: Done.

Now all we need is to get rid of that nasty "purple ghosting" effect users have reported in the previous pages and it sounds like we have a good candidate for a x265-2.0 release. ;)

That's just an assumption from my end, nothing else. It would just seem silly to bump the 1.9 version further forever "a la" x265-1.9+64829173.

Time to let go 1.9 and shoot for x265-2.0 boys! :)

waiting for the v2.0 build as well, when the recent changes should be settled to some stable implements. Then we are ready to do our 4th round of massive tuning test.

[pingfr]

waiting for the v2.0 build as well, when the recent changes should be settled to some stable implements. Then we are ready to do our 4th round of massive tuning test.

I think I can safely say on the behalf of the community, we can't wait for your 4th round of tests. :D

[nandaku2]

Looks like we're getting closer and closer to a newer milestone release to me once that NUMA patch gets merged in the main tree.

- Presets tinkered a bit further: Done.
- Implementation of the --[no-]recursion-skip and --slow-firstpass features: Done.
- Tune grain improvements: Done.
- Docs cleaned out: Done.
- Multi-pass tweaks: Done.
- Full UNICODE support: Done.
- NUMA systems optimization: Done.

Now all we need is to get rid of that nasty "purple ghosting" effect users have reported in the previous pages and it sounds like we have a good candidate for a x265-2.0 release. ;)

That's just an assumption from my end, nothing else. It would just seem silly to bump the 1.9 version further forever "a la" x265-1.9+64829173.

Time to let go 1.9 and shoot for x265-2.0 boys! :)

Yes - this is the direction. We're also investigating a couple more quality issues in veryslow, as well as SAO.

I can't seem to locate any ghosting artifact issues posted, which is not a sub-720p resolution (in which case, folks, please consider lowering max-CTU). Can someone help me out here?

[pingfr]

I can't seem to locate any ghosting artifact issues posted, which is not a sub-720p resolution (in which case, folks, please consider lowering max-CTU). Can someone help me out here?

I think it is firstly posted around the page 183'ish of this thread?

Also see this specific post:

http://forum.doom9.org/showpost.php?p=1766393&postcount=3660

There appears to be some "ghosting effect" reported.

[LigH]

I believe you misunderstood, possibly due to the comma: nandaku2 believes that there is no report of ghosting artefacts with at least some HD resolution; all ghosting reports seem to address lower resolutions.

The only report I remember where some motion related issue was reported for a higher resolution video was the StarWars clip where a star blinked when the text started to scroll by.

[pingfr]

Oh, ermph. Was only trying to help. :)

[littlepox]

For resolution <= 720p, never a single case out of our hundreds of tests ever suggest that x265 outperforms x264 by any significant measure; most of the tests prove x264 to be a much better choice, at least before x265 v1.9.

[Jamaika]

The only report I remember where some motion related issue was reported for a higher resolution video was the StarWars clip where a star blinked when the text started to scroll by.
The worst are large transparent subtitles with some effects, but not nitpicking at this stage of development.

PS The smaller the image, the less one can see.;)

[Selur]

@jamaika: It would probably help if the developers hat a sample of an input file to reproduce the issue. ;)

[roo1234]

For resolution <= 720p, never a single case out of our hundreds of tests ever suggest that x265 outperforms x264 by any significant measure; most of the tests prove x264 to be a much better choice, at least before x265 v1.9.
X265 clearly outperforms x264 in very low bitrates/perceived quality

[MeteorRain]

X265 clearly outperforms x264 in very low bitrates/perceived quality

Well, I assume LP was talking about higher bitrate where quality alone matters. On very low bitrate, x265 might fit better.

[littlepox]

X265 clearly outperforms x264 in very low bitrates/perceived quality

In 2016, very low bitrate @ 720p is NOT a significant measure.

[Jamaika]

@jamaika: It would probably help if the developers hat a sample of an input file to reproduce the issue. ;)
It's not a problem for me. I try not use transparent subtitle.

For the inquisitive.
https://www.sendspace.com/file/3ijlto

[roo1234]

In 2016, very low bitrate @ 720p is NOT a significant measure.
You wrote <=720, which means all resolutions until 720. X265 is Winner in that.

[fauxreaper]

There's artifacts in sample posted on https://mailman.videolan.org/pipermail/x265-devel/2016-May/010350.html even with --no-recursion-skip. You just need to encode this sample video with subtitles to see the artifacts.

[nandaku2]

There's artifacts in sample posted on https://mailman.videolan.org/pipermail/x265-devel/2016-May/010350.html even with --no-recursion-skip. You just need to encode this sample video with subtitles to see the artifacts.

Thanks - this is the one I was looking for.

[littlepox]

You wrote <=720, which means all resolutions until 720. X265 is Winner in that.

I mean very few people would like a bitrate-starving 720p nowadays, like 1000Kbps, which is even lower than the online videos.

Even x265 is indeed the winner, so what? With all the FHD/UHD monitors and TB sized hard drive, we are not in the rmvb/xvid->x264 era. If you can only do 720p, at least feed it with enough bitrate and retain those fragile details as much as possible.

[pingfr]

@littlepox: For me, the real argument to favor x265 over x264 at the moment is because there has been very little dev/work done on x264 over the past months. At this point it feels like x264 dev has halted or at least reached a point there is very little optimization left to do.

On the contrary, x265 is the "next gen" encoder and it's free, open source and well discussed/dev/maintained.

It's safe to say there is still a lot of headroom ahead of ourselves to improve the compression:quality factor even if that is at the cost of time:cpu-cycles spent either encoding or decoding.

x264/AVC/VC-1 is a thing of the past. HD/1080p/Blu-Ray is the past.
x265/HEVC is the way to go. UHD/4K/Ultra Blu-Ray is the future.

[roo1234]

I mean very few people would like a bitrate-starving 720p nowadays, like 1000Kbps, which is even lower than the online videos.

Even x265 is indeed the winner, so what? With all the FHD/UHD monitors and TB sized hard drive, we are not in the rmvb/xvid->x264 era. If you can only do 720p, at least feed it with enough bitrate and retain those fragile details as much as possible.
Why most only think of local files? Ok, we have terabytes of cheap storage, but what if youre on a low bandwidth and would like an online video, etc? Bandwidth savings mean $$$ and accessibility to masses. Thats why lossy codecs are evolving, doing more with less.
Well, that and a better efficiency for higher res.

[Jamaika]

I mean very few people would like a bitrate-starving 720p nowadays, like 1000Kbps, which is even lower than the online videos.
Oh, they would be lose count. First, you must have a well-recorded video, a free codec is a addition. In Webcamming sports and 3000kbps is not enough.

[benwaggoner]

Got a dual Xeon E5640 system and I wonder what I could do to boost the cpu usage during x265 encoding

atm. I use:
265 --preset slow --pme --input - --output-depth 10 --y4m --profile main10 --no-high-tier --level-idc 4.1 --amp --no-open-gop --weightb --crf 18.00 --psy-rdoq 15.00 --vbv-maxrate 20000 --vbv-bufsize 20000 --range limited --colormatrix bt709 --output "D:\09_02_06_7310_02.265"
and run two encodes in parallel, but cpu usage still is just around 65%. Input and output are inside a RAM disk and decoding also isn't the bottleneck, so the problem is with the x265 settings. (I get ~5fps per encoder instance)

adding different --pools settings just caused the encoding to be even slower.
using different --frame-threads counts doesn't seem to help either
using --pmode additionally to --pme doesn't help
using msvc instead of mingw builds doesn't help (version I use is 1.9+183)

-> Is there some recommendations on what to do, to utilize the CPU on multi socket systems better?

I think that --pme is the likely culprit. You need a LOT of threads for that to do anything useful, and in typical use I've seen it actually slow things down. Generally --pmode is much more useful on a dual Xeon.

[benwaggoner]

I can't seem to locate any ghosting artifact issues posted, which is not a sub-720p resolution (in which case, folks, please consider lowering max-CTU). Can someone help me out here?
If the optimal max-CTU value changes based on resolution, can x265 use a different default value based on the encoded resolution? In general, the defaults and presets should take advantage of whatever encoder-time state information is available to better tune default encodes.

[benwaggoner]

In 2016, very low bitrate @ 720p is NOT a significant measure.
Perhaps not for your use case, but it certainly matters for a LOT of use cases. For adaptive streaming, a good very low bitrate 720p means that low-bandwidth clients could now get HD instead of SD.

[littlepox]

Perhaps not for your use case, but it certainly matters for a LOT of use cases. For adaptive streaming, a good very low bitrate 720p means that low-bandwidth clients could now get HD instead of SD.

I'm not saying that low bitrate encoding is insignificant, I'm trying to say that currently for x265 to demonstrate some advantage, the bitrate must be RIDICULOUSLY low so that it's even unpractical for online videos. In that situation the video looks too blurry and washed to be classified as "720p HD", and at that bitrate, x264@480p looks no worse even with upscale.

It's possible in the future that x265 will make it acceptable to human eyes, but not now, not before x265 v1.9.

[Magik Mark]

May we ask what we should focused on testing build 192? Thanks


Sent from my iPhone using Tapatalk

[eclipse98]

Yes - this is the direction. We're also investigating a couple more quality issues in veryslow, as well as SAO.

I can't seem to locate any ghosting artifact issues posted, which is not a sub-720p resolution (in which case, folks, please consider lowering max-CTU). Can someone help me out here?

Nandaku2, I posted an issue with color ghosting here: https://forum.doom9.org/showpost.php?p=1767169&postcount=3681

It has screenshots as well as original video source to re-produce the issue - all my attempts to get rid of these artifacts have failed, I tried pretty much everything. The only way to reduce artifacts by 30-40% is to use SSIM tune at expense of visual quality.

It gets worse though, in addition to bare trees/bushes, I have observed these artifacts on pine trees, rocky mountains and trees with leaves too (to a lesser degree). I can provide more samples if needed.

Cheers !

[x265_Project]

I'm not saying that low bitrate encoding is insignificant, I'm trying to say that currently for x265 to demonstrate some advantage, the bitrate must be RIDICULOUSLY low so that it's even unpractical for online videos. In that situation the video looks too blurry and washed to be classified as "720p HD", and at that bitrate, x264@480p looks no worse even with upscale.

It's possible in the future that x265 will make it acceptable to human eyes, but not now, not before x265 v1.9.

It frustrates us when we see someone say that x265 is no better than x264 for typical video resolutions and bit rates. That's not our experience, or the experience of any of the dozens of video experts at the companies and organizations we work with. We take it as a challenge. And so, we challenge you or anyone else to show us what you're seeing.

Please point us to a good test sequence that x264 encodes better than x265, and let us know the bit rate you prefer. Not something that was already compressed to consumer streaming video bit rates (which already has H.264 compression artifacts) - a real uncompressed or very lightly compressed (very high bit rate) video test sequence, like one of the videos posted on media.xiph.org (or CableLabs, Elemental, Harmonic, etc.). Any test video, at any bit rate. Tell us your preferred x264 settings also, and we'll encode to the same bit rate with x265 and let everyone judge which encode is better.

Before you run your own tests, be sure you're using the latest development build of x265. Littlepox - I know you have your own favorite x265 command-line recipe, but after May 12th, things changed, and I think that recipe won't deliver the best visual quality. I suggest that you start with default settings for --preset veryslow, and if you have time, also try --preset placebo (which is now noticeably better than veryslow). If you want to run faster than veryslow, also try adding --no-recursion-skip to your command line.