x265 HEVC Encoder

[jlpsvk]

Yeah....when using 720p, then CRF 17-18 will be OK.

[jlpsvk]

Originally Posted by anonymlol

jlpsvk, could you please run Ma's test as well? I'm curious about how much speed difference there is between your AVX2 capable i7-4790k (4.8GHz) and my AVX capable i7-2700k (4.8 GHz).

I will, but no earlier than in 13-14 hours. Must wait until current encode will finish. Hmm...I now realised, that after BIOS update I forgot to set the CPU back to 4.8GHz, so now encoding only at 4.2GHz.

[Ma]

Originally Posted by jlpsvk

Didi you tried my encode settings?

I had to stop my previous encoding and start from beginning (sound card driver failure), but now my encoding options are closer to your proposition:
--preset slower --crf 17.0 --rdoq-level 1 --psy-rd 0.4 --deblock -1

If there will be too much blur I will try something stronger (maybe exactly your proposition). I want more details and less blur, but I don't want to destroy quite good and balanced 10-bit x265 default output.

[RBX]

Originally Posted by jlpsvk

what do you mead by big screen? have 50" 1080p plasma watching from 3-4 meters and everything is OK.

I said "and", that means you need a good source as well. Re-encoding a poorly encoded file does't change much.

[MoSal]

Originally Posted by LigH

Daala even tries to derive chrominance from luminance.

It's the other way around.

[Ajvar]

Originally Posted by sneaker_ger

Your assumptions about crf are wrong. Just download the files and you will see they are both the same size.

My assumption about CRF is 100% solid truth. And about those 2 files, one was encoded with --tune-film (x264) and second was encoded with --tune-grain (x265) and that's not how proper comparison is made.

Originally Posted by anonymlol

jlpsvk, could you please run Ma's test as well? I'm curious about how much speed difference there is between your AVX2 capable i7-4790k (4.8GHz) and my AVX capable i7-2700k (4.8 GHz).

Are you totally sure that AVX Ivy Bridge is actually using AVX for everything and not SSE4 fo some part of work for example? I don't know this but have a feeling that AVX2 CPUs use AVX2 instructions for more work than older processors. This is just speculation though because I am not an expert, just a feeling because how big performace boost it gives.

[benwaggoner]

Originally Posted by Ajvar

Are you totally sure that AVX Ivy Bridge is actually using AVX for everything and not SSE4 fo some part of work for example? I don't know this but have a feeling that AVX2 CPUs use AVX2 instructions for more work than older processors. This is just speculation though because I am not an expert, just a feeling because how big performace boost it gives.

In comparisons between the Ivy Bridge cc3.8xlarge instances and the Broadwell cc4.8xlarge instances, we see a healty double-digit encoding speed improvement per clock/core. And the gap has been growing substantially as more AVX2 instructions get checked in. The differential is bigger with faster presets

Some of that is due to other microarchitectural changes, but I think the majority has been from AVX2 for a while now.

And yes, SSE4 and straight assembler gets used for lots of algorithms even with AVX and AVX2. Although there are now lots of AVX2 optimized functions that don't have an AVX function.

Checking the commits is pretty amazing to see the pace of AVX2 optimizations going in over the last month.

[Stereodude]

Originally Posted by jlpsvk

what do you mead by big screen? have 50" 1080p plasma watching from 3-4 meters and everything is OK.

Perhaps because you're too far away from a screen that size to notice. It's not just a function of screen size or just seating distance. Ignoring potential differences in visual acuity, it's a function of the ratio between screen size is and how far away you are from it.

[Boulder]

Originally Posted by Ajvar

My assumption about CRF is 100% solid truth. And about those 2 files, one was encoded with --tune-film (x264) and second was encoded with --tune-grain (x265) and that's not how proper comparison is made.

Unfortunately there is no equivalent for --tune film in x265, I would have used it if there were. --tune grain was used to retain as much detail as possible and as you can see from my later post, I also tried without any tuning and --rdoq-level 1 but it still smoothes the image much more than x264.

I'm not looking to compare identical settings, I'm looking to get x265's detail retention level as close as possible to x264's and thus possibly benefit from the more advanced techniques it uses.

[jlpsvk]

Originally Posted by anonymlol

jlpsvk, could you please run Ma's test as well? I'm curious about how much speed difference there is between your AVX2 capable i7-4790k (4.8GHz) and my AVX capable i7-2700k (4.8 GHz).

Running now at 4.2GHz only, as I am not by PC. But I noticed something interesting.... --pmode slows down encoding by about 0.3fps. Even if with --pmode, the CPU usage is at 98-100%, the encoding fps is slower. Without --pmode, CPU usage is about 80-85% but encoding fps is higher..

[LigH]

I remember this being mentioned already when it was introduced several months ago: Parallelizing mode decisions may be only useful under specific conditions. Possibly mainly for large dimensions. In my tests with smaller dimensions (up to 720p) and rather outdated CPUs, --pmode always slowed down the encoding.

Instead, parallelizing motion estimation (--pme) can speed up results, depending on the complexity of the encoding (a.k.a. preset).
__

Out-of-schedule, here are some additional builds, experimenting with jb_alvarado's media-autobuild_suite.

x265_1.5+420-24fdb661bb57.7z (MSYS, MinGW32, GCC 4.8.2, package from xhmikosr + 4x cross compile script, EXE+DLL)
x265_1.5+420-24fdb661bb57.GCC492.7z (MSYS2, MinGW64, GCC 4.9.2, media-autobuild_suite, EXE only, stripped and UPX'ed)

[jlpsvk]

Yep.... Removing --pmode and adding --pme make 1fps difference on my CPU.

[LazyNcoder]

I have a dual-cpu (6core/12thread each) machine and it's killing me (33% - 720p - slow preset - --aq-mode 2 --aq-strength 1.0). I'm using --pmode --pme --threads 48. it makes the final size a bit larger though(I think it lowers the quality too/not sure yet). Now I'll try it without --pmode to see what happens.

There's something I need to know though. someone mentioned that --frame-threads 1 would lower/remove the banding problem. I don't know if it's true or not( I mean I didn't test it yet) but I wonder if using options I mentioned above would increase the banding problem.

[jlpsvk]

@LigH
GCC 4.9.2 added another 0.4fps speed increase!!! Thanks for that build.

[jlpsvk]

Originally Posted by LazyNcoder

I have a dual-cpu (6core/12thread each) machine and it's killing me (33% - 720p - slow preset - --aq-mode 2 --aq-strength 1.0). I'm using --pmode --pme --threads 48. it makes the final size a bit larger though(I think it lowers the quality too/not sure yet). Now I'll try it without --pmode to see what happens.

There's something I need to know though. someone mentioned that --frame-threads 1 would lower/remove the banding problem. I don't know if it's true or not( I mean I didn't test it yet) but I wonder if using options I mentioned above would increase the banding problem.

If you're using 10-bit x265, banding isn't issue. So --frame-threads 1 isn't necessary. Tested by myself. Remove --pmode and replace --threads by --pools

[LigH]

Allowing more and more threads (via --pools) doesn't guarantee that more are eventually used: x265 doesn't use more frame threads than it calculates to be efficient.

[jlpsvk]

LigH...on the GCC 4.9.2 video does not play smoothly? Will test again...just first thoughts.

[Motenai Yoda]

Originally Posted by LigH

Out-of-schedule, here are some additional builds, experimenting with jb_alvarado's media-autobuild_suite.

Did you know how to set it to compile for a specific march or native?
Edit: I'm trying to replace -mtune=generic with -march=native -O2 into media-autobuild_suite.bat

[RBX]

Originally Posted by LazyNcoder

I have a dual-cpu (6core/12thread each) machine and it's killing me (33% - 720p - slow preset - --aq-mode 2 --aq-strength 1.0). I'm using --pmode --pme --threads 48. it makes the final size a bit larger though(I think it lowers the quality too/not sure yet). Now I'll try it without --pmode to see what happens.

I once did tests for pmode and the size was a little bit higher than without it. I also once tried aq-mode 2, and resulting file size was larger than source file size with the settings I normally use. It might have been some minor bug, or source file problem. How well does it work for you?

[LazyNcoder]

Originally Posted by RBX

I once did tests for pmode and the size was a little bit higher than without it. I also once tried aq-mode 2, and resulting file size was larger than source file size with the settings I normally use. It might have been some minor bug, or source file problem. How well does it work for you?

With pmode, it uses more CPU than without it. But I didn't test if it really helps the speed or not. I always thought more CPU utilization = faster encode.

aq-mode 2 was default in previous versions of x265, and I did lots of encodes with it, and it's still my favorite. I like it better than aq-mode 1. maybe a little larger output sometimes(depends on the content) and the thing you said, never happened for me. (I'm using x265 since v1.2)