x265 HEVC Encoder

[uneedme]

I was wondering that there is any chance to add the opencl support?

let the idle gpu to work along......on encoding......

or it is an available function I just dont know?



some has support opencl decoding (gpu processes parts of load)

any existed opencl mod some gui has already added for encoding side?

or opened-standard commands of opencl only support decoding side?



opencl is getting more common on pc-lineup?

Will this idea be useful?

[anonymlol]

I was wondering that there is any chance to add the opencl support?

let the idle gpu to work along......on encoding......

or it is an available function I just dont know?



some has support opencl decoding (gpu processes parts of load)

any existed opencl mod some gui has already added for encoding side?

or opened-standard commands of opencl only support decoding side?



opencl is getting more common on pc-lineup?

Will this idea be useful?

This is from 3 months ago:
Nothing to announce at this time. We have been working since the start of the x265 project on a private branch that leverages GPUs, but to get true acceleration under a wide range of conditions we need advanced capabilities in the chips and drivers. On some platforms these capabilities are just starting to become available. We've made great progress, but we will publish no code before its time.

[uneedme]

This is from 3 months ago:

Quote:
Originally Posted by x265_Project View Post
Nothing to announce at this time. We have been working since the start of the x265 project on a private branch that leverages GPUs, but to get true acceleration under a wide range of conditions we need advanced capabilities in the chips and drivers. On some platforms these capabilities are just starting to become available. We've made great progress, but we will publish no code before its time.






I thought opencl is an open-public-architecture any complying hardware would support？Caring free about the actual HW......using gpu as another cpu...

Need to specify chips and drivers？


Individual gpu mod？

Should this fork（branch）version work on generic gpus would be great！It means it will support no-opencl gpus as well.

Expecting~

[LigH]

@ jlpsvk:

I was already told elsewhere (possibly in the mailing list) that x265 won't use more frame threads than it calculates to be efficient. Parallelization of algorithms has its limits. Some may depend on the frame dimensions and GOP structure.

But you limiting the frame threads explicitly by a parameter will create an additional bottleneck, I guess xooyoozoo is right here.

Affirmative answers are to be expected from a developer of x265, though, not from me...

[x265_Project]

@ jlpsvk:

I was already told elsewhere (possibly in the mailing list) that x265 won't use more frame threads than it calculates to be efficient. Parallelization of algorithms has its limits. Some may depend on the frame dimensions and GOP structure.

But you limiting the frame threads explicitly by a parameter will create an additional bottleneck, I guess xooyoozoo is right here.

Affirmative answers are to be expected from a developer of x265, though, not from me...

That's correct.

"--frame-threads (http://x265.readthedocs.org/en/default/threading.html#frame-threading) 1" will force x265 to encode only one frame at a time. This turns off frame parallelism. To take advantage of many-core machines x265 needs to encode multiple frames in parallel. You would want to turn off frame parallelism if you need extremely low latency real-time encoding (typically you would also turn off B frames in this scenario). If you are encountering a tricky rate control issue (when using one-pass ABR rate control), turning off frame parallelism can help as a brute-force diagnostic test. For an offline CRF encode, there are minimal benefits to turning off frame parallelism. The only benefit is that the motion search for inter-prediction would have unlimited motion search range available in reference frames when frame parallelism is turned off. But you can protect a wider motion search range across reference frames that are being encoded in parallel by increasing --merange (add increments of the --ctu setting), and I think you'll see that this typically has very little benefit to compression efficiency. But as always, we welcome your feedback.

[NikosD]

OpenCL HEVC decoding has been implemented quite some time now by at least two decoders - Lentoid Strongene and Cyberlink's PowerDVD.

They are working quite good on both Intel and AMD the two companies that have real OpenCL drivers - not like Nvidia's pseudo-OpenCL driver.

I think OpenCL HEVC encoding is feasible.

[jlpsvk]

I switched to 1 because it was mentioned, that value 1 is helping reduce banding and encode color gradients. :)

[Ma]

Try to encode that scene with 10-bit x265 with this command line and let me know. I'm curious. Use x265 1.5.258 or higher. :)
--crf 20 --preset slow --rdoq-level 1 --min-keyint 23 --keyint 240 --aq-mode 1 --pmode --deblock -3:-3 --psy-rd 0.5 --frame-threads 1

OK, I will test deblock option. My current encoding goes to 52%, time remaining: 2 days, 13 hrs.

So there are 2 option missing in HEVC file header: rdoq-level and deblock.

[x265_Project]

I switched to 1 because it was mentioned, that value 1 is helping reduce banding and encode color gradients. :)

I would welcome examples of this.

[jlpsvk]

Originally Posted by RBX View Post
10 bit encoding is great. Although slow, the reduction in banding, even in real life videos is very good. I can still see some vertical slices where light starts dimming. What change can work positively to reduce this?

Originally Posted by benwagoner
--frame-threads 1 will generally fix this. Depending on frame size, cores, and preset, you'll likely need to turn on --pmode to make up for the loss of parallelism.

[uneedme]

I think OpenCL HEVC encoding is feasible.


Good!

[NikosD]

Feasible doesn't necessarily mean that it's going to happen.

Real hardware HEVC encoding like some of QuickSync's next version which has a tradition of fast and qualitative AVC transcodings is a more possible and interesting road to follow.

[uneedme]

Feasible doesn't necessarily mean that it's going to happen.

Real hardware HEVC encoding like some of QuickSync's next version which has a tradition of fast and qualitative AVC transcodings is a more possible and interesting road to follow.

The hardware encoding strictly comply to the embedded Instruction set, which means fixed output and not optimized result.

Through opencl is acquiring the gpu, the hardware, as an auxiliary, the program is still the main body...

It is totally different...

[NikosD]

QuickSync is using ASIC + GPU too for flexibility and it's not using ASIC only approach (fixed - function HW) like Nvidia.

[sborho]

Yes, numbers:

x265 --preset slow --crf 18 --no-rdoq-level 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 126.42s (3.99 fps), 21445.36 kb/s

x265 --preset slow --crf 18 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 148.96s (3.38 fps), 24243.95 kb/s

x265 --preset slow --crf 18 --rdoq-level 1 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 143.56s (3.51 fps), 25158.41 kb/s

This stumped me for a while until I thought it all through. CRF works by estimating the complexity of each picture (measuring average variance of each block) and setting a single slice level QP for the picture, so there is no bitrate consideration.

Within mode decision, it is making coding decisions based on the least rate-distortion cost (distortion + lambda * bits). What RDOQ is doing is making residual coded blocks have much fewer bits but slightly higher distortion, and this is making residual coded blocks much more competitive to "skip" blocks in RD cost and so the encoder is picking more residual coded blocks. This increases bitrate (and quality) substantially.

The short summary is that you cannot really compare bitrates in CRF encodes if you start messing with the functions that evaluate RD cost (the same is true of CQP).

[sborho]

I switched to 1 because it was mentioned, that value 1 is helping reduce banding and encode color gradients. :)

There are three features which are affected by frame parallelism.

1 - ABR and VBV rate control (less accuracy with higher -FN)
2 - motion search search area limited with -FN>1
3 - noise reduction (less accuracy with higher -FN)

If you add --pmode to overcome the loss of parallelism with -F1, you get improved compression because pmode disables some analysis early outs (you get exhaustive analysis for each CU). You would get this improvement even with frame parallelism enabled, but pmode might make the encode slower depending on how many cores you have

[LigH]

Next: x265 1.5+370-cc496665280f (https://www.mediafire.com/download/nbi4xnd9fj98a5n/x265_1.5+370-cc496665280f.7z)

[MeteorRain]

And my personal modification 1.5+370+8-1c84fa233a5d (https://down.7086.in/x264_Yuuki/x265-Yuuki-1.5%2B370%2B8-1c84fa233a5d.7z) compiled by mingw-w64.

[LigH]

And my personal modification

Did you document anywhere what you modified?

Ah, it seems to include the L-SMASH multiplexer to support MP4 output.

[MeteorRain]

Did you document anywhere what you modified?

Ah, it seems to include the L-SMASH multiplexer to support MP4 output.

https://bitbucket.org/msg7086/x265-yuuki

Just some cosmetic mod, and (buggy?) l-smash / haali mkv muxer patch after heavy hacking on the core.

[Vulpix]

I am also having a bit of trouble getting into the x265 / h265 thing. I use staxrip and found out that the "medium" preset of x265 is +- encoding speed-wise equal to the "slow/slower" preset of x264. The size is about 2x smaller but there is a distinct loss of visual quality (like the user "me" stated - a lot of things are blurred out so fine detail is lost). Is "rdoq=1" and psy-rd 0.5 the answer? Or will I have to go to "slower" preset for x265 no matter what? The speed becomes a lot slower at that point, which is a bit of a downer.

Thanks!

[LigH]

You said that the resulting bitrate of the x265 default (CRF 28) is a lot lower than the bitrate of the x264 default (CRF 23). So don't be surprised that the quality is also a bit lower. Even though HEVC/H.265 may be a bit more efficient than AVC/H.264 doesn't mean that half the bitrate can look just as good, especially not in every case.

Except for some issues still being developed, in general, at the same bitrate, x265 should be able to preserve more quality than x264. But to find settings where the quality is about equal, and then comparing the bitrates, is not a serious approach to compare them. Furthermore, the defaults are not tuned to be as equal as possible between x265 and x264, regarding quality. CRF 28 for x265 will probably be worse than CRF 23 for x264 in many cases, and both are far away from "visually transparent quality preservation".

[Boulder]

According to my tests, x265 still doesn't retain details like x264 does but smoothes the image quite heavily even with CRF values around 20 or less. I-frames looked quite the same but other ones were different. If I've understood correctly, this is just the way it is unless x265 adopts the same psy algorithms that x264 uses? I have not tested any recent build but one some two-three weeks ago.

[Ma]

I've made speed test of 10-bit x265 1.5+365 builds.

Contenders:
x265-MSVC.exe - Daemon404 build form http://chromashift.org/x265_builds/x265-1.5.365-highbitdepth-msvc2012-64.7z
x265-492-O2.exe - my normal build, GCC 4.9.2, -O2 optimize option, -march=corei7-avx
x265-485-O2.exe - GCC 4.8.5 dongsheng-daily build 20150323 from MinGW-w64, -O2 optimize option, -march=corei7-avx
x265-485-O3.exe - GCC 4.8.5 dongsheng-daily build 20150323 from MinGW-w64, -O3 optimize option, -march=corei7-avx
x265-493-O2.exe - GCC 4.9.3 dongsheng-daily build 20150323 from MinGW-w64, -O2 optimize option, -march=corei7-avx
...

I've executed first two contenders twice to calibrate results and to estimate the measurement error. My platform: Win 7 64-bit, i5 3450S.

Results:
i:\m\v1>x265-MSVC.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 278.16s (1.81 fps), 3473.84 kb/s
encoded 504 frames in 277.52s (1.82 fps), 3473.84 kb/s

i:\m\v1>x265-492-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 268.74s (1.88 fps), 3473.84 kb/s
encoded 504 frames in 268.47s (1.88 fps), 3473.84 kb/s

i:\m\v1>x265-485-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 273.19s (1.84 fps), 3473.84 kb/s

i:\m\v1>x265-485-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 275.76s (1.83 fps), 3473.84 kb/s

i:\m\v1>x265-493-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 266.67s (1.89 fps), 3473.84 kb/s

i:\m\v1>x265-493-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 270.63s (1.86 fps), 3473.84 kb/s

i:\m\v1>x265-500-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 325.87s (1.55 fps), 3473.84 kb/s

i:\m\v1>x265-500-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 314.20s (1.60 fps), 3473.84 kb/s

So GCC 4.9.3 rules, GCC 4.8.5 weak, GCC 5.0.0 crap, crap and ones more crap.

If someone wants to repeat this test:
contenders - http://www.msystem.waw.pl/x265/test.7z
video - http://media.xiph.org/video/derf/y4m/720p50_parkrun_ter.y4m

[MeteorRain]

For now 5.0.0 isn't aiming at speed, is it? GCC 4.9 should be the fastest among its family.
However very interesting to see GCC beating MSVC. How about ICL?

[anonymlol]

edit: Nevermind, I compared them myself.


CPU: i7-2700k (4.8 GHz)
settings: --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

x265-MSVC.exe 2.30 fps
x265-MSVC.exe 2.30 fps
x265-492-O2.exe 2.37 fps
x265-492-O2.exe 2.40 fps

x265-485-O2.exe 2.36 fps
x265-485-O3.exe 2.30 fps
x265-493-O2.exe 2.41 fps
x265-493-O3.exe 2.36 fps
x265-500-O2.exe 2.01 fps
x265-500-O3.exe 2.09 fps

My own build (492 O3 fprofiled, 1.5+370)
x265.exe 2.41 fps
x265.exe 2.41 fps

[Vulpix]

I tested this on my i7-4765T (bit of a crazy cpu -> http://ark.intel.com/products/75121/Intel-Core-i7-4765T-Processor-8M-Cache-up-to-3_00-GHz ). Also Win7 x64.

I cannot really see much difference between the versions. The 4.9.3 O2 is the fastest... but by very little (3.6% in comparison with the slowest, MSVC compilation)

d:\Transcode\TEST>x265-MSVC.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 308.40s (1.63 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-MSVC.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 308.52s (1.63 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-492-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 298.35s (1.69 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-492-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 299.62s (1.68 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-485-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 304.52s (1.66 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-485-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 306.14s (1.65 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-493-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 297.95s (1.69 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-493-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 299.59s (1.68 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-500-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 305.28s (1.65 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-500-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc

encoded 504 frames in 305.28s (1.65 fps), 3473.84 kb/s

[RBX]

For now 5.0.0 isn't aiming at speed, is it? GCC 4.9 should be the fastest among its family.
However very interesting to see GCC beating MSVC. How about ICL?
I'd like to know this as well. I use the ones compiled by Intel compiler hoping that Intel might have enabled some exclusive optimizations for intel processors.

[Vulpix]

Hmm.

Would the general consensus then be that instead of trying to get the same quality and then compare the bitrates, I should rather get the same bitrates?

I.e. using h265 not to improve my encoded filesize but to improve the amount of retained detail / overall quality (as from what I'm gathering, the x265 encode should yield better results than x264 one at the same bitrate) ?

I agree I was maybe asking a bit much from the encodes when I ended up with a file that was 2x smaller using the same "quality" preset from staxrip ...

[MoSal]

According to my tests, x265 still doesn't retain details like x264 does but smoothes the image quite heavily even with CRF values around 20 or less. I-frames looked quite the same but other ones were different. If I've understood correctly, this is just the way it is unless x265 adopts the same psy algorithms that x264 uses? I have not tested any recent build but one some two-three weeks ago.

I came to the same conclusion.
x265 (and libvpx/vp9 btw) are no match to x264 when it comes to detail preservation.

Optimizing (and micro-optimizing) for the human eye is not expected to become a top priority for sponsors. So, we might never have an HEVC encoder that is better than x264 at preserving details.

---

Although they are not even close to a finalized spec. It seems the Daala team is the only one primarily optimizing for the human eye. So, let's wish them success.

[LigH]

Would the general consensus then be that instead of trying to get the same quality and then compare the bitrates, I should rather get the same bitrates?

Well, somehow ... yes, and on top, let's have thousands of probands participate in the comparison in "ABX tests". This way we can statistically measure how good it works subjectively, means, if x265 will be able to actually "look better" for the average audience than other encoders, at the same bitrates.

That will hopefully show if detail retention is for nitpickers only, or indeed a crucial attribute. :rolleyes: :devil:

[benwaggoner]

I came to the same conclusion.
x265 (and libvpx/vp9 btw) are no match to x264 when it comes to detail preservation.
I think the new --rdoq-level setting may be helpful in this regard. There's an innate tension between accuracy and verisimilitude in encoding; making something with the same feel as the original takes a lot fewer bits than encoding every little detail exactly as it was before.

Optimizing (and micro-optimizing) for the human eye is not expected to become a top priority for sponsors. So, we might never have an HEVC encoder that is better than x264 at preserving details.
Why would you think that wouldn't be important to sponsors?

There is also work going on to use HEVC for mezzanine files, which today are normally MPEG-2 (quality issues, 8-bit only or ProRes (huge, not great interoperability). Excellent detail preservation is critical for that use case. HEVC offers way better compression than MPEG-2 and with range extensions all the color space modes of ProRes.

Go down to --crf 10 and you'll get a perfect reproduction at very competitive bitrates.

Although they are not even close to a finalized spec. It seems the Daala team is the only one primarily optimizing for the human eye. So, let's wish them success.
HEVC architecturally has tons of optimizations for human vision. Of course, pretty much everything in codecs are psychovisual optimizations, except for entropy encoding. Even fundamental stuff like gamma and frequency-based transforms are psychovisual optimizations.

[Boulder]

Well, I'm going to give x265 another go as soon as I get the spare CPU time. I do enjoy trying it out and who knows, some day I might be very pleasantly surprised :)

[x265_Project]

I came to the same conclusion.
x265 (and libvpx/vp9 btw) are no match to x264 when it comes to detail preservation.

Optimizing (and micro-optimizing) for the human eye is not expected to become a top priority for sponsors. So, we might never have an HEVC encoder that is better than x264 at preserving details.

Nonsense. Optimizing visual quality (including spatial detail) is our top priority. If you have an example where x264 has higher spatial detail than x265, please share. But spatial detail isn't the only thing that video encoders need to preserve. You can crank up psy-rd in x264 or x265 and get higher spatial detail at the expense of motion accuracy. In other words, if you don't mind lots of motion artifacts, you can get more spatial detail. But motion artifacts can be just as disturbing as a lack of spatial detail. HEVC generally has much better motion accuracy, and since we're encoding video and not just still images, we don't want to compromise this unnecessarily.

You also need to be careful when it comes to looking for spatial detail not to confuse noise with picture detail. H.264 tends to have "macroblocking" noise, where H.265 doesn't. This noise adds energy and texture to decoded frames. Looking at individual decoded frames, you might think that this texture was part of the original picture, and conclude that the H.264 encoder did a better job. But if you overlay the source frame with your decoded H.264 and H.265 frame, and wipe back and forth, it's easier to see what is picture and what is noise. We have a special player that we've built to do this. It's hard to do accurate video analysis without such a tool.

It's been a long time since I've seen an x264 encode that looked better at identical bit rate to the x265 encode. If you have publicly available source content and your x264 and x265 settings to share, we would be happy to look at your results.

[Boulder]

I just did a test and here are my results.

Video:
x264 @ CRF 18.5 : https://drive.google.com/file/d/0BzeF_1syecQwYzB0aFYtVFI5V2s/view?usp=sharing
x265 @ CRF 20.3 : https://drive.google.com/file/d/0BzeF_1syecQwM2RUcWptdU1hZXM/view?usp=sharing

Screenshots to show the difference:
x264 : https://drive.google.com/file/d/0BzeF_1syecQwTXRDVXpkQ2lkUms/view?usp=sharing
x265 : https://drive.google.com/file/d/0BzeF_1syecQwQS10RUtLclZHTzA/view?usp=sharing

Settings:

c:\x264\x264.exe --stdin y4m - --sar 1:1 --level 4.1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709" --tune film
--preset veryslow --crf 18.5 --output c:\x265\x264_crf18.5.h264
c:\x265\x265.exe --y4m --input - --sar 1:1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709"
--preset slow --tune grain --crf 20.3 --output c:\x265\x265_crf20.3.h265

I have cropped and resized the image and used a custom denoiser to press down the noise slightly. The reason for this is that I like to test real-life situations to see if I should use x265 or not.

The filesizes of the screenshots already reveal that x265 has smoothed the image quite a lot as it's also smaller as a png file. It's not just noise that the encoder has removed, it's actual detail from the field. If I remember correctly, Hot Fuzz is considered a very good quality source so I've been using the scene in my tests.

If you need me to test anything, just let me know.

[Tommy Carrot]

Boulder's screenshots demonstrate quite well what i was saying about x265. X265 smoothes the fine details out in places where the luma or chroma deviation between the neightboring pixels is fairly small. X264 retains these details considerably better at similar bitrates. Psy-rd helps a bit, but even at very high settings it still blurs significantly more than x264.

[x265_Project]

I just did a test and here are my results.

Video:
x264 @ CRF 18.5 : https://drive.google.com/file/d/0BzeF_1syecQwYzB0aFYtVFI5V2s/view?usp=sharing
x265 @ CRF 20.3 : https://drive.google.com/file/d/0BzeF_1syecQwM2RUcWptdU1hZXM/view?usp=sharing

Boulder - I would need a link to your source file, in order to see what is going on here, but I don't think you should be using --tune grain. Can you repeat the test without --tune grain?

[Boulder]

Yes, I'll test it tomorrow but you can get the original sample clip here : https://drive.google.com/file/d/0BzeF_1syecQwakhsX3RuZGhWcjA/view?usp=sharing . I'm assuming this is fair use even though the clip is over a thousand frames long.

[Ajvar]

@Boulder, what's the point of using x265 at bigher CRF like 20 and compare it to x264 at CRF18 if it should be opposite because x265 can give higher quality at the same bitrate?

The best would be 2pass encode at high bitrate like 10000 kbit/s for x265 and x264. Although I still believe that x265 blurrs picture more or x264's macroblock noise gives more details, whatever it is called.

[sneaker_ger]

He chose the CRF values to make both encodes identical bitrate so the quality can be compared.

[Ajvar]

He chose the CRF values to make both encodes identical bitrate so the quality can be compared.

That wouldn't be true because of nonlinear bitrate/crf curve even if increasing CRF for x265 would anyhow give closer bitrate to lower CRF of 264 which is OPPOSITE.
I just did a test and here are my results.
Video:
x264 @ CRF 18.5 :
x265 @ CRF 20.3 :

At equal CRFX x265's file will have lower bitrate than x264's so to make it equal you need to lower CRF value (to CRFX-1 or CRFX-2) of x265, not x264.

[sneaker_ger]

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

[Ma]

I tested this on my i7-4765T (bit of a crazy cpu -> http://ark.intel.com/products/75121/Intel-Core-i7-4765T-Processor-8M-Cache-up-to-3_00-GHz ). Also Win7 x64.

d:\Transcode\TEST>x265-493-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 297.95s (1.69 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-500-O2.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 305.28s (1.65 fps), 3473.84 kb/s

d:\Transcode\TEST>x265-500-O3.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 305.28s (1.65 fps), 3473.84 kb/s

Quite interesting result. On 4-cores/8-threads CPU the difference between GCC 5.0.0-O2/O3 and GCC 4.9.3-O2 is 2.46%. On my 4-cores/4-threads CPU GCC 5.0.0-O2 time is 22.2% longer than GCC 4.9.3-O2 and GCC 5.0.0-O3 -- 17.8%. Maybe GCC 5.0.0 on 8-cores/16-threads CPU will be faster than GCC 4.9.3.

[Ma]

New speed test of 10-bit x265 1.5+370 builds. Now with ICL, LigH and anonymlol builds. I also included my generic build (without "-march=corei7-avx" option). Calibration on MSVC and my AVX builds.

Win 7 64-bit, i5 3450S (4-cores/4-threads @ 3.5GHz):
i:\m\v1>x265-MSVC.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 277.29s (1.82 fps), 3473.84 kb/s
encoded 504 frames in 277.68s (1.82 fps), 3473.84 kb/s

i:\m\v1>x265-AVX.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 267.28s (1.89 fps), 3473.84 kb/s
encoded 504 frames in 267.91s (1.88 fps), 3473.84 kb/s

i:\m\v1>x265-anonymlol.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 267.78s (1.88 fps), 3473.84 kb/s

i:\m\v1>x265-GEN.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 271.49s (1.86 fps), 3473.84 kb/s

i:\m\v1>x265-ICL.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 283.50s (1.78 fps), 3473.42 kb/s

i:\m\v1>x265-LigH.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 278.50s (1.81 fps), 3473.84 kb/s

ICL build produces significant different output (with different bitrate). It is slow (on my 4-cores/4-threads CPU).

Anonymlol build is very impressive -- generic profiled build is equal fast as my AVX build. It will be clear winner with additional "-march=corei7-avx" option.

Contenders -- http://www.msystem.waw.pl/x265/test2.7z

[Boulder]

He chose the CRF values to make both encodes identical bitrate so the quality can be compared.Exactly, as that was requested. The x264 CRF value was chosen to represent my real-life situations, otherwise it wouldn't make sense to compare.

Here's the x265 file without --tune grain:

https://drive.google.com/file/d/0BzeF_1syecQwSmlDRlFnS2FiZVE/view?usp=sharing

This probably isn't the exact same frame as the previous x265 screenshot, but smoothing is clearly visible:
https://drive.google.com/file/d/0BzeF_1syecQwTkpNWFR4Qk84cUE/view?usp=sharing

c:\x265\x265.exe --y4m --input - --sar 1:1 --colormatrix "bt709" --colorprim "bt709" --transfer "bt709"
--preset slow --rdoq-level 1 --crf 17.25 --output c:\x265\x265_crf17.25.h265

[MeteorRain]

i:\m\v1>x265-ICL.exe --preset slower 720p50_parkrun_ter.y4m 720p50_parkrun_ter.hevc
encoded 504 frames in 283.50s (1.78 fps), 3473.42 kb/s

ICL build produces significant different output (with different bitrate). It is slow (on my 4-cores/4-threads CPU).


Just want to confirm with you that I also observed non binary identical on ICL build from chromashift's build.

[MeteorRain]

And 1.5+380 (https://down.7086.in/x264_Yuuki/x265-Yuuki-1.5%2B380-7b66c36ed9ef%2B10%402d6d5c99324f.7z) 1.5+395 (https://down.7086.in/x264_Yuuki/x265-Yuuki-1.5%2B395-e637273e2ae6%2B10%402d6d5c99324f.7z)

[Vulpix]

Quite interesting result. On 4-cores/8-threads CPU the difference between GCC 5.0.0-O2/O3 and GCC 4.9.3-O2 is 2.46%. On my 4-cores/4-threads CPU GCC 5.0.0-O2 time is 22.2% longer than GCC 4.9.3-O2 and GCC 5.0.0-O3 -- 17.8%. Maybe GCC 5.0.0 on 8-cores/16-threads CPU will be faster than GCC 4.9.3.

I noticed that during the tests, the CPU utilization never reached 100%. It was hovering around 60-80%, so I think seeing as your "threads" are real, physical cores (whereas half of mine are the HTs), the difference is more palpable.

[JohnLai]

Seems to me, most people prefer to use CRF.
On the other hand, I prefer to use CQP.

I would like to know what is the recommended value for x265 CQP?

[YamashitaRen]

Well, somehow ... yes, and on top, let's have thousands of probands participate in the comparison in "ABX tests". This way we can statistically measure how good it works subjectively, means, if x265 will be able to actually "look better" for the average audience than other encoders, at the same bitrates.

That will hopefully show if detail retention is for nitpickers only, or indeed a crucial attribute. :rolleyes: :devil:

I would gladly take part in such a test :)