x265 HEVC Encoder

[benwaggoner]

Same feeling. TV series, dark scenes and fast motion.
Noticeable improvements generally speaking but there seems to be more noise, especially in dark scenes.

Are you using --aq-mode 3? I recommend that for SDR content, as it reduces QP in dark areas.

I wonder if aq-mode also needs to be retuned for the new lambda table.

[benwaggoner]

did you ever made tests how high the 10->8bit conversion overhead is for an almost perceptual banding free result, especially on high f-stop captured skyboxes internally and where the point of f-stop slope is it makes virtually no difference anymore in overall perception
I think all you're going to get from x265 for this scenario is the --dither option for better quality dithering when x265 is doing the color space conversion.

Can you share a sample of this content? I'm having a hard time visualizing.

It's possible that you could adapt your own lambda table if it has very different psychovisual properties.

[need4speed]

Are you using --aq-mode 3? I recommend that for SDR content, as it reduces QP in dark areas.

I wonder if aq-mode also needs to be retuned for the new lambda table.

AQ3? Not really, it's 1080p to 1080p, avc to x265 to decrease size.
Tried aq3 in the past, somehow wasn't good as expected. Some improvement in dark areas, but the impression was more blurring.
The aq-motion currently in use is giving good results, besides it seems to disable standard aq modes (correct me if Im'm wrong).

[CruNcher]

I think all you're going to get from x265 for this scenario is the --dither option for better quality dithering when x265 is doing the color space conversion.

Can you share a sample of this content? I'm having a hard time visualizing.

It's possible that you could adapt your own lambda table if it has very different psychovisual properties.

you practically see that in every 10 bit UHD Demo today especially Natural light HDR Demos all are focusing on it and it's the part where especially no studio natural lighting film content benefits the most perceptually (overall stability) and all agree upon if they don't fight on the contrast side with each other ;).

It's crazy how even LG and Samsung buildup a whole Broadcasting Network and experimenting their.

[Andrew Placid]

Hi.
Is any tool for cutting/combining x265 raw stream?

[sneaker_ger]

mkvmerge followed by mkvextract. (If you need something graphical try SolveigMM Video Splitter or AviDemux)

[Barough]

x265 v2.3+23-97435a0870be (http://www73.zippyshare.com/v/9rWBxuWB/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+23-97435a0870be
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

Are there any "sensible low anchor" GCC optimizations you would suggest for x265?

I just compared build scripts on two different PCs, because I noticed a size difference, and found that I used
export CXXFLAGS="-march=pentium4 -mtune=generic"
for Win32 target only in one of my build environments (not for Win64 because I guess there is already an assumed similar minimum for the x86-64 platform as such). Any suggestions regarding this choice? My goal is not maximum speed for top CPU generations, rather a good compromise with high compatibility for all the hardware expected as minimum recommendable to run x265 on.

[Andrew Placid]

mkvmerge followed by mkvextract. (If you need something graphical try SolveigMM Video Splitter or AviDemux)
I need clean raw on export. I'm not sure that extracted raw stream from mkv after cutting will 100% correct.

[adsun701]

Hi there. For Video Usability Information, is it possible to add support for the new color primaries in the latest (4th) version of the HEVC standard on the ITU website, such as DCI P3? Also, can the new SMPTE ST 2085 color matrix and the ICtCp color matrix be supported?

Thanks!

[x265_Project]

Hi there. For Video Usability Information, is it possible to add support for the new color primaries in the latest (4th) version of the HEVC standard on the ITU website, such as DCI P3? Also, can the new SMPTE ST 2085 color matrix and the ICtCp color matrix be supported?

Thanks!
I'll ask our development team to look at this.

Tom Vaughan
VP and GM, Video

By the way, I'm the only person who logs into Doom9 as x265_Project

[Ma]

Are there any "sensible low anchor" GCC optimizations you would suggest for x265?

I just compared build scripts on two different PCs, because I noticed a size difference, and found that I used
export CXXFLAGS="-march=pentium4 -mtune=generic"
for Win32 target only in one of my build environments (not for Win64 because I guess there is already an assumed similar minimum for the x86-64 platform as such). Any suggestions regarding this choice? My goal is not maximum speed for top CPU generations, rather a good compromise with high compatibility for all the hardware expected as minimum recommendable to run x265 on.

At the beginning of GCC 6 release if you compile x265 without -march=pentium4 the resulting exe was not working. Now it is special workaround in cmake that adds -mpreferred-stack-boundary=2 if it detect GCC 6 and 32-bit mode. Now it is not necessary to specify -march=pentium4.

You can consider difference in speed. I've made test of encoding with command line:
x265_32 -D10 -f130 ../ducks_take_off_1080p50.y4m w.hevc

The result was:

LigH 2.3+17 version with -march=pentium4 -mtune generic
encoded 130 frames in 100.31s (1.30 fps), 8566.20 kb/s, Avg QP:38.35

Barough 2.3+23 version
encoded 130 frames in 133.73s (0.97 fps), 8562.60 kb/s, Avg QP:38.35

2.3+23 version GCC 7.0 SSE4.1
encoded 130 frames in 84.20s (1.54 fps), 8566.20 kb/s, Avg QP:38.35

2.3+23 version GCC 7.0 SSSE3
encoded 130 frames in 92.38s (1.41 fps), 8566.20 kb/s, Avg QP:38.35

If you do not specify -march=pentium4 -mtune=generic for 32-bit x265, the encoding time in 10-bit mode will be longer about 33%. Computers with Pentium 3 are very slow and with tiny memory so anyway there are not for x265 encoding.

[benwaggoner]

Hi there. For Video Usability Information, is it possible to add support for the new color primaries in the latest (4th) version of the HEVC standard on the ITU website, such as DCI P3? Also, can the new SMPTE ST 2085 color matrix and the ICtCp color matrix be supported?

Thanks!
I'm not seeing a lot of interest in DCI P3 as a native color space for HEVC delivery at least, but it could be useful for mezzanines.

ICtCp is used for Dolby Vision encoding, and so definitely has a significant current use case. It seems likely that the lambda table will need to be retuned for it (and probably for HDR PQ in general), and that --hdr-opt may need to be refactored for ICtCp.

I imagine Dolby would be motivated to help get MCW the necessary details.

What is SMPTE 2085 for? I see it's YDzDx Color-Difference Encoding for XYZ signals. Some sort of more efficient digital cinema color space or something?

[pingfr]

At the beginning of GCC 6 release if you compile x265 without -march=pentium4 the resulting exe was not working. Now it is special workaround in cmake that adds -mpreferred-stack-boundary=2 if it detect GCC 6 and 32-bit mode. Now it is not necessary to specify -march=pentium4.

You can consider difference in speed. I've made test of encoding with command line:
x265_32 -D10 -f130 ../ducks_take_off_1080p50.y4m w.hevc

The result was:

LigH 2.3+17 version with -march=pentium4 -mtune generic
encoded 130 frames in 100.31s (1.30 fps), 8566.20 kb/s, Avg QP:38.35

Barough 2.3+23 version
encoded 130 frames in 133.73s (0.97 fps), 8562.60 kb/s, Avg QP:38.35

2.3+23 version GCC 7.0 SSE4.1
encoded 130 frames in 84.20s (1.54 fps), 8566.20 kb/s, Avg QP:38.35

2.3+23 version GCC 7.0 SSSE3
encoded 130 frames in 92.38s (1.41 fps), 8566.20 kb/s, Avg QP:38.35

If you do not specify -march=pentium4 -mtune=generic for 32-bit x265, the encoding time in 10-bit mode will be longer about 33%. Computers with Pentium 3 are very slow and with tiny memory so anyway there are not for x265 encoding.

So which build toolchain would you recommend to use on modern architectures? (and by modern I mean anything newer than Ivy Bridge, Sandy Bridge, Haswell, Skylake, Kaby Lake even) running a modern OS consumer oriented such as Windows 7, 8 or Windows 10.

[adsun701]

I'm not seeing a lot of interest in DCI P3 as a native color space for HEVC delivery at least, but it could be useful for mezzanines.

ICtCp is used for Dolby Vision encoding, and so definitely has a significant current use case. It seems likely that the lambda table will need to be retuned for it (and probably for HDR PQ in general), and that --hdr-opt may need to be refactored for ICtCp.

I imagine Dolby would be motivated to help get MCW the necessary details.

What is SMPTE 2085 for? I see it's YDzDx Color-Difference Encoding for XYZ signals. Some sort of more efficient digital cinema color space or something?

Yes. SMPTE ST 2085 is used for efficient processing of high dynamic range content using CIE XYZ primaries.

That also means CIE XYZ (SMPTE ST 428-1) primaries would have to be supported in Video Usability Information. :)

[Ma]

So which build toolchain would you recommend to use on modern architectures? (and by modern I mean anything newer than Ivy Bridge, Sandy Bridge, Haswell, Skylake, Kaby Lake even) running a modern OS consumer oriented such as Windows 7, 8 or Windows 10.

VS 2017 with options /GS- /GL (at least). I assume that you write about 64-bit version of x265.

My speed test was for 32-bit version of x265 and 10-bit mode. It is similar to 64-bit x265 with option --no-asm.

[pingfr]

VS 2017 with options /GS- /GL (at least). I assume that you write about 64-bit version of x265.

My speed test was for 32-bit version of x265 and 10-bit mode. It is similar to 64-bit x265 with option --no-asm.

x64 yes indeed.

[Sagittaire]

VS 2017 with options /GS- /GL (at least). I assume that you write about 64-bit version of x265.

My speed test was for 32-bit version of x265 and 10-bit mode. It is similar to 64-bit x265 with option --no-asm.

I make little comparison with ICC, GCC 7.0 and VS 2017: VS 2017 seem produce better speed for x265.

[LigH]

I still wonder if there is a recommendation whether I should use no additional compiler flags (because CMake scripts already take enough care of that?), or may enable some basic optimizations just based on a minimum architecture suitable for x265 due to architecture details (e.g. cache dimensions). Ma's remark about P3 vs. P4 class sounds worth a thought. Regarding AMD, I would assume Athlon 64 X2 (K9 core) as low anchor. In general, I'm looking at architectures implementing at least SSE2, because I see the Phenom-II CPUs I can use as a minimum I need to support with my own builds (still trying to get rich...).

[pingfr]

VS 2017 with options /GS- /GL (at least).

I make little comparison with ICC, GCC 7.0 and VS 2017: VS 2017 seem produce better speed for x265.

So far that's at least two different doom9'ers who have confirmed Visual Studio 2017 is the way to go.

Need a third one to confirm the trend. ;)

Anyone else? :D

[NikosD]

Need a third one to confirm the trend. ;)

Anyone else? :D

There is a third one here:
http://forum.doom9.org/showthread.php?p=1800781

[CruNcher]

It might be true indeed for Windows not for anything else and also only if those test have been done properly.

Though it might be even only true for a specific ntoskrnl and scheduling also when we talk about milliseconds so their could be even a difference between Windows Vista/7/8 to 10.

But it is even with the Posix Layer pretty normal that Microsoft optimizes for Windows entirely and doesn't fight so much as GCC devs have to fight finding the right balance ;)

[pingfr]

There is a third one here:
http://forum.doom9.org/showthread.php?p=1800781

Thanks for pointing that out.

However:

Minimum CPU arch: none, SSSE3, AVX and AVX2 is for C++ compile option – x265 source code is divided into C++ and asm parts. Asm code determine CPU type at runtime, C++ code needs information about CPU type at compile time. It means that if you have CPU with AVX extension, you can use all binaries except AVX2 (which hangs at encoding on AVX-CPU). You can determine your CPU arch by executing x265 with option -V, for example:

So a Sandy Bridge or Ivy Bridge user cannot or rather should not use AVX2 built binaries? Is that correct?

[LigH]

Correct: If your CPU does not support AVX2, you should not use a build compiled with options where AVX2 support is already assumed for the C++ parts of the code. It may crash somewhere due to unsupported opcodes or wrong assumptions about register widths.

[CruNcher]

PS: Im really heavily interested to see a compare of x265 on Nano Server vs Server Core and Full Core :)

so fully headless without all the different reviewers overhead in place, those results can only be trusted very partially that we see here now being talked about especially on Windows Consumer OS.

[pingfr]

x265vs.exe --preset ultrafast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit
encoded 600 frames in 6.06s (98.96 fps), 777.30 kb/s, Avg QP:35.01

x265gcc.exe --preset ultrafast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
encoded 600 frames in 6.11s (98.15 fps), 777.30 kb/s, Avg QP:35.01

0.81 fps delta.

x265vs.exe --preset veryfast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit
encoded 600 frames in 10.56s (56.81 fps), 892.48 kb/s, Avg QP:34.54

x265gcc.exe --preset veryfast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
encoded 600 frames in 10.71s (56.04 fps), 892.48 kb/s, Avg QP:34.54

0.77 fps delta.

x265vs.exe --preset fast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit
encoded 600 frames in 15.90s (37.74 fps), 933.94 kb/s, Avg QP:34.47

x265gcc.exe --preset fast Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
encoded 600 frames in 16.16s (37.13 fps), 933.94 kb/s, Avg QP:34.47

0.61 fps delta.

x265vs.exe --preset medium Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit
encoded 600 frames in 25.89s (23.17 fps), 1098.05 kb/s, Avg QP:34.03

x265gcc.exe --preset medium Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
encoded 600 frames in 26.29s (22.82 fps), 1098.05 kb/s, Avg QP:34.03

0.35 fps delta.

x265vs.exe --preset slow Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit
encoded 600 frames in 47.79s (12.55 fps), 1101.31 kb/s, Avg QP:34.17

x265gcc.exe --preset slow Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
encoded 600 frames in 48.57s (12.35 fps), 1101.31 kb/s, Avg QP:34.17

0.20 fps delta.

x265vs.exe --preset slower Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit
encoded 600 frames in 134.03s (4.48 fps), 1175.77 kb/s, Avg QP:34.14

x265gcc.exe --preset slower Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
encoded 600 frames in 135.53s (4.43 fps), 1175.77 kb/s, Avg QP:34.14

0.05 fps delta.

x265vs.exe --preset veryslow Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit+10bit+12bit
encoded 600 frames in 222.69s (2.69 fps), 1183.63 kb/s, Avg QP:34.11

x265gcc.exe --preset veryslow Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m -o Bosphorus_1920x1080_120fps_420_8bit_YUV.hevc
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit+10bit+12bit
encoded 600 frames in 235.91s (2.54 fps), 1183.63 kb/s, Avg QP:34.11

0.15 fps delta.

The differences are subtle as the preset "increases" but yes, it's there. I guess at this point, everything "counts". :D

Maybe it was a one-time occurence but it appears --preset veryslow benefits the most from the improvements. Will require extended tests.

PS: Tests were done on an i7-6700 (non K/non overclocked) 4c/8t@3.7GHz running Windows 10.

[pingfr]

This is a weird experiment but getting the same results again:

When using a VS compiled x265 against a GCC compiled x265, if running --preset veryslow, I'm getting a 0.14 fps to 0.15 fps speed delta compared to using a "lesser aggressive" preset such as --preset slower and an almost equal delta while using preset --slow.

If this is confirmed using other source materials, it implies --preset veryslow has similar benefits to using --preset slow but an increased yield quality.

That is, if you can stand and cope with the slow fps crunching overall.

Would be good if anyone can run the same tests.

[benwaggoner]

This is a weird experiment but getting the same results again:

When using a VS compiled x265 against a GCC compiled x265, if running --preset veryslow, I'm getting a 0.14 fps to 0.15 fps speed delta compared to using a "lesser aggressive" preset such as --preset slower and an almost equal delta while using preset --slow.



I think it is better to cite percentage improvements rather than raw fps deltas, since the base fps can vary so widely.

[pingfr]

I think it is better to cite percentage improvements rather than raw fps deltas, since the base fps can vary so widely.

Yes but still can anyone run the tests and run them with --preset placebo as well?

[burfadel]

Jusr curious, is SAO improvements being looked in to? It's something which usually subjectively seems better turned off, which I realise shouldn't be the case. I have suspected in the past it may be because it is too strong?

[Shevach]

Question on mastering_display_colour_volume SEI.

From several posts where mastering_display_colour_volume SEI explained (e.g https://www.linkedin.com/pulse/hdr-10-metadata-smpte-st2086-maxfall-maxcll-carlos-carmona ) i can infer that the parameters max_display_mastering_luminance and min_display_mastering_luminance have to be calculated from input yuv-file or from 16/12 bit RGB TIFF. The algorithm is specified in a SMPTE document.
Here is my question. x265 encoding (unless it is lossless) makes original frames and reconstructed ones to different. Hence, max_display_mastering_luminance and min_display_mastering_luminance may be incorrect on decoder's side (and hence on display's side).
My question, should i re-compute max_display_mastering_luminance and min_display_mastering_luminance from reconstructed images or remain these parameters intact after encoding (i.e. remain them 'as-is' as computed from input raw data)?

[nevcairiel]

Here is my question. x265 encoding (unless it is lossless) makes original frames and reconstructed ones to different. Hence, max_display_mastering_luminance and min_display_mastering_luminance may be incorrect on decoder's side (and hence on display's side).
My question, should i re-compute max_display_mastering_luminance and min_display_mastering_luminance from reconstructed images or remain these parameters intact after encoding (i.e. remain them 'as-is' as computed from input raw data)?

min/max_display_mastering_luminance describe the display which was used to master this content, not the content itself.
What you probably meant is MaxFALL and MaxCLL?

In any case, the overall luminance of the image should not change from a lossy encoding (and even if it did, it would be miniscule changes at worst), so using the value you calculated on the original frames is fine.

[CruNcher]

min/max_display_mastering_luminance describe the display which was used to master this content, not the content itself.
What you probably meant is MaxFALL and MaxCLL?

In any case, the overall luminance of the image should not change from a lossy encoding (and even if it did, it would be miniscule changes at worst), so using the value you calculated on the original frames is fine.

Like this ?

https://forum.doom9.org/showpost.php?p=1796861&postcount=207

also some user here showed something similar with x265 output results where the entire lighting seem to have changed perceptually

both are 10->8 bit conversion results

Though i guess it's just that Intel is more efficient with it's chroma handling that lets it look like more pixels responsible for the indirect lighting where captured in the end and better preserved so overall a higher perceptual visible compression efficiency in the HDR space compared to Nvidia, or they just prefer to give chroma a higher per frame distribution priority to look closer to the source in HDR.

or just a better 10->8 bit conversion origin uknown

As you can clearly see the distribution differs and Nvidia seems to be psy wise investing into other parts then Intel does, quiete fascinating to see this without needing to measure the difference :)

AMD and Nvidia seem pretty identical in their output only Intel differs on this specific part ;)

[Shevach]

min/max_display_mastering_luminance describe the display which was used to master this content, not the content itself.
What you probably meant is MaxFALL and MaxCLL?

In any case, the overall luminance of the image should not change from a lossy encoding (and even if it did, it would be miniscule changes at worst), so using the value you calculated on the original frames is fine.

Thanks for a prompt reply. Frankly speaking i meant both min/max_display_mastering_luminance (signaled in MasteringDisplayColorVolume SEI) and MaxCLL/MaxFall (signaled in Content Light Level SEI).
What's about MaxCll? After encoding this value might be different from that obtained from source yuv or tiff.

In my opinion, lossy encoding may cause non-negligible changes in min/max_display_mastering_luminance and MaxFall/MaxCll.
Why? If a quantization rounding offset is less 0.5 in an encoder then reconstructed pixels tend to be smaller (leakage of energy). If the quantization rounding offset is above 0.5 then an opposite effect takes place. The quantization rounding offset is like a pump which either inhale or exhale "energy".
Consequently, after encoding MaxFall/MaxCll may differ from those in the original file.

[pradeeprama]

Correct: If your CPU does not support AVX2, you should not use a build compiled with options where AVX2 support is already assumed for the C++ parts of the code. It may crash somewhere due to unsupported opcodes or wrong assumptions about register widths.

x265 queries the CPU for what generation of SIMD it supports (AVX2, AVX, SSE4, MMX) at run-time and links the asm routines for the highest generation supported. So it shouldn't matter which generation you built on as long as it is x86.

[jairovital]

I'm having problem with non English filename using StxRip on Windows 7 64, Codepage 1252/850.
Running avs2pipemod64.exe (version 1.1.1 - Aug 2016) it gives:

avs2pipemod[error]: Import: couldn't open "B:\Programas\StaxRipTemp\S� corro_temp\S� corro.x265 - MKV - Super Low 26 - AAC - 22050 Hz.avs"

Talking with its author, Stax76, he said that since it works with x264, probably x265 could be the cause of problem, once we need to implement an avifile/avisynth/vapoursynth reader. "All of Rigaya's hardware encoders have direct support for avs and vpy, x264, so it supports at least avs".

I suspected avs2pipemod was the cause of problem, but it seems not.

Greetings from me and Stax76.
:)

[need4speed]

Thanks for all the new efforts but one thing is not clear to me: is new table already fully implemented or just 8-bit? On all versions starting from?
Thanks

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Barough]

@need4speed
It's only available for 8bit encoding atm.

Sent from my Samsung Galaxy S7 edge via Tapatalk

[need4speed]

@need4speed
It's only available for 8bit encoding atm.

Sent from my Samsung Galaxy S7 edge via Tapatalk
Thanks, just for confirmation: do not need to point to any external table, correct?


Inviato dal mio GT-N7100 utilizzando Tapatalk

[LigH]

No, since v2.3+22 it's default.

[need4speed]

No, since v2.3+22 it's default.
Ok great cause St least for my personal setup this has been a good step forward.

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Boulder]

The latest commit seems to put --limit-tu 4 in the presets slower and veryslow. Previously it was mentioned that --limit-tu 3 would provide good subjective quality while increasing performance, so has there been some more testing regarding the option?

[x265_Project]

The latest commit seems to put --limit-tu 4 in the presets slower and veryslow. Previously it was mentioned that --limit-tu 3 would provide good subjective quality while increasing performance, so has there been some more testing regarding the option?
Yes. Tests showed a ~20% performance increase with almost no detectable impact to quality.

[benwaggoner]

Thanks for a prompt reply. Frankly speaking i meant both min/max_display_mastering_luminance (signaled in MasteringDisplayColorVolume SEI) and MaxCLL/MaxFall (signaled in Content Light Level SEI).
What's about MaxCll? After encoding this value might be different from that obtained from source yuv or tiff.

In my opinion, lossy encoding may cause non-negligible changes in min/max_display_mastering_luminance and MaxFall/MaxCll.
Why? If a quantization rounding offset is less 0.5 in an encoder then reconstructed pixels tend to be smaller (leakage of energy). If the quantization rounding offset is above 0.5 then an opposite effect takes place. The quantization rounding offset is like a pump which either inhale or exhale "energy".
Consequently, after encoding MaxFall/MaxCll may differ from those in the original file.
You are entirely correct that encoding can reduce the MaxFALL and particularly MaxCLL from the source. However, industry standard behavior is to retain the values from the source as indicative of creative intent. Also, with adaptive bitrate switching, different streams could have different encoded metadata values. But Displays don't like mid-stream metadata value changes, so the same values should be used for all bitrates.

THAT said, devices don't make heavy use of MaxFALL and MaxCLL in practice, because knowing what the brightest frame and brightest pixel across an entire movie isn't that useful. Dynamic metadata ala Dolby Vision and SMPTE 2094-40 are much more useful for tone mapping.

[CruNcher]

MaxFALL and MaxCLL play no role in Hardware protection or could they be used to save energy more efficient per frame improving overheating statistics and overall Hardware output efficiency ?


Though not sure for what that would help you need those data in realtime and some heat buffer that corrects the latency before you need to emergency shutdown, HDR is pretty interesting in those regards how smart (adaptive) the Display Hardware must react to not get damaged or MTBF rising heavily whiich in the end also defines the end result of what you gonna percept overall :)

HDR + VFR overall seem also to have the potential to be very efficiently combined especially 1 compensating the others higher power output needs :)

Especially Nvidia and AMD currently seem to be very interested in pushing this forward in their Labs currently :)

HDR generates some interesting drawbacks in terms of energy output savings that have been done over the years in power consumption it lowers the output efficiency again or compensates some of the advantages done in the Mobile Power Saving space pretty rapidly.

Power Supplier are surely pretty happy about this development ;)

[jairovital]

I'm having problem with non English filename using StxRip on Windows 7 64, Codepage 1252/850.
Running avs2pipemod64.exe (version 1.1.1 - Aug 2016) it gives:

avs2pipemod[error]: Import: couldn't open "B:\Programas\StaxRipTemp\S? corro_temp\S? corro.x265 - MKV - Super Low 26 - AAC - 22050 Hz.avs"

Talking with its author, Stax76, he said that since it works with x264, probably x265 could be the cause of problem, once we need to implement an avifile/avisynth/vapoursynth reader. "All of Rigaya's hardware encoders have direct support for avs and vpy, x264, so it supports at least avs".

I suspected avs2pipemod was the cause of problem, but it seems not.

Greetings from me and Stax76.
:)

[Barough]

x265 v2.3+24-a0eee4b41185 (http://www117.zippyshare.com/v/6VXBOfyU/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+24-a0eee4b41185
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[brumsky]

Could someone please post the latest build while using VS 2017?

Thanks!

[Leo 69]

Could someone please post the latest build while using MSVC 2017?

Thanks!

http://www.mediafire.com/file/1g95yof33vr73u7/x265-2.3_24-a0eee4b_vs2017-AVX.7z

http://www.mediafire.com/file/4nsvdbf65ipbne9/x265-2.3_24-a0eee4b_vs2017-AVX2.7z

[Ma]

Could someone please post the latest build while using VS 2017?

Thanks!

If you don't see latest build on page www.msystem.waw.pl/x265 please refresh the page (F5 should help).

[brumsky]

http://www.mediafire.com/file/1g95yof33vr73u7/x265-2.3_24-a0eee4b_vs2017-AVX.7z

http://www.mediafire.com/file/4nsvdbf65ipbne9/x265-2.3_24-a0eee4b_vs2017-AVX2.7z


If you don't see latest build on page www.msystem.waw.pl/x265 please refresh the page (F5 should help).


Awesome thank you both!!

[pingfr]

Awesome thank you both!!

I can only agree and applaud with both hands.

At the moment it is... "un-wise" to use a GCC built x265 binary.

VS2017 is (at least for now) the way to go.

[Barough]

Why is that pingfr?

GCC compiles mite be slow for 10bit encodes but thats not the case for 8bit.

Personally so am i not interested in 10bit due 2 that its not especially compatible with hardware.

Sent from my Samsung Galaxy S7 edge via Tapatalk

[LigH]

The differences are subtle as the preset "increases"...

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

http://www.ligh.de/pics/x265-speed.png

With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.

[benwaggoner]

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

I full agree about using percentage ratios.

Has anyone tried doing profile-driven optimizations for x265? I don't know if it would help much given all the assembler, but 5% on veryslow with a different compiler suggests there may be some juice to squeeze out there still.

[LigH]

An analytic with a lot of spare time would probably check: Which features are only enabled in slower presets, and are they still in C code? Most probably, as I would assume they are not primitive operations, thus rather hard to implement in lower level languages.

[pingfr]

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

http://www.ligh.de/pics/x265-speed.png

With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.

Thanks for making that table re-cycling the data I pasted a few days ago, glad it served a purpose.

Although it is missing the placebo preset.

I just can't be bothered waiting 45 minutes to run each placebo encodes.

Also note it is important to remind you these tests were ran using 2.3+23, it is worth mentioning the latest commit applies limit-tu to slower, veryslow presets for an up to 20% increase in FPS according to the commit, this most likely has skewed the presented data here, it has to be seen whether the delta remains and even there we're talking about 0.15 of 1 fps. :p

[LigH]

Don't be sad; I do not even have any AVX2 capable processor available.

[aymanalz]

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

http://www.ligh.de/pics/x265-speed.png

With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.


What exactly is that ratio percent in the last row? In the first comparison, one encode is faster than the other by 0.83%, which you have called as a 100.83% ratio.

So in all the comparisons, to know by how much one is faster than the other, you have to ignore the "100", and whatever remains is the percentage difference in speed.

Isn't that the relevant metric? By what percent one is faster than the other?

[aymanalz]

Thanks for making that table re-cycling the data I pasted a few days ago, glad it served a purpose.

Although it is missing the placebo preset.

I just can't be bothered waiting 45 minutes to run each placebo encodes.


You could run the placebo encodes on a very short clip, maybe trimmed from your original clip.

[nevcairiel]

Isn't that the relevant metric? By what percent one is faster than the other?

Its the same metric, just a different way to express it.
Declaring GCC to be the reference at 100%, then this gives you the numbers above for VS2017 - easy enough to read the increases out of.

[pingfr]

Its the same metric, just a different way to express it.
Declaring GCC to be the reference at 100%, then this gives you the numbers above for VS2017 - easy enough to read the increases out of.

Regardless a 5.91% speed increase is nothing to be "ashamed of".

[nakTT]

Only if you prefer to look at absolute differences, instead of relative ratios. And to be frank, I see no reason to prefer absolute differences over relative ratios.

http://www.ligh.de/pics/x265-speed.png

With the exception of the extremes, the relative ratios of the encoding speeds of most presets were almost constant (and the differences among these ratios most probably in a range of random influences, like interrupting kernel tasks).

At least, there is a certain advantage of the MSVC builds. Rather small yet reliable.
I agree on this. Generally MSVC builds is consistently better. I have been comparing the performance for every new release of x265 and found this to be true.

[LigH]

I decided to keep building with GCC still, I believe that an advantage of <2% is no reason to abandon it, and furthermore, installing Visual Studio seens to be much more elaborate than using an MSYS environment, just for this small task and nothing else...

But I don't mind other people publishing MSVC builds. More choice!

[CruNcher]

Please dont freaking forget the compiler is Windows only GCC has to be Multiplatform that is a different bread to crunch entirely, in balancing and overall performance on every Posix OS and different ARCHs running on them.

[Ma]

The speed comparison of different x265 builds is not so simple.
Let's say that we want compare speed of encoding file "Bosphorus_1920x1080_120fps_420_8bit_YUV.y4m" at preset medium to 8-bit hevc (like in pingfr test, but only for preset medium).

There are many CPUs on the world, so we compare encoding speed with different '--asm' levels (from false [= --no-asm] to AVX).
gcc63s2 means GCC 6.3 build that works on SSE2 CPU (which is 'none' for Win64)
gcc70s3 means GCC 7.0 build for SSSE3 CPUs and better
gcc70s4 means GCC 7.0 build for SSE4.1 CPUs and better
vs2017a1 means VS 2017 build for AVX CPUs and better.
(There are no AVX2 builds -- my CPU is only with AVX.)

Relative encoding speed on Win7 64-bit, i5 3450S, RAM DDR3 1600:
--asm= | false .|. SSE2 .| SSSE3 .| SSE4.1 | AVX
--------|--------|----------------------------------
gcc63s2 |100.00% |100.00% |100.00% |100.00% |100.00%
gcc70s2 | +4.63% | +4.12% | +4.81% | +0.56% | +0.61%
gcc70s3 | +8.47% | +5.14% | +5.74% | +0.04% | +0.14%
gcc70s4 |+11.57% | +8.06% | +6.90% | +0.16% | -0.42%
vs2017s2|-19.66% |-21.68% |-30.75% | +1.07% | +0.87%
vs2017a1|-18.77% |-20.90% |-29.68% | +2.48% | +2.45%

Some remarks:
1) gcc70s4 build is the fastest with '--no-asm' option but is the slowest with '--asm=avx' option.

2) VS 2017 builds are very slow on CPUs <= SSSE3, the switch is on SSE4.1 level.

3) GCC 7.0 builds are a little bit faster than GCC 6.3 builds.

4) My i5 3450S is surprisingly slower than pingfr's i7 6700 -- 12.34 fps to 23.17 fps.

5) The speed difference from '--asm=sse4' to '--asm=avx' is minimal (12.30 fps to 12.34 fps; full data in attachment).

[Midzuki]

I decided to keep building with GCC still, I believe that an advantage of <2% is no reason to abandon it, and furthermore, installing Visual Studio seens to be much more elaborate than using an MSYS environment, just for this small task and nothing else...

But I don't mind other people publishing MSVC builds. More choice!

I second that. Visual Studio is a nightmare, tons of bloat in the registry and needless services. It's okay and a must-have for professional programmers, but I am not a professional programmer, I'm just a not-so-advanced ordinary user.

@Ma:
many thanks for the useful post :thanks:

That's exactly what I was thinking, but I didn't have any empirical evidence :o

[pingfr]

4) My i5 3450S is surprisingly slower than pingfr's i7 6700 -- 12.34 fps to 23.17 fps.

And why would this be "surprising" at any rates? You're comparing an i7 against an i5 and furthermore a CPU from the 6th generation against one from the 3rd generation which furthermore is an "S" CPU targeted at semi-embedded low-power users?

Unless I missed something here...

Even though, the point I was trying to make a few days ago regarding these tests was that for "some obscure" reasons --preset veryslow was giving us the biggest increase when switching from a GCC build to a VS2017 build compared to a supposedly much faster (but therefore having less optimized settings) preset such as --preset medium and that is where things needed further investigations.

[shinchiro]

@Ma thanks for the detailed test. btw the gcc is built with posix or win32 threads?

[Ma]

And why would this be "surprising" at any rates? You're comparing an i7 against an i5 and furthermore a CPU from the 6th generation against one from the 3rd generation which furthermore is an "S" CPU targeted at semi-embedded low-power users?

There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

@shinchiro: win32 threads

[pingfr]

There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

Okay I see.

Also some benchmarks have been somewhat leaked regarding a 3.6GHz upcoming AMD Ryzen with... 16 cores. So you might want to hold your breath a little longer before buying a newer CPU.

[CruNcher]

There was opinion, that from 3rd to 4th generation is only a little bit speed-up and from 4th to 5th and 6th is none, so I was thinking that
a little bit + none + none = 1.3x (max 1.5x)
but 1.9x is surprising to me. It is time for new CPU.

@shinchiro: win32 threads

More impressive it becomes if you look @ it Realtime doing the Decoding instead of the Encoding which is harder to grasp visually ;)

[pingfr]

More impressive it becomes if you look @ it Realtime doing the Decoding instead of the Encoding which is harder to grasp visually ;)

Me no understanderino you. :helpful: :helpful: :helpful:

[easyfab]

@Ma could you test this build https://www.sendspace.com/file/biunt6

GCC 6.3 but fprofile with my i2600k

[LigH]

@ easyfab:

Look how to avoid an unnecessary full-quote... :rolleyes:

[Ma]

@Ma could you test this build https://www.sendspace.com/file/biunt6

GCC 6.3 but fprofile with my i2600k

normal GCC 6.3 = 100%

--asm= |SSSE3 |SSE4.1 |AVX
gcc63s2 |100.00%|100.00%|100.00%
gcc70s2 | +5.00%| +0.54%| +0.83%
gcc63pr |-36.29%| +1.89%| +1.46%
vs2017s2|-30.60%| +0.99%| +0.87%


At SSSE3 level your profiled version is very slow but it is OK -- when you profile the functions that are not executed are compiled for minimize size.

At SSE4.1 level you speed-up +1.89% to normal GCC 6.3 build -- it is better than VS 2017 build (but a bit slower than VS 2017 AVX build). So it is the fastest version that you can execute.

[easyfab]

@Ma Thanks for the report

I will try with GCC 7 to see if it better.

[Boulder]

Does x265 have framerate-aware ratecontrol like x264 does?

http://git.videolan.org/gitweb.cgi?p=x264.git;a=commit;h=c583687fab832ba7eaf8626048f05ad1f861a855

I was just wondering if I should run into material that needs to be encoded at double framerate. Many concerts are encoded as interlaced and I use QTGMC on them to get high quality progressive output at double framerate.

[sneaker_ger]

Yes. (But I don't think you can supply timecodes to the CLI for VFR.)

[Romario]

Is there any news for Ryzen optimizations?

Gesendet von meinem GT-I9295 mit Tapatalk

[Ma]

I decided to try with profiled VS 2017 version -- www.msystem.waw.pl/x265/vs2017pgo.7z
Speed gain at 8-bit --profile medium:
SSE4.1: 12.10 -> 12.53 (+3.55%)
AVX: 12.14 -> 12.56 (+3.46%)

[Boulder]

Yes. (But I don't think you can supply timecodes to the CLI for VFR.)That's good, I rarely need VFR and I can use x264 for those anyway :)

[pingfr]

I decided to try with profiled VS 2017 version -- www.msystem.waw.pl/x265/vs2017pgo.7z
Speed gain at 8-bit --profile medium:
SSE4.1: 12.10 -> 12.53 (+3.55%)
AVX: 12.14 -> 12.56 (+3.46%)

Uh? would you be kind enough to supply us with a such "optimized" binary?

[easyfab]

I decided to try with profiled VS 2017 version -- www.msystem.waw.pl/x265/vs2017pgo.7z
Speed gain at 8-bit --profile medium:
SSE4.1: 12.10 -> 12.53 (+3.55%)
AVX: 12.14 -> 12.56 (+3.46%)

nice, better boost than mine with profiled GCC version.

I'm curious to see what a profiled version can give for ryzen ?

[Ma]

Uh? would you be kind enough to supply us with a such "optimized" binary?

Probably yes if I write batch file to automate all strange things that I do manually.
-------------------------------
8- and 10-bit for SSE4.1 and AVX CPUs optimized mainly for my encoding options (-p veryslow --crf 18 -I480 --deblock -1):
www.msystem.waw.pl/x265/x265-2.3+24-a0eee4b_vs2017-PGO.7z

[Sagittaire]

nice, better boost than mine with profiled GCC version.

I'm curious to see what a profiled version can give for ryzen ?

There are certainely higher optimisation in x265 code itself. actualy x265 encoding with AVX2 off is better than with AVX2 on.

http://rigaya34589.blog135.fc2.com/blog-entry-909.html

[Dclose]

720p should be around 2800kbits whereas 1080p should be around 6500kbits if you want "acceptable" quality, depends on the fps and the crop.

Those rates are 2-3 times higher for what I consider acceptable quality. These terms are subjective, but 6500kbits 1080p I would expect to look pretty darn great.

I turn on practically every quality option though.


Can I use denoise filter, make that any sense? To have better quality encodes, of course.
In general, I consider denoisers a waste of time unless the source is very bad quality. Even then, denoiser will usually hurt detail, so you're giving up detail for a cleaner but less original picture. Also, x265 inherently denoises and smooths, and lots of people have spent a lot of time trying to figure out how to get it to not do that. :)

[Dclose]

at this point in time, x265 is not on-par with x264's detail retention, and no amount of knobs tweaking will change that. Sorry to say it, but you'll have to accept this for the moment.
I disagree. Though I say that knowing more about and having tested x265 settings than about x264 settings. I've used x264 Very Slow for years, and would use Placebo now. (yes, I do notice a difference.)

Stock x265 presets I think turn a lot of new people off. It's like every preset is still geared to smoothing and lower bitrate. It really could use some presets more geared to quality to better show what it can do.

There's been talk about x265 Grain setting lately, and that can help, but it also can overdo it. Lower the two Psy amounts to get more of a Film setting than a Grain setting.

Here's a detail setting I think a lot of people miss in x265, probably since tooltips and the manual recommend not to touch it:
Adaptive Quantization Strength
Default is 1.00.
Details that you could never get sharp enough no matter how much bitrate or CQ you threw at it? Change it to 2.00 and see.

2.00 is a lot, though. 1.1 to 1.5 is more balanced. 2.00 can bring ringing and halos and mosquito noise, etc.

Bitrate will go up, but I'd generally rather watch video of CQ22 and 1.5 AQS than the same size (or even bigger) file at CQ21 and 1.0.

As with most settings, it's a balancing act based on what result you're trying to achieve.

[Motenai Yoda]

I just noticed there isn't any userdata or cli output to check if ssim-rd is enabled or not.

[need4speed]

Here's a detail setting I think a lot of people miss in x265, probably since tooltips and the manual recommend not to touch it:
Adaptive Quantization Strength
Default is 1.00.
Details that you could never get sharp enough no matter how much bitrate or CQ you threw at it? Change it to 2.00 and see.

As with most settings, it's a balancing act based on what result you're trying to achieve.

This is pretty interesting and something worth a try.
My standard settings for quality/speed 1080p are:
C:\Portable\StaxRip-x64-1.4.1.1-test\Apps\x265\x265.exe --crf 20 --amp --aq-strength 1.25 --qcomp 0.7 --aq-motion --me star --no-strong-intra-smoothing --no-deblock --no-sao --frames 60745 --y4m --output "D:\DA CONVERTIRE

This is giving me good results, assumed that perceived quality is something personal and all relative.
Question would be: AQS raised to 1,5 will allow to lower CRF?
Besides, not sure if aq-motion will turn off or disable aq-mode? Meaning that using aq-motion will make aq-mode choice irrelevant?
Thanks!

[LigH]

additional compiler flags

I found a (hopefully) comprehensive overview (https://gcc.gnu.org/onlinedocs/gcc-6.3.0/gcc/x86-Options.html#x86-Options). Might be useful for enthusiastic optimizers to have this bookmarked.

[Dclose]

This is pretty interesting and something worth a try.
My standard settings for quality/speed 1080p are:
C:\Portable\StaxRip-x64-1.4.1.1-test\Apps\x265\x265.exe --crf 20 --amp --aq-strength 1.25 --qcomp 0.7 --aq-motion --me star --no-strong-intra-smoothing --no-deblock --no-sao --frames 60745 --y4m --output "D:\DA CONVERTIRE

This is giving me good results, assumed that perceived quality is something personal and all relative.
Question would be: AQS raised to 1,5 will allow to lower CRF?
Besides, not sure if aq-motion will turn off or disable aq-mode? Meaning that using aq-motion will make aq-mode choice irrelevant?
Thanks!
1.25 is from what I can tell a nice compromise setting that gives details extra punch without adversely affecting much else. I generally prefer a sharper picture with some potential artifacts over dull and smeared, so at the moment 1.50 is generally more my preference. As I said, generally, I'd rather watch cq22 and 1.5AQS than CQ21 and 1.00, and the file should be smaller.

I'd like to use 2.00 all the time. But it can add a lot of bitrate. It can make complicated things like faces talking in close-ups look great (instead of looking like smeared plastic like they often do). But at other times it will look hyper-detailed like a sharpness filter set too high, and do things like a scene of three people on the screen but, strangely, only one of the three is surrounded by mosquito noise -- possibly due to the background making the scene complicated, like people standing outside with some in front of trees and gravel while others that are in front of water in that same scene have mosquito noise.

From the handful of tests I've done on Motion Based AQ, I didn't like it and turn it off. I forget why. Maybe I wrote it down on a note somewhere. Two probable reasons are it either added smoothness (blur) like so many x265 settings do and which so many of us turn off :D or it added too much bitrate vs. video quality improvement.

[need4speed]

1.25 is from what I can tell a nice compromise setting that gives details extra punch without adversely affecting much else. I generally prefer a sharper picture with some potential artifacts over dull and smeared, so at the moment 1.50 is generally more my preference. As I said, generally, I'd rather watch cq22 and 1.5AQS than CQ21 and 1.00, and the file should be smaller.

From the handful of tests I've done on Motion Based AQ, I didn't like it and turn it off. I forget why. Maybe I wrote it down on a note somewhere. Two probable reasons are it either added smoothness (blur) like so many x265 settings do and which so many of us turn off :D or it added too much bitrate vs. video quality improvement.

Basically my above command line was with your AQS tweaking while encoding, so I've checked output and it does make a difference in terms of details.
On the other hand keeping same CRF increases file size, so I'll try with CRF 21 and 22 together with AQS 1,5. I assume AQ mode is set to 1, correct?
As for aq-motion I have noticed some differences as well, so will disable and see what happens playing around with CRF and AQS only.
I am not a pixel peeper and have spent last year trying to find best compromise between encoding time, quality and detail retention. 1080p TV series mainly, the goal is to save between 40 and 50% in terms of space (vs AVC) and, finally, looks like we're almost there.
Every bit of help counts here, my I7 3770 Ivy Bridge is finally giving me 8/9 fps with my settings, which is totally acceptable.
Thanks for your tips! Much appreciated since I have tried a lot of different stuff and most of times couldn't tell the difference in the output video, in spite of a massime encoding fps drop.

[Dclose]

I assume AQ mode is set to 1, correct?

Every bit of help counts here, my I7 3770 Ivy Bridge is finally giving me 8/9 fps with my settings, which is totally acceptable.

AQ1 seems more visually consistent than AQ2.

I assume I turn on more quality settings than you since my 3770k at 4.1ghz does more like 1-2 fps with 1080.
So what's the story with rdoq-level 1 vs 2? I've been toying around with it and it seems that 1 is "sharper" but it might not be as true to the source compared with 2.

I also noticed rdoq-level 2 is used in the higher presets.
I'm wondering about that too. From my tests so far, 2 seems sharper, though. 1 cleans up the video to perhaps make detail easier to see, but it removes detail mixed in with grain. I'm trying to think of a better way to explain it.

Using a pretty grainy test clip, 1 removed a lot of grain. 2 kept more of the grain and looks more like the source. 1 is 10+% bigger filesize.

Currently trying to find negatives of using 2 instead of 1.

[need4speed]

AQ1 seems more visually consistent than AQ2.

I assume I turn on more quality settings than you since my 3770k at 4.1ghz does more like 1-2 fps with 1080.

AQ1,Aq2 and AQ3 with my seetings look almost the same, can't spot a difference. Maybe aq3 was keeping a bit more detail in dark areas (if memmory serves well) but, again, cant tell the difference.

Well, my settings are more speed-oriented, trying to retain as much detail as possible. I have tried a lot of tweaking, messed around with every and each switch trying to find a balance between speed and quality (perceived, this is all personal).
The idea of 2/4 fps to me is not acceptable, hence the speed I get I assume. This is since most of additional tweaking gave back no significant added value, in spite of looong encoding times.
A good step forward was made with latest lambda table and encoder releases. This was brilliant and, always imho, has given me the result I want.
I still encode in 8bit, 8bit pseed is almost the double of 10bit and I cannot see a significative difference between the two final files. This as general quality, have spotted differences in single frames and yes, there are some, but to me not worth 4fps vs 8/9 fps speed.
I have come to my "final" settings, still about to decide among
option 1: --crf 20 --amp --aq-strength 1.25 --qcomp 0.7 --aq-motion --me star --no-strong-intra-smoothing --no-deblock --no-sao

option 2: x265.exe --crf 21 --amp --aq-strength 1.5 --qcomp 0.7 --me star --no-strong-intra-smoothing --no-deblock --no-sao --frames 60755 --y4m --output "D

The difference will be made by final size more than quality whch presumably will be more or less the same.

For the record my most significative test to judge quality is grabbing some frames with writings, signs, plates or whatever similar and check original vs encoded video. Maybe not a significative test but gives a good idea about detail retention.

[Dclose]

AQ1,Aq2 and AQ3 with my seetings look almost the same, can't spot a difference. Maybe aq3 was keeping a bit more detail in dark areas (if memmory serves well) but, again, cant tell the difference.

Well, my settings are more speed-oriented, trying to retain as much detail as possible.

I still encode in 8bit, 8bit pseed is almost the double of 10bit and I cannot see a significative difference between the two final files.
AQ3 increased my filesizes a lot and seemed to have a mind of its own. It's also apparently geared for dark areas, and that's a main area I generally will accept a quality loss in first since it's harder to see details in dark areas anyway and x265 is good at avoiding big macroblocks unless using Max Merge 1.

I only use 10-bit on animation. It can be a big help on that especially at low bitrate.

If you're not already using it, Early Skip is probably the biggest speed/quality setting in x265. It obviously gives imperfections and artifacts at very low resolution and bitrate, (at that level, the video needs all the help it can get and encodes pretty fast anyway without it), while at higher res and bitrate its quality negatives are less noticeable and boost speed often around 30+%.

[brumsky]

@Dclose

Yeah I've seen the same thing. 1 seems to make the "detail" pop more or look darker in an attempt to stand out more. 2 does seem more like the source but requires a slightly higher psy value to get the same level of detail - at least to my eye.

@need4speed

I've done some testing with higher aq strength 1.1 - 1.5 and I don't like the outcome... The sharpness of hair, for example, looks worse the higher the aq strength. It ends up fussy and blocky\noisy around objects in the foreground.

The two settings that seem to improve the quality the best for me on a quality\speed trade off. Is ref 6 and max merge 5. Those two together provide a relatively small hit in speed but a big gain in quality, at least to my eye.

[brumsky]

option 1: --crf 20 --amp --aq-strength 1.25 --qcomp 0.7 --aq-motion --me star --no-strong-intra-smoothing --no-deblock --no-sao

option 2: x265.exe --crf 21 --amp --aq-strength 1.5 --qcomp 0.7 --me star --no-strong-intra-smoothing --no-deblock --no-sao --frames 60755 --y4m --output "D


What preset are you using? I'm asking because amp requires rect if memory serves me right.

Try adding ref 5 or 6 & max merge 4 or 5 depending on the preset you use and drop aq-strength to 1. 6 & 5 respectively should give the best results.

[need4speed]

What preset are you using? I'm asking because amp requires rect if memory serves me right.

Try adding ref 5 or 6 & max merge 4 or 5 depending on the preset you use and drop aq-strength to 1. 6 & 5 respectively should give the best results.

Preset is medium; if I'm not mistaken (I use staxrip) the log shows some warning if any setting is not enabled due to something wrong, but I might be wrong here.
Will try your tweaks and see how it goes, leaving AQS set to 1. Btw, medium preset requires ref and maxmerge set as?
Usually I end up with 4000/6000 Kbs and haven't noticed any problem with sharpness or blockyness around the objects. But will look at more deeply.
Thanks!
@DClose early-skip seems to be enabled by default as I see, at least with latest builds I use.

[Dclose]

Yeah I've seen the same thing. 1 seems to make the "detail" pop more or look darker in an attempt to stand out more. 2 does seem more like the source but requires a slightly higher psy value to get the same level of detail - at least to my eye.

The two settings that seem to improve the quality the best for me on a quality\speed trade off. Is ref 6 and max merge 5. Those two together provide a relatively small hit in speed but a big gain in quality, at least to my eye.
I would say the opposite on psy level for 1 and 2, based on my small number of tests so far. 2 is inherently more grainy and so needs less psy -- which also means if I'm trying to preserve grain then a lower psy setting means an even smaller file than 2 already does.

The size difference at the same settings has my curiosity. I'm trying to figure out where 1 is putting that extra bitrate. Would expect 2 to be bigger but it's not.

What I'm still trying to eye is the difference 1 and 2 do on complicated areas. It can be hard to compare since 1 looks like it "holds together" better and makes a more "precise" picture, but maybe that's only because 2 has more grain over it. More testing and eyeballing is needed.

Max Merge can be a complicated setting, and I'm surprised that in this entire thread I think only a couple of us have brought it up. At higher bitrate and resolution, a merge of 5 probably doesn't kick in all that much anyway except when really useful. At very low res and bitrate, 5 can be a necessity to keep the video watchable. And at like 720p and 2000 kbps, lots of things can happen, such as 5 making objects and "big detail/edges" more solid, but while also destroying grain and fine detail and making things flat and smooth. At that res/bitrate, 1 can make the video look great in well-lit scenes, but the blocking and similar ugliness in dark areas basically necessitates the use of at least 2. And 1 at that res/bitrate can make objects seem "thin/ghostly."

It's interesting which path to choose: more Max Merge to stop blocking and similar, or less Max Merge but use more deblocking filter.

Ironically, (ok, maybe not ironically), AQS of 2.00 seems it might do best with Max Merge 5. Like MM 5 is merging (too much) detail together, but AQS 2.00 is trying to jam in more (too much) detail. So it kind of works out.

But, AQS 2.00 is unfortunately too much overall, at least at the mild bitrates I've tested at, and Max Merge 5 is too much overall, at least at mild bitrates. I can understand people liking MM 5 at mild bitrate, but it smooths and smears and makes things like cheeks on a face close-up look flat, sort of like if setting the deblock filter too high.

I don't know what setting you mean by "ref 6" unless you mean RDO 6.

[brumsky]

Preset is medium; if I'm not mistaken (I use staxrip) the log shows some warning if any setting is not enabled due to something wrong, but I might be wrong here.
Will try your tweaks and see how it goes, leaving AQS set to 1. Btw, medium preset requires ref and maxmerge set as?
Usually I end up with 4000/6000 Kbs and haven't noticed any problem with sharpness or blockyness around the objects. But will look at more deeply.
Thanks!
@DClose early-skip seems to be enabled by default as I see, at least with latest builds I use.

Medium defaults to ref 3 max merge 2, so start with ref 5 & max 4. The more reference frames you give the encoder the better the results. If it's to slow then drop max to 3. If you can stomach the speed try ref 6.

Try zooming in with staxrips video comparison tool, you'll see the extra noise\blocking around places like hair when higher AQ strength is used.

[brumsky]

I would say the opposite on psy level for 1 and 2, based on my small number of tests so far. 2 is inherently more grainy and so needs less psy -- which also means if I'm trying to preserve grain then a lower psy setting means an even smaller file than 2 already does.

The size difference at the same settings has my curiosity. I'm trying to figure out where 1 is putting that extra bitrate. Would expect 2 to be bigger but it's not.

What I'm still trying to eye is the difference 1 and 2 do on complicated areas. It can be hard to compare since 1 looks like it "holds together" better and makes a more "precise" picture, but maybe that's only because 2 has more grain over it. More testing and eyeballing is needed.

Max Merge can be a complicated setting, and I'm surprised that in this entire thread I think only a couple of us have brought it up. At higher bitrate and resolution, a merge of 5 probably doesn't kick in all that much anyway except when really useful. At very low res and bitrate, 5 can be a necessity to keep the video watchable. And at like 720p and 2000 kbps, lots of things can happen, such as 5 making objects and "big detail/edges" more solid, but while also destroying grain and fine detail and making things flat and smooth. At that res/bitrate, 1 can make the video look great in well-lit scenes, but the blocking and similar ugliness in dark areas basically necessitates the use of at least 2. And 1 at that res/bitrate can make objects seem "thin/ghostly."

It's interesting which path to choose: more Max Merge to stop blocking and similar, or less Max Merge but use more deblocking filter.

Ironically, (ok, maybe not ironically), AQS of 2.00 seems it might do best with Max Merge 5. Like MM 5 is merging (too much) detail together, but AQS 2.00 is trying to jam in more (too much) detail. So it kind of works out.

But, AQS 2.00 is unfortunately too much overall, at least at the mild bitrates I've tested at, and Max Merge 5 is too much overall, at least at mild bitrates. I can understand people liking MM 5 at mild bitrate, but it smooths and smears and makes things like cheeks on a face close-up look flat, sort of like if setting the deblock filter too high.

I don't know what setting you mean by "ref 6" unless you mean RDO 6.

rdoq 2 basically rounds out some of the equations resulting in less high frequency noise being retained. With my testing it seems like 1 makes the noise darker and seems to stand out more compared to rdoq 2. I thought 1 was better at first - but after running encodes on several different sets of video I can more clearly see the difference. I've since gone back to rdoq 2.

My understanding of max merge is that it allows motion predictions to be more accurate by giving the encoder room to expand it's search. Someone please correct me if I misunderstand it's purpose.

ref is the number of reference frames the encoder can use. This is taken from the docs.

Max number of L0 references to be allowed. This number has a linear multiplier effect on the amount of work performed in motion search, but will generally have a beneficial affect on compression and distortion.

Note that x265 allows up to 16 L0 references but the HEVC specification only allows a maximum of 8 total reference frames. So if you have B frames enabled only 7 L0 refs are valid and if you have --b-pyramid enabled (which is enabled by default in all presets), then only 6 L0 refs are the maximum allowed by the HEVC specification. If x265 detects that the total reference count is greater than 8, it will issue a warning that the resulting stream is non-compliant and it signals the stream as profile NONE and level NONE and will abort the encode unless --allow-non-conformance it specified. Compliant HEVC decoders may refuse to decode such streams.

[need4speed]

Medium defaults to ref 3 max merge 2, so start with ref 5 & max 4. The more reference frames you give the encoder the better the results. If it's to slow then drop max to 3. If you can stomach the speed try ref 6.

Try zooming in with staxrips video comparison tool, you'll see the extra noise\blocking around places like hair when higher AQ strength is used.
Ok thanks.
First tests on 5 mins video gives approx 5fps which is still kinda acceptable.
As for video comparison tool the difference with my previous settings is noticeable but not so relevant. Again, pixel peeping is not my goal, when video is playing the difference is barely visible.
Still, there is something to consider: the input video quality. Usually I re-enable amazon webrips or bd TV shows and what I have noticed is that my 8 fps template works OK with those, but when it comes to standard webdl approximately 6000 lbs avc yes, your additional tweaks make a difference as for noise and details in dark areas.
Above all I am looking after killing any smoothing effect, I accept some blockyness but not "plastic faces".
Have also tried fast preset, somehow the impression is that overall image is sharper but detail loss is too high.

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Boulder]

As a non-technical person, I've never really understood --max-merge. What does it do in layman's terms? I've understood that it doesn't merge blocks but the resulting vectors from n blocks to predict motion.

[Dclose]

rdoq 2 basically rounds out some of the equations resulting in less high frequency noise being retained. With my testing it seems like 1 makes the noise darker and seems to stand out more compared to rdoq 2. I thought 1 was better at first - but after running encodes on several different sets of video I can more clearly see the difference. I've since gone back to rdoq 2.

My understanding of max merge is that it allows motion predictions to be more accurate by giving the encoder room to expand it's search. Someone please correct me if I misunderstand it's purpose.

ref is the number of reference frames the encoder can use. This is taken from the docs.
I did a clip from season 1 of Burn Notice, (shot intentionally grainy), and rdoq 1 looks like someone used a denoiser filter (or Max Merge 5! lol) on it compared to rdoq 2.

For an extreme MM example, do a test and output as low resolution, like 250 res and CQ 27. Do Max Merge 1 and then Max Merge5. MM1 probably looks like a mess, while MM5 probably looks way too smooth and has obvious big, thick edges on things.

More MM might be "expanding its search," but more importantly, and sometimes badly, it does what its name says: merge. In the 720p 2000kbps zone, MM5 can kill detail and make things look flat. Things will still have "chunks" and "areas" of detail, but it's not fine detail, and, frankly, can look as if you're using a lower resolution than what you are.

A funny thing about the default presets last time I checked is the slower the preset the more Max Merge is used. So you get (some) people using slower presets hoping for more detail, but then there's still SAO, intra smoothing and whatever else, but now also more Max Merge is used, which makes things even more smoothed.

For reference frames I've pretty much settled on 4 refs and 10 b-frames as the sweet spot. B-frames seems to help more than more refs. I think more refs helped but the speed/quality trade-off wasn't ideal. People will say 10 is too much and rarely gets used, but I have seen the difference, and some others have said the same, so whatever. Having said that, I don't think refs and b-frames are something to be overly concerned about.

[need4speed]

Medium defaults to ref 3 max merge 2, so start with ref 5 & max 4. The more reference frames you give the encoder the better the results. If it's to slow then drop max to 3. If you can stomach the speed try ref 6.

Try zooming in with staxrips video comparison tool, you'll see the extra noise\blocking around places like hair when higher AQ strength is used.

Updating settings and first feedback is a fps drop 9 to 5..almost 50%. Will see if woth it but comparison tool is showing (imho) no significative improvemet, but definitely there is some.
Will get back.

[brumsky]

@need4speed

I don't always zoom in when comparing, I just did it with this last because I could see something was different. After zooming in is when I noticed it.

Maybe just try to up ref but keep max merge at its default.

I checked the docs and confirmed my gut feeling. If rect is disabled amp is disabled as well.

From the docs:
This setting has no effect if rectangular partitions are disabled. Default disabled

[brumsky]

@Dclose

Yeah I'm not a fan of rdoq 1, I think 2 is better.

I'll have to test MM again, I know the last time I did it it looked better. That was at 1080p with a "healthy" bitrate.

b frames are for compression not quality. I & P frames have higher bit rates and quality.

@need4speed
what settings did you use for ref and mm?

[brumsky]

@Dclose and @Need4speed

Something to keep in mind, it's best to compare b frame to b frame from the source and your encodes. Try using something like AvsPmod. You'll need to add .ffinfo(cfrtime=false,vfrtime=false,version=false,colorspace=false,colorrange=false,cropping=false,sar=false) to your script. This will show you what type of frames you are comparing. You shouldn't compare mismatched frame types. Source I vs encode B for a worst case scenario.

[Dclose]

b frames are for compression not quality. I & P frames have higher bit rates and quality.
In a complicated scene involving jungle, fine dirt, and a dozen people, people walking left to right in the background looked better with 10 b-frames than with fewer b-frames.

I don't write the manual for this stuff. I just run test clips and look for the differences. *shrug*

[brumsky]

In a complicated scene involving jungle, fine dirt, and a dozen people, people walking left to right in the background looked better with 10 b-frames than with fewer b-frames.

I don't write the manual for this stuff. I just run test clips and look for the differences. *shrug*

How do you know you were looking at b frames and not p frames or even I frames?

[Midzuki]

How do you know you were looking at b frames and not p frames or even I frames?

Possibly with Elecard HEVC Analyzer :)

[pingfr]

Possibly with Elecard HEVC Analyzer :)

Got a download link for that matey? ;)

[Dclose]

How do you know you were looking at b frames and not p frames or even I frames?
If one minute of video looks different than another one minute of video, and the only thing changed is the x265 b-frame setting, I'm going to assume the difference in video has something to do with the b-frame setting.

[need4speed]

@Dclose

Yeah I'm not a fan of rdoq 1, I think 2 is better.

I'll have to test MM again, I know the last time I did it it looked better. That was at 1080p with a "healthy" bitrate.

b frames are for compression not quality. I & P frames have higher bit rates and quality.

@need4speed
what settings did you use for ref and mm?
'Morning.
Actually last encode from an Amazon webrip (approx 13k kbs avc) was made with 5 ref and 5 bframes. I have left untouched max merge. Can't really tell why but it looks a bit better, somehow clearer image and dust in the air looks better.
Good tips, thanks.
What about early skip in this context?

Inviato dal mio GT-N7100 utilizzando Tapatalk

[brumsky]

@Dclose

Sounds good...

@Neef4speed

Glad to hear it! try ref 6 and let me know what you think.

[need4speed]

@Dclose

Sounds good...

@Neef4speed

Glad to hear it! try ref 6 and let me know what you think.
Will try ref6 for sure, what do you thinks of early-skip? To be enabled?

[brumsky]

Will try ref6 for sure, what do you thinks of early-skip? To be enabled?

I used to us it about a year ago before I started comparing b frames.

What kind of CPU do you have again?

If you're looking to speed up encodes try adding these settings.

--ctu 32 generally provides better quality and is noticeable faster. I use it on almost every encode. My exceptions would be high CRF,14-16, encodes that I want a bit more compression.

--qg-size <CTU/2> So if your running ctu 32, then it's 16. Faster and generally better quality but less compression.

Also you may want to take another look at --deblock. I did a shit ton of tests with it and settled on --deblock -3:0. The first param is it's strength, second is how many pixels it affects. I found that negative numbers for the 2nd param, pulls the deblock to far from the edge of the block. basically defeating the purpose of using it. I tested disabling deblock and didn't like the outcome.

Try adding these settings: --ref 6 --ctu 32 --qg-size 16
It should be a bit faster and give better quality.

[need4speed]

I used to us it about a year ago before I started comparing b frames.

What kind of CPU do you have again?

If you're looking to speed up encodes try adding these settings.

--ctu 32 generally provides better quality and is noticeable faster. I use it on almost every encode. My exceptions would be high CRF,14-16, encodes that I want a bit more compression.

--qg-size <CTU/2> So if your running ctu 32, then it's 16. Faster and generally better quality but less compression.

Also you may want to take another look at --deblock. I did a shit ton of tests with it and settled on --deblock -3:0. The first param is it's strength, second is how many pixels it affects. I found that negative numbers for the 2nd param, pulls the deblock to far from the edge of the block. basically defeating the purpose of using it. I tested disabling deblock and didn't like the outcome.

Try adding these settings: --ref 6 --ctu 32 --qg-size 16
It should be a bit faster and give better quality.

I7 3700 and to be honest it still works ok since I'm not after perfection :)
For starters I have tried to raise maxmerge and, well, again personally speaking the difference is not worth a 8/9 to 4/5 fps speed drop.
Raising ref and bframes to 5 was a good hint, so thanks also for this.
Deblock..went through a lot of testing in the past months and, to be honest, ended up leaving disabled. Again, my own personal opinion.
Bottom line is that I try to keep things simple, with an eye on speed and not worrying much about final size (happy if files are 30% lighter). By keeping simple I must admit my ignorance, too many parameters to play around with and, also reading over and over white papers, I am all but sure what each one does in combination with others.
Basically I am alost there in terms of speed/details/quality, but at times there's still the impression to look at things through a window, so to speak. Clean glass but there's still something that doesn't match AVC final result. Would need a dehaze filter like in Lightroom :)
What it still amazes me is how a couple of tweaks (leaving CRF alone) can make a file the half or the double. In there past three days I have had an output of 890megs or 1,9 gigs out of the same original file!
Whatever, I will try to go back and retouch CTU and QG size and see if with latest releases the benefit is worth additional tweaking.
now will try to leave everything as is and run a second encode with early-skip enabled.
Thanks again!

[Motenai Yoda]

I used to us it about a year ago before I started comparing b frames.
--ctu 32 generally provides better quality and is noticeable faster. I use it on almost every encode.
--qg-size <CTU/2> So if your running ctu 32, then it's 16. Faster and generally better quality but less compression.
I tested a lot and imho
b-frames 3-8 don't change too much as the total number of b per gop is about the same
ctu 32 isn't better/faster than 64
qg-size don't has to be ctu/s, ctu 64 + qg-size 8 is legit
reference > 4 can be over level 4/4.1 so you lose compatibility with a lot of hw decoders.

[brumsky]

I7 3700 and to be honest it still works ok since I'm not after perfection :)
For starters I have tried to raise maxmerge and, well, again personally speaking the difference is not worth a 8/9 to 4/5 fps speed drop.
Raising ref and bframes to 5 was a good hint, so thanks also for this.
Deblock..went through a lot of testing in the past months and, to be honest, ended up leaving disabled. Again, my own personal opinion.
Bottom line is that I try to keep things simple, with an eye on speed and not worrying much about final size (happy if files are 30% lighter). By keeping simple I must admit my ignorance, too many parameters to play around with and, also reading over and over white papers, I am all but sure what each one does in combination with others.
Basically I am alost there in terms of speed/details/quality, but at times there's still the impression to look at things through a window, so to speak. Clean glass but there's still something that doesn't match AVC final result. Would need a dehaze filter like in Lightroom :)
What it still amazes me is how a couple of tweaks (leaving CRF alone) can make a file the half or the double. In there past three days I have had an output of 890megs or 1,9 gigs out of the same original file!
Whatever, I will try to go back and retouch CTU and QG size and see if with latest releases the benefit is worth additional tweaking.
now will try to leave everything as is and run a second encode with early-skip enabled.
Thanks again!

I was just curious what CPU you were running that's all. It's not AVX2 so CTU 64 will receive a performance penalty because of that.

Give the other options a try it'll be a little faster. Don't worry about max merge, ref 6 will improve the quality and ctu 32 & qg-size 16 will speed it up.

[brumsky]

I tested a lot and imho
b-frames 3-8 don't change too much as the total number of b per gop is about the same
ctu 32 isn't better/faster than 64
qg-size don't has to be ctu/s, ctu 64 + qg-size 8 is legit
reference > 4 can be over level 4/4.1 so you lose compatibility with a lot of hw decoders.

Your right increased b frames won't make a huge difference but it does affect the outcome.

CTU 32 is absolutely faster than ctu 64 especially for non-AVX2 CPUs like the 3700 - hence why I asked what CPU he has.

I never said qg-size has to be ctu/2. I said that is what I like to do. it is a compression\speed trade off.

This is the first I've ever heard of ref > 4 can be over any level. The levels 4 & 4.1 are for other things like bitrates & resolutions. You're thinking of ref > 8 which the encoder generates a error and exits, unless you specify --allow-non-conformance.

Taken from the docs:
Note that x265 allows up to 16 L0 references but the HEVC specification only allows a maximum of 8 total reference frames. So if you have B frames enabled only 7 L0 refs are valid and if you have --b-pyramid enabled (which is enabled by default in all presets), then only 6 L0 refs are the maximum allowed by the HEVC specification. If x265 detects that the total reference count is greater than 8, it will issue a warning that the resulting stream is non-compliant and it signals the stream as profile NONE and level NONE and will abort the encode unless --allow-non-conformance it specified. Compliant HEVC decoders may refuse to decode such


Read this for a quick review on Levels.

https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels

[Jamaika]

Recently one thing I am wondering. When converting yuv 422 10bit for the preset veryslow I have a darker film. For x264 10bit (selur) is fine.
Too bad, apparently the codec does so, but from the curiosity I changed the preset medium and it is correct. Interesting.

[Ma]

Recently one thing I am wondering. When converting yuv 422 10bit for the preset veryslow I have a darker film. For x264 10bit (selur) is fine.
Too bad, apparently the codec does so, but from the curiosity I changed the preset medium and it is correct. Interesting.

Could you specify your command line and sample video to reproduce?

[Jamaika]

ffmpeg.exe -loglevel error -i rgb.avi -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=pc:out_color_matrix=bt2020_nc:out_range=pc,format=yuv422p10le -strict -1 - |
x265-10b.exe --y4m --input-csp i422 --input-depth 10 --output-depth 10 --preset medium/veryslow --fps 29.970 --keyint 60 --info --no-open-gop --no-hrd --bitrate 6000
--colormatrix bt2020nc --range full --limit-tu 0 --output "output.h265" -
I mean that the colors are more dull, unnatural.
Codec:http://msystem.waw.pl/x265/x265-2.3+25-6e1edaf_gcc63.7z

[sneaker_ger]

Sample files and maybe screenshots that show the difference?

[Ma]

I mean that the colors are more dull, unnatural.

In my tests movie with --preset medium has bitrate 6005.89 kb/s, with preset veryslow 5180.42 kb/s. My movie is from 6 jpeg (each is repeated 10 times) and there is no problem with quality.

I think that your problem maybe is related with special source -- could you copy encoders outputs (my is for example)f:\speed\422>ffmpeg.exe -loglevel error -i img%02d.jpg -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=pc:o
ut_color_matrix=bt2020_nc:out_range=pc,format=yuv422p10le -strict -1 - | x265-10b.exe --y4m --input-csp i422 --fps 8 --input-d
epth 10 --output-depth 10 --preset medium --keyint 60 --info --no-open-gop --no-hrd --bitrate 6000 --colormatrix bt2020nc --rang
e full --limit-tu 0 --output "om.hevc" -
y4m [info]: 1920x1080 fps 8000/1000 i422p10 sar 9:10 unknown frame count
raw [info]: output file: om.hevc
x265 [info]: HEVC encoder version 2.3+25-6e1edafd6dc7
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:2:2 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 2 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 6 / 60 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 20 / 4 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 3 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-6000 kbps / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 rskip signhide tmvp strong-intra-smoothing
x265 [info]: tools: lslices=6 deblock sao
x265 [info]: frame I: 6, Avg QP:8.44 kb/s: 59906.54
x265 [info]: frame P: 18, Avg QP:15.30 kb/s: 28.33
x265 [info]: frame B: 36, Avg QP:18.50 kb/s: 11.23
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 45.8% 12.5% 8.3% 12.5% 20.8%

encoded 60 frames in 13.26s (4.52 fps), 6005.89 kb/s, Avg QP:16.53

f:\speed\422>ffmpeg.exe -loglevel error -i img%02d.jpg -an -f yuv4mpegpipe -vf scale=1920:1080:in_color_matrix=rgb:in_range=pc:o
ut_color_matrix=bt2020_nc:out_range=pc,format=yuv422p10le -strict -1 - | x265-10b.exe --y4m --input-csp i422 --fps 8 --input-d
epth 10 --output-depth 10 --preset veryslow --keyint 60 --info --no-open-gop --no-hrd --bitrate 6000 --colormatrix bt2020nc --ra
nge full --limit-tu 0 --output "ov.hevc" -
y4m [info]: 1920x1080 fps 8000/1000 i422p10 sar 9:10 unknown frame count
raw [info]: output file: ov.hevc
x265 [info]: HEVC encoder version 2.3+25-6e1edafd6dc7
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 4:2:2 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 6 / 60 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-6000 kbps / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: rskip signhide tmvp b-intra strong-intra-smoothing deblock
x265 [info]: tools: sao
x265 [info]: frame I: 6, Avg QP:9.72 kb/s: 51056.41
x265 [info]: frame P: 10, Avg QP:14.63 kb/s: 401.45
x265 [info]: frame B: 44, Avg QP:19.23 kb/s: 10.73
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: Weighted B-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 50.0% 0.0% 0.0% 25.0% 0.0% 0.0% 0.0% 0.0% 25.0%

encoded 60 frames in 55.98s (1.07 fps), 5180.42 kb/s, Avg QP:17.51
or even better sample source?

[raymondjpg]

2-pass or --tune grain (1-pass). Which of these two options is likely to deliver the best quality improvement over 1-pass (without --tune grain)? Using both together takes forever.

[Boulder]

--tune grain omits --rskip. Try adding that one back and see what happens both performance and quality-wise. I use it with --tune grain and have not noticed any difference in the quality of the result.

[Jamaika]

I think that your problem maybe is related with special source -- could you copy encoders outputs (my is for example)
Sorry. I have a problem with the player. I have to reinstall and install the latest lavvideo.

[raymondjpg]

--tune grain omits --rskip. Try adding that one back and see what happens both performance and quality-wise. I use it with --tune grain and have not noticed any difference in the quality of the result.
Thanks for the tip. That certainly speeds things up, but my original question remains. Say for argument, with the same bitrate set, which of the two options - 2-pass or --tune grain (1-pass) - is likely to deliver the best quality improvement over 1-pass (without --tune grain)? Put another way, does 2-pass deliver anything like the quality improvement benefit ascribed to --tune grain? If it doesn't, then I could resort to just using --tune grain with or without --rskip.

[LigH]

For 1-pass, you better don't set a bitrate, but a quality level (CRF) instead. A 1-pass encoding with constant/average bitrate will not distribute the quality optimally.

Grain tuning changes the behaviour of the encoder in several ways. It moves the focus towards elements with higher frequencies, taking available bitrate from the lower frequency parts of the image – which are usually responsible for the base quality of the whole frame. If you want to keep the bitrate in the same range as without, enabling grain tuning will probably give you more details (including noise) at the cost of more compression artifacts.

2-pass encoding is only important if you want to approach a specific size or stay below a maximum bitrate (in conjunction with VBV parameters). If you have no size or bitrate restrictions, there is no need for it. Just complying to VBV restrictions is even possible in a 1-pass encoding mode. 2-pass encoding is no alternative to grain tuning; the encoder behaves differently. A 1-pass CRF encoding and a 2-pass encoding with the same final size will have almost the same quality distribution; grain tuning will look differently to both of them.

[raymondjpg]

For 1-pass, you better don't set a bitrate, but a quality level (CRF) instead. A 1-pass encoding with constant/average bitrate will not distribute the quality optimally.

Grain tuning changes the behaviour of the encoder in several ways. It moves the focus towards elements with higher frequencies, taking available bitrate from the lower frequency parts of the image – which are usually responsible for the base quality of the whole frame. If you want to keep the bitrate in the same range as without, enabling grain tuning will probably give you more details (including noise) at the cost of more compression artifacts.

2-pass encoding is only important if you want to approach a specific size or stay below a maximum bitrate (in conjunction with VBV parameters). If you have no size or bitrate restrictions, there is no need for it. Just complying to VBV restrictions is even possible in a 1-pass encoding mode. 2-pass encoding is no alternative to grain tuning; the encoder behaves differently. A 1-pass CRF encoding and a 2-pass encoding with the same final size will have almost the same quality distribution; grain tuning will look differently to both of them.
Thanks for that explanation. I have found CRF to be preferable as far as quality is concerned, but resulting file size is variable depending on the complexity and detail of the source material. I mostly recompress for archiving so prefer to limit file size by setting an ABR.

Until recently I gave been recompressing using ABR with H264 limited to --threads 4, and my understanding is that 2-pass with H264 does not deliver any significant quality improvement over single pass.

However I have read that 2-pass encoding can give up to 18% quality improvement over a single pass with H265, so is that right?

[LigH]

1-pass CRF and 2-pass VBR with the same target size will have very similar results. This will be true for both x264 and x265 encoders. I am not sure if x265 will behave noticably different than x264 when comparing a 1-pass CRF result with a 2-pass VBR result of the same size (and I don't understand how you would measure a quality difference to be 18%, as quality is subjective) ... but I am quite sure that for both encoders, a 1-pass ABR encode will not have an optimal quality distribution, as it is rather focused on a less varying bitrate (e.g. useful for the constraints of a limited bandwidth and limited decoding buffer).

[raymondjpg]

1-pass CRF and 2-pass VBR with the same target size will have very similar results. This will be true for both x264 and x265 encoders. I am not sure if x265 will behave noticably different than x264 when comparing a 1-pass CRF result with a 2-pass VBR result of the same size (and I don't understand how you would measure a quality difference to be 18%, as quality is subjective) ... but I am quite sure that for both encoders, a 1-pass ABR encode will not have an optimal quality distribution, as it is rather focused on a less varying bitrate (e.g. useful for the constraints of a limited bandwidth and limited decoding buffer).
Thanks. I think I'm convinced now that a 2-pass H265 encode is likely to be preferable to a single pass ABR encode set at the same bitrate, and that is where a quality improvement however it is determined or perceived would come in.

[x265_Project]

If you're doing 2 pass encodes, I would suggest that you try our new --multi-pass-opt-distortion option. Without this option, x265 will simply normalize quality on a frame-by-frame basis. With --multi-pass-opt-distortion, x265 will also adjust quality within each frame, on a block-by-block basis, by analyzing the quality of each encoded block from the first pass compared to the source video, increasing the quality of blocks with abnormally high distortion, borrowing bits from blocks with below-average distortion (higher than average quality). So, basically, --multi-pass-opt-distortion is a finer-grained version of 2 pass, where we are leveling quality spatially as well as temporally. We look forward to your feedback.

[Boulder]

Just wondering, are there pending quality improvements in the 10-bit lambda tables? I have a longish queue of stuff to process but I'd like to hold them if there is something in the pipeline for the near future.

[x265_Project]

Just wondering, are there pending quality improvements in the 10-bit lambda tables? I have a longish queue of stuff to process but I'd like to hold them if there is something in the pipeline for the near future.
Yes. Soon. Some time next week.

[Boulder]

Yes. Soon. Some time next week.Thank you for the information, it's much appreciated :)

[Barough]

x265 v2.3+28-08a05ca9fd16 (http://www44.zippyshare.com/v/49We8PLL/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+28-08a05ca9fd16
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[aegisofrime]

Yes. Soon. Some time next week.

While we are on topic, are the tables for 12-bit coming at the same time? No pressure :)

[need4speed]

Hi again, I have been playing around a lot with CRF lately so question would be: there is any way to roughly predict the average final video kbs starting from original kbs, duration and qcomp or whatever else?
All same settings and crf but:
Example 1 : 40 mins, 9000 kbs I end up with 2300kbs hevc file.
Example 2 : 40 mins, 13000 kbs I end up with 4900 kbs 2.4 gigs.
I fully understand how crf works but wondering if 9000 to 2300 kbs might mean loose too much quality.


Inviato dal mio GT-N7100 utilizzando Tapatalk

[LigH]

No panic. You understood CRF? Then you understood that it will use only as much bitrate as the video material needs to preserve "enough" quality.

40 minutes of action, motion, details: High bitrate is required.

40 minutes of stills, slack, blur: Low bitrate is sufficient.

[need4speed]

No panic. You understood CRF? Then you understood that it will use only as much bitrate as the video material needs to preserve "enough" quality.

40 minutes of action, motion, details: High bitrate is required.

40 minutes of stills, slack, blur: Low bitrate is sufficient.
Thanks as usual Ligh,
No panic at all and I must admit the perceived quality is satisfactory as expected.
Was just wondering if there was any way to somehow have a rough idea about final kbs. Out of curiosity, really.
I am about to encode the whole Heroes br set but will wait for 10bits new tables.
Any suggestion for grainy old videos? Somehow heroes videos are grainy and noisy, wondering if the tune grain might help here

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Natty]

currently using these settings for 1080p content and i am impressed with the results. getting low fps though.

--pass 1 --bitrate 3333 --output-depth 10 --rd 4 --rdoq-level 2 --aq-mode 3 --qcomp 1 --multi-pass-opt-analysis --multi-pass-opt-distortion --aq-motion --subme 5 --me star --bframes 8 --rc-lookahead 60 --lookahead-slices 5 --ref 6 --min-keyint 20 --keyint 400 --no-strong-intra-smoothing --no-constrained-intra --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --hdr --vui-timing-info --vui-hrd-info --opt-cu-delta-qp --multi-pass-opt-rps --deblock -3:0 --psy-rd 4 --psy-rdoq 8 --opt-qp-pps --opt-ref-list-length-pps

i need comments of experts on this.

:script:

[sneaker_ger]

qcomp 1?

[x265_Project]

currently using these settings for 1080p content and i am impressed with the results. getting low fps though.

--pass 1 --bitrate 3333 --output-depth 10 --rd 4 --rdoq-level 2 --aq-mode 3 --qcomp 1 --multi-pass-opt-analysis --multi-pass-opt-distortion --aq-motion --subme 5 --me star --bframes 8 --rc-lookahead 60 --lookahead-slices 5 --ref 6 --min-keyint 20 --keyint 400 --no-strong-intra-smoothing --no-constrained-intra --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --hdr --vui-timing-info --vui-hrd-info --opt-cu-delta-qp --multi-pass-opt-rps --deblock -3:0 --psy-rd 4 --psy-rdoq 8 --opt-qp-pps --opt-ref-list-length-pps

i need comments of experts on this.

:script:

Are you running 2 passes? If not you don't need --pass 1 or --multi-pass-opt-analysis. You're heavily modifying our default (--preset medium) settings. We recommend you stick with one of our presets, which represent a fairly optimal tradeoff of speed for quality.

For example, you're increasing the # of reference frames from the default setting of 3 frames to --ref 6. This is a big waste of time. You'll get diminishing returns (in terms of quality for the speed impact) with each additional reference frame, and almost no improvement above 4 ref frames. You'll get a better overall result just by moving to a higher quality preset, like --preset slow.

There is no need to use --hdr when you're not encoding high dynamic range content.

[Natty]

Are you running 2 passes? If not you don't need --pass 1 or --multi-pass-opt-analysis. You're heavily modifying our default (--preset medium) settings. We recommend you stick with one of our presets, which represent a fairly optimal tradeoff of speed for quality.

For example, you're increasing the # of reference frames from the default setting of 3 frames to --ref 6. This is a big waste of time. You'll get diminishing returns (in terms of quality for the speed impact) with each additional reference frame, and almost no improvement above 4 ref frames. You'll get a better overall result just by moving to a higher quality preset, like --preset slow.

There is no need to use --hdr when you're not encoding high dynamic range content.

yes its 2 pass. and what about the rest of the settings and qcomp 1? i observed that qccomp 1 helps in retaining grain more. maybe just my illusion.

[elahn]

There's been talk about x265 Grain setting lately, and that can help, but it also can overdo it. Lower the two Psy amounts to get more of a Film setting than a Grain setting.

I've been using --tune grain and this is interesting. Would you still use --tune grain, but override the default psy-rd=4.00 psy-rdoq=10.00? By how much would you lower them? I don't really care about grain, but I do want good detail retention.

If one minute of video looks different than another one minute of video, and the only thing changed is the x265 b-frame setting, I'm going to assume the difference in video has something to do with the b-frame setting.

Are you using ABR or 2-pass? If so, increased compression due to b-frames would free up extra bits to be used for increased quality.

While it's very useful, I question the general methodology of using ABR or 2-pass for an apples to apples comparison of all parameters. In this case, wouldn't any parameter that increases compression create surplus bits and thus increase quality?

For CRF encodes, I'd like to know which options in the slow/slower/very slow/placebo presets increase quality/detail retention, which increase compression and which can do both.

Personally, the slow preset gives me plenty of compression and most of the time I'm happy with medium preset compression-wise. I am willing to pay for increased quality with slower encoding, but I'd usually prefer to pay for it with increased bitrate (when necessary, not globally). I'm currently investigating rdLevel, references, tu-intra-depth, tu-inter-depth, amp and rc-lookahead... Any insight (in relation to CRF) would be appreciated. IIUC bframes, b-intra and weightb affect compression not quality.

Thanks @x265_Project, it's good to know that ref > 4 gives almost no improvement.

For context, I use: --crf 20 --preset slow --tune grain --profile main10 --no-strong-intra-smoothing --deblock -3:0 --rskip --ctu 32 (no AVX2, 2 core/4 threads 2.1ghz)

[Natty]

Are you running 2 passes? If not you don't need --pass 1 or --multi-pass-opt-analysis. You're heavily modifying our default (--preset medium) settings. We recommend you stick with one of our presets, which represent a fairly optimal tradeoff of speed for quality.

For example, you're increasing the # of reference frames from the default setting of 3 frames to --ref 6. This is a big waste of time. You'll get diminishing returns (in terms of quality for the speed impact) with each additional reference frame, and almost no improvement above 4 ref frames. You'll get a better overall result just by moving to a higher quality preset, like --preset slow.

There is no need to use --hdr when you're not encoding high dynamic range content.


yes its a 2 pass encode in staxrip. what about the rest of my settings like qcomp 1? observed that it helps in retaining more grain, maybe just my illusion.

[Krautmaster]

oh, wow, I wish somewone would look at my custom line as well.

I am using handbrake nightly righty now, seem they include the 2.3 version of x265 too. Im transcoding 30GB x264 material to few GB for direct streaming with plex. Single pass. Quality mode. 5.1 opus audio @ 320 kb/s.
My params are:

1. medium preset
+
rc-lookahead=32:ssim-rd=1:ctu=32:crf=23:pbratio=1.22:subme=3:aq-mode=3:aq-strength=1.2:qcomp=0.64:no-sao=1:level-idc=4.1:high-tier=1:rd=4:psy-rd=2.5:psy-rdoq=3.5:rdoq-level=2:bframes=8:no-strong-intra-smoothing=1:weightb=1:b-intra=1:rect=1:limit-modes=1:rskip=1

thanks for testing and commenting!

I tried grain tune as well but that really sucks, very blocky in dark areas which my line does pretty well up there. You guys may try. I get 10-12 FPS with it , on a ryzen as well on a i7 5820K @ 4,3 Ghz.

[need4speed]

Hi again,
first off thanks to everybody for all the hints, finally managed to get the speed/quality I was looking for.
Same topic but a bit different: any special hint or tweak for animated contents/anime? 1080p.
TIA

[need4speed]

For example, you're increasing the # of reference frames from the default setting of 3 frames to --ref 6. This is a big waste of time. You'll get diminishing returns (in terms of quality for the speed impact) with each additional reference frame, and almost no improvement above 4 ref frames. You'll get a better overall result just by moving to a higher quality preset, like --preset slow.


Just my two cents really, but have experimented a lot lately and my personal experience is that 6 ref frames and 8 bframes are a total waste of time.
Wondering why leaving SAO active, as for deblock I have had mixed results but at the end of the day I disable it, together with SAO and Strong Intra smoothing.
As for qcomp1 really no idea, my default is 0.7 and going above have given me absolutely no benefit.

[benwaggoner]

How do you know you were looking at b frames and not p frames or even I frames?
If you are looking a single frames, you're not watching video anyway. I strongly feel that video quality only matters when it's moving at the fps that end users will see it at.

[benwaggoner]

Just my two cents really, but have experimented a lot lately and my personal experience is that 6 ref frames and 8 bframes are a total waste of time.
They can matter a lot if trying to get the best quality at a given bitrate, instead of just trying to get the best quality regardless of bitrate.

Wondering why leaving SAO active, as for deblock I have had mixed results but at the end of the day I disable it, together with SAO and Strong Intra smoothing.
As for qcomp1 really no idea, my default is 0.7 and going above have given me absolutely no benefit.
Also features that are useful when trying to maximize quality at a given bitrate.

[benwaggoner]

Are you using ABR or 2-pass? If so, increased compression due to b-frames would free up extra bits to be used for increased quality.

While it's very useful, I question the general methodology of using ABR or 2-pass for an apples to apples comparison of all parameters. In this case, wouldn't any parameter that increases compression create surplus bits and thus increase quality?
Well, yes, freeing up bits from where they aren't needed in order to spend them where they are is why codecs have psychoviual models and rate distortion optimization.

It does get down to what are the independent and dependent variables. I prefer testing at fixed bitrate or file size so that the independent variable(s) are the ones I am testing. Testing with CRF means both quality AND file size are changing together. Which makes sense if trying to tune for quality irrespective of file size, but not if trying to tune for optimal quality given a bitrate or file size constraint.

Tests and comparisons are always specific to a given context. So it's important to know what are your apples and what are other fruit.

[benwaggoner]

Thanks for that explanation. I have found CRF to be preferable as far as quality is concerned, but resulting file size is variable depending on the complexity and detail of the source material. I mostly recompress for archiving so prefer to limit file size by setting an ABR.
If you want to do CRF with a max file size, set --vbv-maxrate to the maximum bitrate you want to use, and --vbv-bufsize to something reasonable, and no more than the max allowed by Profile @ Level.

That will give you output that never exceeds --vbv-maxrate, but will use lower bitrates than that if your CRF target can be achieved at a smaller file size

[need4speed]

They can matter a lot if trying to get the best quality at a given bitrate, instead of just trying to get the best quality regardless of bitrate.


Also features that are useful when trying to maximize quality at a given bitrate.
Didn't mean to sound rude, sorry.
Thing is hevc is becoming more and more popular and worth it but personally speaking maxing out all settings and getting 3 fps or so is good for testing and for sure final results are worth the wait but the difference is so clear?
Nothing against endless encoding but in this forum we read about mixed results.
Quality is a personal perception beyond some point and 3 or 6 fps does make a difference for most of ppl I guess.
Hope this clears up my previous post!

Inviato dal mio GT-N7100 utilizzando Tapatalk

[brumsky]

If you are looking a single frames, you're not watching video anyway. I strongly feel that video quality only matters when it's moving at the fps that end users will see it at.

I agree for the most part. However, I do feel that comparing b frame to b frame has its role though.

[brumsky]

They can matter a lot if trying to get the best quality at a given bitrate, instead of just trying to get the best quality regardless of bitrate.


This is typically my goal, max quality per bit. I don't like just throwing bitrate at an encode just because. For example, if <5% increase in quality costs 20-25% more bitrate, then it's not worth it to me.

I've chased near perfect transparency, in b frames, before which resulted in encodes 50% larger. However, when played side by side it was very difficult to see the difference.

So both playback & b frame comparisons have their place - IMO.

[Krautmaster]

Hi guy, new here!

1st: sound is a good point. It easily made 30% until I noticed that something is wrong with my Video Quali / result size thing. With passing several GB of DTS HD tracks that made sence :)

2nd: I found the grain tune prerset and default to blocky in dark scenes.

3rd: I tried 30 movies the last two days and finally I use this params:

rc-lookahead=32:ssim-rd=1:ctu=32:crf=23:pbratio=1.22:subme=3:aq-mode=3:aq-strength=1.2:qcomp=0.64:no-sao=1:level-idc=4.1:high-tier=1:rd=4:psy-rd=2.5:psy-rdoq=3.5:rdoq-level=2:bframes=8:no-strong-intra-smoothing=1:weightb=1:b-intra=1:rect=1:limit-modes=1:rskip=1

+high quality sound by Opus 7.1 @ 320 kb/s. Kodi does well by HDMI + my 7.1 AV. Bare medium preset is fine but dark stuff is blocky. Would be interesting what "x265_Project" would think abt those params. :)

... above setting brings good quali in dark scenes ... that was the main issue to me. I have some movies which scales badly but most are around 5GB.
feel free to test and report please.

Edit: for batch jobs Im using handbrake nightly. Seems to use x265 2.3. Fine? Disadvantages? The setting above does ~10 FPS at a awesome qualiy, way better than the same with grainy tune, in terms of detail and all. I focus on 1pass encoding + HQ dark scenes + good quality / Site.

If someone needs a daily fresh master build of ffmpeg - I build them here:
https://1drv.ms/f/s!Ar_eIBtD4lGqg85_iDGvRCjP6xkc7g

[Selur]

Add dynamic rate-control reconfiguration
and this is intended to do what?

[LigH]

I suspect a feature not for a CLI encoder recoding one file, but rather for an integrated solution encoding live footage.

Or maybe, who knows ... zones support?

[Selur]

@LigH: Zones are supported for quite some time -> http://x265.readthedocs.io/en/latest/cli.html?highlight=zones#cmdoption-zones
But you might be right with the changing of the rate control during live encoding through the API and it really doesn't look like anything intended for CLI. :)
-> so probably not that interesting for normal users.

[x265_Project]

and this is intended to do what?

Dynamic rate control is only useful through the x265 API. It is for live encoding applications where you need to change the target bit rate on the fly, such as when the channel bandwidth varies, or for statistical multiplexing (statmux) of multiple video channels through a single transmission channel.

Statmux is a technique designed to maximize quality by taking advantage of the fact that while the complexity of one video varies by a large degree over time, the average complexity of multiple video signals varies much less. If you encode one video with constant quality, you get a widely varying bit rate. If you encode one video with constant bit rate, you get widely varying quality. With statistical multiplexing, you can encode multiple video signals at a constant channel bit rate with something much closer to constant quality.

[Selur]

Thanks for the info. :)

[albt]

--tune grain omits --rskip. Try adding that one back and see what happens both performance and quality-wise. I use it with --tune grain and have not noticed any difference in the quality of the result.

i'm doing the same, --rskip only waste time.

[albt]

Hi guy, new here!

1st: sound is a good point. It easily made 30% until I noticed that something is wrong with my Video Quali / result size thing. With passing several GB of DTS HD tracks that made sence :)

2nd: I found the grain tune prerset and default to blocky in dark scenes.

3rd: I tried 30 movies the last two days and finally I use this params:

rc-lookahead=32:ssim-rd=1:ctu=32:crf=23:pbratio=1.22:subme=3:aq-mode=3:aq-strength=1.2:qcomp=0.64:no-sao=1:level-idc=4.1:high-tier=1:rd=4:psy-rd=2.5:psy-rdoq=3.5:rdoq-level=2:bframes=8:no-strong-intra-smoothing=1:weightb=1:b-intra=1:rect=1:limit-modes=1:rskip=1

+high quality sound by Opus 7.1 @ 320 kb/s. Kodi does well by HDMI + my 7.1 AV. Bare medium preset is fine but dark stuff is blocky. Would be interesting what "x265_Project" would think abt those params. :)

... above setting brings good quali in dark scenes ... that was the main issue to me. I have some movies which scales badly but most are around 5GB.
feel free to test and report please.

Edit: for batch jobs Im using handbrake nightly. Seems to use x265 2.3. Fine? Disadvantages? The setting above does ~10 FPS at a awesome qualiy, way better than the same with grainy tune, in terms of detail and all. I focus on 1pass encoding + HQ dark scenes + good quality / Site.

If someone needs a daily fresh master build of ffmpeg - I build them here:
https://1drv.ms/f/s!Ar_eIBtD4lGqg85_iDGvRCjP6xkc7g

aq-mode 3 and rskip is what i add in tune grain. i use psy-rd 2, psy-rdoq 4, rd-penalty 1 too.

[aymanalz]

i'm doing the same, --rskip only waste time.

To clarify, don't you mean NOT having --rskip wastes time?

[albt]

sorry, i mean --no-rskip.

[cojj]

Yes. Soon. Some time next week.
Has this been postponed? Would appreciate a simple update :) (simple update as in short message on the current status)

@LigH sorry for confusing you. I wish I was skilled enough haha

@aymanalz thank you for the clarification, that's what I meant!

[LigH]

If it was as simple as you believe, you could provide the patch... ;)

[aymanalz]

If it was as simple as you believe, you could provide the patch... ;)

I think he meant that a simple message would be appreciated, updating us on the progress. Not that the update of x265 itself is simple. Two different meanings for "update" - Updating the code, versus updating us about the progress.

[Barough]

x265 v2.3+30-c7b7c736696f (http://www88.zippyshare.com/v/XImWrLSA/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+30-c7b7c736696f
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Motenai Yoda]

into source\common\param.cpp
line 1432
++ BOOL(p->bSsimRd, "ssim-rd");
line 1532/1533
++ BOOL(p->bSsimRd, "ssim-rd");

[LigH]

I just noticed there isn't any userdata or cli output to check if ssim-rd is enabled or not.

That has been fixed hereby, I believe.

BTW, line 1432: "TOOLOPT(param->bSsimRd, "ssim-rd");"

[Magik Mark]

Guys,

Has the 10bit lamda released?

[LigH]

No. Go check the x265 commit log (https://bitbucket.org/multicoreware/x265/commits/all) before asking. ;)

[pingfr]

Out of sheer curiosity;

Are the presets defined in the docs available at https://x265.readthedocs.io/en/default/presets.html still "current" and accurate after the changes brought up at commit a0eee4b?

Thanks in advance.

[microchip8]

Out of sheer curiosity;

Are the presets defined in the docs available at https://x265.readthedocs.io/en/default/presets.html still "current" and accurate after the changes brought up at commit a0eee4b?

Thanks in advance.

x265_project said that due to the new lambda tables, presets need to be adjusted. I don't follow the commit history so I have no idea if this is done already. I suspect it is not yet

[Selur]

also doc about newest release is normally under http://x265.readthedocs.io/en/latest/ not https://x265.readthedocs.io/en/default/

[Motenai Yoda]

That has been fixed hereby, I believe.

BTW, line 1432: "TOOLOPT(param->bSsimRd, "ssim-rd");"

Asd I was so sleepy I pasted twice the same line

[Barough]

x265 v2.3+2.3+32-1ed218717877 (http://www76.zippyshare.com/v/tUu4Xqnt/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+32-1ed218717877
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

CLI: informs if '--ssim-rd' is used;
Add dynamic rate-control reconfiguration (API only);
Improved sao implementation by limiting sao types:
--[no-]limit-sao Limit Sample Adaptive Offset types. Default disabled

x265 2.3+32-1ed218717877 (https://www.mediafire.com/file/3j72g2ed5pl9og0/x265_2.3%2B32-1ed218717877.7z)

x265 2.3+28-08a05ca9fd16 (http://www.mediafire.com/file/56aq5t6zhlvqv26/x265_2.3%2B28-08a05ca9fd16.7z) (belated)
_

Makes me wonder: Is it possibly to summarize in simple terms which SAO types get disabled when limited, and which tradeoff between quality and speed can be reported by the developers ... and whether this will change presets?

[stax76]

@LigH

the change summary helps, thanks.


@x265_Project

there is a issue with the docs: http://x265.readthedocs.io/en/latest/cli.html#cmdoption-limit-sao

avs/vpy reader would still be useful...

[LigH]

there is a issue with the docs: http://x265.readthedocs.io/en/latest/cli.html#cmdoption-limit-sao

Forwarded this to the developer mailinglist.

[aymanalz]

Improved sao implementation by limiting sao types:
--[no-]limit-sao Limit Sample Adaptive Offset types. Default disabled

Interesting, I wonder if this would address the complaints against SAO on this thread, namely that it causes too much blurring.

[LigH]

From the description in the online docs (adaptive early opt-outs), I would only expect some speed-up with rather little optical difference. But I did not yet test, have little spare time and only old CPU's.

[NikosD]

@all

I did earlier today a test comparison of latest 2.3+33 x265 compilation using MS VC 2017 AVX/AVX2 optimized binaries from here http://msystem.waw.pl/x265/ on my two systems - a Sandybridge and a Haswell.

I tested different SIMD architectures using these parameters --crf 24 --preset medium --tune grain --ssim --psnr --pme on a 4K sample.

Sandybridge and Haswell gained almost the same using SSE2fast (61% for Sandy and 72% for Haswell) and SSE4(4.2) (77% for Sandy and 88% for Haswell)

The gain is compared against the previous SIMD architecture starting from --no-asm and going like this:
NO ASM, MMX2, SSE2fast, SSSE3, SSE4.2, AVX, AVX2, FMA3, FMA3 LZCNT, FMA3 LZCNT BMI2

MMX2 and AVX gives ~0% for both Intel architectures (Sandy and Haswell)

SSSE3 gives ~13% for both and AVX2 gives only 18% for Haswell compared to SSE4.2 (AVX gives nothing)

So, first myth busted.

x265 doesn't gain a lot using AVX2, only 18% on Haswell compared to SSE4.2

The huge advantage is using SSE2fast and even more using SSE4.2

Now, using FMA3 the performance drops to the level of SSE4.2.
It looses any gains of AVX2.

When adding LZCNT and BMI2 changes nothing.

ATTENTION to x265 developers.

You should put FMA3 SIMD architecture before AVX2, just like x264 does, because it drops performance a lot.
Or maybe remove it completely.

Using LZCNT and BMI2 add nothing to FMA3 performance.

@all

Please, confirm or deny my results because I think we have a major performance issue here.

[brumsky]

@NikosD

thank you for posting this information! I am going to run some of my own tests now!! ;)

[nevcairiel]

Now, using FMA3 the performance drops to the level of SSE4.2.
It looses any gains of AVX2.


I did a search through the sources, and I couldn't find a single function that uses FMA3, so it doesn't seem like much of a surprise if its not any faster.

As an additional point of information, the console output may list AVX2 first in the list, however if you set it to FMA3, it does not actually use AVX2.
It uses the logical implications that the CPUs implementing those usually full-fill, ie. a FMA3 CPU implements AVX and all the SSE's (and MMX, naturally), and thats what x265 uses. It only uses AVX2 if you tell it to use AVX2 (or don't tell it anything at all and let it use everything).

The "main" optimizations like MMX, SSE* and AVX/2 all work like that, they imply the ones that came before it, so if you set it to SSE4.1, it automatically activates everything from MMX to SSE4.1. FMA3/4 came after AVX, so they imply AVX - but they do not imply AVX2.

So sure, if they want to, they could re-order the listing of things to be in the same logical order, but its only a cosmetical issue only.
If you just run x265 without specifying simd features (which you should), there is no "slowdown" from FMA3.

To activate all options (ie. the default), you would need to specify "AVX2,FMA3,FMA4,XOP,LZCNT,BMI1,BMI2" - a bit uncomfortable to write out everytime. :) (Disclaimer: I do not know if BMI or LZCNT are ever used anywhere, but this is the full list of instructions the command line currently takes)
It looks like specifying options your CPU doesn't support might crash though, so care has to be taken.

[NikosD]

Yes, if by putting nothing next to x265 there is no drop in performance, then we are OK.

From my comparison tests both x265 and x264 should stop to AVX2 and remove completely FMA3, LZCNT and BMI2.

Using x264 I saw a small drop-off in performance using those instructions along with AVX2 compared to net AVX2.

So, for x264 you should definitely set explicitly --asm AVX2 and not let it to auto (nothing next to binary) because the performance drops.

Luckily we are writing to x265 thread and there is no drop in performance as you say using FMA3, LZXNT, BMI2.

Have you done the test to set --asm AVX2 using x265 and then auto (nothing next to x265) and see the difference ?

Better, null or worse ?

A reverse of FMA3 and AVX2 order would make things better or the removal of FMA3 and the other weird instructions would be best (if it drops performance)

[nevcairiel]

FMA3/4, LZCNT and BMI1 don't seem to have any functions, the only that exist are a few in BMI2 and a few in XOP. XOP was AMD only and Zen even dropped support for it again, so it can mostly be ignored entirely.
The BMI2 functions used are only 2 small functions, so their performance impact is probably negligble (could test --asm AVX2 vs --asm AVX2,BMI2).

Either way, all of those are very "special" instruction sets designed for a particular niche, and their performance advantage is often not very huge - but no reason not to use them if available. Hopefully the developers do test if they are faster on most major CPUs. :)
I only know how this works in FFmpeg, where such functions are typically tested on a variety of generations of CPUs when submitted as patches - I don't follow how development of x265 works for this.

[Natty]

so GCC 7.0 - SSE4.1 is the fastest ?

[nevcairiel]

so GCC 7.0 - SSE4.1 is the fastest ?

Personally I try to avoid pre-release compilers (which GCC 7 is).
People have also said MSVC is fater for them, fwiw, but I have not compared compilers

Generally, use whatever your CPU supports though, if it can do AVX(2), use that.

[Dclose]

There's posts lately about updates to 10-bit. I don't know if there were updates before that in the past months, but I've been trying it again after not using it for a while and am surprised at the results. 10-bit was always helpful particularly with color banding, but I avoided it in x265 because x265 is so slow.

Now trying it, it's like a slight layer of grease is removed from the screen and things are sharper. And, I'm not sure yet, but it may not have the big fps hit it had 6+ months ago.

Well, it is extremely slow on one of my computers for some reason. A 720p video is over 2fps using 10-bit. In my other desktop, 10-bit drops the fps to .5. Both are using updated Hybrid, both have similar components other than one has older (slower) hard drives which shouldn't matter at this low fps. Both have the same i7 3770k CPU and are doing 100% usage. The main difference is the faster one is Windows 8.1 64-bit and the slow one is Windows 7 32-bit. I don't know why that would matter, and only matter for 10-bit not for 8-bit, but something strange is happening with it when I turn 10-bit on. If anyone has ideas on that, I'm listening.

When is SSIM RD used? The Hybrid tooltip says it's only used for certain presets, and then says RD over 3. I swear checking the box on and off made a difference months ago when I tried it, but trying it now with most settings in x265 maxed out the file sizes come out the same whether it's on or off. I'm assuming it's not just a Hybrid error.

[mariush]

The 32bit version of x265 may lack some assembly optimizations that are present in the 64bit version of x265.

The 32bit version would also be more memory constrained, since it would be limited to 2-3 GB of memory... 64 bit versions wouldn't have such limitations.

[qyot27]

The 32bit version of x265 may lack some assembly optimizations that are present in the 64bit version of x265.
Close. It's actually that there is no support for high bit depth 32-bit builds, and doing so you have to turn the asm off completely. So 8-bit builds of x265 32-bit have assembly, >8-bit builds don't. 64-bit builds have assembly, regardless of bit depth.

https://github.com/videolan/x265/blob/master/source/CMakeLists.txt#L346
https://github.com/qyot27/mpv/blob/extra-new/DOCS/crosscompile-mingw-tedious.txt#L2406

[Dclose]

Close. It's actually that there is no support for high bit depth 32-bit builds, and doing so you have to turn the asm off completely. So 8-bit builds of x265 32-bit have assembly, >8-bit builds don't. 64-bit builds have assembly, regardless of bit depth.
It sounds like Windows 32-bit doesn't do ASM in 10-bit which means 10-bit that runs at over 2 fps on Windows 64-bit is going to run at .5 fps on Windows 32-bit.

Damn. And just when I was getting excited about using 10-bit again. Well, at least I know what the problem is now. Thanks, guys.

Regarding other things, I had posted about increasing the AQ Strength to get more detail. RDOQ2 instead of RDOQ1 lessened the need for that. Switching to RDOQ2 from 1 has helped fix various problems that I was trying to fix with band-aids like AQS and more PSY.

[LigH]

The reason not to implement assembler optimized routines in 32 bit x265 versions is that it would be a waste of development time. Bit depths >8 would require twice the amount of RAM compared to the 8 bit version (addressing 16 bit even if only 10 or 12 bits precision are relevant), and already the allocated memory for 8 bit depth may be too much to encode 1080p video with a 32 bit build, depending on the complexity (preset).

[x265_Project]

The reason not to implement assembler optimized routines in 32 bit x265 versions is that it would be a waste of development time. Bit depths >8 would require twice the amount of RAM compared to the 8 bit version (addressing 16 bit even if only 10 or 12 bits precision are relevant), and already the allocated memory for 8 bit depth may be too much to encode 1080p video with a 32 bit build, depending on the complexity (preset).
Contributions are always welcomed, but you're right... the effort to fully optimize the 32 bit version of x265 (8 bit encoding only) is tough to justify. x265 has hundreds of kernels that are SIMD optimized for various instruction sets, and it's a fairly substantial effort (many, many developer man-months).

[brumsky]

Any idea when we might see the 10bit lamda table? I'm dying to give it a try!!

[LigH]

There is light at the end of the tunnel: A patch for 10 and 12 bit lambda tables was proposed in the mailing list. So stay alert, new builds might appear soon™...

[Magik Mark]

[emoji106]


Sent from my iPhone using Tapatalk

[brumsky]

Awesome!!

[benwaggoner]

Interesting, I wonder if this would address the complaints against SAO on this thread, namely that it causes too much blurring.
It's "just" a performance optimization.

[benwaggoner]

The 32bit version of x265 may lack some assembly optimizations that are present in the 64bit version of x265.

The 32bit version would also be more memory constrained, since it would be limited to 2-3 GB of memory... 64 bit versions wouldn't have such limitations.
Beyond the lack of assembly optimization, x64 has double the number of registers as old x86 vanilla.

I'm always startled to find someone still using a 32-bit OS. I think all my systems have been 64-bit since Win 7 came out back in 2009. Living in 4 GB of RAM for video apps was impractical a long time ago. Adobe dropped 32-bit support in their video apps back in 2010. And 64-bit is generally faster and quite a bit more secure. 64-bit software decoders are generally faster than 32-bit versions as well.

I recommend folks upgrade to 64-bit OSes rather than trying to make x265 run better on 32-bit!

[x265_Project]

Haivision was one of the four original commercial sponsors of x265, and four years later, we can finally go public with this! They have been a terrific partner over the years, continually investing in x265 and UHDkit, to push the envelope of what is possible in a software encoder. Both Haivision and MulticoreWare will be demonstrating the latest capabilities of x265 and UHDkit at the NAB show next week.

Haivision to Demonstrate Breakthrough Performance of Live 4K HEVC/H.265 Software Encoding at 2017 NAB Show
http://www.haivision.com/news-events/news/haivision-to-demonstrate-breakthrough-performance-of-live-4k-hevch265-software

[qyot27]

Beyond the lack of assembly optimization, x64 has double the number of registers as old x86 vanilla.

I'm always startled to find someone still using a 32-bit OS. I think all my systems have been 64-bit since Win 7 came out back in 2009. Living in 4 GB of RAM for video apps was impractical a long time ago. Adobe dropped 32-bit support in their video apps back in 2010. And 64-bit is generally faster and quite a bit more secure. 64-bit software decoders are generally faster than 32-bit versions as well.

I recommend folks upgrade to 64-bit OSes rather than trying to make x265 run better on 32-bit!
I don't know how large the market for them really is, but there are plenty of small mini-PCs that still ship with 32-bit versions of Windows because the companies involved don't want to put larger (read: anything over 32GB) internal storage in them, even though they use x86-64 hardware platforms.

And because said machines are likely using 32-bit UEFI (the horror) (https://software.intel.com/en-us/blogs/2015/07/22/why-cheap-systems-run-32-bit-uefi-on-x64-systems), it's practically impossible to upgrade to 64-bit Windows without replacing the computer entirely. You can still run 64-bit Linux distributions on them (with varying levels of difficulty getting it set up right), since EFI mixed mode has been supported in the Linux kernel since version 3.15 (https://www.phoronix.com/scan.php?page=news_item&px=MTY0OTI).

Personal anecdote time: I'm typing this post out on one such mini-PC (the Quantum Byte, specifically). It's a perfectly capable little machine for casual encoding or media consumption, or mundane office tasks/web browsing, but it's obviously not going to be used for serious encoding tasks. If I really want to squeeze it for performance and 64-bit usage, I did manage to get 64-bit Ubuntu installed to a USB stick and can boot from that when I need to (but running the OS through a USB 2.0 port is not exactly ideal for speed; probably negates all of the benefits 64-bit would've gotten me). It runs on the Atom Z3735F Bay Trail-T/Silvermont platform, so extrapolate whatever speed estimates you can there. It's good enough to bide my time until Coffee Lake arrives and I build something to replace the ancient Coppermine tower I'd been using as my main setup before I got the Byte. Provided Coffee Lake has AVX-512, anyway; there's been conflicting reports about that.

[Dclose]

I'm always startled to find someone still using a 32-bit OS. I think all my systems have been 64-bit since Win 7 came out back in 2009. Living in 4 GB of RAM for video apps was impractical a long time ago.
Windows 7 OS uses less than a gb. Encoding mostly relies on CPU. X265 was working great until I wanted to use 10-bit. Windows 7 32-bit works as well for video on my HTPC as it did when I first put it together years ago.

Though the main reason 32-bit 7 is on there is because the TV tuner cards in it don't have a driver that works with 64-bit except 64-bit Vista.

Anyway, can anyone explain when SSIM RD setting is used? Sometimes it kicks in when changing only that setting, and sometimes the file size remains the same. It says it's only used on certain presets. Does x265 have to have a preset selected for SSIM RD to be used at all?

[sneaker_ger]

https://x265.readthedocs.io/en/default/cli.html#cmdoption-ssim-rd
https://x265.readthedocs.io/en/default/presets.html

[benwaggoner]

Windows 7 OS uses less than a gb. Encoding mostly relies on CPU. X265 was working great until I wanted to use 10-bit. Windows 7 32-bit works as well for video on my HTPC as it did when I first put it together years ago.
CPUs run faster in x86-64 than x86-32, due to the doubled registers, even if they have the same asm features. The SIMD registers are doubled too, which can matter a lot.

Though the main reason 32-bit 7 is on there is because the TV tuner cards in it don't have a driver that works with 64-bit except 64-bit Vista.
Driver compatibility is one of the reasons why someone would stick to an old OS. Although the power and time savings from faster encoding would probably pay for a new tuner card quickly.

Anyway, can anyone explain when SSIM RD setting is used? Sometimes it kicks in when changing only that setting, and sometimes the file size remains the same. It says it's only used on certain presets. Does x265 have to have a preset selected for SSIM RD to be used at all?

--ssim-rd only works at --rd 3 or above. See here (http://x265.readthedocs.io/en/default/cli.html#cmdoption-ssim-rd).

--rd 3 is enabled in --preset medium and higher. See here (http://x265.readthedocs.io/en/default/presets.html#presets)(referenced as rdlevel).

ssim-rd is slower, so it definitely wouldn't make sense to use below --preset medium. I'd guess it wouldn't be a decent speed/quality tradeoff until at least --preset slower.

[brumsky]

@BenWaggoner

Based on the name of the paramter --ssim-rd, could one infer this should only be used for SSIM and PSNR tests?

Do you feel --ssim-rd is worth using?

[Dclose]

https://x265.readthedocs.io/en/default/cli.html#cmdoption-ssim-rd
https://x265.readthedocs.io/en/default/presets.html
Yes, those are there. But the preset chart doesn't show SSIM in it. And there's a tune for SSIM, but not SSIM RDO.
CPUs run faster in x86-64 than x86-32, due to the doubled registers, even if they have the same asm features. The SIMD registers are doubled too, which can matter a lot.

Driver compatibility is one of the reasons why someone would stick to an old OS. Although the power and time savings from faster encoding would probably pay for a new tuner card quickly.

On two desktops side by side, Win8.1-64 and Win7-32, both using i7 3770k at the same speed, 8-bit x265 speed has been similar on both of them. Maybe 10% or so slower on the one, but that one also has slower hard drives though I wouldn't think that matters when using high-quality/slow-speed settings in x265.

Using 10-bit x265 is when a huge difference is seen. Around 75% slower.


--ssim-rd only works at --rd 3 or above. See here.

--rd 3 is enabled in --preset medium and higher. See here (referenced as rdlevel).

That first sentence describes it more specifically. Here's why the question came up:

The paragraph for SSIM RDO says SSIM RDO is only used on presets which use RDO 3 and above.

Since presets can change, I've been leaving it on None and set everything manually. I wouldn't think a particular setting requires a preset to be used even when set manually, but when the description says "It only has effect on presets... --rd 3 and above," I raise an eyebrow and wonder.

And speaking of SSIM RDO, I don't know if it has better quality from months ago, but it seems like it.

[benwaggoner]

@BenWaggoner

Based on the name of the paramter --ssim-rdo, could one infer this should only be used for SSIM and PSNR tests?
It is --ssim-rd, not --ssim-rdo

It uses SSIM as a more advanced rate distortion metric than the default, taking longer but ideally improving perceptual quality.

Do you feel --ssim-rdo is worth using?
I'm not clear if it is a universal win in its current implementation. So many parameters to test!

[brumsky]

It is --ssim-rd, not --ssim-rdo

It uses SSIM as a more advanced rate distortion metric than the default, taking longer but ideally improving perceptual quality.


I'm not clear if it is a universal win in its current implementation. So many parameters to test!

That was a typo, I fixed it. ;)

Thanks, I'll test it with my preferred settings and go from there.

[sneaker_ger]

Yes, those are there. But the preset chart doesn't show SSIM in it. And there's a tune for SSIM, but not SSIM RDO.
Well, you tested - to cite you - when it "kicks in" so from that you should be able to deduct the answer.

The paragraph for SSIM RDO says SSIM RDO is only used on presets which use RDO 3 and above.

Since presets can change, I've been leaving it on None and set everything manually. I wouldn't think a particular setting requires a preset to be used even when set manually, but when the description says "It only has effect on presets... --rd 3 and above," I raise an eyebrow and wonder.
Yes, it's poorly documented.
1. Default is disabled. (== --no-ssid-rd)
2. It's not bound to having explicitly set any preset.

[brumsky]

It is --ssim-rd, not --ssim-rdo
I'm not clear if it is a universal win in its current implementation. So many parameters to test!

I just ran a very quick test with my settings which are a mix of very slow and placebo... For some reason my psy-rd was set to 0. Which of course resulted in a much smaller file, 55% smaller, but took about 1 second longer. The encode looks terrible compared to my default settings.

Has anyone else run into this?

[sneaker_ger]

Yes, psy rd is set to 0.0 when ssim-rd is turned on.

If you want to compare quality encode to same bitrate using 2pass encoding. Not surprising if something that uses 55% less bitrate looks worse. No knowledge to be gained from that.

[brumsky]

Yes, psy rd is set to 0.0 when ssim-rd is turned on.

If you want to compare quality encode to same bitrate using 2pass encoding. Not surprising if something that uses 55% less bitrate looks worse. No knowledge to be gained from that.

Why would it disable psy rd?

[benwaggoner]

Why would it disable psy rd?
Psy-rd adjusts QPs down for smoother areas and up for more complex areas of the video. SSIM as a metric weighs error in smoother areas higher than more complex areas, and thus optimize for exactly that sort of thing. Psy-rd + SSIM would likely give some kind of weird race condition.

[x265_Project]

HDR10+ delivers an optimized, high-quality HDR experience to consumers; Amazon Video is the first streaming video service that will implement HDR10+ technology to deliver a new source of high-quality digital video to Prime Video customers around the globe

LAS VEGAS--(BUSINESS WIRE)--Samsung Electronics Co., Ltd. and Amazon Video today announced the introduction of HDR10+, an updated open standard that leverages dynamic metadata to produce enhanced contrast and colors on an expanded range of televisions.

HDR10+ elevates the HDR10 open standard with the addition of Dynamic Tone Mapping. The current HDR10 standard utilizes static metadata that does not change during playback despite scene specific brightness levels. As a result, image quality may not be optimal in some scenes. For example, when a movie’s overall color scheme is very bright but has a few scenes filmed in relatively dim lighting, those scenes will appear significantly darker than what was originally envisioned by the director.

HDR10+ incorporates dynamic metadata that allows a high dynamic range (HDR) TV to adjust brightness levels on a scene-by-scene or even frame-by-frame basis. With the ability to display outstanding contrast with detailed highlights and a richer range of colors, HDR10+ produces images that are much closer to the director’s intent.

All of Samsung’s 2017 UHD TVs, including its premium QLED TV lineup, support HDR10+. In the second half of this year, Samsung’s 2016 UHD TVs will gain HDR10+ support through a firmware update.

“As an advanced HDR10 technology, HDR10+ offers an unparalleled HDR viewing experience — vivid picture, better contrast and accurate colors — that brings HDR video to life,” said Kyoungwon Lim, Vice President of Visual Display Division at Samsung Electronics. “We’re excited to work with world-class industry partners, including Amazon Video, to bring more amazing HDR content directly to our 2017 UHD TVs, including our QLED TV lineup.”

“Together with Samsung, we are excited to offer customers an enhanced viewing experience on a broad range of devices,” said Greg Hart, Vice President of Amazon Video, worldwide. “At Amazon, we are constantly innovating on behalf of customers and are thrilled to be the first streaming service provider to work with Samsung to make HDR10+ available on Prime Video globally later this year.”

The launch of the HDR10+ content continues Samsung’s and Amazon Video’s leadership in the HDR space. With the move to HDR 10+, Amazon Video is the first streaming service provider to begin development of the standard for its audiences. In May 2015, Samsung and Amazon Video brought HDR to the market using the HDR10 open standard, the first in the field. This bold and innovative advancement laid the groundwork for several HDR launches. From Hollywood film studios to global TV manufacturers, HDR10 is the most broadly used HDR standard today.

Samsung has also partnered with other industry leaders to deliver the best HDR10+ content viewing experience by establishing an HDR10+ ecosystem. Previously, Samsung collaborated with Colorfront to improve HDR10+ workflows for creative post-production mastering by using Colorfront’s Transkoder. Samsung also partnered with MulticoreWare to complete the integration of HDR10+ support in the x265 High Efficiency Video Coding (HEVC), which is available for free under an open source license, and is used by many popular commercial encoding system providers including Telestream, Haivision, and Rohde and Schwarz.

About Samsung Electronics Co., Ltd.

Samsung Electronics Co., Ltd. inspires the world and shapes the future with transformative ideas and technologies. The company is redefining the worlds of TVs, smartphones, wearable devices, tablets, digital appliances, network systems, and memory, system LSI and LED solutions. For the latest news, please visit the Samsung Newsroom at news.samsung.com.

About Amazon Video

Amazon Video is a premium on-demand entertainment service that offers customers the greatest choice in what to watch, and how to watch it. Prime Video offers thousands of movies and TV shows, including popular licensed content plus critically-acclaimed and award-winning Amazon Original Series and Movies from Amazon Studios like Transparent, The Man in the High Castle, Love & Friendship and kids series Tumble Leaf, available for unlimited streaming as part of an Amazon Prime membership. Prime Video is also now available to customers in more than 200 countries and territories around the globe at www.primevideo.com.

[Jamaika]

Samsung and Amazon Video Deliver Next Generation HDR Video Experience With HDR10+
How write these colors HDR10+ and HDR10 in the commands for codec x265?

[LigH]

Relax and wait for new parameters in coming CLI builds... I already see proposed patches in the mailing list. But parameters are just half the fun; without matching video material, they don't fulfill a meaning.

[Midzuki]

x265.exe 2.3+40-2c6e6c9c3da7

http://www.mediafire.com/file/iymx3l6rjmyttv4/x265_2.3+40-2c6e6c9c3da7.7z

NOTICE:

[ 75%] Building CXX object encoder/CMakeFiles/encoder.dir/sei.cpp.obj
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp: In member function
'void x265::SEI::write(x265::Bitstream&, const x265::SPS&)':
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp:51:18:
warning: declaration of 'type' shadows a previous local [-Wshadow]
uint32_t type = m_payloadType;
^~~~
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp:41:14: note: shadowed declaration is here
uint32_t type = m_payloadType;
^~~~

[LigH]

I tried to enable Dynamic HDR10 routines for compilation with GCC 6.3.0, but C++11 compatibility is missing in the current CMake scripts. Release postponed...

[nevcairiel]

HDR10+ incorporates dynamic metadata that allows a high dynamic range (HDR) TV to adjust brightness levels on a scene-by-scene or even frame-by-frame basis. With the ability to display outstanding contrast with detailed highlights and a richer range of colors, HDR10+ produces images that are much closer to the director’s intent.

Is this an official HEVC standard, or a proprietary invention by Amazon and Samsung?
Any specifications about the SEI messages, their intepretation, and how to send them to a TV over HDMI (specifically, does this require HDMI 2.1)?

New tech is nice and all, knowing how to use it would be even nicer. :)

[cojj]

I'm getting file sizes that are 25~50% bigger with the new 10bit lamda table with an identical setting (mostly preset slower).

Is this expected?

[Boulder]

Yes, it's expected. Adjust your CRF accordingly to compensate; as they say, the perceptual quality should be improved at the same bitrate.

[aymanalz]

Has the 10 bit lambda table been incorporated into the latest build? If so, what build number?

[Midzuki]

I tried to enable Dynamic HDR10 routines for compilation with GCC 6.3.0, but C++11 compatibility is missing in the current CMake scripts. Release postponed...

Thanks for the clarification. I stopped reading x265's CMakeLists.txt ages ago... and its readme.rst is no replacement for a (still non-existent) What's-New.txt...
In other words, HDR10 support is disabled by default, and I would never notice that by myself.

Anyway, and FWIW:

make[2]: *** [dynamicHDR10/CMakeFiles/dynamicHDR10.dir/build.make:82: dynamicHDR10/CMakeFiles/dynamicHDR10.dir/json11/json11.cpp.obj] Error 1
make[1]: *** [CMakeFiles/Makefile2:147: dynamicHDR10/CMakeFiles/dynamicHDR10.dir/all] Error 2
make: *** [Makefile:117: all] Error 2
cp: cannot stat 'libx265.a': No such file or directory

[Barough]

x265 v2.3+41-6dc49dcff6da (http://www73.zippyshare.com/v/7dBI8NqO/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.3+41-6dc49dcff6da
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[nevcairiel]

In other words, HDR10 support is disabled by default, and I would never notice that by myself.

Its only about HDR10+ (not ordinary HDR10), and its a brand new feature which clearly still has issues even building properly everywhere, so it might get enabled by default later.

[need4speed]

Dumb question on encoding 10bit:
Do I need to enable both depth10 AND profile main10?
Sorry but have tried to read all posts and a couple of white papers, this to improve banding and still it's not clear.
Thanks in advance!
So new 10bit table is active in latest builds (.40 and .41)?

[sneaker_ger]

Dumb question on encoding 10bit:
Do I need to enable both depth10 AND profile main10?
If you set output depth to 10 bit it will automatically choose main10 profile. If you have a build that's only compiled for 10 bit you don't have to set anything at all.
Just check the output in MediaInfo and look at the x265 log if you are not sure.

So new 10bit table is active in latest builds (.40 and .41)?
Yes, the new tables for 10 and 12 bit have arrived.

[LigH]

Regarding Dynamic HDR10: It is not enabled by default, but a CMake switch is available. I tried to enable this supporting switch. The resulting errors point at C++11 support not yet being enabled in the MSYS/GCC branch of the make scripts, possibly just forgotten when another preferred compiler of a developer supports it per default.

[x265_Project]

Its only about HDR10+ (not ordinary HDR10), and its a brand new feature which clearly still has issues even building properly everywhere, so it might get enabled by default later.

To get the HDR10+ capability to market more quickly, the developers used Standard Template Libraries. As you noticed, STLs may introduce compiler compatibility issues, so for now, compiling HDR10+ in x265 is off by default. We expect the HDR10+ code to be updated to avoid the use of STLs, so that it can be compiled in x265 by default.

[need4speed]

If you set output depth to 10 bit it will automatically choose main10 profile. If you have a build that's only compiled for 10 bit you don't have to set anything at all.
Just check the output in MediaInfo and look at the x265 log if you are not sure.


Yes, the new tables for 10 and 12 bit have arrived.
Thanks!
Was wondering about 10bits tables because my latest converted file has decreased in terms of size keeping the same crf. Have read it has happened the opposite so wondering how the story was.
Besides with regards of earlier 10bit encoded speed time latest versions seem to be a bit faster, around 2 fps increase in medium preset with some tweaks

Inviato dal mio GT-N7100 utilizzando Tapatalk

[x265_Project]

HDR10 is a static HDR system defined by SMPTE 2084 (Electro Optical Transfer Function, or EOTF) and SMPTE 2086 (HEVC metadata). By static, we mean that the EOTF (the curve that defines how to map color sample values in the HEVC bitstream to luminance levels on the display) is the same for the entire video. Static HDR works, but it isn't ideal because with only 10 bits (1024 values) to map a very wide range of luminance levels, colorists have to pick a single setting that works well on average for the whole title. This means that brighter than average scenes may have regions that are washed out, and darker than average scenes might have regions where it is hard to distinguish what is happening in the shadows.

HDR10+ is a dynamic HDR system defined by the SMPTE 2094-40 standard. It lets colorists adjust the EOTF on a scene-by-scene basis. There are 4 flavors of SMPTE 2094...
•2094-1 –the core definitions document
•2094-10 –[Dolby Vision] metadata for a tone mapping based on the source content characteristics and colorist adjustments.
•2094-20 –[Philips] metadata for a color transform based on a creatively set tone mapping curve and a luminance dependent saturation gain curve.
•2094-30 –[Technicolor] metadata for reference-based color volume remapping, derived from two grades of the same content.
•2094-40 –[Samsung HDR10+] metadata for tone mapping and color saturation based on mastering and target displays peak luminances and content characteristics.

x265's HDR10+ support was contributed by Samsung. It provides the capability to parse a JSON file containing metadata generated by Samsung's tone mapping software. Samsung is working with content creators, color grading software developers and content distributors to enable HDR10+ tone mapping (generating the JSON file).

If you want to know more about Dynamic HDR, I suggest ...
https://www.smpte.org/sites/default/files/2017-01-12-ST-2094-Borg-V2-Handout.pdf
http://www.ste-ca.org/images/STE_Presentation_Apil_2016.pdf
http://set6.tempsite.ws/eventos/palestras/matthew_goldman_set_expo_2016.pdf

[Ma]

Regarding Dynamic HDR10: It is not enabled by default, but a CMake switch is available. I tried to enable this supporting switch. The resulting errors point at C++11 support not yet being enabled in the MSYS/GCC branch of the make scripts, possibly just forgotten when another preferred compiler of a developer supports it per default.

If you change in source/CMakeLists.txt line 190 from
add_definitions(-std=gnu++98)
to
add_definitions(-std=gnu++11)
you can compile x265 with '-DENABLE_DYNAMIC_HDR10=ON'.

I don't know if it make sense only in 10-bit depth or in any bit depth.
Compiled 10-bit x265 with dhdr10 for Windows (64-bit and 32-bit):
www.msystem.waw.pl/x265/x265-10hdr.7z

[brumsky]

Thanks!
Was wondering about 10bits tables because my latest converted file has decreased in terms of size keeping the same crf. Have read it has happened the opposite so wondering how the story was.
Besides with regards of earlier 10bit encoded speed time latest versions seem to be a bit faster, around 2 fps increase in medium preset with some tweaks

Inviato dal mio GT-N7100 utilizzando Tapatalk

I've noticed an increase in speed as well. Much less but I think it is because I use modified placebo settings. Also, files initially seemed to be larger - 2000kbps ish increase.

[Midzuki]

If you change in source/CMakeLists.txt line 190 from
add_definitions(-std=gnu++98)
to
add_definitions(-std=gnu++11)
you can compile x265 with '-DENABLE_DYNAMIC_HDR10=ON'.

I don't know if it make sense only in 10-bit depth or in any bit depth.
Compiled 10-bit x265 with dhdr10 for Windows (64-bit and 32-bit):
www.msystem.waw.pl/x265/x265-10hdr.7z

Many thanks for the info :goodpost:
Now the thing gets compiled.
BUT still with tons of warnings ;)

FWIW: I disabled HDR10+ only for the 8-bit section in my new multilib building script.

[need4speed]

I've noticed an increase in speed as well. Much less but I think it is because I use modified placebo settings. Also, files initially seemed to be larger - 2000kbps ish increase.
Trying another session right now. Will get back but at the moment confirming the bitrate is lower than before, same everything

Inviato dal mio GT-N7100 utilizzando Tapatalk

[Midzuki]

Hmmm, commit 7f77e66 says:

compilation fix in dhdr10

However GCC 6.3.0 still returns TONS of warnings.
Also, CMakeLists.txt hasn't been fixed.

[x265_Project]

Unless you are encoding content that has been mastered with Samsung's tone mapping system, and you have the JSON file with the HDR metadata, you don't need to build x265 with this feature. You'll get errors if you're not using the same compiler that this feature was targeted to. I'll ask our development team to clarify which compilers are supported by this feature today.

[Midzuki]

Unless you are encoding content that has been mastered with Samsung's tone mapping system, and you have the JSON file with the HDR metadata, you don't need to build x265 with this feature. You'll get errors if you're not using the same compiler that this feature was targeted to. I'll ask our development team to clarify which compilers are supported by this feature today.

Actually, the warnings have nothing to do with the Dynamic HDR support. The quote below is only a tiny sample of what I am talking about.

............

NOTICE:

[ 75%] Building CXX object encoder/CMakeFiles/encoder.dir/sei.cpp.obj
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp: In member function
'void x265::SEI::write(x265::Bitstream&, const x265::SPS&)':
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp:51:18:
warning: declaration of 'type' shadows a previous local [-Wshadow]
uint32_t type = m_payloadType;
^~~~
D:/KOMPILES/MCW/x265/source/encoder/sei.cpp:41:14: note: shadowed declaration is here
uint32_t type = m_payloadType;
^~~~

[x265_Project]

Actually, the warnings have nothing to do with the Dynamic HDR support. The quote below is only a tiny sample of what I am talking about.
Sorry Midzuki! There were a few messages about building x265 with Dynamic HDR turned on. I thought you were trying this also.

[benwaggoner]

Is this an official HEVC standard, or a proprietary invention by Amazon and Samsung?
Any specifications about the SEI messages, their intepretation, and how to send them to a TV over HDMI (specifically, does this require HDMI 2.1)?

New tech is nice and all, knowing how to use it would be even nicer. :)
It is SMPTE standard 2094-40.

Generating the metadata is pretty complex, and that's not in x265. Colorfront's Transkoder product can generate the data from a source file. x265 supports incorporating the metadata into an encoded HDR-10 HEVC bitstream.

[nevcairiel]

It is SMPTE standard 2094-40.

Generating the metadata is pretty complex, and that's not in x265. Colorfront's Transkoder product can generate the data from a source file. x265 supports incorporating the metadata into an encoded HDR-10 HEVC bitstream.

I'm not interested in generating the data, just consuming it to various degrees, possibly to transmit it to a TV through HDMI down the line, have to at least try to keep PCs able to use those new formats.
For transmission, thats apprently in CTA-861-G (ie. the HDMI 2.0/2.1 standard), perhaps some software features can be supported on older HDMI interfaces by firmware updates (like dynamic metadata).

[benwaggoner]

I'm not interested in generating the data, just consuming it to various degrees, possibly to transmit it to a TV through HDMI down the line, have to at least try to keep PCs able to use those new formats.
For transmission, thats apprently in CTA-861-G (ie. the HDMI 2.0/2.1 standard), perhaps some software features can be supported on older HDMI interfaces by firmware updates (like dynamic metadata).
I'm not sure exactly how transport over HDMI will work and with what requirements. So far all the demonstrations have been on devices with integrated screens.

[Jamaika]

I'm not interested in generating the data, just consuming it to various degrees, possibly to transmit it to a TV through HDMI down the line, have to at least try to keep PCs able to use those new formats.
For transmission, thats apprently in CTA-861-G (ie. the HDMI 2.0/2.1 standard), perhaps some software features can be supported on older HDMI interfaces by firmware updates (like dynamic metadata).
Interesting thought. I don't know how it is, but I think @sneaker once wrote that HDR is also for 8bit video in VP9 codec. It seems to me that google policy has also changed. The site is only about 10bit movies.
https://support.google.com/youtube/answer/7126552?hl=en
http://www.androidcentral.com/new-nvidia-shield-streaming-box-includes-google-assistant-4k-hdr-streaming
https://www.heise.de/newsticker/meldung/AMD-Radeon-RX-400-HDR-Gaming-ueber-HDMI-nur-mit-8-statt-10-Bit-3488970.html
http://static.frazpc.pl/cms/2016/11/file-14bc21be7eaeed046f-600x333.jpeg
Dolby Vision also works with the older HDMI 1.4a standard, while HDR10 requires HDMI 2.0. Dolby Vision is backwardly compatible to HDR10, but it's not clear if it will work with the new standard HDR10+.
But what exactly does that mean? HDR10/HDR10+ is the current industry standard for HDR in consumer televisions. This first-generation “open” format technology is the starting point for High Dynamic Range, which needs a compatible interface—either HDMI 2.0a/HDMI 2.1 or Internet connection...
Make sure your TV and AV receiver firmware are up to date. Many newer TVs and devices can take updates—if you find that it doesn't support some 4K or HDR features, a TV or receiver firmware update may resolve the problem. Check your TV or device manual to see how to update the firmware.

Edit: Who knows what this is for the Dynamic Range Pro for HDR10? Is it also set in HEVC codecs?

[benwaggoner]

Interesting thought. I don't know how it is, but I think @sneaker once wrote that HDR is also for 8bit video in VP9 codec. It seems to me that google policy has also changed. The site is only about 10bit movies.
Doing some degree of HDR in 8-bit is possible. I had some working prototypes a couple of years ago. But using the full PQ range isn't feasible without a lot of banding. 10-bit is definitely required to do "standard" HDR over HDMI.

Edit: Who knows what this is for the Dynamic Range Pro for HDR10? Is it also set in HEVC codecs?
The HDR10+/SMPTE 2094-40 metadata is inside the HEVC bitstream as SEI messages. I don't know if there is a final spec for transmission over HDMI.

[Jamaika]

The HDR10+/SMPTE 2094-40 metadata is inside the HEVC bitstream as SEI messages. I don't know if there is a final spec for transmission over HDMI.
Thanks for the answer. I ask curiosity, because it amazes me advertising SONY. We have 10x more contrast range products than Dynamic Range HDR10 called Dynamic Range Pro which aren't HDR10+. Where are these extra information extracted from the metadata?
It begins to be it for me even more puzzling.

[nevcairiel]

Sony's "Dynamic Range Pro" is not "dynamic HDR", its just static HDR with some proprietary contrast booster.

So far there have been 4 competing dynamic HDR concepts grouped under SMPTE 2094
2094-10: Dolby Vision
2094-20: Phillips
2094-30: Technicolor (used by LG, IIRC)
2094-40: Samsung

Its a rather unfortunate situation that we have 4 competing concepts already, and possibly more in the future.
We'll have to see how they differ and if TVs will be able to just handle content in all of the formats.

From what I could turn up, the next release of the HEVC spec (October 2017) should also encorporate the SEI messages for these officially.
I also found information that claims that ST 2094-10 and ST 2094-20 are optional parts of the UHD Blu-ray Specification, but the other two didn't make it in at all.

Transmission over HDMI will likely require HDMI 2.1 for all variants of SMTPE ST 2094 - with the exception of Dolbys proprietary transmission format, which requires full hardware support on both ends.

[Sagittaire]

I want make direct comparison with HT On and HT Off.

It's possible to change the wpp raws number in x265?

[dipje]

Has the 10 bit lambda table been incorporated into the latest build? If so, what build number?

In the bitbucket of multicoreware (official x265 repo I'm guessing) I see the commit of the new lambda tables (10bit / 12bit) being commited on the 13th of april, both in the 'default' branch and the 'stable' branch.

I'm guessing any build from that point on has it?
Or is the commit I'm seeing still something that needs to be approved?

[Selur]

I'm guessing any build from that point on has it?
not exactly, it was merged to default branch two days ago, and since then any new build includes the new lambda tables.

[Ma]

I want make direct comparison with HT On and HT Off.

It's possible to change the wpp raws number in x265?

To simulate encoding with CPU with different numbers of logical cores, there are needed two options: '--pools <N>' and '-F <NF>' where N is number of logical cores that you want to simulate and NF is number of frame threads that x265 uses for N logical cores -- formula is at:
https://bitbucket.org/multicoreware/x265/src/2c6e6c9c3da72aaddb33565d7031918fb5a37097/source/encoder/encoder.cpp?at=default&fileviewer=file-view-default#encoder.cpp-137

Example: if you want to simulate 4 logical cores system, use
--pools 4 -F 2

for 8 cores:
--pools 8 -F 3

for 20 cores:
--pools 20 -F 5

for 32 cores and 1080p source movie:
--pools 32 -F 6

wpp you can only turn on or off (for '--no-wpp' option number of frame threads are min(logical cores, 16) for high resolution source).

[Natty]

how to use 10 bit lambda table

[nevcairiel]

how to use 10 bit lambda table

Its always used when you encode 10-bit content, and any builds of the last few days should have the new table.

[pradeeprama]

x265 version 2.4 has been released. This release incorporates support for the new HDR10+ standard, and revised lambda tables for main, main10, and main12 profiles that significantly improve visual quality!

Version 2.4 can now be downloaded from here (md5: ab0986aa5c4465b874de94095b0d0cae). Full documentation is available at http://x265.readthedocs.io/en/stable/.

Release Notes for Version 2.4
======================

Release date - 22nd April, 2017.

Encoder enhancements
----------------------------------
1. HDR10+ supported. Dynamic metadata may be either supplied as a bitstream via the userSEI field of x265_picture, or as a json file that can be parsed by x265 and inserted into the bitstream; use --dhdr10-info to specify json file name, and --dhdr10-opt to enable optimization of inserting tone-map information only at IDR frames, or when the tone map information changes.
2. Lambda tables for 8, 10, and 12-bit encoding revised, resulting in significant enhancement to subjective visual quality.
3. Enhanced HDR10 encoding with HDR-specific QP optimizations for chroma, and luma planes of WCG content enabled; use --hdr-opt to activate.
4. Ability to accept analysis information from other previous encodes (that may or may not be x265), and selectively reuse and refine analysis for encoding subsequent passes enabled with the --refine-level option.
5. Slow and veryslow presets receive a 20% speed boost at iso-quality by enabling the --limit-tu option.
6. The bitrate target for x265 can now be dynamically reconfigured via the reconfigure API.
7. Performance optimized SAO algorithm introduced via the --limit-sao option; seeing 10% speed benefits at faster presets.

API changes
-------------------
1. x265_reconfigure API now also accepts rate-control parameters for dynamic reconfiguration.
2. Several additions to data fields in x265_analysis to support --refine-level: see x265.h for more details.

Bug fixes
--------------
1. Avoid negative offsets in x265 lambda2 table with SAO enabled.
2. Fix mingw32 build error.
3. Seek now enabled for pipe input, in addition to file-based input
4. Fix issue of statically linking core-utils not working in linux.
5. Fix visual artifacts with --multi-pass-opt-distortion with VBV.
6. Fix bufferFill stats reported in csv.

Happy Compressing!

x265 team.

[Midzuki]

x265.exe 2.4+2-5bc5e73760cd

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2483884#post2483884

[dipje]

not exactly, it was merged to default branch two days ago, and since then any new build includes the new lambda tables.

Ah so that was the catch I was missing :).
It looked reverse on my end , (I've read it wrong it bitbucket apparently?),
Like it was added to the default branch , but 2 days ago that default branch was merged into 'stable branch.
So it depends which branch is used in the builds , but I believe most people who are nice enough around here use the default branch.

Anyway, talking about nice people who builds, can we expect a 2.4 build from LigH, or are you still having compilation problems?

[Midzuki]

Anyway, talking about nice people who builds, can we expect a 2.4 build from LigH, or are you still having compilation problems?

Over here, no compiler warnings happened.
But I didn't enable the HDR10+ thing, I was too lazy to edit CMakeLists.txt.
LigH's next build of x265 will appear sooner or later anyway :)

[Selur]

quick question about the new options:
--dhdr10-info <filename> JSON file containing the Creative Intent Metadata to be encoded as Dynamic Tone Mapping
--[no-]dhdr10-opt Insert tone mapping SEI only for IDR frames and when the tone mapping information changes.Default disabled
Do I get it right that: dhdr10-info is always required for dynamic hdr10 and dhdr10-opt is an option which allows to limit how often the tone mapping SEI is inserted?

Also does it also require '--hdr' or are those separate?

[LigH]

Mateusz Brzostek proposed a patch:

[x265] [PATCH] cmake: set '-std=gnu++11' for GCC if ENABLE_DYNAMIC_HDR10 is on (https://mailman.videolan.org/pipermail/x265-devel/2017-April/010984.html)

but it has not yet been commited. And I have only little experience in manual working set management with TortoiseHg, I prefer using only commited updates.
_

P.S.: I tried to import this patch, but it failed with code 255. Might be because the base changeset is already outdated?

[Selur]

multilib.sh should also be adjusted,..
for clang it's c++11 instead of gnu++1 and in encoder.h:
- #include "dynamicHDR10\hdr10plus.h"
+ #include "dynamicHDR10/hdr10plus.h"

[LigH]

Of course, I made my own builds script by adding "-DENABLE_DYNAMIC_HDR10=ON" to 10 and 12 bit libraries.

[Barough]

x265 v2.4+2-5bc5e73760cd (http://www55.zippyshare.com/v/HMZWezgh/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 : HEVC encoder version 2.4+2-5bc5e73760cd
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[I]HDR10 Enabled

[Ma]

I tried to import this patch, but it failed with code 255. Might be because the base changeset is already outdated?

If you save 3 attachments "warnings.patch", "cmake-hdr10.patch" and "dhdr10.patch" to your x265 folder, you can execute (in MSYS)
patch -p1 <warnings.patch
patch -p1 <cmake-hdr10.patch
patch -p1 <dhdr10.patch

If you want clean source (remove these patches), please execute
hg update -C

[stax76]

-limit-tu 4 is in slower and veryslow preset

a new issue I see is mediainfo don't show any info like depth 10, main 10, resolution 10 when using mkv

is this issue caused by mkvmerge, mediainfo or x265?

for mp4 output it's there:

https://s16.postimg.org/6fwvm77fl/Unbenannt.png (https://postimg.org/image/6fwvm77fl/)

[Selur]

a new issue I see is mediainfo don't show any info like depth 10, main 10, resolution 10 when using mkv
isn't new been that way for a few month as I remember, but I never really looked into it :)

[stax76]

This is really new because every time when I update the x265 build I make a 8 bit and a 10 bit encode to verify it's actually a multi lib build.

[Selur]

Strange, noticed this month ago,...

[stax76]

I don't update mediainfo often, could be a mediainfo issue then, not sure when I updated it the last time.

[sneaker_ger]

Mkvmerge somewhere between 10.0.0 and 11.0.0. But that doesn't necessarily mean it's a bug in mkvmerge.

[stax76]

I've posted it also to Mosu's and Zenitram's thread.

[LazyNcoder]

Hi guys,

I want to know what's the deal with this --limit-tu option in new v2.4. is it on by default in slow and very slow presets or should we enable it manually?
If it's not default, what's the best value for it? which level of the option would affect the quality the lower?
I usually encode with slow preset. should I need other options we've talked before like --rskip --limit-refs 3 --limit-modes and so? I care about quality the most, but it won't hurt to have a faster encoding.

Thanks

[stax76]

Hi guys,

I want to know what's the deal with this --limit-tu option in new v2.4. is it on by default in slow and very slow presets or should we enable it manually?
If it's not default, what's the best value for it? which level of the option would affect the quality the lower?
I usually encode with slow preset. should I need other options we've talked before like --rskip --limit-refs 3 --limit-modes and so? I care about quality the most, but it won't hurt to have a faster encoding.

Thanks

It's 4 with slower and veryslow, otherwise 0.

https://x265.readthedocs.io/en/default/presets.html

https://bitbucket.org/multicoreware/x265/src/5bc5e73760cdb61d2674e74cc52149fa0603af8a/source/common/param.cpp?at=default&fileviewer=file-view-default#param.cpp-401

[LigH]

Verbose documentation (http://x265.readthedocs.io/en/default/cli.html?highlight=--limit-tu#cmdoption-limit-tu)

Preset options (http://x265.readthedocs.io/en/default/presets.html?highlight=--limit-tu)

As you can see, the developers enabled TU limiting mode 4 for presets "slower" and "veryslow" only ("placebo" has always everything enabled, no matter how much time it wastes for how little improvement; and any faster preset is probably still fast enough without limiting).

You may agree to me that an average user may not easily understand the meaning of the four different modes, it may require in-depth understanding of the encoder. I would recommend to trust the developers using a good choice in their presets, and anyone who is certain to know it better may explain to us why... ;)

[Motenai Yoda]

Notice it is default 4 on presets where tu-inter is more than 1 too, coz limit-tu speed up only tu-inter > 1

[littlepox]

The reason for them to open limit-tu 4 for slower&veryslow is to fight --amp.
--amp enables TOO MANY possible partitions; with close-to-zero gain.

[LazyNcoder]

It's 4 with slower and veryslow, otherwise 0.

https://x265.readthedocs.io/en/default/presets.html

https://bitbucket.org/multicoreware/x265/src/5bc5e73760cdb61d2674e74cc52149fa0603af8a/source/common/param.cpp?at=default&fileviewer=file-view-default#param.cpp-401

Verbose documentation (http://x265.readthedocs.io/en/default/cli.html?highlight=--limit-tu#cmdoption-limit-tu)

Preset options (http://x265.readthedocs.io/en/default/presets.html?highlight=--limit-tu)

As you can see, the developers enabled TU limiting mode 4 for presets "slower" and "veryslow" only ("placebo" has always everything enabled, no matter how much time it wastes for how little improvement; and any faster preset is probably still fast enough without limiting).

You may agree to me that an average user may not easily understand the meaning of the four different modes, it may require in-depth understanding of the encoder. I would recommend to trust the developers using a good choice in their presets, and anyone who is certain to know it better may explain to us why... ;)

Thank you guys.

So, there should be some mistake in "release notes" of v2.4 because it stated "Slow and veryslow" presets have changed.
I thought it's odd Slower preset is left out. But now I know it's slower and veryslow presets. No benefits for me. lol.

http://x265.readthedocs.io/en/default/releasenotes.html#version-2-4

[troica]

Hello guys is there any forum for the HM test model for HEVC? Just off topic-ing for a bit, since my question is for the HM test model.

Is the current HM model (16.3) now supporting error concealment capabilities per CTU (not just per frame) or still under development? Thank you!

[LigH]

It doesn't seem like this topic has been discussed often before; so just create a new thread in this forum (High Efficiency Video Coding (HEVC) (https://forum.doom9.org/forumdisplay.php?f=81)).

[LigH]

According to recent test reports in the x265 developer mailinglist, GCC 6.x and CLang both seem to work well with "-std=c++11" (no need for gnu++11 for GCC), so a unified patch should be expectable soon, to enable the required compiler mode in relation to possibly enabled DHDR10 support. :cool:

[Ma]

I did a comparison of an old 10-bit lambda with a new 10-bit lambda.
Movie: Tears of Steel 4K downsized to 2K, encoded @ 1000 kb/s
old lambda - www.msystem.waw.pl/x265/tears-old-lambda.mkv
new lambda - www.msystem.waw.pl/x265/tears-new-lambda.mkv

command line (first & second pass):
ffmpeg -i ../tearsofsteel-4k.y4m -pix_fmt yuv420p16 -vf "scale=1920:-4:flags=bicubic+accurate_rnd+full_chroma_int+
full_chroma_inp:param0=-0.5:param1=0.25,setsar=1" -v warning -strict -1 -f yuv4mpegpipe - | x265 --y4m - --bitrate 1000 -p9 --de
block -1 --keyint 480 --multi-pass-opt-distortion -o p1n-.hevc --pass 1

ffmpeg -i ../tearsofsteel-4k.y4m -pix_fmt yuv420p16 -vf "scale=1920:-4:flags=bicubic+accurate_rnd+full_chroma_int+
full_chroma_inp:param0=-0.5:param1=0.25,setsar=1" -v warning -strict -1 -f yuv4mpegpipe - | x265 --y4m - --bitrate 1000 -p9 --de
block -1 --keyint 480 --multi-pass-opt-distortion -o p2n-.hevc --pass 2

Encoder log from 2 pass old lambda:
y4m [info]: 1920x804 fps 24/1 i420p16 sar 1:1 unknown frame count
raw [info]: output file: p2-.hevc
x265 [info]: HEVC encoder version 2.3+28-08a05ca9fd16
x265 [info]: build info [Windows][MSVC 1910][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1000 kbps / 0.60
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 tskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-read
x265 [info]: frame I: 129, Avg QP:24.88 kb/s: 9257.96
x265 [info]: frame P: 3666, Avg QP:29.50 kb/s: 2845.08
x265 [info]: frame B: 13825, Avg QP:35.23 kb/s: 431.98
x265 [info]: Weighted P-Frames: Y:2.2% UV:1.8%
x265 [info]: Weighted B-Frames: Y:0.9% UV:0.6%
x265 [info]: consecutive B-frames: 10.7% 5.3% 7.8% 27.8% 16.8% 15.1% 4.2% 6.4% 6.0%

encoded 17620 frames in 68761.43s (0.26 fps), 998.67 kb/s, Avg QP:33.96

Encoder log from 2 pass new lambda:
y4m [info]: 1920x804 fps 24/1 i420p16 sar 1:1 unknown frame count
raw [info]: output file: p2n-.hevc
x265 [info]: HEVC encoder version 2.3+40-2c6e6c9c3da7
x265 [info]: build info [Windows][MSVC 1910][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1000 kbps / 0.60
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 tskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-read
x265 [info]: frame I: 129, Avg QP:25.82 kb/s: 9022.46
x265 [info]: frame P: 3666, Avg QP:30.36 kb/s: 2828.23
x265 [info]: frame B: 13825, Avg QP:36.14 kb/s: 438.65
x265 [info]: Weighted P-Frames: Y:2.2% UV:1.8%
x265 [info]: Weighted B-Frames: Y:0.9% UV:0.6%
x265 [info]: consecutive B-frames: 10.7% 5.3% 7.8% 27.8% 16.8% 15.1% 4.2% 6.4% 6.0%

encoded 17620 frames in 76852.48s (0.23 fps), 998.67 kb/s, Avg QP:34.86

I don't see that new lambda is better. Definitely 1000 kb/s is too small for this movie.

[Natty]

I did a comparison of an old 10-bit lambda with a new 10-bit lambda.

I don't see that new lambda is better. Definitely 1000 kb/s is too small for this movie.

why arent u using x265 2.4.2 to compare ? on both of ur encodes the x265 versions are different

[LigH]

That's the trick. The older x265 version (2.3+28) uses the older tables per default, the newer version (2.3+40) uses the newer tables. It doesn't require the very latest version (2.4+2), just one before the patch and one after.

If you wanted to use the same version with different lambda tables, you would need separate files with these tables to specify. I don't remember seeing such a file published anywhere, yet...

[Ma]

why arent u using x265 2.4.2 to compare ? on both of ur encodes the x265 versions are different

From x265 2.3+40 to 2.4+2 there are no changes in normal encoding (without dhdr10). I started encoding before 2.4+2 came out.

[Romario]

Now is slow time for beginning of AVX-512 optimisation though whole x265 code.

What are the plans about it?

Gesendet von meinem GT-I9295 mit Tapatalk

[Jamaika]

According to recent test reports in the x265 developer mailinglist, GCC 6.x and CLang both seem to work well with "-std=c++11" (no need for gnu++11 for GCC), so a unified patch should be expectable soon, to enable the required compiler mode in relation to possibly enabled DHDR10 support. :cool:
Hmm, but some programs need eg c++14. Short question: What files can be used interchangeably gnu++11 and c++11? Only .cpp or all.

[LigH]

This patch is related to a source language level (the compiler understanding the source structure at all). It is not related to compiler brands and versions, especially not to Microsoft Visual C++ (as it is for GNU C++ and CLang).

It doesn't matter if different applications are written in different source language levels (like casual Chinese vs. Mandarin dialect), as soon as they are all available in executable binary form. Runtime DLL's are a completely different topic.

[NikosD]

The speed-up from SSE4.x to AVX2 is about ~20%

The speed-up from AVX2 to AVX-512 could be less than 10%

[benwaggoner]

That's the trick. The older x265 version (2.3+28) uses the older tables per default, the newer version (2.3+40) uses the newer tables. It doesn't require the very latest version (2.4+2), just one before the patch and one after.

If you wanted to use the same version with different lambda tables, you would need separate files with these tables to specify. I don't remember seeing such a file published anywhere, yet...
You can pull the old lambda table out of the diff, and then load the csv file with a command:

For 10/12-bit you can get the old csv from the red lines here:
https://bitbucket.org/multicoreware/x265/commits/94d59c325e975888e4f7b152cc90b4199d9d24c4

Put that into a file, and then call it using:

--lambda-file (http://x265.readthedocs.io/en/default/cli.html#cmdoption-lambda-file)

At least, that should work in theory. I haven't tried it myself.

Note that for apples-to-apples comparison, you'll want to use 2-pass ABR encoding. The new lambda table uses somewhat higher bitrate for a given CRF value, so if you compare with CRF you'll get better quality AND a bigger file, which isn't that informative.

[benwaggoner]

The speed-up from SSE4.x to AVX2 is about ~20%

The speed-up from AVX2 to AVX-512 could be less than 10%
And will probably vary some between different frame sizes, other parameters, and CPU implementations.

AVX and AVX2 got relatively greater performance boosts on more recent Intel processors, since not as much thermal limiting was applied. And IIRC we saw a greater perf delta the slower the preset used.

[Sagittaire]

I did a comparison of an old 10-bit lambda with a new 10-bit lambda.
Movie: Tears of Steel 4K downsized to 2K, encoded @ 1000 kb/s
old lambda - www.msystem.waw.pl/x265/tears-old-lambda.mkv
new lambda - www.msystem.waw.pl/x265/tears-new-lambda.mkv

command line (first & second pass):
ffmpeg -i ../tearsofsteel-4k.y4m -pix_fmt yuv420p16 -vf "scale=1920:-4:flags=bicubic+accurate_rnd+full_chroma_int+
full_chroma_inp:param0=-0.5:param1=0.25,setsar=1" -v warning -strict -1 -f yuv4mpegpipe - | x265 --y4m - --bitrate 1000 -p9 --de
block -1 --keyint 480 --multi-pass-opt-distortion -o p1n-.hevc --pass 1

ffmpeg -i ../tearsofsteel-4k.y4m -pix_fmt yuv420p16 -vf "scale=1920:-4:flags=bicubic+accurate_rnd+full_chroma_int+
full_chroma_inp:param0=-0.5:param1=0.25,setsar=1" -v warning -strict -1 -f yuv4mpegpipe - | x265 --y4m - --bitrate 1000 -p9 --de
block -1 --keyint 480 --multi-pass-opt-distortion -o p2n-.hevc --pass 2

Encoder log from 2 pass old lambda:
y4m [info]: 1920x804 fps 24/1 i420p16 sar 1:1 unknown frame count
raw [info]: output file: p2-.hevc
x265 [info]: HEVC encoder version 2.3+28-08a05ca9fd16
x265 [info]: build info [Windows][MSVC 1910][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1000 kbps / 0.60
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 tskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-read
x265 [info]: frame I: 129, Avg QP:24.88 kb/s: 9257.96
x265 [info]: frame P: 3666, Avg QP:29.50 kb/s: 2845.08
x265 [info]: frame B: 13825, Avg QP:35.23 kb/s: 431.98
x265 [info]: Weighted P-Frames: Y:2.2% UV:1.8%
x265 [info]: Weighted B-Frames: Y:0.9% UV:0.6%
x265 [info]: consecutive B-frames: 10.7% 5.3% 7.8% 27.8% 16.8% 15.1% 4.2% 6.4% 6.0%

encoded 17620 frames in 68761.43s (0.26 fps), 998.67 kb/s, Avg QP:33.96

Encoder log from 2 pass new lambda:
y4m [info]: 1920x804 fps 24/1 i420p16 sar 1:1 unknown frame count
raw [info]: output file: p2n-.hevc
x265 [info]: HEVC encoder version 2.3+40-2c6e6c9c3da7
x265 [info]: build info [Windows][MSVC 1910][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1000 kbps / 0.60
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 tskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-read
x265 [info]: frame I: 129, Avg QP:25.82 kb/s: 9022.46
x265 [info]: frame P: 3666, Avg QP:30.36 kb/s: 2828.23
x265 [info]: frame B: 13825, Avg QP:36.14 kb/s: 438.65
x265 [info]: Weighted P-Frames: Y:2.2% UV:1.8%
x265 [info]: Weighted B-Frames: Y:0.9% UV:0.6%
x265 [info]: consecutive B-frames: 10.7% 5.3% 7.8% 27.8% 16.8% 15.1% 4.2% 6.4% 6.0%

encoded 17620 frames in 76852.48s (0.23 fps), 998.67 kb/s, Avg QP:34.86

I don't see that new lambda is better. Definitely 1000 kb/s is too small for this movie.


x265 seem really powerfull at quantizer ~25 with default setting. It's certainely the best quantizer area for make comparison. 1000 kbps for 2K source at q35 have definitely too low visual quality.

[WhatZit]

x265 has hundreds of kernels that are SIMD optimized for various instruction sets, and it's a fairly substantial effort (many, many developer man-months).

I understand that your recent collaboration with HaiGear Labs exploited expensive, but otherwise completely generic, Intel Visual Compute Accelerator 2's accessed via your UHDKit to produce those 4Kp60 real-time streaming results.

Given your hint at "various instruction sets", does this mean that one of these:

http://www.intel.com/content/www/us/en/servers/accelerators/visual-compute-accelerator-2.html

is currently the closest thing we can get to a proper Multicoreware x265 (not anyone else's "HEVC") hardware encoder card?

Of course, I can see at least these two flies swimming in the ointment:

1) The VCA2 hardware support was custom coded by Haivision, not Multicoreware
2) The VCA2 hardware support was coded by Multicoreware, but is only available through the UHDKit API, not the x265 CLI

Additionally, if x265 does include optimised instruction support for the VCA2, does that mean that the VCA (1st one, which is now half the cost) is also supported?

Is there any clarification that you can make on this?

I ask, because I need to plan for a new system who's primary purpose is x265 encoding, and one of these in the appropriate system, although very expensive, could be a dream come true.

Especially if you consider that a Ryzen/Kaby Lake might top out at about 40-60% speed increase over my current rig, but a Xeon+VCA2 would get me a 250-500% (?) speed increase! That would be worth it over the lifespan just in time savings/productivity increases alone.

[x265_Project]

I understand that your recent collaboration with HaiGear Labs exploited expensive, but otherwise completely generic, Intel Visual Compute Accelerator 2's accessed via your UHDKit to produce those 4Kp60 real-time streaming results.

Given your hint at "various instruction sets", does this mean that one of these:

http://www.intel.com/content/www/us/en/servers/accelerators/visual-compute-accelerator-2.html

is currently the closest thing we can get to a proper Multicoreware x265 (not anyone else's "HEVC") hardware encoder card?

Of course, I can see at least these two flies swimming in the ointment:

1) The VCA2 hardware support was custom coded by Haivision, not Multicoreware
2) The VCA2 hardware support was coded by Multicoreware, but is only available through the UHDKit API, not the x265 CLI

Additionally, if x265 does include optimised instruction support for the VCA2, does that mean that the VCA (1st one, which is now half the cost) is also supported?

Is there any clarification that you can make on this?

I ask, because I need to plan for a new system who's primary purpose is x265 encoding, and one of these in the appropriate system, although very expensive, could be a dream come true.

Especially if you consider that a Ryzen/Kaby Lake might top out at about 40-60% speed increase over my current rig, but a Xeon+VCA2 would get me a 250-500% (?) speed increase! That would be worth it over the lifespan just in time savings/productivity increases alone.
Haivision demonstrated an experimental version of UHDkit that didn't rely on Intel's VCA board. UHDkit was running multiple instances of x265 in a new configuration. This new version is showing promising results for live encoding scenarios, but it is not fully optimized, so it's too soon to share design details or test results.

That doesn't mean we won't look to find ways to accelerate x265 using VCA or similar hardware.

[x265_Project]

Now is slow time for beginning of AVX-512 optimisation though whole x265 code.

What are the plans about it?

Gesendet von meinem GT-I9295 mit Tapatalk
We plan to optimize x265 with AVX-512 instructions, as soon as possible.

[Romario]

We plan to optimize x265 with AVX-512 instructions, as soon as possible.
What speed gains are possible, when all is finished?

Gesendet von meinem GT-I9295 mit Tapatalk

[uneedme]

Hi all

I am a little confused the Lambda Table is auto applied on 2.4 version? No need to refer to the csv files using -- lambda file?

If the parameter table （csv file） is optimized where can i find the latest one？

Cheers

[LigH]

See: commit 94d59c3 (2017-04-13) (https://bitbucket.org/multicoreware/x265/commits/94d59c325e975888e4f7b152cc90b4199d9d24c4)

The lambda tables are not in separate CSV files, but in source/common/constants.cpp (you would have to extract them to separate CSV files if you wanted to switch them "on demand").

I don't know which syntax they have to use if provided as CSV. One value per line?

[x265_Project]

I am a little confused the Lambda Table is auto applied on 2.4 version? No need to refer to the csv files using -- lambda file?

Correct. v2.4 incorporates the new lambda tables.

[x265_Project]

See: commit 94d59c3 (2017-04-13) (https://bitbucket.org/multicoreware/x265/commits/94d59c325e975888e4f7b152cc90b4199d9d24c4)

The lambda tables are not in separate CSV files, but in source/common/constants.cpp (you would have to extract them to separate CSV files if you wanted to switch them "on demand").

I don't know which syntax they have to use if provided as CSV. One value per line?
Yes. Externally referenced lambda tables have one value per line. There are 70 entries for lambda, and 70 more for lambda2. Blank lines are ignored, so I usually insert a blank line in between lambda and lambda2.

[brumsky]

What speed gains are possible, when all is finished?

Gesendet von meinem GT-I9295 mit Tapatalk

I too would like to know this.

[x265_Project]

What speed gains are possible, when all is finished?
Speedup from SIMD instructions like AVX-512 varies a lot, depending on the machine you're using (and # of cores/threads you're using), the x265 preset you're running, and the picture size of the video. For AVX-2, we saw as much as a 53% speedup on a Haswell generation server (E5-2699 v3) for 4K Ultrafast at CRF 22, and as little as 0% speedup for medium preset (increasing again to ~ 10% speedup for veryslow preset).

You can easily test this yourself on any Haswell or later generation Intel chip, simply by running a job once as usual, and then again (after your system has cooled down) with --asm avx, which will turn off AVX-2 optimization. To get valid results you would need to be testing only x265 and not FFMPEG (so, encode from a YUV file to an HEVC bitstream, ideally from and to a RAMdisk to eliminate I/O bottlenecks as a factor).

We expect even bigger gains on Purley generation (E5 v5) Xeons and Skylake Extreme Edition chips due to the higher internal memory bandwidth and many other CPU improvements.

[Romario]

Speedup from SIMD instructions like AVX-512 varies a lot, depending on the machine you're using (and # of cores/threads you're using), the x265 preset you're running, and the picture size of the video. For AVX-2, we saw as much as a 53% speedup on a Haswell generation server (E5-2699 v3) for 4K Ultrafast at CRF 22, and as little as 0% speedup for medium preset (increasing again to ~ 10% speedup for veryslow preset).

You can easily test this yourself on any Haswell or later generation Intel chip, simply by running a job once as usual, and then again (after your system has cooled down) with --asm avx, which will turn off AVX-2 optimization. To get valid results you would need to be testing only x265 and not FFMPEG (so, encode from a YUV file to an HEVC bitstream, ideally from and to a RAMdisk to eliminate I/O bottlenecks as a factor).

We expect even bigger gains on Purley generation (E5 v5) Xeons and Skylake Extreme Edition chips due to the higher internal memory bandwidth and many other CPU improvements.
Ok, thank you. And do you know in which tineframe will AVX-512 support be finished?

For x265 2.6 Version?

Gesendet von meinem GT-I9295 mit Tapatalk

[NikosD]

We plan to optimize x265 with AVX-512 instructions, as soon as possible.
And what about RyZen architecture (not SIMD specifically) optimizations ?

[x265_Project]

Ok, thank you. And do you know in which time frame will AVX-512 support be finished?
For x265 2.6 Version?
I can't say at this point. We're actively trying to figure out how to get it done as soon as possible, but it's a big project.

[x265_Project]

And what about RyZen architecture (not SIMD specifically) optimizations?
As with all platforms, we're always reaching out to hardware companies to find ways to optimize performance. There is nothing I can update you on (with respect to Ryzen) at this time.

[NikosD]

As with all platforms, we're always reaching out to hardware companies to find ways to optimize performance. There is nothing I can update you on (with respect to Ryzen) at this time.
Interesting.

No help from AMD ?

Seems strange to me, since they are trying hard to be close to developers especially now, since Zen is a very new and promising architecture.

[Sagittaire]

To get valid results you would need to be testing only x265 and not FFMPEG (so, encode from a YUV file to an HEVC bitstream, ideally from and to a RAMdisk to eliminate I/O bottlenecks as a factor).

hhmmm ... if you use ffmpeg like frameserver, you have by far better speed decoding than speed encoding if you use medium (and higher) preset.

ffmpeg\ffmpeg.exe -i Sample\Exodus_UHD_HDR_Exodus_draft.mp4 -an -f rawvideo - | x265\x265.exe --input-res 3840x2160 --fps 23.976 - -o Output\x265_2160p.265 --input-depth 10 --output-depth 10 --crf 24 --preset medium --tune grain --bframes 3 --min-keyint 1 --qcomp 0.75 --ssim --psnr

with that you have less than 5% of CPU charge for HEVC stream decoding without I/O bottlenecks.

[x265_Project]

Interesting.

No help from AMD ?
I didn't say that.

You have to understand that our conversations with our chip partners are confidential. They wouldn't want me to characterize or elaborate on the extent of their support or cooperation, or in some cases, the lack thereof. When we have some improvements or progress to report, we'll let you know. From our perspective, you can be sure that we want more performance on every platform, and we're doing everything possible to get it.

[x265_Project]

hhmmm ... if you use ffmpeg like frameserver, you have by far better speed decoding than speed encoding if you use medium (and higher) preset.

with that you have less than 5% of CPU charge for HEVC stream decoding without I/O bottlenecks.
Performance measurement is a tricky thing. You don't just have the CPU % to consider. You also have to consider data availability (cache poisoning) and data dependencies (x265 waiting for decoded frames from FFMPEG, for example). When you're trying to measure the effect of SIMD optimization on a particular workload, you want to make sure that's the only workload running. We do this at both the kernel level and the full x265 library level.

[NikosD]

I didn't say that.

You have to understand that our conversations with our chip partners are confidential. They wouldn't want me to characterize or elaborate on the extent of their support or cooperation, or in some cases, the lack thereof. When we have some improvements or progress to report, we'll let you know. From our perspective, you can be sure that we want more performance on every platform, and we're doing everything possible to get it.

Thank you for your reply.

I'm always here to help.

Agner's optimization manuals including RyZen have just released here:
http://www.agner.org/optimize/optimization_manuals.zip

Impressive low-level performance for RyZen in instruction latency/ throughput, most of the times looks on par or even faster than Intel in IPC, something that we haven't seen so far due to other limitations obviously.

[LigH]

The long awaited:

x265 2.4+6-fd01abfc7898 (https://www.mediafire.com/file/qskcb7il5jdrot7/x265_2.4%2B6-fd01abfc7898.7z) (merge with stable) contains an additional multi-lib EXE with Dynamic HDR10 enabled.

[jlpsvk]

Can I use multilib EXE with DHDR enbled for encoding non-HDR and normal HDR?

[LigH]

Of course. Just don't specify DynamicHDR10 control files.

[elahn]

I'm liking the new 10-bit lambda tables, thank you x265 developers! So far, I'm finding a declination of 0.3 CRF is appropriate when targeting a similar size/quality to the old lambda tables.

--crf 20 --preset slow --tune grain --profile main10 --no-strong-intra-smoothing --deblock -3:0 --rskip --ctu 32

While CRF 20.3 is good enough for many sources, I choose CRF 20 when I want better quality. For my eyes, anything worse than CRF 20.3 when combined with --tune grain is not worth it.

Could someone please explain why encoding an 8-bit AVC source as 10-bit x265 is higher quality than 8-bit x265? It boggles my mind and I can't help but question whether I've misunderstood the intention behind certain comments in this thread.

I suspect my last comment is only visible to moderators for some reason since it never appeared in the thread, yet benwaggoner replied (https://forum.doom9.org/showthread.php?p=1802854#post1802854) to it. The quoted text is not the full comment. For context, I'm tuning for optimal file size without encoding much slower than the command line above, given a quality constraint.

[LigH]

Modern video encoders don't store the pixels in a video frame; they transform parts of it into a spectrum of visual frequencies and store their parameters. An encoder with 8 bit precision stores up to 256 different frequency parameter values. An encoder with 10 bit precision may store up to 1024 different values. Where an 8 bit encoder has to decide between n and n+1, a 10 bit encoder as 4 times the number of values to store the frequency parameters as precise as possible. Precision can be a trade-off: On one hand, more different numbers take more space; on the other hand, more precise encoding may leave less difference and lead to more efficient compression, especially with predicted (P, B) frames. Many people reported 10-bit x264 being quite efficient for cartoons, in comparison to 8-bit x264.

Re-coding one lossy format with another lossy format may look worse where the second encoder wastes bitrate on quantization errors the first encoder already left in the video frames. It's quite possible that one kind of quantization (similar to integer division while encoding, and multiplication while decoding) does not match the factor of the other, leaving occasional larger gaps in the "stair steps" between re-quantized parameters. Try for yourself, calculate at first the closest multiple of - let's say - 5 to a range of natural numbers, and then, the closest multiple of 7 to this result. You will notice that the steps get more irregular.

[Boulder]

Many people reported 10-bit x264 being quite efficient for cartoons, in comparison to 8-bit x264.In x264, the 10-bit encode was usually 10-15% smaller in my tests (CRF mode, of course). In x265, the 10-bit encode is larger than the 8-bit one. The 12-bit x265 encode is once again smaller than the others :)

[nevcairiel]

In x264, the 10-bit encode was usually 10-15% smaller in my tests (CRF mode, of course). In x265, the 10-bit encode is larger than the 8-bit one. The 12-bit x265 encode is once again smaller than the others :)

You can't really compare sizes of the same settings with different bitdepths, a comparison here isn't very meaningful. The encoder makes different decisions based on the bitdepth, so not only can the size vary, but the quality as well.

A better comparison would be to tweak the rate-control settings to generate the exact same file size and then compare quality, or tweak quality settings to generate the exact same measurable quality and then compare sizes. Both are of course a bit involved processes, but its the only way to draw any sort of conclusion.

[Boulder]

You can't really compare sizes of the same settings with different bitdepths, a comparison here isn't very meaningful. The encoder makes different decisions based on the bitdepth, so not only can the size vary, but the quality as well.Hmm, I recall seeing a technical explanation as to why the 10-bit x264 encode is more efficient compression-wise than the 8-bit one. I was just wondering whether it's the same case here regarding the 12-bit x265 encode.

[LoRd_MuldeR]

Hmm, I recall seeing a technical explanation as to why the 10-bit x264 encode is more efficient compression-wise than the 8-bit one. I was just wondering whether it's the same case here regarding the 12-bit x265 encode.

Higher "internal" bit-depth of the Codec (encoder/decoder) results in higher compression efficiency, because there are less rounding errors in all the various intermediate stages - that's regardless of whether you are encoding a true "high bit-depth" source or an 8-Bit source. Encoding at 8-Bit rather than 10-Bit (or 12-Bit) is merely a speed hack. Or, if you think about hardware Codes, a way to save some silicon. If speed wasn't an issue, we could use 32-Bit right away.

Some people make the false assumption that encoding at 10-Bit/12-Bit requires a higher bit-rate than encoding at 8-Bit, because 10-Bit/12-Bit video contains more information (more LSB's) than 8-Bit video. But, when encoding at 10-Bit/12-Bit, you can compensate for that by using higher quantizers, thus retaining exactly as many "significant bits" as in a 8-Bit encode - and still get improved compression efficiency due to less rounding errors in the intermediate stages.

See also:
https://forum.doom9.org/showpost.php?p=1260621&postcount=19

[albt]

when the tune film will be released?

[nevcairiel]

Hmm, I recall seeing a technical explanation as to why the 10-bit x264 encode is more efficient compression-wise than the 8-bit one. I was just wondering whether it's the same case here regarding the 12-bit x265 encode.

The exact same argument doesn't apply fully anymore to H.265, since the internal precission was increased independent of the actual bitdepth, however there are still some gains - just not as high anymore as there were with H.264.

[Midzuki]

x265.exe 2.4+9-7ecd263f6d43

(GCC 7.1.0, Dynamic HDR10, multilib, x64)

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2485466#post2485466

[Khun_Doug]

when the tune film will be released?

There was some discussion back some months with folks picking their own favorite settings for something like tune=film. I haven't seen anything on that for some time now. I also was waiting but then another discussion on tune=grain explained that grain makes internal adjustments above and beyond CLI controls. Some simple tests proved it, so I am a believer.

Here is what I have found seems to work well. First, i am interested in retaining high quality rather than getting small compressed files. Generally, I have found 1 or 2 pass with grain, and set my bitrate in the range of 11000 and 12000. I also try a 10 minute segment to see how it compresses and use that as a guide to my bitrate and choice of 1 pass or 2 pass. I also have a few instances of using CRF 20 and grain.

Essentially, I start the compress when I am finished with the machine for the evening and let it run over night.

[albt]

There was some discussion back some months with folks picking their own favorite settings for something like tune=film. I haven't seen anything on that for some time now. I also was waiting but then another discussion on tune=grain explained that grain makes internal adjustments above and beyond CLI controls. Some simple tests proved it, so I am a believer.

Here is what I have found seems to work well. First, i am interested in retaining high quality rather than getting small compressed files. Generally, I have found 1 or 2 pass with grain, and set my bitrate in the range of 11000 and 12000. I also try a 10 minute segment to see how it compresses and use that as a guide to my bitrate and choice of 1 pass or 2 pass. I also have a few instances of using CRF 20 and grain.

Essentially, I start the compress when I am finished with the machine for the evening and let it run over night.

I'm talking about small files, but even for this, at x264 there is small difference from the big file, while at the x265 there is more difference. When using normal x265 settings, it changes things a lot, tune grain is made for big sizes, while tune film suggested here is good but needs some improvements I think.

[benwaggoner]

You can't really compare sizes of the same settings with different bitdepths, a comparison here isn't very meaningful. The encoder makes different decisions based on the bitdepth, so not only can the size vary, but the quality as well.

A better comparison would be to tweak the rate-control settings to generate the exact same file size and then compare quality, or tweak quality settings to generate the exact same measurable quality and then compare sizes. Both are of course a bit involved processes, but its the only way to draw any sort of conclusion.
...plus "measurable quality" is very challenging to measure in a well subjectively correlated way, particularly when comparing different bit depths. Of the built-in x265 metrics, SSIM is the best, but still has lots of limitations. And the relevance of the mean of all frames is also questionable for content more than a few seconds long. A CBR and a VBR encode might have the same mean SSIM, but the CBR have wildly oscillating values and a much worse subjective viewer experience.

Comparing subjective quality at the same file size and parameters (bitrate, max-vbv, max-bufsize) is really the only reliable way to measure subtle quality differences.

[Ma]

x265 seem really powerfull at quantizer ~25 with default setting. It's certainely the best quantizer area for make comparison. 1000 kbps for 2K source at q35 have definitely too low visual quality.

For curiosity I've encoded 2K version of Tears of Steel @ 2000 kbit/s, the quality is much better.

Command line:f:\speed\tear>ffmpeg -i ../tearsofsteel-4k.y4m -pix_fmt yuv420p16 -vf "scale=1920:-4:flags=bicubic+accurate_rnd+full_chroma_int+
full_chroma_inp:param0=-0.5:param1=0.25,setsar=1" -v warning -strict -1 -f yuv4mpegpipe - | x265 --y4m - --bitrate 2000 -p9 --de
block -1 --keyint 480 --multi-pass-opt-distortion -o p1m.hevc --pass 1
[yuv4mpegpipe @ 000000000046c9c0] Warning: generating non standard YUV stream. Mjpegtools will not work.
y4m [info]: 1920x804 fps 24/1 i420p16 sar 1:1 unknown frame count
raw [info]: output file: p1m.hevc
x265 [info]: HEVC encoder version 2.4+14-bc0e9bd7c08f
x265 [info]: build info [Windows][MSVC 1910][64 bit] 10bit+8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-2000 kbps / 0.60
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 tskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-write
x265 [info]: frame I: 129, Avg QP:22.35 kb/s: 13618.64
x265 [info]: frame P: 3666, Avg QP:24.43 kb/s: 5747.81
x265 [info]: frame B: 13825, Avg QP:30.17 kb/s: 845.36
x265 [info]: Weighted P-Frames: Y:5.5% UV:4.3%
x265 [info]: Weighted B-Frames: Y:3.8% UV:2.6%
x265 [info]: consecutive B-frames: 10.7% 5.3% 7.8% 27.8% 16.8% 15.1% 4.2% 6.4% 6.0%

encoded 17620 frames in 81497.66s (0.22 fps), 1958.88 kb/s, Avg QP:28.92

f:\speed\tear>ffmpeg -i ../tearsofsteel-4k.y4m -pix_fmt yuv420p16 -vf "scale=1920:-4:flags=bicubic+accurate_rnd+full_chroma_int+
full_chroma_inp:param0=-0.5:param1=0.25,setsar=1" -v warning -strict -1 -f yuv4mpegpipe - | x265 --y4m - --bitrate 2000 -p9 --de
block -1 --keyint 480 --multi-pass-opt-distortion -o p2m.hevc --pass 2
[yuv4mpegpipe @ 00000000004ec9c0] Warning: generating non standard YUV stream. Mjpegtools will not work.
y4m [info]: 1920x804 fps 24/1 i420p16 sar 1:1 unknown frame count
raw [info]: output file: p2m.hevc
x265 [info]: HEVC encoder version 2.4+14-bc0e9bd7c08f
x265 [info]: build info [Windows][MSVC 1910][64 bit] 10bit+8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 5 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 60 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-2000 kbps / 0.60
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 tskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-read
x265 [info]: frame I: 129, Avg QP:20.66 kb/s: 15524.06
x265 [info]: frame P: 3666, Avg QP:25.10 kb/s: 5673.36
x265 [info]: frame B: 13825, Avg QP:30.80 kb/s: 897.89
x265 [info]: Weighted P-Frames: Y:2.2% UV:1.8%
x265 [info]: Weighted B-Frames: Y:0.9% UV:0.6%
x265 [info]: consecutive B-frames: 10.7% 5.3% 7.8% 27.8% 16.8% 15.1% 4.2% 6.4% 6.0%

encoded 17620 frames in 74910.62s (0.24 fps), 1998.55 kb/s, Avg QP:29.54

Video: www.msystem.waw.pl/x265/tears-2Mbps.mkv

[Midzuki]

x265.exe 2.4+22-c102c809fc4f

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2485922#post2485922

[zub35]

Please rename the existing preset "placebo" in "superslow" and new (true) preset "placebo":
+ bframes=16 ref=16 rc-lookahead=120 me=full subme=7 frame-threads=1

[benwaggoner]

Please rename the existing preset "placebo" in "superslow" and new preset "placebo":
+ bframes=16 ref=16 rc-lookahead=120 me=full subme=7 frame-threads=1
Well, if we are going FULL PLACEBO, we should also add:

--cu-lossless
--ref 6
--tskip

And for psychovisual optimization, --aq-mode 3 would likely help.

Also, this looks like just the first pass of what's intended to be a multipass encode. Presuming this is meant to be VBR, doing a second pass would improve quality significantly.

[sneaker_ger]

ref 16 is not even allowed in HEVC spec.

[zub35]

sneaker_ger That's right, my mistake. As said benwaggoner, ref=6
benwaggoner Psychovisual optimization is an additional correction, Not in the compression category options presets. This is closer to "tune" presets.

[LigH]

x265 2.4+22-c102c809fc4f (https://www.mediafire.com/file/i2aev4frrc9joa5/x265_2.4%2B22-c102c809fc4f.7z)

adds CTUInfo API (seems to be a debug feature, quite time consuming) and an AVX2 framework of integral functions to speed up SEA motion search.

[pradeeprama]

x265 2.4+22-c102c809fc4f (https://www.mediafire.com/file/i2aev4frrc9joa5/x265_2.4%2B22-c102c809fc4f.7z)

adds CTUInfo API (seems to be a debug feature, quite time consuming) and an AVX2 framework of integral functions to speed up SEA motion search.

The CTUInfo API is a new API introduced to enable applications that include the x265 library to provide additional information about certain locations in the video that have to be treated differently than the rest of the video. Though a combination of the CTUInfo API and the --ctuinfo options, a partition shape can be forced on the region of interest passed via this API and encoding parameters can be controlled as described in the online docs.

[x265_Project]

Please rename the existing preset "placebo" in "superslow" and new (true) preset "placebo":
+ bframes=16 ref=16 rc-lookahead=120 me=full subme=7 frame-threads=1
We look at our performance presets every so often, and we run a large batch of tests to determine the optimal combination of settings to achieve the best speed vs. compression efficiency trade-off for each of the 10 presets. I take responsibility for our preset strategy. The strategy for --preset placebo has not been to make every possible speed trade-off in search of every last possible bit of quality. Rather, this point on the speed vs. efficiency curve is the slowest possible encoding speed that we believe any reasonable person would tolerate. Maybe it will take more than a day to encode a short video, but it won't take weeks or months. It's generally well beyond the point of diminishing returns. Certainly, you can modify some settings to go even slower (and we've experimented with all of these, except the newer options like --me sea or --me full), but you will likely see almost no visible benefits. Now, if someone shows me that there are real compression efficiency benefits to be gained, we'll consider making placebo even slower. You would have to run some tests, using placebo vs. your modified placebo, and show that at the same bit rate, your modified placebo setting achieves visibly higher subjective visual quality. But no one is going to use placebo if it encodes one frame per minute.

Reminder... we care only about subjective visual quality at identical bit rates, not objective measurements like PSNR or SSIM.

Tom

[nakTT]

We look at our performance presets every so often, and we run a large batch of tests to determine the optimal combination of settings to achieve the best speed vs. compression efficiency trade-off for each of the 10 presets. I take responsibility for our preset strategy. The strategy for --preset placebo has not been to make every possible speed trade-off in search of every last possible bit of quality. Rather, this point on the speed vs. efficiency curve is the slowest possible encoding speed that we believe any reasonable person would tolerate. Maybe it will take more than a day to encode a short video, but it won't take weeks or months. It's generally well beyond the point of diminishing returns. Certainly, you can modify some settings to go even slower (and we've experimented with all of these, except the newer options like --me sea or --me full), but you will likely see almost no visible benefits. Now, if someone shows me that there are real compression efficiency benefits to be gained, we'll consider making placebo even slower. You would have to run some tests, using placebo vs. your modified placebo, and show that at the same bit rate, your modified placebo setting achieves visibly higher subjective visual quality. But no one is going to use placebo if it encodes one frame per minute.

Reminder... we care only about subjective visual quality at identical bit rates, not objective measurements like PSNR or SSIM.

Tom
Thanks for a very nice clarification. Now I understand more on the reasons behind x265 presets, especially the placebo.



Btw, any of you guys think that it is wise for me to encode videos with resolution 640*272 using x265 Very Slow preset at the bitrate of 300kbps for the video? Is there any way for me to be more efficient?

Thank you in advance. :thanks:

[Ma]

I've made some tests with true placebo option -- 2-pass encoding first 2160 frames of big_buck_bunny_1080p24.y4m.

common options was:
-D8 --bitrate 1500 -I480 --psnr --ssim -p9 --no-psy-rd --multi-pass-opt-distortion -f2160 --pass 1/2

Results:
Global PSNR | SSIM Mean Y (dB) | tested/additional options:
44.055 | 17.401 | no additional options
44.043 | 17.392 | --cu-lossless
44.041 | 17.388 | --cu-lossless --me sea
44.078 | 17.408 | --rc-lookahead 100
44.083 | 17.409 | --rc-lookahead 100 --bframes 10
44.093 | 17.418 | --rc-lookahead 120 --bframes 12
44.107 | 17.433 | --rc-lookahead 120 --bframes 12 --ref 6
44.115 | 17.440 | --rc-lookahead 120 --bframes 12 --ref 6 --subme 7
44.120 | 17.442 | --rc-lookahead 120 --bframes 12 --ref 6 --subme 7 -F1

Full results in attachment.

Only --cu-lossless and --me sea make the result PSNR/SSIM worse and --me sea is a big slow down. I've tried to test --me full, but encoding speed was about 0.03 fps, so I given up.

From my test the true placebo option is:
-p9 --rc-lookahead 120 --bframes 12 --ref 6 --subme 7 -F1
--------------------------
Sample to watch: 2K version of Big Buck Bunny encoded @ 1500 kbps with true placebo option: www.msystem.waw.pl/x265/bb1500.mkv
Encoder output:
f:\speed\2.4+25>x265 -D8 --bitrate 1500 -I480 --psnr --ssim -p9 --no-psy-rd --multi-pass-opt-distortion --rc-lookahead 120 --bfr
ames 12 --ref 6 --subme 7 -F1 ../big_buck_bunny_1080p24.y4m btp1.hevc --pass 1
y4m [info]: 1920x1080 fps 24/1 i420p8 sar 1:1 frames 0 - 14314 of 14315
raw [info]: output file: btp1.hevc
x265 [info]: HEVC encoder version 2.4+25-b4149e898b50
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 1 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 7 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 120 / 12 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 6 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1500 kbps / 0.60
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rdoq=1.00 tskip signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao stats-write
x265 [info]: frame I: 132, Avg QP:20.77 kb/s: 23917.87 PSNR Mean: Y:47.813 U:50.299 V:50.809 SSIM Mean: 0.989789 (19.909dB
)
x265 [info]: frame P: 3202, Avg QP:24.87 kb/s: 4070.12 PSNR Mean: Y:44.882 U:48.155 V:48.646 SSIM Mean: 0.984755 (18.169dB
)
x265 [info]: frame B: 10981, Avg QP:31.11 kb/s: 480.10 PSNR Mean: Y:44.928 U:48.058 V:48.668 SSIM Mean: 0.984954 (18.226dB
)
x265 [info]: Weighted P-Frames: Y:6.7% UV:4.7%
x265 [info]: Weighted B-Frames: Y:2.5% UV:1.7%
x265 [info]: consecutive B-frames: 10.3% 13.5% 13.5% 30.6% 8.1% 10.0% 3.1% 4.6% 1.6% 1.3% 0.9% 1.1% 1.6%

encoded 14315 frames in 71887.79s (0.20 fps), 1499.24 kb/s, Avg QP:29.62, Global PSNR: 45.806, SSIM Mean Y: 0.9849541 (18.226 dB
)

f:\speed\2.4+25>x265 -D8 --bitrate 1500 -I480 --psnr --ssim -p9 --no-psy-rd --multi-pass-opt-distortion --rc-lookahead 120 --bfr
ames 12 --ref 6 --subme 7 -F1 ../big_buck_bunny_1080p24.y4m btp2.hevc --pass 2
y4m [info]: 1920x1080 fps 24/1 i420p8 sar 1:1 frames 0 - 14314 of 14315
raw [info]: output file: btp2.hevc
x265 [info]: HEVC encoder version 2.4+25-b4149e898b50
x265 [info]: build info [Windows][MSVC 1910][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main profile, Level-5 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 1 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 7 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 120 / 12 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 6 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1500 kbps / 0.60
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rdoq=1.00 tskip signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao stats-read
x265 [info]: frame I: 132, Avg QP:20.86 kb/s: 23111.23 PSNR Mean: Y:48.060 U:50.452 V:50.964 SSIM Mean: 0.990132 (20.057dB
)
x265 [info]: frame P: 3202, Avg QP:26.04 kb/s: 4188.95 PSNR Mean: Y:44.876 U:48.047 V:48.562 SSIM Mean: 0.985262 (18.316dB
)
x265 [info]: frame B: 10981, Avg QP:32.33 kb/s: 456.05 PSNR Mean: Y:44.802 U:47.901 V:48.521 SSIM Mean: 0.985439 (18.368dB
)
x265 [info]: Weighted P-Frames: Y:1.1% UV:0.5%
x265 [info]: Weighted B-Frames: Y:0.6% UV:0.4%
x265 [info]: consecutive B-frames: 10.3% 13.5% 13.5% 30.6% 8.1% 10.0% 3.1% 4.6% 1.6% 1.3% 0.9% 1.1% 1.6%

encoded 14315 frames in 52657.88s (0.27 fps), 1499.94 kb/s, Avg QP:30.82, Global PSNR: 45.700, SSIM Mean Y: 0.9854429 (18.369 dB
)

[Atak_Snajpera]

Thanks for a very nice clarification. Now I understand more on the reasons behind x265 presets, especially the placebo.



Btw, any of you guys think that it is wise for me to encode videos with resolution 640*272 using x265 Very Slow preset at the bitrate of 300kbps for the video? Is there any way for me to be more efficient?

Thank you in advance. :thanks:
For such ultra low resolutions you should stick with x264. x265 works best with FHD+ resolutions. 640x272 is less than DVD.

[divxmaster]

Thanks for a very nice clarification. Now I understand more on the reasons behind x265 presets, especially the placebo.



Btw, any of you guys think that it is wise for me to encode videos with resolution 640*272 using x265 Very Slow preset at the bitrate of 300kbps for the video? Is there any way for me to be more efficient?

Thank you in advance. :thanks:

This is possible, but under certain situations. I have done a lot of work with very low bitrate x265. It depends on what screen size you are viewing it on. For phone and tablet viewing, I have found even much lower bitrates to work fine.
For example, with stargate sg1, I keep the full resolution, 720x480, and encode with crf28 and nrintra 400, nrinter 400. I wouldnt normally use those, but on a small screen you cannot really see the detail loss.
Using 10bit is essential, it allows low bitrate and removes any banding due to that. The bitrates I have for s05e22 is only 119kbps! No macroblocking, etc... Heck I even just watch a bit on my 15.6 laptop screen and it is watchable. But not on a big screen, say 48".
Note this is on older versions of x265 (1.8+106), I havent tried new versions yet. I can provide full parameters if you wish.

Cheers,
Divxmaster

[Dclose]

Btw, any of you guys think that it is wise for me to encode videos with resolution 640*272 using x265 Very Slow preset at the bitrate of 300kbps for the video? Is there any way for me to be more efficient?
You might find 360p (and aspect ratio equivalents) resolution (with possibly higher cfr to compensate for size) is worth it over 272p and 288p since x265 likes resolution more than texture at extreme low bitrates, and 360p seems to add just enough extra res to go from a 288p video that's "ewww" to "eh, I've seen worse."

You might even find 200 kbps or less tolerable.

720p at CFR of 28 or even higher can look surprisingly good (relatively speaking) especially the farther away/smaller the screen you watch it since when farther away grain/texture goes away and you focus more on edges of objects. But that setting will still usually use more bitrate than a "eh, I've seen worse" 360p resolution.

A main problem of higher resolution still comes down to x265 being so slow. 720p is a lot slower than 360p resolution. At extreme low bitrate, 720p may not be worth the encoding time and electricity over 360p resolution if you're just going for small size and tolerable quality.
For such ultra low resolutions you should stick with x264. x265 works best with FHD+ resolutions. 640x272 is less than DVD.
I disagree. The lower the resolution and bitrate, the more x265 shines over x264. x265 makes extreme low bitrate and res tolerable to watch compared to x264 making it unwatchable.

[sneaker_ger]

x265 shines at low bitrates compared to x264 but lower resolutions don't increase that effect, they decrease it. So x265 becomes better with decreasing bitrate and increasing resolution.

[Dclose]

x265 shines at low bitrates compared to x264 but lower resolutions don't increase that effect, they decrease it. So x265 becomes better with decreasing bitrate and increasing resolution.
I don't see (literally!) :) why x264 is better. x265 is known for less inherent detail/grain than x264, and that doesn't matter much at extreme low bitrate/res, and x265 is better than x264 at "holding the picture together" for lack of a better term, regardless of resolution.

I've encoded lots of extreme-low bitrate stuff at 360p, 288p, all the way down to around 150p, with x265. I've tried to do the same with x264 on Placebo and it's just a macroblocking mess. That's not to say x265 at extreme-low bitrate/res is great to look at, but it's not as messy as x264 is.

Basically, at such low bitrate/resolution, what I would consider unwatchable on x264 I consider watchable with x265.

[LigH]

Different people have a different taste. How many pages did people already discuss the loss of details which they did not enjoy. There are people who can tolerate some compression artefacts easier than a "sterile" result... But that happens with rather convenient bitrates.

[sneaker_ger]

I don't see (literally!) :) why x264 is better.
I didn't say x264 is better at low resolution/low bitrate. The point of my post is: if you lower the resolution the gap between x264 and x265 will close, not widen.

[benwaggoner]

x265 shines at low bitrates compared to x264 but lower resolutions don't increase that effect, they decrease it. So x265 becomes better with decreasing bitrate and increasing resolution.
Another way to look at it is that x265 can use a higher resolution than x264 at the same bitrate, and deliver more detail that way.

[nakTT]

For such ultra low resolutions you should stick with x264. x265 works best with FHD+ resolutions. 640x272 is less than DVD.
Thanks for the reply.

I was having the same thought to. However, based on results of quite an extensive test, x265 @ "Very Slow" preset (both 8 and 10 bit) is still noticeably better to the eyes than x264 @ "Placebo" preset (both 8 and 10 bit) even at such a low resolution and bitrate.

I do wonder if there are any settings besides a simple "Very Slow" preset (with Automated 2-Pass) that I have used that could help me further in term of visual quality without sacrificing the encoding speed too much. Hope you guys could share a thought on this.

Thank you in advance.:thanks:

This is possible, but under certain situations. I have done a lot of work with very low bitrate x265. It depends on what screen size you are viewing it on. For phone and tablet viewing, I have found even much lower bitrates to work fine.
For example, with stargate sg1, I keep the full resolution, 720x480, and encode with crf28 and nrintra 400, nrinter 400. I wouldnt normally use those, but on a small screen you cannot really see the detail loss.
Using 10bit is essential, it allows low bitrate and removes any banding due to that. The bitrates I have for s05e22 is only 119kbps! No macroblocking, etc... Heck I even just watch a bit on my 15.6 laptop screen and it is watchable. But not on a big screen, say 48".
Note this is on older versions of x265 (1.8+106), I havent tried new versions yet. I can provide full parameters if you wish.

Cheers,
Divxmaster
Thanks for the advice.

Seems like both of us share the same interest, at least as far as the very low bitrates and resolutions video encoding are concerned.

Speaking of the use of 10bit option in x265 encoding, does 12bit offer any advantage over the 10bit? I have done some testing but I can't really tell if there are any improvements in the subjective visual quality. Did you came across any situation where it does? Btw, im using "Very Slow" preset (with Automated 2-Pass) to keep the video within the selected average bitrate. Hope to hear from you soon.

Thank you in advance.:thanks:

You might find 360p (and aspect ratio equivalents) resolution (with possibly higher cfr to compensate for size) is worth it over 272p and 288p since x265 likes resolution more than texture at extreme low bitrates, and 360p seems to add just enough extra res to go from a 288p video that's "ewww" to "eh, I've seen worse."

You might even find 200 kbps or less tolerable.

720p at CFR of 28 or even higher can look surprisingly good (relatively speaking) especially the farther away/smaller the screen you watch it since when farther away grain/texture goes away and you focus more on edges of objects. But that setting will still usually use more bitrate than a "eh, I've seen worse" 360p resolution.

A main problem of higher resolution still comes down to x265 being so slow. 720p is a lot slower than 360p resolution. At extreme low bitrate, 720p may not be worth the encoding time and electricity over 360p resolution if you're just going for small size and tolerable quality.
Thanks for the reply.

I have done some further testing with 200kbps bitrate per your advice and it is indeed tolerable in quite a few use case.

As for a lower bitrates, I did quite a few testing using anime input with x264 (during its heyday) and found that even 150kbps bitrate is very much tolerable. However I have yet to give x265 a try with the same anime input. Do let me know if you have tried it with x265.

Thank you in advance.:thanks:

[divxmaster]

Hi NakTT,
here are the params I used.... Although I use low bitrate, I dont use low res... not necessary...

set param=--y4m --crf 28 --psy-rd 0.3 --limit-modes --limit-refs 3 --preset slow --b-intra --ref 5 --bframes 5 --max-merge 5 --nr-intra 400 --nr-inter 400 --sar %sar% --no-open-gop --min-keyint 23 --keyint 288 --deblock -1:-1

Note this is a year old, so not optimised for latest x265 but it still works great. For phone and tablet encodes only!! I havent tried 12 bit.
Cheers,
Divxmaster

[Barough]

x265 v2.4+27-e9e574bbed93 (http://www42.zippyshare.com/v/26AfVjXo/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 : HEVC encoder version 2.4+27-e9e574bbed93
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[I]HDR10+ Enabled

[x265_Project]

HDR10 Enabled
I think you meant to say HDR10+.

HDR10 has been enabled in x265 for 2 years.

[Barough]

x265 v2.4+28-f850cdbe381c (http://www115.zippyshare.com/v/HSVMHt3K/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 : HEVC encoder version 2.4+28-f850cdbe381c
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[I]HDR10+ Enabled

[eclipse98]

Back in Sept 2016 when we encoded our videos with x265 - took a bit of experimenting and we settled on pretty simple set-up with 2.0 build (slow preset, CRF26), 1080 60 fps footage at 6-8mbps.

Now, 9 months later with 2.4 build, exact same footage (same slow preset, CRF26 settings) encodes at around 10-15% higher bitrate - previously encoded 6000 kbps video is now in 6800-6900 kbps range.

Expectations were, of course, that given same CR we should see lower bit rate OR higher CR at same bit rate, so it's quite a disappointment to say the least.
Understandably presets have changed - but still one should expect improvements for the same CR.

What am I missing here ? Please advice ! :thanks:

[sneaker_ger]

Same CRF does not guarantee exact same quality with different settings and/or different x265 versions. If you want lower bitrate increase CRF a bit to compensate. If you want to compare old to new version encode to same bitrate using 2pass.

[Boulder]

The new lambda tables that were introduced recently increase the bitrate.

[LoRd_MuldeR]

The new lambda tables that were introduced recently increase the bitrate.

Increases bitrate for what?

If you use 2-Pass mode, then "old" and "new" lambda tables should produce the exactly same bitrate. And, if you use CRF mode, then you must not expect any particular bitrate anyway. It is likely that the introduction of the "new" lambda tables has changed the "meaning" of CRF values - once again. If, for example, the same CRF value results in a higher bitrate with "new" lambda tables, compared to "old" lambda tables, it means exactly nothing - because you are not taking into account at all how quality has changed at the same CRF value! Quite possibly, you can now (with "new" lambda tables) retain "similar" quality at a higher CRF value and therefore, in fact, get away with a lower bitrate...

So, if you want to do a "fair" comparison between the "old" and the "new" lambda tables, you have to compare clips with the exactly same average bitrate, i.e. clips created in 2-Pass mode. Then you can decide which one looks better.

(And once you have decided whether you prefer "old" or "new" lambda tables, you can re-adjust "your" CRF value for the new situation)

[LigH]

The "rate factor" is not a metric for a subjective quality impression. It is a measurable value for objective quality loss (~ difference between input and reconstructed video after quantization, possibly influenced by psycho-visual tweaks). Different encoding options may cause quality loss in different areas (e.g. frequency ranges), causing different bitrates despite the same CRF limit.

[Boulder]

Increases bitrate for what?

Quote Tom : "Note that a constant QP or CRF encode will probably be larger than your default encode"

If the user is using the exact same settings with the exact same video, the difference in the bitrate comes from the new lambda tables. My guess is that he has a lot of similar videos to encode and has found out the "average" bitrate level where they end up, and now the new version produces higher bitrates with the same settings.

What I personally did was that I adjusted CRF accordingly based on encoding the same couple of clips with the old and new lambdas (otherwise the same settings), so that the final result of the new version produces a slightly larger file.

[LoRd_MuldeR]

Quote Tom : "Note that a constant QP or CRF encode will probably be larger than your default encode"

If the user is using the exact same settings with the exact same video, the difference in the bitrate comes from the new lambda tables.

Yes. But it's more fundamental: If the user expects a certain fixed CRF value to result in a certain bitrate, then the user hasn't understood how CRF mode works. And, if the user thinks that comparing the bitrates that result from a certain fixed CRF value between different encoder configurations - may it be different lambda tables or something else - is meaningful (without considering how quality has changed as well!) hasn't understood how CRF mode works either.

It's all about compression efficiency, i.e. the "quality per bit" ratio. If some change (e.g. the "new" lambda tables) improves the compression efficiency, then it means that you can either get an improved quality at the same (average) bitrate, or that you can get a reduced (average) bitrate at the same quality. Conversely, if some change hurts the compression efficiency, then it means that you either get a worse quality at the same (average) bitrate, or that you get an increased (average) bitrate at the same quality. But, in any case, with CRF mode you simply do not know where exactly on the "quality/bitrate" curve you are going to end up. Therefore, it is quite possible that, even though the compression efficiency (i.e. the "quality per bit" ratio) has improved, the absolute bitrate - at a certain fixed CRF value - has increased as well! In the end, all you really know is that the absolute bitrate has changed and that the absolute quality (probably) has changed at the same time.

In order to draw a useful conclusion, at least one of the two factors - usually the average bitrate - needs to remain unchanged. Which means that you need to use 2-Pass mode, with same target bitrate, and then compare the resulting quality.

(In theory it is also possible to adjust the CRF value of each encode, until both configurations produce the exactly same quality and then compare the resulting bitrates. But this is much more difficult to do properly!)


What I personally did was that I adjusted CRF accordingly based on encoding the same couple of clips with the old and new lambdas (otherwise the same settings), so that the final result of the new version produces a slightly larger file.

IMO, the right method would be to adjust the CRF values until both - the "new" and the "old" lambda tables - produce the exactly same quality. Then, and only then, a comparison of the resulting bitrates would be meaningful.

But, because establishing "exactly same quality" is very difficult to do (probably would require a lot of ABX testing), it is much more easy to just encode in 2-Pass mode, at the same bitrate, and then decide which "flavor" looks better (if any).

[LigH]

x265 2.4+27-e9e574bbed93 (https://www.mediafire.com/file/406er6d04ob964k/x265_2.4%2B27-e9e574bbed93.7z) (merge with stable): more fields in rcStats and CSV file

[Atak_Snajpera]

x265_2.4+27-e9e574bbed93 (https://www.mediafire.com/file/406er6d04ob964k/x265_2.4%2B27-e9e574bbed93.7z) (merge with stable): more fields in rcStats and CSV file

Thanks. I have been waiting for your builds.

[x265_Project]

Back in Sept 2016 when we encoded our videos with x265 - took a bit of experimenting and we settled on pretty simple set-up with 2.0 build (slow preset, CRF26), 1080 60 fps footage at 6-8mbps.

Now, 9 months later with 2.4 build, exact same footage (same slow preset, CRF26 settings) encodes at around 10-15% higher bitrate - previously encoded 6000 kbps video is now in 6800-6900 kbps range.

Expectations were, of course, that given same CR we should see lower bit rate OR higher CR at same bit rate, so it's quite a disappointment to say the least.
Understandably presets have changed - but still one should expect improvements for the same CR.

What am I missing here ? Please advice ! :thanks:

As others have pointed out, the new lambda tables have changed the quality and bit rate you will achieve for a given QP or CRF value, with a given video title. To hit the same bit rate as before, you would have to adjust your QP or CRF value up a bit. We're confident, however, that you will achieve higher subjective quality at identical bit rates to your older encodes.

[Boulder]

IMO, the right method would be to adjust the CRF values until both - the "new" and the "old" lambda tables - produce the exactly same quality. Then, and only then, a comparison of the resulting bitrates would be meaningful.

But, because establishing "exactly same quality" is very difficult to do (probably would require a lot of ABX testing), it is much more easy to just encode in 2-Pass mode, at the same bitrate, and then decide which "flavor" looks better (if any).
That's why I trust the developers (and their QA people) and just adjusted the CRF to compensate. It was already enough work to initially find out the CRF level which will produce a good result with x265 without the bitrate skyrocketing :)

[pingfr]

As others have pointed out, the new lambda tables have changed the quality and bit rate you will achieve for a given QP or CRF value, with a given video title. To hit the same bit rate as before, you would have to adjust your QP or CRF value up a bit. We're confident, however, that you will achieve higher subjective quality at identical bit rates to your older encodes.

CRF 18 was mostly considered as the "sweet spot" with the 2.3 base, what would be it's equivalent now with 2.4?

[eclipse98]

As others have pointed out, the new lambda tables have changed the quality and bit rate you will achieve for a given QP or CRF value, with a given video title. To hit the same bit rate as before, you would have to adjust your QP or CRF value up a bit. We're confident, however, that you will achieve higher subjective quality at identical bit rates to your older encodes.

OK, that makes sense, we'll adjust CRF accordingly to hit similar bitrates. Appreciate everybody's input, keep up the good work !

Cheers !

[eclipse98]

Yes. But it's more fundamental: If the user expects a certain fixed CRF value to result in a certain bitrate, then the user hasn't understood how CRF mode works. And, if the user thinks that comparing the bitrates that result from a certain fixed CRF value between different encoder configurations - may it be different lambda tables or something else - is meaningful (without considering how quality has changed as well!) hasn't understood how CRF mode works either.

Thank you for the lesson! There was never an expectation that same CRF will result in same bitrate for different sources. Our goal was to maintain similar video quality across multiple (100+) videos. So CRF, rather than pre-defined bitrate, was an obvious (and faster) choice.

We observed bitrates from 2-10 mbps since our sources have quite significant variety, from wooded forests to almost desert-like conditions. Which is fine, as long as quality is "similar" (I understand it is very subjective).

Going forward we need to maintain that same "comparable" video quality. Clearly, recent changes in lambda tables (I have no clue what it is :)) did result in better quality and higher bitrates (for same settings) when compared to older encodes. So, it's back to the drawing board to find out which new CRF value will allow us to meet our goals.

Thanks again for all your help, Cheers !

[nakTT]

Hi NakTT,
here are the params I used.... Although I use low bitrate, I dont use low res... not necessary...

set param=--y4m --crf 28 --psy-rd 0.3 --limit-modes --limit-refs 3 --preset slow --b-intra --ref 5 --bframes 5 --max-merge 5 --nr-intra 400 --nr-inter 400 --sar %sar% --no-open-gop --min-keyint 23 --keyint 288 --deblock -1:-1

Note this is a year old, so not optimised for latest x265 but it still works great. For phone and tablet encodes only!! I havent tried 12 bit.
Cheers,
Divxmaster
Thanks for the reply.

I will give it a try and see if it works with the latest version of x265.

[Winston_Smith_101]

At 4.5.-8.5.2017 there were some speed optimizations in areas of the codec. Are there still more to be expected for the future?

[Midzuki]

x265.exe 2.4+36-de49a722b256

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2487738&viewfull=1#post2487738

[benwaggoner]

At 4.5.-8.5.2017 there were some speed optimizations in areas of the codec. Are there still more to be expected for the future?
x264 is still getting speed optimizations. x265 has years more ahead of it, I am sure. AVX-512 hardware is only just rolling out!

[Thunderbolt8]

arent there any real profiles or gui options to specify for x265 yet aside from the command line? at least in MeGUI there is nothing like that which is available for x264.

[benwaggoner]

arent there any real profiles or gui options to specify for x265 yet aside from the command line? at least in MeGUI there is nothing like that which is available for x264.



MeGUI just hasn't implemented a full GUI for x265 yet. Other products have much richer GUI options. It's all available via API.


Sent from my iPhone using Tapatalk

[x265_Project]

Apple adds HEVC support to iOS and MacOS ...https://www.cnet.com/news/apple-answers-iphone-storage-woes-with-smaller-photos-videos/

[LigH]

x265 2.4+36-de49a722b256 (https://www.mediafire.com/file/lrq9h0eb2jsdej6/x265_2.4%2B36-de49a722b256.7z)

New parameters:

--scale-factor <int> Specify factor by which input video is scaled down for analysis save mode. Default 0
--[no-]refine-intra Enable intra refinement for load mode. Default disabled
--[no-]refine-inter Enable inter refinement for load mode. Default disabled

[pradeeprama]

arent there any real profiles or gui options to specify for x265 yet aside from the command line? at least in MeGUI there is nothing like that which is available for x264.

You can give this consumer application a spin and see if it works out for you: https://x265.com/create-hevc-video/what-is-hevc/

[troica]

Is this x265 encoder using a C++ language (Microsoft Visual Studio)?

[sneaker_ger]

Yes, it's mostly written in C++. You can compile it using Visual Studio. For source code and compile instructions see: https://bitbucket.org/multicoreware/x265/wiki/Home

[troica]

Thank you!

Another question. If I want to know which source code lines do a specific thing (e.g. intracoding and intercoding mode of HEVC in the Encoder side), how do I run or debug each line? Is there a single step command? Thank you. It's for my thesis by the way.

[LigH]

Please read the documentation of your Visual Studio about how to use its debugger, how to set breakpoints on source lines, how to run a debugging session of a CLI application with command line parameters. That's just not the topic of this thread...

[troica]

I already know how to do that, what I mean is, is there some a way for us debuggers to see the actual modifications (e.g. in a video sequence) or do you really need to guess what parameters are being modified per line?

[LigH]

Debuggers usually allow to "watch expressions", so when a breakpoint is caught, you can usually inspect the value of specific variables at this point. And x265 is commercial-grade software with quite clean, verbose, and well documented sources, so you should find most variable and function names telling you something about their purpose.

[Natty]

in order to use --refine-mv we must have analysis = load and refine level = 10, but to use them we must disable mutlipass-opt-rps, multipass-opt-analysis and distortion. am i right ? :readrule:

[benwaggoner]

in order to use --refine-mv we must have analysis = load and refine level = 10, but to use them we must disable mutlipass-opt-rps, multipass-opt-analysis and distortion. am i right ? :readrule:
That sounds right. I'd like to better understand the pros/cons of each option.

One drawback to Refine Level 10 is HUGE log files. Typically a lot bigger than the encoded bitstream.

[Natty]

That sounds right. I'd like to better understand the pros/cons of each option.

One drawback to Refine Level 10 is HUGE log files. Typically a lot bigger than the encoded bitstream.

i get huge log (analysis) file even with refine level 5 to 9. i use 9. i cant use 10 though (along with refine-mv) because it needs new multipass options disabled. so i would like to know if those 3 multipass commands would produce a better result or refine-mv alone.

[Barough]

x265 v2.4+37-e75d5f5eeae3 (http://www23.zippyshare.com/v/4kIvr4MD/file.html) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.4+37-e75d5f5eeae3
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 2.4+41-82ba8c85f8e9 (https://www.mediafire.com/file/papx661ixcl4cgn/x265_2.4%2B41-82ba8c85f8e9.7z)

AVX2 speedup for integral4h; add support for hdr-opt even when aq-mode is disabled; moved CSV feature into libx265; fix slicetype mismatch between analysis save and load modes

[LigH]

x265 2.4+61-28bbc349d170 (GCC 6.3.0) (https://www.mediafire.com/file/g6ix29o274vg6tm/x265_2.4%2B61-28bbc349d170.GCC630.7z)
x265 2.4+61-28bbc349d170 (GCC 7.1.0) (https://www.mediafire.com/file/ck8xpa432nk29cr/x265_2.4%2B61-28bbc349d170.GCC710.7z)

major overhaul of x86inc assembler routines (in sync with those in x264)

[pingfr]

Wow! Impressive.

If I'm not mistaken the commits between 2.4+41 and 2.4+61 are more or less all about code cleanup and optimization thus yielding (at least in theory) speedup gains. :)

Kudos to the devs, hope we get to see even more improvements in that grey area soon enough. :)

[Boulder]

Too bad it's only x86 :)

[LigH]

I'd assume changes to be relevant for x86 as well as x86-64. Which architecture do you prefer instead, PowerPC or ARM big.LITTLE? ;)

This set of patches is intended update x86inc.asm file. This synchronises x86inc with that of x264.

[Boulder]

I'd assume changes to be relevant for x86 as well as x86-64. Which architecture do you prefer instead, PowerPC or ARM big.LITTLE? ;)Hehe, I'm spoiled so I usually expect x86 or x64. Read too many times that x86 assembly is not the same as x64 :)

[LigH]

Of course, there are differences between "legacy" x86 and x86-64 a.k.a. AMD64 (e.g. twice as many and twice as wide registers); and in fact, using assembler optimizations is disabled for 32 bit builds with High Bit Depths because it would be inefficient to spend development time on a quite restricted platform (already FullHD resolutions will probably hit RAM limits for 32-bit processes). But I believe a few routines still exist in both variants.

[nevcairiel]

The entire point of the "x86inc.asm" framework developed for x264 and used by x265 as well as ffmpeg is to make it easier to write ASM code that works on both x86_32 and x86_64, as well as on various platforms (ie. Linux/Unix and Windows), because calling conventions also vary. That of course doesn't mean that all ASM code automatically works on both 32-bit and 64-bit, since 64-bit offers twice the amount of registers its often much easier to write complex ASM for 64-bit with double the registers to use.

[Magik Mark]

Just a clarification on "Analysis Mode"

If I want to to reuse the analysis data writen by an earlier encode of the same sequence, I have to execute "--analysis-mode load"?

Are there any other prerequisites? In "--multi-pass-opt-analysis" and "--multi-pass-opt-distortion", "cu-tree" needs to be off. I might be missing something. Just want to be sure

[Natty]

Just a clarification on "Analysis Mode"

If I want to to reuse the analysis data writen by an earlier encode of the same sequence, I have to execute "--analysis-mode load"?

Are there any other prerequisites? In "--multi-pass-opt-analysis" and "--multi-pass-opt-distortion", "cu-tree" needs to be off. I might be missing something. Just want to be sure
yes u need to turn them off sadly, even refine-mv requires those options to be disabled :(

[Kavitha]

Just a clarification on "Analysis Mode"

If I want to to reuse the analysis data writen by an earlier encode of the same sequence, I have to execute "--analysis-mode load"?

Are there any other prerequisites? In "--multi-pass-opt-analysis" and "--multi-pass-opt-distortion", "cu-tree" needs to be off. I might be missing something. Just want to be sure


-analysis-load isn't going to provide any benefit in pass 2 unless you use --analysis-save. Both the analysis modes require cutree, pmode to be off. Even if these options are 'on', x265 internally turns them off with a warning.

[santhoshini]

Just a clarification on "Analysis Mode"

If I want to to reuse the analysis data writen by an earlier encode of the same sequence, I have to execute "--analysis-mode load"?

Are there any other prerequisites? In "--multi-pass-opt-analysis" and "--multi-pass-opt-distortion", "cu-tree" needs to be off. I might be missing something. Just want to be sure

To use multi-pass-opt-analysis/multi-pass-opt-distortion the first pass must include --multi-pass-opt-analysis/multi-pass-opt-distortion. These
options do not rely on --analysis-save (it's a different type of analysis that is saved in the 1st pass) and they do not work in conjunction with analysis-save/analysis-load modes. multi-pass-opt-analysis/multi-pass-opt-distortion does not require cu-tree to be off but requires pmode/pme to be turned off.

We'll clarify the online documentation about these options.

[iwod]

I cant believe it has been 4 - 5 years since x265 first appeared on Doom9! And I cant believe I had to wait all these years for wide spread support and uses, starting with Apple. God I am Old!

Anyway, I wanted to ask, how far is x265 being developed in terms of Video Quality? Are we in the late stage of development where we are focusing on encoding speed and shouldn't expect any more dramatic improvement in Video Quality? Pretty much like x264 in 2011 onwards.

[LigH]

More or less ... unfortunately there are still some quality issues to be investigated: Some people believe that detail retention could be improved (which is mainly an issue for smaller frame dimensions), and there are cases where tiny image elements are dragged away by motion (notorious example: Star Wars intro, star scroller).

[Motenai Yoda]

...starting with Apple. God I am Old!
starting with who?
HEVC has "wide spread support and uses" since years, s5 was the first smartphone with hevc hw decode capability as most of nowdays smartphones/tablets, Windows 10 has an integrate HEVC support (but only hw based), a lot of tvs can play even 10bit HEVC 4K HDR video/stream

this apple marketing piss me off when even my father's p8 lite can play a hevc file!!!

[stax76]

Does x264 --no-cabac fit into any of the tab page names that are used in the staxrip x265 GUI?

https://github.com/stax76/staxrip#x265-encoder-options

I'm re-implementing the x264 GUI, in the nvenc GUI I've put cabac to the 'Other' page, maybe there is a better fit.

[iwod]

starting with who?
HEVC has "wide spread support and uses" since years, s5 was the first smartphone with hevc hw decode capability as most of nowdays smartphones/tablets, Windows 10 has an integrate HEVC support (but only hw based), a lot of tvs can play even 10bit HEVC 4K HDR video/stream

this apple marketing piss me off when even my father's p8 lite can play a hevc file!!!

Ok.

Because of the way it works, most Android could play HEVC due to Software decoding. But not everyone will play it smoothly, due to the lacking single thread performance and hardware decode.
Not "Every" Samsung Phone or Tablet has HEVC hardware Decode. Namely their own SoC. Although most Qualcomm SoC should have by default.
Not every manufacture would have hardware decode by default EVEN if it is present on the SoC, because of patents licensing. And happens in certain countries.
And of coz there is a difference between FULL hardware decode and partial hardware decode.


Now name me a few big Network, services providers that are using HEVC for broadcasting or streaming? Purely for the numbers, there is more HEVC hardware decode capable product sold in China then US + EU + Japan combined. And yet most of their Streaming networks still aren't on HEVC. ( Actually not entirely true now in 2017 for China )
And which of these Network, has a FULL catalog of options available in HEVC. Not Amazon, Not Netflix, Not BBC, and heck the most common BT movie and shows are still on H.264 and not on HEVC. And this is the same in China.

May be i should have said "Ending" with Apple. Now the world could finally moves towards HEVC. ;)

[Motenai Yoda]

I didn't wrote that all products supports hevc, but most of them since years, also even most low budget phones like huawei p8 lite or samsung grand prime can easely hw decode a 720p 8bit, IIRC all tvs on sale in Germany, France and Italy should have a t2 decoder with hevc support, intel igpus from haswell (hw accelerated, from skylake full 8/10bit hw), nvidia gpus since gtx 960 and xbox one too.

You ask for some network? Netflix and Amazon streams 4k hevc to their subscribers, and PB lists me a lot of movies/series in hevc (405026)
UHD BD format rely on HEVC

but now apple with its 100 milions iphone 6s/7 will change everything, sure

[x265_Project]

FYI - Kavitha and Santhoshini are 2 of our developers. As they mentioned, we'll work on improving the documentation for all of x265's analysis load/save/optimization features.

[GhostAFRippEr]

x265 Where can I add HDR ?

[sneaker_ger]

http://x265.readthedocs.io/en/default/cli.html#vui-video-usability-information-options

You can use those options to add the necessary flags. Actual creation of HDR content has to be done outside of x265.

[LigH]

x265 2.4+75-80c23559084c (GCC 6.3.0) (https://www.mediafire.com/file/lxh7odjv4v5ial5/x265_2.4%2B75-80c23559084c.GCC630.7z)
x265 2.4+75-80c23559084c (GCC 7.1.0) (https://www.mediafire.com/file/9irj6iurcva2cec/x265_2.4%2B75-80c23559084c.GCC710.7z)

mostly improvements for SEA integral calculations with AVX2 assembly; some tidy-up.

Note: make directive "ENABLE_DYNAMIC_HDR10" is now renamed to "ENABLE_HDR10_PLUS"

Attention: New archive structure! (May change next time again, it feels bloated already... what to omit, what to keep?)
_

libhdr10plus.dll — separate DLL to handle Dynamic HDR10+ definitions in JSON format (possibly to be used by a custom application, used in parallel to a libx265.dll?)

libx265_main.dll — DLL with 8 bit precision x265 encoder core, to be used by a custom application or another x265 CLI, Dynamic HDR10+ support disabled
libx265_main10.dll — DLL with 10 bit precision x265 encoder core, to be used by a custom application or another x265 CLI, Dynamic HDR10+ support disabled
libx265_main12.dll — DLL with 12 bit precision x265 encoder core, to be used by a custom application or another x265 CLI, Dynamic HDR10+ support disabled
libx265.dll — multi-library DLL with 8+10+12 bit precision x265 encoder cores, to be used by a custom application, Dynamic HDR10+ support disabled

x265_main.exe — CLI application with 8 bit precision x265 encoder core (can use DLLs with different precisions), Dynamic HDR10+ support disabled
x265_main10.exe — CLI application with 10 bit precision x265 encoder core (can use DLLs with different precisions), Dynamic HDR10+ support disabled
x265_main12.exe — CLI application with 12 bit precision x265 encoder core (can use DLLs with different precisions), Dynamic HDR10+ support disabled
x265_ml.exe — multi-library CLI application with 8+10+12 bit precision x265 encoder cores (needs no other DLLs), Dynamic HDR10+ support disabled

HDR10plus\libx265.dll — multi-library DLL with 8+10+12 bit precision x265 encoder cores, to be used by a custom application, Dynamic HDR10+ support enabled
HDR10plus\x265_ml.exe — multi-library CLI application with 8+10+12 bit precision x265 encoder cores (needs no other DLLs), Dynamic HDR10+ support enabled
_

I don't see any reference to the libhdr10plus.dll in any x265 CLI or DLL when built with Dynamic HDR10+ disabled, so I doubt that they will be able to support it simply because the libhdr10plus.dll resides in the same directory (similar to supporting a core with different precision); I guess that if you want Dynamic HDR10+ to be supported, you have to use an enabled build, but then it will already contain the code, so there is no obvious need for that separate DLL, at least for [lib]x265; maybe for a custom application handling both tasks separately.

I did not yet try to discover if it is possible to build a mostly dynamically linked package with Dynamic HDR10+ support, consisting of one CLI and all the rest as DLLs, with the libhdr10plus.dll still separated... I would assume that its code would be included in the CLI or DLLs at least once, if not everywhere.

As a GUI author using any x265 CLI, I assume you would prefer using only the HDR10plus\x265_ml.exe (All-In-One build) as x265.exe called by your GUI.

[Midzuki]

x265.exe 2.4+87-5f2330bdb8fa

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2489522#post2489522

[LigH]

x265 2.4+87-5f2330bdb8fa (GCC 6.3.0) (https://www.mediafire.com/file/9xkdqecw3qtu0o2/x265_2.4%2B87-5f2330bdb8fa.GCC630.7z)
x265 2.4+87-5f2330bdb8fa (GCC 7.1.0) (https://www.mediafire.com/file/v7xdauig5gozxu4/x265_2.4%2B87-5f2330bdb8fa.GCC710.7z)

merge with stable; several renames, optimizations, refinements... most obvious CLI changes:

--analysis-reuse-mode <string|int> save - Dump analysis info into file, load - Load analysis buffers from the file. Default 0
--analysis-reuse-file <filename> Specify file name used for either dumping or reading analysis data. Deault x265_analysis.dat
--analysis-reuse-level <1..10> Level of analysis reuse indicates amount of info stored/reused in save/load mode, 1:least..10:most. Default 5

--[no-]refine-mv Enable mv refinement for load mode. Default disabled

--[no-]const-vbv Enable consistent vbv. turned on with tune grain. Default disabled

[Atak_Snajpera]

As a GUI author using any x265 CLI, I assume you would prefer using only the HDR10plus\x265_ml.exe (All-In-One build) as x265.exe called by your GUI.
Yeah. Single executable makes more sense for GUI maker like me.

[stax76]

less is sometimes more...

[pradeeprama]

I don't see any reference to the libhdr10plus.dll in any x265 CLI or DLL when built with Dynamic HDR10+ disabled, so I doubt that they will be able to support it simply because the libhdr10plus.dll resides in the same directory (similar to supporting a core with different precision); I guess that if you want Dynamic HDR10+ to be supported, you have to use an enabled build, but then it will already contain the code, so there is no obvious need for that separate DLL, at least for [lib]x265; maybe for a custom application handling both tasks separately.



We've enabled exporting libhdr10plus.dll in case any application integrator wants to use the functions exported by this library (which enable parsing json files that contain creative intent meta-data for the SMPTR-2094-40) in their own video library.

By default, libx265 already integrates this code natively when HDR10PLUS is enabled in Cmake, to avoid extra library dependence. When disabled, the options --dhdr10-info, and --dhdr10-plus won't work.

Hope this clarifies things.

[LigH]

So I have to ask: Does anyone here need anything more than the "All-in-one" EXE? If not, I will release only that regularly in the future. Alternative files by request only (e.g. a library for GUIs like Avidemux).

[stax76]

All-in-one sounds good.

[Magik Mark]

Can somebody confirm my finding:

Using +87 in --multi* causes a lot of blocking in 2pass 10bit x265. Video is unwatchable. No problem before +87

[Magik Mark]

How do I use the --analysis-reuse *?

If I use "Save", When and how do i use the "Load"? In 2nd pass?

[Ma]

Can somebody confirm my finding:

Using +87 in --multi* causes a lot of blocking in 2pass 10bit x265. Video is unwatchable. No problem before +87

Yes, see issue #354 https://bitbucket.org/multicoreware/x265/issues/354/patch-69f316d001b5-breaks-2pass-encoding
--------------------------------
Now 2pass encoding is fixed (from ver. 2.4+89).

[Barough]

x265 v2.4+89-fa076d29d619 (http://ge.tt/6jKmxYl2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.4+89-fa076d29d619
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Midzuki]

x265.exe 2.4+93-ef8dfbb70dd6

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2490163&viewfull=1#post2490163

[Magik Mark]

Guys,

Can you explain the difference between --analysis vs --multipass?

Both are trying to eliminate the work redundancy on multi pass encoding. Why not just have one command for this?

[LigH]

The mysteries of

http://kestas.kuliukas.com/MultiPass/leeloo_multipass.jpg

--[no-]multi-pass-opt-analysis (http://x265.readthedocs.io/en/default/cli.html#cmdoption-multi-pass-opt-analysis)
--[no-]multi-pass-opt-distortion (http://x265.readthedocs.io/en/default/cli.html#cmdoption-multi-pass-opt-distortion)

Multipass {analysis refinement|refinement of qp} cannot be enabled when ‘analysis-save/analysis-load’ option is enabled and both will be disabled when enabled together.

--analysis-reuse-mode <string|int> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-mode)
--analysis-reuse-file <filename> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-file)
--analysis-reuse-level <1..10> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-level)

I guess that using an analysis file supersedes several on-the-fly internal calculations a refinement would have used with fixed values not meant to be changed further... I wonder how deep you have to understand the principles of operation in the encoder core, to understand the relations between these two groups of options. You may probably have to be able to read and understand the C sources, at least.

I see the analysis file use rather as a kind of debugging and optimization tool for running dozens of encodings and comparing a lot of statistics, rather than speeding up a casual user's movie conversion.

[Magik Mark]

Thanks LigH.

It is really difficult to understand these things especially for ordinary folks like me. How I wish someone can explain these through images. I think that is more comprehensible for everyone

[Barough]

x265 v2.4+96-58b4fa89c42d (http://ge.tt/3FD54al2) (MSYS/MinGW, GCC 6.3.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 [info]: HEVC encoder version 2.4+96-58b4fa89c42d
x265 [info]: build info [Windows][GCC 6.3.0][32 bit/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

https://bitbucket.org/multicoreware/x265/commits/branch/default

[x265_Project]

The mysteries of
...
--analysis-reuse-mode <string|int> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-mode)
--analysis-reuse-file <filename> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-file)
--analysis-reuse-level <1..10> (http://x265.readthedocs.io/en/default/cli.html#cmdoption-analysis-reuse-level)

Analysis reuse provides the basic framework for more advanced solutions that we are building on top of / around x265 (in UHDkit). I don't want to go into more detail about all of the use-cases, as we've seen our competition already attempting to our methods. The basic idea is to produce solutions that run faster (for live encoding scenarios) and more computationally efficient (for offline encoding scenarios). These modes are not going to provide any benefit to anyone today who is just using x265 alone. They won't produce higher quality.

[LigH]

x265 2.4+96-58b4fa89c42d (https://www.mediafire.com/file/fk1tj49fs44rc21/x265_2.4%2B96-58b4fa89c42d.7z) (GCC 7.1.0, Win32+Win64, AIO EXE+DLL only)

merge with stable; several fixes and tweaks

renamed / changed / new CLI options:

--analysis-reuse-mode <string|int> save - Dump analysis info into file, load - Load analysis buffers from the file. Default 0
--analysis-reuse-file <filename> Specify file name used for either dumping or reading analysis data. Deault x265_analysis.dat
--analysis-reuse-level <1..10> Level of analysis reuse indicates amount of info stored/reused in save/load mode, 1:least..10:most. Default 5

--refine-intra <int> Enable intra refinement for load mode. Default 0

--[no-]const-vbv Enable consistent vbv. turned on with tune grain. Default disabled

[Midzuki]

x265.exe 2.4+97-006c75cf822e

Aruna Matheswaran committed 006c75c
2017-06-22

Allocate frame threads based on available pool threads

This patch decides #frame-threads based on #pool-threads available. If pools not
specified, #frame-threads will be decided based on detected #CPU-threads.

This patch also decreases #frame-threads allocated for #pool-threads in the
interval (15 - 31) and (>= 32) as there is high run to run variation in bitrate
and SSIM with higher frame threads.With this reduction in #frame-threads there
is ~3-4 % drop in fps with little SSIM improvement for #pool-threads (15 - 31)
and no significant change in performance for #pool-threads (>= 32).


https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2490727&viewfull=1#post2490727

[pingfr]

x265.exe 2.4+97-006c75cf822e

Aruna Matheswaran committed 006c75c
2017-06-22

Allocate frame threads based on available pool threads

This patch decides #frame-threads based on #pool-threads available. If pools not
specified, #frame-threads will be decided based on detected #CPU-threads.

This patch also decreases #frame-threads allocated for #pool-threads in the
interval (15 - 31) and (>= 32) as there is high run to run variation in bitrate
and SSIM with higher frame threads.With this reduction in #frame-threads there
is ~3-4 % drop in fps with little SSIM improvement for #pool-threads (15 - 31)
and no significant change in performance for #pool-threads (>= 32).


https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2490727&viewfull=1#post2490727

If this is what I think it is, this should tremendously help encoding faster on high-end dedicated servers? Thinking of a SMP machine with like 60 cores, 120 threads, etc?

[LigH]

The maximum number of threads will still be somewhat limited, due to a limited bitfield width of the core mask. Furthermore, too many threads for one encoder instance don't make sense, will be inefficient because each thread will only "see" a small part of the frame, and the thread sync overhead rises. With a huge number of physical cores, running several instances of the encoder in parallel on a subset of cores each is much more efficient (quality / speed).

I guess this patch will support the execution of several instances, each limited to a subset of cores, by allocating threads based on the limited amount of cores in each separate pool, as if there was only a CPU with fewer cores, thus avoiding too many threads in the sum of all instances.

[sneaker_ger]

Did we read the same text?
With this reduction in #frame-threads there
is ~3-4 % drop in fps with little SSIM improvement for #pool-threads (15 - 31)
and no significant change in performance for #pool-threads (>= 32).
To me it means:
15 - 31 threads: 3% to 4% slower
>= 32 threads: +/- 0%

[LigH]

Pradeep's patch review note before committing was: "The improvements in quality seem to justify the change."

Quite imaginable to me: Fewer threads reduce the speed a bit, but increase the quality. And beyond a threshold of threads, saturation effects of the thread management may be the bottleneck, I guess.

[Barough]

x265 v2.4+99-3160e1a0cc5f (http://ge.tt/4bMFkhl2) (MSYS/MinGW, GCC 7.1.0, 32 & 64bit 8/10/12bit multilib EXEs)

x265 : HEVC encoder version 2.4+99-3160e1a0cc5f
x265 [info]: build info [Windows][GCC 7.1.0][32/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2

[I]Merge with default; prep for v2.5

https://bitbucket.org/multicoreware/x265/commits/branch/default

[pingfr]

Pradeep's patch review note before committing was: "The improvements in quality seem to justify the change."

Quite imaginable to me: Fewer threads reduce the speed a bit, but increase the quality. And beyond a threshold of threads, saturation effects of the thread management may be the bottleneck, I guess.

In layman's terms, does that implies this patch merged in not only increases encoding speed but the overall resulting quality as well or am I getting confused here? :o

[nevcairiel]

In layman's terms, does that implies this patch merged in not only increases encoding speed but the overall resulting quality as well or am I getting confused here? :o

It slows down speed for some thread/core configurations but increases quality.

[pingfr]

So quality increase (visual subjectivity is subjective) at equal bitrate pre-patch but at a 3-4% speed decrease cost, correct?

[burfadel]

Depending on configuration. Actual difference also includes any filters used. The figures aren't given as 'you will receive', if figures weren't given people would be questioning how much.

[LigH]

Let me explain more verbosely how I imagine that. (If I am wrong, don't hesitate to correct me. Understanding x265 frame threading constraints (http://x265.readthedocs.io/en/default/threading.html#frame-threading) is hard.)

Let's imagine you have a dual socket mainboard, each of your two CPU's has 16 cores (maybe logical due to HT). So the whole system will report 32 cores overall.

You decide to run two instances of x265 at the same time, each with a thread pool of 16, to run distinctly on either CPU.

Before this patch, the number of frame threads depended on the number of cores in the whole system, so it was calculated in relation to the number 32.

After this patch, the number of frame threads will depend on the capacity of each separate thread pool, thus be calculated in relation to the number 16. In addition, it reduces them a bit more, as the developers discovered that even fewer threads in this range, compared to the previous calculation of the optimal number, has an advantage.

Of course this means fewer frame threads. That will slow down the calculation a bit. But before, x265 may have been less efficient, because it spawned too many threads for the limited pool (causing more synchronization overhead than necessary) and with a smaller scope each ("seeing" less of the whole neighborhood of the currently encoded slice, finding less candidates to reduce redundancy).

After this patch, the number of frame threads will match the size of the limited thread pool better, there is less thread synchronization, and each frame thread can have a wider scope, encoding more efficiently by finding better inter-coding candidates in a further distance. (At least the second half of this statement may be misunderstood.)
_

P.S. - a quote from the docs:

Over-allocating frame threads can be very counter-productive. They each allocate a large amount of memory and because of the limited number of CTU rows and the reference lag, you generally get limited benefit from adding frame encoders beyond the auto-detected count, and often the extra frame encoders reduce performance.

Doesn't really explain the reason for a potential quality limitation due to over-allocation, though...

[Sagittaire]

x264 and x265 coding are really problematic with new CPU with multiple core like "threadripper" or "skylake-X". x264 and x265 are unable to make encoding at 100% for CPU charge for 2K or even for 4K with 16C/32T or more.

@ x265 team

Not possible to create a new encoding mode in x265 with multiple instance for better threading compatibility?

Use for exemple high lookahead buffer for make frame type decision and open new instance coding at each new Iframe (will be IDR).

This mode imply certainely high frame buffer but if you have "threadripper" or "skylake-X" CPU, you must have at least 16 GB for RAM or more.

This mode imply just Closed GOP and perhaps short GOP (60 frames maximum) to minimize frame buffer.

[pingfr]

Use for exemple high lookahead buffer for make frame type decision and open new instance coding at each new Iframe (will be IDR).

This mode imply certainement high frame buffer but if you have "threadripper" or "skylake-X" CPU, you must have at least 16 GB for RAM or more.

This mode imply just Closed GOP and perhaps short GOP (60 frames maximum) to minimize frame buffer.

Got 512GB of RAM here, should be fine. :devil:

[x265_Project]

x264 and x265 coding are really problematic with new CPU with multiple core like "threadripper" or "skylake-X". x264 and x265 are unable to make encoding at 100% for CPU charge for 2K or even for 4K with 16C/32T or more.

@ x265 team

Not possible to create a new encoding mode in x265 with multiple instance for better threading compatibility?

Use for exemple high lookahead buffer for make frame type decision and open new instance coding at each new Iframe (will be IDR).

This mode imply certainely high frame buffer but if you have "threadripper" or "skylake-X" CPU, you must have at least 16 GB for RAM or more.

This mode imply just Closed GOP and perhaps short GOP (60 frames maximum) to minimize frame buffer.
For a single instance of x265, we are limited in the # of threads we can use at any one time due to the serial nature of video encoding. For 4K encoding you should be able to utilize at least 20 threads efficiently. To increase parallelism, you can increase the number of frame threads, but this can affect rate control (although if you are using CRF rate control and you aren't using VBV, you shouldn't have any problem). You can also use --pme and/or --pmode. These functions will definitely increase CPU utilization, but they are not work-efficient (you won't see an increase in FPS that correlates with the increase in CPU utilization).

We have a commercial product called UHDkit that can run multiple x264 or x265 instances, in order to get more performance under different circumstances. As you know, x265 is free for anyone who can comply with the terms of the GPL v2 license. This includes large web video services, who don't distribute x265 (they distribute video). UHDkit is our value-added solution designed as an incentive for commercial customers to come to us to get a commercial license, which means they go from being free-riders on the x265 open source project to being sponsors of the project, which means we can hire more developers to improve x265 for everyone. The features in UHDkit are features that only commercial users would need, like the ability to produce multiple bit/quality rate tiers from a single video file twice as efficiently as doing unique encodes, or the ability to do live 4K 60P 10 bit encoding on a many-core (dual socket) server. Of course, anyone can run multiple instances of x265 on a single machine by themselves, but it wouldn't be easy to match the performance optimization features, or the other value-added features in UHDkit.

[Atak_Snajpera]

High core count on AMD/Intel cpus is not a problem if you are RipBot264 user. All you need to do is activate distributed encoding mode with some servers.
http://i.cubeupload.com/bFnBKC.png
This way you can easily saturate even dual AMD EPYC 7601 cpus (64C/128T) with just 1080p footage.

[x265_Project]

High core count on AMD/Intel cpus is not a problem if you are RipBot264 user. All you need to do is activate distributed encoding mode with some servers.
This way you can easily saturate even dual AMD EPYC 7601 cpus (64C/128T) with just 1080p footage.
Is it open source? If you call x264 or x265, you need to comply with the GPL v2, and make your source code available under the GPL v2. This is a good thing, as others can contribute to help make it even better.

[jd17]

May I ask a question to the x265 devs here?

Why is --sao enabled by default?
We recently discussed this in another thread...

As the other thread is about high quality encodes, I thought --sao might be beneficial at low bitrates...
So I encoded my sample at 400 kbit/s, default settings, no tune. Once default, once with --no-sao.

Even at this extremely low bitrate I see no real benefit of --sao.
At high bitrates however, nobody seems to like --sao, because it adds a lot of blur.

The savings with a CRF also seem minor, considering this is such a big quality impact...


So, what is the reason for --sao by default?
Am I just missing something or would you consider --no-sao as default? :)

[littlepox]

May I ask a question to the x265 devs here?

Why is --sao enabled by default?
We recently discussed this in another thread...

As the other thread is about high quality encodes, I thought --sao might be beneficial at low bitrates...
So I encoded my sample at 400 kbit/s, default settings, no tune. Once default, once with --no-sao.

Even at this extremely low bitrate I see no real benefit of --sao.
At high bitrates however, nobody seems to like --sao, because it adds a lot of blur.

The savings with a CRF also seem minor, considering this is such a big quality impact...


So, what is the reason for --sao by default?
Am I just missing something or would you consider --no-sao as default? :)

I think they will remove it once they are pressured by AV1 or something so that the boss demand them to increase the compression efficiency by 20% in the next release.

[LigH]

There are surely cases where SAO makes sense to reduce complexity. Mostly in UHD resolutions where looking at tiny details from a larger distance is less important than looking at small video dimensions close-up, where a pixel still makes an important detail, in relation.

[jd17]

Could someone help me out here?:
https://forum.doom9.org/showthread.php?p=1811483#post1811483

I would mainly like to know what exactly --hdr-opt actually does.
It does come with a bitrate saving, so far so good, but is there a (negative) impact on quality? If so, what kind of impact?

I don't see an immediate degradation in that demo video, but it might not be well suited to make out the difference...

[LigH]

Most of all, it tells the encoder to expect high dynamic range, and to adapt internal value ranges to characteristics of specific displays.

It is pretty useless for conversion of "usual video" without a high bit depth already in the original video source. If you don't know what "color primaries" mean, don't attempt to use it.

[x265_Project]

Could someone help me out here?:
https://forum.doom9.org/showthread.php?p=1811483#post1811483

I would mainly like to know what exactly --hdr-opt actually does.
It does come with a bitrate saving, so far so good, but is there a (negative) impact on quality? If so, what kind of impact?

I don't see an immediate degradation in that demo video, but it might not be well suited to make out the difference...

An MPEG study group looked at the question of whether the HEVC standard needed to be revised in order to optimize encoding of HDR content. People had noticed quality issues in certain places, and so this group looked at what was needed to avoid those issues. They found that no change was needed to the HEVC standard, but they issued some recommendations. --hdr-opt implements these recommendations. It's like a special type of adaptive quantization, which looks at the brightness level of each block of video. It improves encoding quality and efficiency for HDR content. Don't try to use it if you aren't encoding High Dynamic Range content.

[jd17]

Thanks for your answers!
It is pretty useless for conversion of "usual video" without a high bit depth already in the original video source. If you don't know what "color primaries" mean, don't attempt to use it.
Don't try to use it if you aren't encoding High Dynamic Range content.

One click on my link guys... ;)

I did encode a 10bit HDR video:
I encoded the "Samsung HDR Wonderland" demo, once with --hdr-opt and once without.

Source MediaInfo:
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 45.7 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.230
Stream size : 878 MiB (100%)
Writing library : ATEME Titan File 3.7.3 (4.7.3.1002)
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

My encode (HandBrake 1.0.7, x265 2.4):
CRF17, medium, no tune
CL custom: --no-sao --uhd-bd --hdr-opt --hrd --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500)"
(I would normally add --max-cll too, but the source does not include that information...)

MediaInfo:
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
Codec ID : V_MPEGH/ISO/HEVC
Duration : 2 min 41 s
Bit rate : 22.2 Mb/s
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.112
Stream size : 427 MiB (98%)
Writing library : x265 2.4+13-26963e98fa64:[Windows][MSVC 1910][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=2 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 /
input-res=3840x2160 / interlace=0 / total-frames=0 / level-idc=51 / high-tier=1 / uhd-bd=1 / ref=3 / no-allow-non-conformance / repeat-headers / annexb / aud / hrd /
info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=1 / keyint=24 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=8 /
scenecut=40 / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 /
dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=3 /
no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / no-sao / no-sao-non-deblock / rd=3 /
no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-mode=0 /
no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=17.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=160000 / vbv-bufsize=160000 /
vbv-init=0.9 / crf-max=0.0 / crf-min=0.0 / ipratio=1.40 / pbratio=1.30 / aq-mode=1 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 /
no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=0 / colorprim=9 / transfer=16 / colormatrix=9 / chromaloc=1 /
chromaloc-top=2 / chromaloc-bottom=2 / display-window=0 / master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,500) / max-cll=0,0 /
min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps /
scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / hdr / hdr-opt / no-dhdr10-opt / refine-level=5 / no-limit-sao
Default : Yes
Forced : No
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0500 cd/m2, max: 1000.0000 cd/m2

The encode without --hdr-opt essentially just resulted in a higher bitrate, everything else is identical:

Bit rate : 25.7 Mb/s


Also, would you be so kind as to "sanity check" those parameters?
Would you change anything for UHD HDR encoding? Is anything essential missing?

I think you also suggested before:
--chromaloc 2
--keyint 48
?

I try to read up on the parameters as much as I can, but everything UHD HDR is not really well documented... So I welcome any help and explanations! :)


--hdr-opt implements these recommendations. It's like a special type of adaptive quantization, which looks at the brightness level of each block of video. It improves encoding quality and efficiency for HDR content.

Does that mean there will be no visible degradation when I use --hdr-opt? :)

[LigH]

x265 2.4+99-3160e1a0cc5f (https://www.mediafire.com/file/6pddrk60ckzz3es/x265_2.4%2B99-3160e1a0cc5f.7z) (merge stable+default)

"Allocate frame threads based on available pool threads" ... + a Mac fix and preps for v2.5 milestone.

[pingfr]

x265 2.4+99-3160e1a0cc5f (https://www.mediafire.com/file/6pddrk60ckzz3es/x265_2.4%2B99-3160e1a0cc5f.7z) (merge stable+default)

"Allocate frame threads based on available pool threads" ... + a Mac fix and preps for v2.5 milestone.

The big pool thread patch merged-in a few days ago alone is 2.5 milestone worthy IMHO. ;)

[LigH]

Another little patch about to be committed, and we will probably have it until the weekend. Optimistic guess.

[pradeeprama]

x265 version 2.5, which includes improvements to grain handling, and improved CSV logging feature which is now built into the library.

Version 2.5 can be downloaded from here (md5: 192e54fa3068b594aa44ab2b703f071d).Full documentation is available at http://x265.readthedocs.io/en/stable/

Release Notes for Version 2.5
=======================

Encoder enhancements
--------------------------------
1. Improved grain handling with --tune grain option by throttling VBV operations to limit QP jumps.
2. Frame threads are now decided based on number of threads specified in the --pools, as opposed to the number of hardware threads available. The mapping was also adjusted to improve quality of the encodes with minimal impact to performance.
3. CSV logging feature (enabled by --csv) is now part of the library; it was previously part of the x265 application. Applications that integrate libx265 can now extract frame level statistics for their encodes by exercising this option in the library.
4. Globals that track min and max CU sizes, number of slices, and other parameters have now been moved into instance-specific variables. Consequently, applications that invoke multiple instances of x265 library are no longer restricted to use the same settings for these parameter options across the multiple instances.
x265 can now generate a seprate library that exports the HDR10+ parsing API. Other libraries that wish to use this API may do so by linking against this library. Enable ENABLE_HDR10_PLUS in CMake options and build to generate this library.
5. SEA motion search receives a 10% performance boost from AVX2 optimization of its kernels.
6. The CSV log is now more elaborate with additional fields such as PU statistics, average-min-max luma and chroma values, etc. Refer to documentation of --csv for details of all fields.
7. x86inc.asm cleaned-up for improved instruction handling.

API changes
-----------------
1. New API x265_encoder_ctu_info() introduced to specify suggested partition sizes for various CTUs in a frame. To be used in conjunction with --ctu-info to react to the specified partitions appropriately.
2. Rate-control statistics passed through the x265_picture object for an incoming frame are now used by the encoder.
3. Options to scale, reuse, and refine analysis for incoming analysis shared through the x265_analysis_data field in x265_picture for runs that use --analysis-reuse-mode load; use options --scale, --refine-mv, --refine-inter, and --refine-intra to explore.
4. VBV now has a deterministic mode. Use --const-vbv to exercise.

Bug fixes
-------------
1. Several fixes for HDR10+ parsing code including incompatibility with user-specific SEI, removal of warnings, linking issues in linux, etc.
2. SEI messages for HDR10 repeated every keyint when HDR options (--hdr-opt, --master-display) specified.

Happy compressing!

[LigH]

Realistic guess, then! :D

x265 2.5+2-18fa144d453e (https://www.mediafire.com/file/x3r8zbukc5wsgwl/x265_2.5%2B2-18fa144d453e.7z) (merge with stable; new v2.5 milestone)

SEI payload message writing fixed

[pingfr]

Hah, I knew it! :devil:

[Barough]

x265 v2.5+3-3f6841d271e3 (http://ge.tt/5o9xpnl2) (GCC 7.1.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.5+3-3f6841d271e3
x265 [info]: build info [Windows][GCC 7.1.0][32/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


https://bitbucket.org/multicoreware/x265/commits/branch/default

[bxyhxyh]

Would developers update todo list? Last update of that is 2016.01.04.

[littlepox]

Would developers update todo list? Last update of that is 2016.01.04.

I prefer they don't. There is the joke that for developers, todo = something I should do but I don't want to do, so I put it down just as a show.

[Barough]

x265 v2.5+4-01a981f509ea (http://ge.tt/3hOyLtl2) (GCC 7.1.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.5+4-01a981f509ea
x265 [info]: build info [Windows][GCC 7.1.0][32/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


https://bitbucket.org/multicoreware/x265/commits/branch/default

[Midzuki]

x265.exe 2.5+6-d11482e5fedb

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2492072&viewfull=1#post2492072

[LigH]

x265_2.5+6-d11482e5fedb (https://www.mediafire.com/file/efm6tv94lm5loz4/x265_2.5%2B6-d11482e5fedb.7z) (merge with stable)

fixes two memory leaks (threading, HDR10+), improves encoder reconfiguration, and allows forced output flushing:

--force-flush <integer> Force the encoder to flush frames. Default 0
0 - flush the encoder only when all the input pictures are over.
1 - flush all the frames even when the input is not over. Slicetype decision may change with this option.
2 - flush the slicetype decided frames only.

I guess this is mainly interesting for scenarios with changing parameters where a quick response is required?

[jlpsvk]

Any news about AVX-512 instructions support? :) Tommorow my new lovely i7-7820X will arrive, so a testing volunteer is here. :D

[NikosD]

I'm really sorry to inform you that there is no real AVX512 support inside your CPU, according to reviews and specs (?)

Intel fused the two FMA AVX2 units into one FMA AVX512, so it's like the support of AVX2 by Zen core which has only AVX128 units.

Don't forget also that AVX512 clocks are a lot lower than AVX2 and sometimes lower even from base clock.

Also, optimizations for AVX512 and x264/x265 will be minimal regarding performance.

Threadripper CPU with a lot of cores and a very high clock, could be far more interesting.

[Atak_Snajpera]

Any news about AVX-512 instructions support? :) Tommorow my new lovely i7-7820X will arrive, so a testing volunteer is here. :D

Slightly more expensive Threadripper@4GHz 1920x (12C/24T) will probably destroy i7-7820x in video encoding. It is odd that you didn't want to wait two weeks for Threadrippers. Intel is now very bad in price to performance ratio.

[LigH]

Intel fused the two FMA AVX2 units into one FMA AVX512, so it's like the support of AVX2 by Zen core which has only AVX128 units.

Don't forget also that AVX512 clocks are a lot lower than AVX2 and sometimes lower even from base clock.

That reminds me of the behaviour on AMD Phenom-II CPU's which are more or less capable of executing SSE3 instructions, but x264 and x265 refuse to enable them because their implementation is so slow (and possibly even incomplete?), thus the fastest instruction set for those old engines is "SSE2Fast". :o

So I would not be surprised if x265 may enable AVX512 instructions only on CPU's where their execution will be a benefit, for the same reason. :sly:

[jlpsvk]

That reminds me of the behaviour on AMD Phenom-II CPU's which are more or less capable of executing SSE3 instructions, but x264 and x265 refuse to enable them because their implementation is so slow (and possibly even incomplete?), thus the fastest instruction set for those old engines is "SSE2Fast". :o

So I would not be surprised if x265 may enable AVX512 instructions only on CPU's where their execution will be a benefit, for the same reason. :sly:

That's why I choosed i7-7820X. :)

Skylake-X should support these AVX512 instructions (in bold):
AVX-512-F: F for Foundation
AVX-512-BW: Support for 512-bit Word support
AVX-512-CD: Conflict Detect (loop vectorization with possible conflicts)
AVX-512-DQ: More instructions for double/quad math operations
AVX-512-ER: Exponential and Reciprocal
AVX-512-IFMA: Integer Fused Multiply Add with 52-bit precision
AVX-512-PF: Prefetch Instructions
AVX-512-VBMI: Vector Byte Manipulation Instructions
AVX-512-VL: Foundation plus <512-bit vector length support
AVX-512-4VNNIW: Vector Neural Network Instructions Word (variable precision)
AVX-512-4FMAPS: Fused Multiply Accumulation Packed Single precision

[Atak_Snajpera]

That's why I choosed i7-7820X. :)

Skylake-X should support these AVX512 instructions (in bold):
AVX-512-F: F for Foundation
AVX-512-BW: Support for 512-bit Word support
AVX-512-CD: Conflict Detect (loop vectorization with possible conflicts)
AVX-512-DQ: More instructions for double/quad math operations
AVX-512-ER: Exponential and Reciprocal
AVX-512-IFMA: Integer Fused Multiply Add with 52-bit precision
AVX-512-PF: Prefetch Instructions
AVX-512-VBMI: Vector Byte Manipulation Instructions
AVX-512-VL: Foundation plus <512-bit vector length support
AVX-512-4VNNIW: Vector Neural Network Instructions Word (variable precision)
AVX-512-4FMAPS: Fused Multiply Accumulation Packed Single precision

Did you know that...
1) AVX-512 instructions "generate" much more heat. Hence introduced by Intel negative AVX offset.
2) Speed-up in x265 will most likely be much lower than SSEx.x vs AVX2.

Do not expect miracles in practice.

[NikosD]

That's why I choosed i7-7820X. :)

Skylake-X should support these AVX512 instructions (in bold):


Sorry to bother you again, but you clearly didn't understand my reply and certainly not Ligh's too.

It's not the support of instructions that matters but the implementation.
That's what I told you and that's exactly the same thing that Ligh told you.

Your Skylake-X supports AVX512 but not in a fast way because Intel enables a real AVX512 FMA unit only on 10 core and above.

Your CPU has a half speed implementation or slower.

But, probably your reply shows us why you chose to buy that CPU in the first place.

[nevcairiel]

x264 already got some AVX512 improvements (although its not complete yet, i've been told). You can use it already today to judge improvements. On a 7900X it does result in a real improvement, but as NikosD said, the 7900X has a second separate full 512-bit unit, which the 7800 and 7820 do not have.

The only "downside" of AVX512 is that the CPUs clock down when its in use due to the heat generation, however Skylake can change its clock much faster then previous platforms, so at least it won't be terrible. x265 already exeperienced issues with downlocks when they worked on AVX2 at first, which also downclocks on server CPUs, so hopefully they'll account for that and only use it when there is a real and tangible improvement to be had.

[NikosD]

Do we know how much is the real difference of x264-AVX512 using a 7900X compared to x264-AVX2 version on the same CPU ?

I'm pretty sure that Threadripper 16C/32T with the same price of 7900K will eat Skylake-X for breakfast on x264, even though it has only a fast FMA AVX-128 bit implementation and not a AVX512 of course.

[sneaker_ger]

x264 results are not that impressive.
2017-06-19 13:55:46 < BugMaster|work> I mean overall speed up vs no AVX512 on same CPU
2017-06-19 13:56:09 < Gramner> 5-10% vs avx2 on veryfast
2017-06-19 13:59:00 < BugMaster|work> and for veryslow it similar or should be faster?
2017-06-19 14:00:41 < Gramner> it goes down to +-0 at veryslow currently.

[nevcairiel]

10% overall is pretty good from some improved SIMD functions. But like I said, its not done yet. There is more functions to optimize. When Gramner gets to those, he didn't say.

[Atak_Snajpera]

10% overall is pretty good from some improved SIMD functions. But like I said, its not done yet. There is more functions to optimize. When Gramner gets to those, he didn't say.

NOT OVERALL! Do not bend facts! 10% max is only in veryfast preset. If you have 10+ core CPU then you most likely aim for veryslow preset for max quality. I doubt that you can get more that few percent extra speedup in those slow modes.

[nevcairiel]

NOT OVERALL! Do not bend facts! 10% max is only in veryfast preset.

I never stated the opposite, clearly anyone is capable of reading one post upwards, so keep your pants on.

Its overall 10% faster in that preset, and thats still a significant speedup. These presets are still quite useful for live encoding for streaming, when the really slow ones are still too slow for realtime (and gaming at the same time, for example).

[Atak_Snajpera]

It clearly says between 5 and 10%. So on average you get less than 10%. So extra ~7% more in useless veryfast preset is just a placebo for me.
2017-06-19 13:56:09 < Gramner> 5-10% vs avx2 on veryfast

These presets are still quite useful for live encoding for streaming, when the really slow ones are still too slow for realtime (and gaming at the same time, for example).
Who on earth buys very expensive x299 AVX-512 cpu for streaming games? For streaming cheap Ryzen 7 1700@3.8GHz is enough.

[sneaker_ger]

10% overall is pretty good from some improved SIMD functions. But like I said, its not done yet. There is more functions to optimize. When Gramner gets to those, he didn't say.
I don't disagree. I actually expected you to answer when I wrote my post. 5% to 10% for free is nothing to turn up your nose at.
But doom9 folks tend to go for "veryslow or go home!"...

[burfadel]

I don't disagree. I actually expected you to answer when I wrote my post. 5% to 10% for free is nothing to turn up your nose at.
But doom9 folks tend to go for "veryslow or go home!"...

It's not 5 to 10 percent for free, you paid extra for the CPU to get that extra speed. Not only that, the extra speed is only applicable to the faster, slower processors thusly. No doubt any improvement for some functions is offset by the associated downclock. It's why a virtualised GPU based onboard SPU (Supplementary Processing Unit) replacing a large part of the ALU and FPU functions could possibly be of advantage here. Sounds pretty good for something I just made up, right? :D

Anyways, it's highly probably that Threadripper will still outperform Skylake-X even without AVX2 functions, and it certainly beats it on price. Considering it is costs less and faster, that 5 to 10 percent for 'free' as you put is, actually in effect costs whatever the performance vs outlay cost difference is percentage wise. So definitely NOT a free 'advantage'!

[Atak_Snajpera]

Also do not forget guys that intel's "NOT GLUED CORES TOGETHER" technology has serious problems with base clock when you add more and more cores.
Intel® Xeon® Platinum 8153 Processor (16c/32t) has base clock at only 2 GHz!
http://ark.intel.com/products/series/125191/Intel-Xeon-Scalable-Processors

ThreadRipper@4GHz 1950x will destroy Skylake-X even without almighty AVX-512.

[IgorC]

Xeon 18153 16 cores 2.0/2.8 GHz has lower TDP (125W).

6142M 16 cores (150W, 2.6/3.7 GHz) is closer to future AMD 16/32 CPU (180W). http://ark.intel.com/products/120488/Intel-Xeon-Gold-6142M-Processor-22M-Cache-2_60-GHz

Core i9-7960X (165W) will be apparently at 3.0/4.x GHz https://en.wikipedia.org/wiki/List_of_Intel_Core_i9_microprocessors

[Atak_Snajpera]

Xeon 18153 16 cores 2.0/2.8 GHz has lower TDP (125W).

6142M 16 cores (150W, 2.6/3.7 GHz) is closer to future AMD 16/32 CPU (180W). http://ark.intel.com/products/120488/Intel-Xeon-Gold-6142M-Processor-22M-Cache-2_60-GHz

Core i9-7960X (165W) will be apparently at 3.0/4.x GHz https://en.wikipedia.org/wiki/List_of_Intel_Core_i9_microprocessors

Taken from Intel
http://i.cubeupload.com/pRbWC0.png

Core i9-7960X won't hit 4GHz on ALL cores only on single one.
Furthermore extra heat caused by AVX-512 will force CPU to work at base frequency during video encoding.

[x265_Project]

Guys - all this speculation about the benefits we'll be able to obtain from AVX-512 instructions is premature. We don't know the answer today. We have to do the work to find out the answer. As with AVX2 instructions, you're using more silicon (wider execution units), which generate more heat than the standard execution units (nothing is free!), and so there are some thermal clock management issues that we have to be aware of as we implement AVX-512 optimization.

Forget about turbo frequencies when you're saturating a processor by running x265. x265 pushes the processor to its thermal limits, and when it is running hot it won't be going into turbo mode. Anyhow, getting twice the work done per instruction (AVX-512 vs AVX2) is beneficial, even if the clock frequency temporarily slows when we implement those instructions.

I also don't think it's useful to compare any high level statistics like core count, TDP, etc. between Intel and AMD in order to estimate performance. There are just too many other differences in CPU architecture between Purley and Zen/Epyc. The bottom line is that either way, it's all good news for x265 users... more cores and much more performance per dollar than what we have been getting until now.

[sneaker_ger]

Is there any good explanation for the way x265 applies reference limits (https://forum.doom9.org/showthread.php?p=1747979#post1747979)? I don't understand how it makes any sense. Why numPocTotalCurr must always be <= 8?
/* The value of NumPocTotalCurr shall be less than or equal to 8 */
int numPocTotalCurr = param.maxNumReferences + vps.numReorderPics;
if (numPocTotalCurr > 8)
{
x265_log(&param, X265_LOG_WARNING, "level %s detected, but NumPocTotalCurr (total references) is non-compliant\n", levels[i].name);
vps.ptl.profileIdc = Profile::NONE;
vps.ptl.levelIdc = Level::NONE;
vps.ptl.tierFlag = Level::MAIN;
x265_log(&param, X265_LOG_INFO, "NONE profile, Level-NONE (Main tier)\n");
return;
}

[x265_Project]

Is there any good explanation for the way x265 applies reference limits (https://forum.doom9.org/showthread.php?p=1747979#post1747979)? I don't understand how it makes any sense. Why numPocTotalCurr must always be <= 8?

We can take a look at this. It's probably best to ask such a question on our developer mailing list. Personally (as the GM and head of product management), I don't want x265 to have any arbitrary limitations. It should support the full HEVC specification, at least, for support profiles. So if it's legal to have more than 8 reference frames in a particular profile and level, and if the user wants to do this, x265 should support it. That's not always a great idea (there may be decoder limitations that you'll run into, and there are seriously diminishing returns beyond about 3 reference frames), but our default performance presets limit --refs, so you have to manually specify --refs if you want more.

[sneaker_ger]

We can take a look at this.
Don't get me wrong. I'm not trying to suggest it's a bug. I'm only trying to understand it.

[jlpsvk]

First stress tests...

CPU: i7-7820X at stock 3.6GHz, all values default on MOBO (MSI X299 RAIDER)
Cooler: Fractal Design Kelvin S36
Case: NZXT H440

All cores running at 4.00GHz automatically, temps around 62 degress Celsius.

[burfadel]

Is that at full load or idle?

[jlpsvk]

Full load.

[Sagittaire]

Guys - all this speculation about the benefits we'll be able to obtain from AVX-512 instructions is premature. We don't know the answer today. We have to do the work to find out the answer. As with AVX2 instructions, you're using more silicon (wider execution units), which generate more heat than the standard execution units (nothing is free!), and so there are some thermal clock management issues that we have to be aware of as we implement AVX-512 optimization.

Forget about turbo frequencies when you're saturating a processor by running x265. x265 pushes the processor to its thermal limits, and when it is running hot it won't be going into turbo mode. Anyhow, getting twice the work done per instruction (AVX-512 vs AVX2) is beneficial, even if the clock frequency temporarily slows when we implement those instructions.

I also don't think it's useful to compare any high level statistics like core count, TDP, etc. between Intel and AMD in order to estimate performance. There are just too many other differences in CPU architecture between Purley and Zen/Epyc. The bottom line is that either way, it's all good news for x265 users... more cores and much more performance per dollar than what we have been getting until now.

Some useful information:

1) actually x265 is unable tu use 16C/32T at 100% for make 1080p encoding. The actual limit for 1080p is more 8C/16T or 10C/20T.

2) you can expect saturate 16C/32T only with 2160p source with real full resolution (no blacks borders)


Considering that:

1) 16C/32T is useless for 1080p encoding. At this time something the R7 1700 is by far the best solution for make encoding with high speed at low cost.

2) it will be really difficult to saturate 16C/32T at 100% even with 2160p source. I think even that it will be usefull to desactivate SMT or HT to have only 16C/16T configuration, particulary for 1080p source. For this reason, I don't think that thermal limit will be a big problem here.

[Sagittaire]

First stress tests...

CPU: i7-7820X at stock 3.6GHz, all values default on MOBO (MSI X299 RAIDER)
Cooler: Fractal Design Kelvin S36
Case: NZXT H440

All cores running at 4.00GHz automatically, temps around 62 degress Celsius.

try this test:
https://forum.doom9.org/showthread.php?p=1799988#post1799988

and report your result thx

[Atak_Snajpera]

1) actually x265 is unable tu use 16C/32T at 100% for make 1080p encoding. The actual limit for 1080p is more 8C/16T or 10C/20T.
With medium preset it is even less than that. I never have full cpu usage on my E5-2690 with default preset (my average is ~80%). In this case I think that 6C/12T is max.

Considering that:

1) 16C/32T is useless for 1080p encoding. At this time something the R7 1700 is by far the best solution for make encoding with high speed at low cost.
Your conclusion is wrong because you are ignoring the fact that you can run multiple instances of x265 to saturate those extra cores.

[benwaggoner]

Your conclusion is wrong because you are ignoring the fact that you can run multiple instances of x265 to saturate those extra cores.
And there is always --pmode. And even --pme.

--preset veryslow --lookahead-slices 4 --pmode --tskip --cu-lossless --tu-inter 4 --tu-intra 4 would likely saturate 16 physical cores on a single socket.

[Atak_Snajpera]

And there is always --pmode. And even --pme.

--preset veryslow --lookahead-slices 4 --pmode --tskip --cu-lossless --tu-inter 4 --tu-intra 4 would likely saturate 16 physical cores on a single socket.

Nope...
--crf 20 --preset veryslow --lookahead-slices 4 --pmode --tskip --cu-lossless --tu-inter 4 --tu-intra 4

Script (files in ramdisk)
LoadPlugin("C:\Users\Dave\Documents\Delphi_Projects\RipBot264\_Compiled\Tools\AviSynth plugins\RawSource\RawSource.dll")
video1=RawSource("E:\_Video_Samples\y4m\crowd_run_1080p50.y4m")
video2=RawSource("E:\_Video_Samples\y4m\park_joy_1080p50.y4m")
video3=RawSource("E:\_Video_Samples\y4m\ducks_take_off_1080p50.y4m")
video4=RawSource("E:\_Video_Samples\y4m\in_to_tree_1080p50.y4m")
video5=RawSource("E:\_Video_Samples\y4m\old_town_cross_1080p50.y4m")

return video1+video2+video3+video4+video5


http://i.cubeupload.com/M7ljR6.png

[benwaggoner]

Nope...

Huh. Well, thanks for testing!

Is this with hyperthreading on? We might not see 100% saturation of logical cores. 75% isn't bad with HT.

Maybe try --pme? That should be able to saturate anything.

[Sagittaire]

And there is always --pmode. And even --pme.


don't work correctly. CPU charge is more intensive ... but with less speed !!???

--preset veryslow --lookahead-slices 4 --pmode --tskip --cu-lossless --tu-inter 4 --tu-intra 4 would likely saturate 16 physical cores on a single socket.

x265 work correctly with default setting with 8C/16T with 1080p (something like more or less 80% in slow mode and higher). But you can't expect that with 16C/32T for 1080p source.

Only solution like Atak_Snajpera say is make mulicession encoding. Anyway x265 is slow and make multicession will be good solution only with multicession for same source (with advanced gui for make multipartition encoding in same time)

[Atak_Snajpera]

Huh. Well, thanks for testing!

Is this with hyperthreading on? We might not see 100% saturation of logical cores. 75% isn't bad with HT.

Maybe try --pme? That should be able to saturate anything.

Nothing helps. Trust me I've done many tests in the past with similar suggestions. The only working solution is spawn more x265 encoder.
According to my tests ThreadRipper 1950x 16C/32T will require 3 instances to get constant 100% usage.

[LigH]

How many times did we already try to explain that 100% parallelization in modern efficient video encoding is a miracle? There are always parts of the compression algorithm which have to wait for other previous parts to finish before they can continue. This is not yet so obvious in x264 for AVC encoding, but much more in x265 where you have a lot more dependencies among parts of the HEVC algorithm.

Running several instances of encoders on a subset of the cores each works a lot better, because they work independently of each other, thus parallelize better.

[jlpsvk]

try this test:
https://forum.doom9.org/showthread.php?p=1799988#post1799988

and report your result thx

|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| CPU | x264 | x265 | LAVC | auto | MMX2 | SSE | SSE2 | SSE3 | SSE4 | AVX | AVX2 | All |

|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|

| Core i7-7820X | 24.95 | 4.74 | 136 | 3.67 | 1.13 | 1.14 | 1.82 | 1.97 | 2.97 | 2.97 | 3.57 | N/A |



Temps under 70 degrees, all cores were running at 100% LOAD and at 4.0GHz.

[zub35]

In this test-example, artifacts of macroblocks 64х64. Scene №3.

raw_1080p30.y4m [534MB] https://cloud.mail.ru/public/D74t/4LPtEm2WG
files x264,x265 [34MB] https://cloud.mail.ru/public/DdcN/HGKoYV5cU

x265 --bitrate 16000/8000 --preset placebo --merange 57 --subme 7 --psy-rd 4 --psy-rdoq 10 --pass 1/2
x264 --bitrate 16000/8000 --preset veryslow --level 4.1 --slow-firstpass --pass 1/2

http://i94.fastpic.ru/big/2017/0729/f6/2a7a431b28f96ccad5319198c86b78f6.png

[x265_Project]

In this test-example, artifacts of macroblocks 64х64. Scene №3.

raw_1080p30.y4m [534MB] https://cloud.mail.ru/public/D74t/4LPtEm2WG
files x264,x265 [34MB] https://cloud.mail.ru/public/DdcN/HGKoYV5cU

x265 --bitrate 16000/8000 --preset placebo --merange 57 --subme 7 --psy-rd 4 --psy-rdoq 10 --pass 1/2
x264 --bitrate 16000/8000 --preset veryslow --level 4.1 --slow-firstpass --pass 1/2

http://i94.fastpic.ru/big/2017/0729/f6/2a7a431b28f96ccad5319198c86b78f6.png

Try re-encoding with default placebo settings, and let us know what you find.

Compression artifacts will occur if you set the psy-rd strength and/or psy-rdoq strength too high. Psy-rd biases mode decision towards candidates that have a similar level of detail (variance) to the source block. A little psy-rd is good, but too much psy-rd strength will cause x265 to choose candidates that aren't the best match visually (blocks that have higher or matching energy levels, even though they are not the best candidate with the lowest Rate-Distortion cost). When psy-rd is too high, you'll typically see motion inaccuracy (for example, blocks that should be portraying smooth motion that instead appear to be staying in one place too long). When psy-rdoq is too high you'll just get compression artifacts.

[excellentswordfight]

Is there any plans of full HLG support? The arib-std-b67 transfer curve is implemented, but the DVB states that this should be flagged in the "alternative_transfer_characteristics" SEI message and bt2020-10 should be flagged in the normal VUI, this way it suppose to be more backwards compatible for non HLG equipment.

http://www.etsi.org/deliver/etsi_ts/101100_101199/101154/02.03.01_60/ts_101154v020301p.pdf

[FranceBB]

I gotta send a sample to a TV which requires constant bitrate (20 Mbit/s) HEVC 10bit 50fps .ts 'cause they are moving from .mxf XDCAM 1080i MPEG-2 25 Mbit/s interlaced contents to 4K HEVC 50fps progressive.
I used:

@avs4x265.exe --preset medium --level 5.1 --tune fastdecode --profile main10 --bitrate 19500 --vbv-maxrate 19500 --vbv-bufsize 19500 --strict-cbr --ref 3 --deblock -1:-1 --overscan show --colormatrix bt709 --range limited --transfer bt709 --colorprim bt709 --videoformat component --no-open-gop --fps 50 -o "raw_video.hevc" "AVS Script.avs"

and also with:

@avs4x265.exe --preset ultrafast --level 5.1 --tune fastdecode --profile main10 --bitrate 19500 --vbv-maxrate 19500 --vbv-bufsize 19500 --strict-cbr --ref 3 --deblock -1:-1 --overscan show --colormatrix bt709 --range limited --transfer bt709 --colorprim bt709 --videoformat component --no-open-gop --fps 50 -o "raw_video.hevc" "AVS Script.avs"

My AVS:

ColorBars(width = 3840, height = 2160, pixel_type = "yv12")

ConvertFPS(50)
ResampleAudio(48000)

Normalize(0.89, show=false)

trim(0, 1500)
barsnote=last

BlankClip(width=3840, height=2160, pixel_type="YV12", fps=50000, fps_denominator=1000, audio_rate=48000, channels=2, sample_type="float", color=$000000, length=1500)

TextSub("Clock.ass")
clock=last

FFmpegSource2("sampleProRes.mov", fpsnum=50000, fpsden=1000, atrack=-1)

ResampleAudio(48000)

Normalize(0.89, show=false)

sample=last

barsnote++clock++sample

But I got a variable bitrate video (about 16 Mb/s going up and down). I'm using the latest version of x265 compiled by LigH (x64). I need a constant bitrate video (or at least a way to mux it pretending that the stream is CBR).

(as to the 8bit processing done by Avisynth, that's because it's just a sample/test; I'm gonna use the 10bit "hack" in FFMpegSource2 to output 10bit, do some post-processing - light denoise and debanding - and then feed x265 directly with the 10bit stream thanks to Dither Tool in the real encode)

I cannot upload publicly the encoded sample, due to copyright rights, but I might send a very little part of it via PM if it's absolutely necessary to solve this "issue", but I'm pretty sure I'm just missing some settings in my encode line. :)

[sneaker_ger]

x265 log? How did you determine the result is not CBR?

[FranceBB]

Well, after I encoded the .hevc file with x265 and the AC3 audio file with ffmpeg, I muxed them in .ts using ffmpeg and I got my .ts file, but Media Info says:


General
ID : 1 (0x1)
Complete name : G:\Sample.ts
Format : MPEG-TS
File size : 370 MiB
Duration : 2 min 58 s
Overall bit rate mode : Variable (instead of Constant)
Overall bit rate : 17.2 Mb/s (instead of 20 Mb/s)

Video
ID : 256 (0x100)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@Main
Codec ID : 36
Duration : 3 min 0 s
Bit rate : 16.0 Mb/s (instead of 19.5 Mb/s)
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 50.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.038
Stream size : 343 MiB (93%)
Writing library : x265 2.5+6-d11482e5fedb:[Windows][GCC 7.1.0][64 bit] 10bit
Encoding settings : cpuid=1050111 / frame-threads=1 / numa-pools=2 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=3840x2160 / interlace=0 / total-frames=9000 / level-idc=51 / high-tier=1 / uhd-bd=0 / ref=1 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / no-open-gop / min-keyint=25 / keyint=250 / bframes=3 / b-adapt=0 / b-pyramid / bframe-bias=0 / rc-lookahead=5 / lookahead-slices=8 / scenecut=0 / no-intra-refresh / ctu=32 / min-cu-size=16 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / no-signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=2 / limit-refs=0 / no-limit-modes / me=0 / subme=0 / merange=57 / temporal-mvp / no-weightp / no-weightb / no-analyze-src-pics / deblock=-1:-1 / no-sao / no-sao-non-deblock / rd=2 / early-skip / rskip / fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / analysis-reuse-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=cbr / bitrate=19500 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / vbv-maxrate=19500 / vbv-bufsize=19500 / vbv-init=0.9 / ipratio=1.40 / pbratio=1.00 / aq-mode=1 / aq-strength=0.00 / cutree / zone-count=0 / strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=0 / overscan=1 / overscan-crop=0 / videoformat=0 / range=0 / colorprim=1 / transfer=1 / colormatrix=1 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / no-dhdr10-opt / analysis-reuse-level=5 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=0 / no-limit-sao / ctu-info=0
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709

Audio
ID : 21 (0x15)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Format settings, Endianness : Big
Codec ID : 129
Duration : 3 min 0 s
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 spf)
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 8.24 MiB (2%)
Language : English
Service kind : Complete Main

Menu
ID : 4096 (0x1000)
Menu ID : 1 (0x1)
Duration : 2 min 58 s
List : 256 (0x100) (HEVC) / 21 (0x15) (AC-3, English)
Language : / English
Service name : Service01
Service provider : FFmpeg
Service type : digital television

[LigH]

But:

rc=cbr / bitrate=19500 ... vbv-maxrate=19500 / vbv-bufsize=19500

That's the point which counts ... but CBR bitrate distribution mode is no guarantee for a really really constant bitrate. If the encoder needs less bitrate to achieve optimal quality, a multiplexer would have to stuff the video stream with empty junk if a pseudo-constant bitrate is expected. And I doubt any playback device is so picky about it. There are more important limits than a bitrate. Like, reference frames, consecutive B frames, B frame pyramid, CABAC, Profile@Level marker...

[littlepox]

But:

rc=cbr / bitrate=19500 ... vbv-maxrate=19500 / vbv-bufsize=19500

That's the point which counts ... but CBR bitrate distribution mode is no guarantee for a really really constant bitrate. If the encoder needs less bitrate to achieve optimal quality, a multiplexer would have to stuff the video stream with empty junk if a pseudo-constant bitrate is expected. And I doubt any playback device is so picky about it. There are more important limits than a bitrate. Like, reference frames, consecutive B frames, B frame pyramid, CABAC, Profile@Level marker...

I have seen such user so keen to use CBR for the following reason:

1. My broadcast/streaming service provider says no more than 20Mbps
2. I should encode with a maximum bitrate of 20Mbps(or to be safe, 19Mbps)
3. in order to maximize the quality under this constrain, make the bitrate constant as 19Mbps
4. Why the fxxk I cannot find a CBR mode? are you serious in telling me to use x264 instead of my favourite one-key encoder?

[LigH]

a) just a casual question to the x265 developers, no accusation intended: When there are no commits for several days ... are you usually hitting a complex issue all together, which takes some time to get investigated, or is it more likely that you have appointments outside the development office (e.g. fairs or customer meetings, maybe it's just vacation season, and hopefully no natural disasters)?
_

b) a question not only to the x265 developers, but mainly: what is the intended difference between "make clean" and "make clean-generated", or more specifically, in which situations should one use either of them?

[excellentswordfight]

I have seen such user so keen to use CBR for the following reason:

1. My broadcast/streaming service provider says no more than 20Mbps
2. I should encode with a maximum bitrate of 20Mbps(or to be safe, 19Mbps)
3. in order to maximize the quality under this constrain, make the bitrate constant as 19Mbps
4. Why the fxxk I cannot find a CBR mode? are you serious in telling me to use x264 instead of my favourite one-key encoder?
I have been doing something similar, were offline files aready encoded were inserted to the live ts stream so they needed to match those settings. If its the same use case here I find it kind of weird that they are concerned about the bitrate but not GOP structure, ref frames etc. So if these are not correct, it needs to be reencoded anyway.

For my case I used ffmeg/x265 with these settings and they ended up close to "true" CBR. I saw no cases with a significant drop in bitrate.

-c:v libx265 -pix_fmt yuv420p10le -preset slow -x265-params level=51:bitrate=24000:vbv-maxrate=24000:vbv-bufsize=24000:keyint=48:no-scenecut=1:b-adapt=0:bframes=8:rc-lookahead=48:strict-cbr=1:colorprim="bt709":transfer="bt709":colormatrix="bt709":range="limited"

I didnt look that closely on your script, but it looked like you inserted bars to it right? This could explain it, they could be encoded at a much lower bitrate even though a higher bitrate is specified (I have at least seen this with abr in the past). But it should be padded (muxrate) anyway when you repack it into a TS-stream so it shouldnt matter right?

[FranceBB]

@excellentswordfight... yes, I used a closed GOP 'cause open GOP it's not supported by their specs and I kept --ref 3 just to be sure that the reference frames won't be a problem. As to the bars-note, I had to insert 30sec bars-note to show them channels mapping, audio level (about -24 LUFS more or less, 'cause according to the law commercial breaks can't be louder than the program itself, that has to be normalised) and that both luma and chroma of the program are in range (bars 75%, luma 0.7) followed by the clock with the name of program, video specs, TC-In, TC-Out and the countdown, lasting for 30 sec in order to have the program starting at 00:01:00.00.

So... yes, probably it's just because of bars-note and the clock/countdown that the encoder lowered the bitrate, which shouldn't be a big deal if it's just for that. Anyway, I sent them a sample; I hope they'll accept it.

[benwaggoner]

I gotta send a sample to a TV which requires constant bitrate (20 Mbit/s) HEVC 10bit 50fps .ts 'cause they are moving from .mxf XDCAM 1080i MPEG-2 25 Mbit/s interlaced contents to 4K HEVC 50fps progressive.
But I got a variable bitrate video (about 16 Mb/s going up and down). I'm using the latest version of x265 compiled by LigH (x64). I need a constant bitrate video (or at least a way to mux it pretending that the stream is CBR).

Try adding --strict-cbr.

However, if there isn't much motion in the content, there are only so many ways to spend the bits. Adding a bit of random noise and using --tune grain is a good way to boost bitrate

[FranceBB]

@benwaggoner I used that parameter (--strict-cbr) already. Anyway, excellentswordfight was right: it was just a few kbit/s at the very beginning due to the bar-note, but the program itself was constant at 19.5 Mbit/s, in fact they just called me to tell me that they accepted the sample.

Gentlemen, it's been a pleasure. XD
No, seriously, thank you, everyone. :)

[qyot27]

b) a question not only to the x265 developers, but mainly: what is the intended difference between "make clean" and "make clean-generated", or more specifically, in which situations should one use either of them?
My gut reaction is that it's the same as the difference between 'make clean' and 'make distclean' in autoconf and the custom build systems used by x264, FFmpeg, etc. 'make clean' scrubs the object files and other at-compile-time stuff away, while 'make distclean' cleans both that and the build process structures generated by running configure.

At least in those systems, distclean should be used whenever a change to the build system occurs, while clean is sufficient if only the actual project code changed.

[WhatZit]

When there are no commits for several days ... are you usually hitting a complex issue all together, which takes some time to get investigated, or is it more likely that you have appointments outside the development office

Remember that there is much more to MulticoreWare's development of x265 than just the visible public open source. They have their proprietary API-based UHDKit, which you definitely WON'T see commits for.

Also, it's entirely possible that MulticoreWare's "sideline projects" (I'm sure calling them that will make 'em angry) might require some collaborative poaching of x265 developers. Their recently developed LipSync technology is a perfect example of this, requiring an amalgam of both video analysis and artificial intelligence.

[LigH]

@ WhatZit: :cool: I wasn't aware of additional projects with similar complexity. Of course, that's a quite probable reason.

@ qyot27: My impression was the opposite, "make clean-generated" only removing CMake generated and similar auxiliary files to force rebuilding from the end of the building sequence for maybe only sub-targets with updates. But it's not easy for me to understand make files without a real clue about their structure, syntax, dependencies ...

[x265_Project]

a) just a casual question to the x265 developers, no accusation intended: When there are no commits for several days ... are you usually hitting a complex issue all together, which takes some time to get investigated, or is it more likely that you have appointments outside the development office (e.g. fairs or customer meetings, maybe it's just vacation season, and hopefully no natural disasters)?
_

b) a question not only to the x265 developers, but mainly: what is the intended difference between "make clean" and "make clean-generated", or more specifically, in which situations should one use either of them?
Vacations, recruiting at local colleges... no disasters, natural or otherwise.

[x265_Project]

Remember that there is much more to MulticoreWare's development of x265 than just the visible public open source. They have their proprietary API-based UHDKit, which you definitely WON'T see commits for.

Also, it's entirely possible that MulticoreWare's "sideline projects" (I'm sure calling them that will make 'em angry) might require some collaborative poaching of x265 developers. Their recently developed LipSync technology is a perfect example of this, requiring an amalgam of both video analysis and artificial intelligence.

We have 4 business units at MulticoreWare. I run the video business. Our LipSync product was developed by our Machine Learning business unit. They didn't poach any of our video developers. :)

Tom

[LigH]

x265 2.5+8-eea2afb81ef2 (https://www.mediafire.com/file/h9ebz1g509r3e1w/x265_2.5%2B8-eea2afb81ef2.7z)

New modes for --refine-intra (http://x265.readthedocs.io/en/default/cli.html#cmdoption-refine-intra) and --refine-inter (http://x265.readthedocs.io/en/default/cli.html#cmdoption-refine-inter)

[Atak_Snajpera]

AMD Threadripper 1950X in x265
https://cubeupload.com/im/bKv6yQ.png

Source -> https://youtu.be/TJiP1bKxLkU?t=3m43s

[mastrboy]

AMD Threadripper 1950X in x265
https://cubeupload.com/im/bKv6yQ.png

Source -> https://youtu.be/TJiP1bKxLkU?t=3m43s

So AMD is still way behind Intel in FPU performance pr core, or will there be future x265 optimizations for Ryzen/Threadripper that could close the gap?

[Sagittaire]

So AMD is still way behind Intel in FPU performance pr core, or will there be future x265 optimizations for Ryzen/Threadripper that could close the gap?

it's intensive multicession encoding with x265: in this case Memory Banding limit speed for Ryzen/Threadripper. In simple 4K encoding 1950X produce better speed than 7900X (~20%).

[Atak_Snajpera]

it's intensive multicession encoding with x265: in this case Memory Banding limit speed for Ryzen/Threadripper. In simple 4K encoding 1950X produce better speed than 7900X (~20%).

Nah. It is just 2xFMAC256 magic vs 2xFMAC128 in Zen. ThreadRipper's Memory Bandwidth is pretty good.

Source -> https://youtu.be/G9JR_v-4BaQ?t=2m2s

[Barough]

x265 v2.5+9-fdf39a97ecb8 (http://ge.tt/3UT4x7m2) (GCC 7.1.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version x265 v2.5+9-fdf39a97ecb8
x265 [info]: build info [Windows][GCC 7.1.0][32/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


https://bitbucket.org/multicoreware/x265/commits/branch/default

[Sagittaire]

Nah. It is just 2xFMAC256 magic vs 2xFMAC128 in Zen. ThreadRipper's Memory Bandwidth is pretty good.

Source -> https://youtu.be/G9JR_v-4BaQ?t=2m2s

Rysen use slow data fabric for internal L3 cache communication between each CCX module. You have really higher latence for intel with DDR4 and L3 too. Use multiple instance is not good idea for AMD.

If you make 4K encoding with X265, you don't saturate memory controler and in this case 1950X@stock will produce better result than 7900X@stock.

You have the same problem with R7 1800X and i7-6900K. In all test in 1080p, R7 1800X@stock and i7-6900K@stock are on par for x265 encoding but not in x265 fhd benchmark.

if possible, reduce the instance number (2x or perhaps 3x 1080p instance will be enough and you will see that relative speed will be really higher for AMD).

[Atak_Snajpera]

Rysen use slow data fabric for internal L3 cache communication between each CCX module. You have really higher latence for intel with DDR4 and L3 too. Use multiple instance is not good idea for AMD.

If you make 4K encoding with X265, you don't saturate memory controler and in this case 1950X will produce really better result than 7900X.

You have the same problem with R7 1800X and i7-6900K. In all test in 1080p, R7 1800X and i7-6900K are on par for x265 encoding but not in x265 fhd benchmark.

Similar results
http://pclab.pl/art75073-14.html
http://www.benchmark.pl/testy_i_recenzje/amd-ryzen-threadripper-1950x-i-1920x-test/strona/28404.html

You are expecting too much from 2xFMAC128 vs 2xFMAC256.
ThreadRipper was designed to use as many processes as possible.
See benchmarks on youtube. Gaming + streaming to youtube + twitch + encoding something in Adobe Premiere.
REMEMBER! You have to use multiple x265 encoders to fully saturate all cores with very common 1080p resolution. So in practice there is no escape from that.

[Sagittaire]

Similar results
http://pclab.pl/art75073-14.html
http://www.benchmark.pl/testy_i_recenzje/amd-ryzen-threadripper-1950x-i-1920x-test/strona/28404.html

You are expecting too much from 2xFMAC128 vs 2xFMAC256.
ThreadRipper was designed to use as many processes as possible.
See benchmarks on youtube. Gaming + streaming to youtube + twitch + encoding something in Adobe Premiere.
REMEMBER! You have to use multiple x265 encoders to fully saturate all cores with very common 1080p resolution. So in practice there is no escape from that.

not really. In pclab test 1950X produce 7% better result than 7900X and in your test it's 2% better result for 7900X.

Moreover, I don't like handbrake test because this gui use heavy filter (avisynth?) and don't use directly stream for encoding. I prefer direct benchmark with high speed ffmpeg frameserver (less than 5% of CPU charge for stream decoding).

Try your benchmark with less instance (just to assure to have CPU charge at 100%) and you will see that speed will be higher. Perhaps higher for Intel CPU too.

[Atak_Snajpera]

not really. In pclab test 1950X produce 7% better result than 7900X and in your test it's 2% better result for 7900X.

Moreover, I don't like handbrake test because this gui use heavy filter (avisynth?) and don't use directly stream for encoding. I prefer direct benchmark with high speed ffmpeg frameserver (less than 5% of CPU charge for stream decoding).

Try your benchmark with less instance (just to assure to have CPU charge at 100%) and you will see that speed will be higher. Perhaps higher for Intel CPU too.
I have already done that on my E5-2690 in distributed encoding mode. 5 x265/x264 encoders vs 1 x265/x264. Difference in encoding time was in margin of error.

[Sagittaire]

I have already done that on my E5-2690 in distributed encoding mode. 5 x265/x264 encoders vs 1 x265/x264. Difference in encoding time was in margin of error.

1) Well I read before that your E5-2690 8C/16T is only at 70-75% for CPU charge in 1080p x265 encoding.

2) In this condition, why use 5x encoding instance, if 1x is enough?

[adsun701]

Hi here. I just created a patch that enables support for SMPTE ST 428,
SMPTE RP 431, and SMPTE EG 432 primaries. It also enables support for
SMPTE ST 2085, ICtCp, and both chroma-derived non-constant and
constant luminance matrices. They are all included in the latest spec.

Here's the link.
https://gist.github.com/Adsun701/472ec93957289f057e0c90599ec4bb9a

[Atak_Snajpera]

It looks like that 1950x in default creative mode (2 dies active) is sitting between 3.3 and 3.4GHz. While i9 7900x runs at constant 4 GHz.
Source -> https://youtu.be/Fr1ZlUu8v_Q?t=9m8s

Scalling in my benchmark is good.
Ryzen 7 1700 @ 3.7GHz (OC) = 25.5 fps
Threadripper 1950x @ 3.4GHz = 43.6 fps
Threadripper 1950x @ 3.7GHz = 47.4 fps (estimated)

Scalling factor = ~1.9x

[microchip8]

Hi here. I just created a patch that enables support for SMPTE ST 428,
SMPTE RP 431, and SMPTE EG 432 primaries. It also enables support for
SMPTE ST 2085, ICtCp, and both chroma-derived non-constant and
constant luminance matrices. They are all included in the latest spec.

Here's the link.
https://gist.github.com/Adsun701/472ec93957289f057e0c90599ec4bb9a

you better post those patches to the x265 mail list, not here.

[x265_Project]

Hi here. I just created a patch that enables support for SMPTE ST 428,
SMPTE RP 431, and SMPTE EG 432 primaries. It also enables support for
SMPTE ST 2085, ICtCp, and both chroma-derived non-constant and
constant luminance matrices. They are all included in the latest spec.

Here's the link.
https://gist.github.com/Adsun701/472ec93957289f057e0c90599ec4bb9a

Thanks! We received your email (sent to x265contributions at multicorewareinc dot com), along with your signed Contributor License Agreement. We'll review your patch ASAP.

Tom

[NikosD]

So AMD is still way behind Intel in FPU performance pr core, or will there be future x265 optimizations for Ryzen/Threadripper that could close the gap?


Nah. It is just 2xFMAC256 magic vs 2xFMAC128 in Zen.



You are expecting too much from 2xFMAC128 vs 2xFMAC256.


x265 has nothing to do with the FPU or the FMACs or floating point performance in general.

It's a pure integer app using AVX2 integers not FMA3 or FADD or FMUL or any floating point in general.

If someone gets a Monsterripper or Killerofskyalakex 16C/32T 1950X try both modes.

UMA and NUMA using x265.

UMA should be faster, but who knows.

Also make sure you saturate all 32 threads.

[Atak_Snajpera]

It's a pure integer app using AVX2 integers not FMA3 or FADD or FMUL or any floating point in general.
Are you 100% sure that FMACs are not being used in integer calculations as well? Haswell is noticeable faster in x265 than Sandy/IvyBridge (clock vs clock).
Looking at architecture I don't see anything special except new FMACs
http://www.anandtech.com/show/6355/intels-haswell-architecture/8

If someone gets a Monsterripper or Killerofskyalakex 16C/32T 1950X try both modes.
Chipzilla 16C/32T will destroy ThreadRipper 1950x in x265 by 1.6x factor.

[NikosD]

Are you 100% sure that FMACs are not being used in integer calculations as well?

Haswell is noticeable faster in x265 than Sandy/IvyBridge (clock vs clock).

Looking at architecture I don't see anything special except new FMACs
http://www.anandtech.com/show/6355/intels-haswell-architecture/8

You seem to confuse vector SIMD integer instruction set with vector SIMD floating point instruction set.

Haswell and above have AVX2 instruction set which enables 256 bit vector SIMD integer instructions leveraged by x265

Sandy & Ivy have only AVX which is for floating point (mainly).
So, no speedup for those processors.

Of course AVX2 has FMA3 too, which doubles the floating point throughput compared to AVX but that's a different story irrelevant to x265.

Chipzilla 16C/32T will destroy ThreadRipper 1950x in x265 by 1.6x factor.

If that becomes a reality - 60% faster than 1950X - prepare yourself to use liquid nitrogen to freeze that CPU coming directly from hell, especially if Intel is still using that mustard between the CPU and heat spreader.

And you will need around 500W for that performance.

[Atak_Snajpera]

Haswell and above have AVX2 instruction set which enables 256 bit vector SIMD integer instructions leveraged by x265
What specific unit in CPU is responsible for calculating AVX2 instructions? My common sense tells me that FMAC does that. After all old SSE2 can also work on integers
https://en.wikipedia.org/wiki/SSE2

Zen has 2xFMAC128 while Intel since haswell has got 2xFMAC256. x265 benchmarks clearly show AMD 16C/32T = Intel 10C/20T. I see clear correlation here.

[NikosD]

What specific unit in CPU is responsible for calculating AVX2 instructions? My common sense tells me that FMAC does that. After all old SSE2 can also work on integers
https://en.wikipedia.org/wiki/SSE2

Zen has 2xFMAC128 while Intel since haswell has got 2xFMAC256. x265 benchmarks clearly show AMD 16C/32T = Intel 10C/20T. I see clear correlation here.

OMG! You really are a stubborn b@st@rd ! :)

The execution units leveraged by AVX2 instruction set are 256 bit SIMD integer for ADD, MUL, SHIFT.

Integer DIV remains 128 bit.

It's the last time I'm telling you that FMACs and floating point numbers have nothing to do with integers and x265 application.

Read here about all execution units of Haswell vs Sandybridge.

http://www.realworldtech.com/haswell-cpu/4/

[Atak_Snajpera]

Ok smart ass so explain us why zen architecture sucks so much in x265...
http://www.linleygroup.com/mpr/article.php?id=11666

[NikosD]

Ok smart ass so explain us why zen architecture sucks so much in x265...
http://www.linleygroup.com/mpr/article.php?id=11666

In case you didn't see it, I put a :) in my first sentence just to be polite with your tremendous ignorance regarding CPU architectures and ego (those two usually come together)

But now, after your reply, I can't be polite anymore.

Your comments made me laugh like no tomorrow regarding FMACs and x265, so keep on posting your thoughts after reading CPU architecture articles you don't understand.

It's so funny!

Thank you!

[Asmodian]

Ok smart ass so explain us why zen architecture sucks so much in x265...

Maybe it is due to its much lower cache bandwidth or much higher cache/memory latency? There are major differences there. Teasing out the differences in the ALUs that might impact x265 is beyond me, so if anyone can help I would appreciate it.

Skylake-X:
Data-Cache Accesses: 2x 32B read + 2x 32B write
L2 Read Bandwidth: 64B

Zen:
Data-Cache Accesses: 2x 16B read + 1x 16B write
L2 Read Bandwidth: 32B

Does the massive L2 of Skylake-X help x265 at all?

[Balthazar2k4]

Ok smart ass so explain us why zen architecture sucks so much in x265...
http://www.linleygroup.com/mpr/article.php?id=11666

I am running a 1950x with a 3.9ghz OC across all 16-cores and, frankly, I am impressed. I have to run two encodes simultaneously to saturate the system and using the medium preset with a CRF of 19 on 1080p material I am seeing ~25fps on both encodes. Will the 16C Intel counterpart beat the 1950x? Most likely. That said, the Intel part is $700 more and would therefore expect it to be superior.

This is my first AMD system in 15+ years and I can say unequivocally that I am very happy with it.

[LigH]

x265 2.5+11-d58761d8db4a (https://www.mediafire.com/file/g0pg09gtnb6fg82/x265_2.5%2B11-d58761d8db4a.7z)

supports some new SMPTE-ST/RP/EG colorimetry options and a new split RD skip command* (documented only in full help):

--[no-]splitrd-skip Enable skipping split RD analysis when sum of split CU rdCost larger than none split CU rdCost for Intra CU. Default disabled

--colorprim <string> Specify color primaries from undef, bt709, bt470m, bt470bg, smpte170m,
smpte240m, film, bt2020, smpte-st-428, smpte-rp-431, smpte-eg-432. Default undef

--colormatrix <string> Specify color matrix setting from undef, bt709, fcc, bt470bg, smpte170m,
smpte240m, GBR, YCgCo, bt2020nc, bt2020c, smpte-st-2085, chroma-nc, chroma-c, ictcp. Default undef


* If I understood the patch comment in the mailing list (https://mailman.videolan.org/pipermail/x265-devel/2017-August/011237.html) correctly, it should speed up intra split cost calculation a little while possibly preserving identical output.

[burfadel]

Yes, the splitRD-skip looks interesting, I wouldn't be surprised that if in the future it isn't enabled by default. I guess that comes down to user reports, or maybe they're waiting on the possibility of it being extended to inter-CU?

[Stephen R. Savage]

In case you didn't see it, I put a :) in my first sentence just to be polite with your tremendous ignorance regarding CPU architectures and ego (those two usually come together)

But now, after your reply, I can't be polite anymore.

Your comments made me laugh like no tomorrow regarding FMACs and x265, so keep on posting your thoughts after reading CPU architecture articles you don't understand.

It's so funny!

Thank you!
If were smart instead of merely a smart-ass, you would know that the FPU (and FMAC) are also responsible for executing integer SIMD instructions. Likewise, you would know that Intel can retire dual 256-bit (512-bit in Skylake) multiply-accumulate of 16-bit integers using the exact same execution ports as floating-point FMA. In fact, why do you think the upcoming Cannonlake will have 52-bit integer FMA instructions (hint (https://en.wikipedia.org/wiki/File:IEEE_754_Double_Floating_Point_Format.svg))?

[NikosD]

If were smart instead of merely a smart-ass, you would know that the FPU (and FMAC) are also responsible for executing integer SIMD instructions. Likewise, you would know that Intel can retire dual 256-bit (512-bit in Skylake) multiply-accumulate of 16-bit integers using the exact same execution ports as floating-point FMA. In fact, why do you think the upcoming Cannonlake will have 52-bit integer FMA instructions (hint (https://en.wikipedia.org/wiki/File:IEEE_754_Double_Floating_Point_Format.svg))?Oh my, oh my (!)

What a smart ass.

What a dump ass

What an asshole.

Port 0 and 1 can dispatch SIMD integer and FMA for floating point, but not all hardware capable of SIMD integer can do SIMD floating point too.

For example port 5 can do SIMD integer but not FMA for floating point in Haswell/Broadwell/Skylake/Kabylake architecture.

Integer FMA is something very new to Intel's CPU architecture and part of AVX-512 instruction set only.

It's called AVX512-IFMA and has 52 bit precision.

Haswell/Broadwell/Skylake/Kabylake do not support AVX-512 and don't support integer FMA of course.

Skylake-X (Skylake-SP core) added an FMA 512 bit unit in Port 5 (10 core and above) but for floating point only, as it supports a limited part of the huge AVX-512 family of instructions set variants, but not AVX512-IFMA.

There are 12 levels of AVX-512 actually.

Cannonlake will be the first mainstream CPU of Intel to support integer FMA.

So, again.

What a smart ass, a dump ass and an asshole.

You should be banned from doom9 for ever.

[littlepox]

* If I understood the patch comment in the mailing list (https://mailman.videolan.org/pipermail/x265-devel/2017-August/011237.html) correctly, it should speed up intra split cost calculation a little while possibly preserving identical output.

Should that be the case, we are probably going to see this option removed while the skip is integrated in the code very soon.

[LigH]

Maybe after a similar feature is available for inter-coding, too. This hope was already expressed in the patch discussion of the intra version.

[Barough]

x265 v2.5+12-fcd9154fa4e2 (http://ge.tt/8Z6izEm2) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.5+12-fcd9154fa4e2
x265 [info]: build info [Windows][GCC 7.2.0][32 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

Side note:

The German c't Magazine reports Ryzen Threadripper (1950X) as the generally fastest desktop CPU at the moment (including advantages of the TR4 platform connecting to PCIx SSD's and graphic cards, plus USB 3.1).

Not so important for x265, specifically. Back to topic.

[zub35]

GPU Fork - x265 HEVC OpenCL or CUDA Encoder

gcc>=7 , -O2 -fopenacc

https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder

[LigH]

Interesting... I wonder if it is technically still as powerful as x265 (means, if GPGPU algorithms can still be as complex as CPU algorithms), and also if it is allowed to be still named something-with-x265. Just curious...

[burfadel]

GPU Fork - x265 HEVC OpenCL or CUDA Encoder

gcc>=7 , -O2 -fopenacc

https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder

OpenCL would make more sense, CUDA is proprietory and NVidia only.

[JohnLai]

GPU Fork - x265 HEVC OpenCL or CUDA Encoder

gcc>=7 , -O2 -fopenacc

https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder


Hmmm......process that could be offloaded.....

Motion search + estimation? All big three gpu have some sort of motion search/estimation code available.

Maybe lookahead (didn't work well in x264), but somehow nvidia is able to implement it using CUDA cores in conjunction with its proprietary NVENC. The code ain't available from nvidia....hmmm....but being able to do it fast.....

Maybe SAO? Some form of low complexity SAO like what nvidia used in Pascal?

Or offloading adaptive quantization calculation like that nvidia did?


*Gotta hand it off to Nvidia software engineers.....they are leading.......in GPGPU usage for video acceleration part....with its CUDA....

[easyfab]

or using FEI from intel if it come to HEVC .
I don't know if this could be interesting to mix with x264/X265

from https://github.com/01org/intel-vaapi-driver/issues/228

"The main highlight of FEI is the possibility to split the encoding process into two phases, first is ENC and the second is PAK.ENC is the operation which performs all motion vector calculation and prediction.PAK is doing all transformations and entropy coding. Without having FEI, the whole ENC+PAK is a black box to middleware, but with FEI user can extract the output of ENC and feed PAK with a custom enhanced motion vectors and macroblock prediction modes."

[x265_Project]

Interesting... I wonder ... if it is allowed to be still named something-with-x265.
No. Anyone can fork a GPL software project, but they can't copy a trademark.

[x265_Project]

or using FEI from intel if it come to HEVC .
I don't know if this could be interesting to mix with x264/X265

from https://github.com/01org/intel-vaapi-driver/issues/228

"The main highlight of FEI is the possibility to split the encoding process into two phases, first is ENC and the second is PAK.ENC is the operation which performs all motion vector calculation and prediction.PAK is doing all transformations and entropy coding. Without having FEI, the whole ENC+PAK is a black box to middleware, but with FEI user can extract the output of ENC and feed PAK with a custom enhanced motion vectors and macroblock prediction modes."
Intel's Flexible Encoder Interface isn't the right way to go. They offer lower-level OpenCL libraries that we've looked at to do these functions. Keep in mind that if we replace a whole section of code with a hardware encoder's functionality, we end up with a very different thing.

[x265_Project]

Hmmm......process that could be offloaded.....

Motion search + estimation? All big three gpu have some sort of motion search/estimation code available.

Maybe lookahead (didn't work well in x264), but somehow nvidia is able to implement it using CUDA cores in conjunction with its proprietary NVENC. The code ain't available from nvidia....hmmm....but being able to do it fast.....

Maybe SAO? Some form of low complexity SAO like what nvidia used in Pascal?

Or offloading adaptive quantization calculation like that nvidia did?


*Gotta hand it off to Nvidia software engineers.....they are leading.......in GPGPU usage for video acceleration part....with its CUDA....
The challenge is speed. If you offload small chunks of work to a GPU, the CPU won't have to do that work, so it can effectively speed up. But if you don't get the result of those tasks back from the GPU before they're needed, you won't accelerate.
GPUs are very good at work that can be highly parallelized, and not good at work that has serial dependencies. Video encoding has many serial dependencies. The block you're encoding right now makes reference to neighboring blocks, or blocks in other frames, all of which must be completely finished encoding before you can efficiently encode the current block.

[x265_Project]

Be sure to vote for x265 in the Streaming Media Reader's Choice poll... http://www.streamingmedia.com/ReadersChoice/2017/Vote.aspx

[Ma]

I've made 10-bit "true placebo" 2500 kb/s test with Sintel movie (from 8-bit 4K png source).

Command line:
f:\speed\Sintel>ffmpeg -framerate 24 -start_number 00000001 -i %08d.png -pix_fmt yuv420p16 -vf "scale=1920:-4:flags=bicubic+accu
rate_rnd+full_chroma_int+full_chroma_inp:param0=-0.5:param1=0.25,setsar=1" -v warning -strict -1 -f yuv4mpegpipe - | x265 -D10
--bitrate 2500 -I480 --psnr --ssim -p9 --no-psy-rd --multi-pass-opt-distortion --rc-lookahead 120 --bframes 12 --ref 6 --subme
7 -F1 --y4m - w1.hevc --pass 1
[yuv4mpegpipe @ 00000000005603a0] Warning: generating non standard YUV stream. Mjpegtools will not work.
y4m [info]: 1920x816 fps 24/1 i420p16 sar 1:1 unknown frame count
raw [info]: output file: w1.hevc
x265 [info]: HEVC encoder version 2.5+11-d58761d8db4a
x265 [info]: build info [Windows][MSVC 1911][64 bit] 10bit+8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 1 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 7 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 120 / 12 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 6 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-2500 kbps / 0.60
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rdoq=1.00 tskip signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao stats-write
x265 [info]: frame I: 187, Avg QP:16.78 kb/s: 16314.61 PSNR Mean: Y:51.527 U:54.999 V:54.462 SSIM Mean: 0.994805 (22.844dB
)
x265 [info]: frame P: 5475, Avg QP:18.42 kb/s: 6150.87 PSNR Mean: Y:50.783 U:54.985 V:54.451 SSIM Mean: 0.993361 (21.779dB
)
x265 [info]: frame B: 15650, Avg QP:23.87 kb/s: 992.31 PSNR Mean: Y:50.160 U:56.112 V:55.537 SSIM Mean: 0.992487 (21.242dB
)
x265 [info]: Weighted P-Frames: Y:10.6% UV:7.3%
x265 [info]: Weighted B-Frames: Y:8.8% UV:5.7%
x265 [info]: consecutive B-frames: 17.7% 9.1% 8.2% 42.3% 6.2% 9.2% 3.2% 2.5% 0.4% 0.2% 0.2% 0.2% 0.6%

encoded 21312 frames in 135210.11s (0.16 fps), 2451.98 kb/s, Avg QP:22.41, Global PSNR: 51.632, SSIM Mean Y: 0.9927318 (21.386 d
B)

f:\speed\Sintel>ffmpeg -framerate 24 -start_number 00000001 -i %08d.png -pix_fmt yuv420p16 -vf "scale=1920:-4:flags=bicubic+accu
rate_rnd+full_chroma_int+full_chroma_inp:param0=-0.5:param1=0.25,setsar=1" -v warning -strict -1 -f yuv4mpegpipe - | x265 -D10
--bitrate 2500 -I480 --psnr --ssim -p9 --no-psy-rd --multi-pass-opt-distortion --rc-lookahead 120 --bframes 12 --ref 6 --subme
7 -F1 --y4m - w2.hevc --pass 2
[yuv4mpegpipe @ 00000000004403a0] Warning: generating non standard YUV stream. Mjpegtools will not work.
y4m [info]: 1920x816 fps 24/1 i420p16 sar 1:1 unknown frame count
raw [info]: output file: w2.hevc
x265 [info]: HEVC encoder version 2.5+11-d58761d8db4a
x265 [info]: build info [Windows][MSVC 1911][64 bit] 10bit+8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [warning]: --psnr used with psy on: results will be invalid!
x265 [warning]: --tune psnr should be used if attempting to benchmark psnr!
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 1 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 4 inter / 4 intra
x265 [info]: ME / range / subpel / merge : star / 92 / 7 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 24 / 480 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 120 / 12 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 6 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-2500 kbps / 0.60
x265 [info]: tools: rect amp rd=6 rdoq=2 psy-rdoq=1.00 tskip signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao stats-read
x265 [info]: frame I: 187, Avg QP:15.44 kb/s: 18757.12 PSNR Mean: Y:53.007 U:56.245 V:55.748 SSIM Mean: 0.996481 (24.535dB
)
x265 [info]: frame P: 5475, Avg QP:19.54 kb/s: 6299.14 PSNR Mean: Y:50.557 U:55.238 V:54.725 SSIM Mean: 0.994567 (22.650dB
)
x265 [info]: frame B: 15650, Avg QP:25.57 kb/s: 977.83 PSNR Mean: Y:49.518 U:56.082 V:55.533 SSIM Mean: 0.993497 (21.869dB
)
x265 [info]: Weighted P-Frames: Y:3.3% UV:2.1%
x265 [info]: Weighted B-Frames: Y:1.0% UV:0.5%
x265 [info]: consecutive B-frames: 17.7% 9.1% 8.2% 42.3% 6.2% 9.2% 3.2% 2.5% 0.4% 0.2% 0.2% 0.2% 0.6%

encoded 21312 frames in 124205.99s (0.17 fps), 2500.86 kb/s, Avg QP:23.93, Global PSNR: 51.261, SSIM Mean Y: 0.9937978 (22.075 d
B)

The result is watchable but encoding speed is a bit too slow.
Result movie -- www.msystem.waw.pl/x265/sintel2500.mkv

[Sagittaire]

AMD Threadripper 1950X in x265
https://cubeupload.com/im/bKv6yQ.png

Source -> https://youtu.be/TJiP1bKxLkU?t=3m43s

well, with 4K encoding with this command line:

ffmpeg\ffmpeg.exe -i Sample\Exodus_UHD_HDR_Exodus_draft.mp4 -an -f rawvideo - | x265\x265.exe --input-res 3840x2160 --fps 23.976 - -o Output\x265_2160p.265 --input-depth 10 --output-depth 10 --crf 24 --preset medium --tune grain


|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| CPU | x264 | x265 | LAVC | auto | MMX2 | SSE | SSE2 | SSE3 | SSE4 | AVX | AVX2 | All |
|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| Core i9-7900X | 32.97 | 6.24 | 157 | 4.70 | 1.57 | 1.58 | 2.50 | 2.74 | 4.07 | 3.98 | 4.82 | N/A |
|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| Threadripper 1950X | 37.59 | 6.50 | 136 | 4.65 | 2.02 | 2.00 | 2.95 | 3.10 | 3.89 | 4.10 | 4.26 | N/A |
|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|



With core i9-7900X @4.5 Ghz and 1950X @stock

at stock, core i9-7900X will be at 27.97 fps for x264 and 5.29 fps for x265

As I always say, massive instance encoding is real problem for Rysen.

Anyway certainely that i9-7960X 16C/32T or i9-7980XE 18C/36T will make really better result than 1950X for x264 and x265 encoding. But it's not the case for i9-7800X 10C/20T even with massive OC at 4.5 Ghz.

[Atak_Snajpera]

at stock, core i9-7900X will be at 27.97 fps for x264 and 5.29 fps for x265
You do realize that stock clock on core i9-7900X in practice means 4GHz? The problem with 1950x is that during x265 encoding clock drops to base 3.4 GHz while intel can sustain steady 4GHz.

As I always say, massive instance encoding is real problem for Rysen.
Poor ryzen then... I thought it was designed to be a RIPPER OF THE THREADS. Oh well another marketing lie. Nothing new.

[Sagittaire]

You do realize that stock clock on core i9-7900X in practice means 4GHz? The problem with 1950x is that during x265 encoding clock drops to base 3.4 GHz while intel can sustain steady 4GHz.

In fact Rysen don't use turbo for x264/x265 encoding: TDP at 180W produce big limitation for that. 1950X have even throttling under 3.4 Ghz base frequency with x264 encoding.

http://www.hardware.fr/medias/photos_news/00/54/IMG0054462.png


Poor ryzen then... I thought it was designed to be a RIPPER OF THE THREADS. Oh well another marketing lie. Nothing new.

it's like that. You have the same problem for 7zip or winrar encoding.

Moreover make 5x x265 instance in 1080p is really massive and useless threading usage. Certainely that 2x or 3x instance is suffisant to have CPU charge at 100% even for 1950X.

[Atak_Snajpera]

Moreover make 5x x265 instance in 1080p is really massive and useless threading usage. Certainely that 2x or 3x instance is suffisant to have CPU charge at 100% even for 1950X.
Well rules are the same for all cpus in my benchmark. Besides Intel with less cores has more things to do than Threadripper. The speed penalty should be even higher there. I'm not going to "optimize" my benchmark to show one particular cpu in better light.
Besides 2 extra instances should not be a big problem. Look at older CPUs 2C/2T or 4C/4T. Scalling is good despite running 5 x 265 at the same time.

44.6 fps - Intel Core i9-7900X @ 3.3GHz ( 10C / 20T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
43.6 fps - AMD Threadripper 1950X @ 3.4GHz ( 16C / 32T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
33.9 fps - Intel Core i7-5960X @ 4.4GHz^ ( 8C / 16T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
25.5 fps - AMD Ryzen 7 1700 @ 3.7GHz^ ( 8C / 16T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
24.8 fps - Intel Core i7-6700K @ 4.8GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
23.7 fps - Intel Core i7-7700K @ 4.8GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
23.3 fps - Intel Core i7-6700K @ 4.7GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
22.6 fps - Intel Core i7-6700K @ 4.5GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
18.6 fps - Intel Core i7-6600K @ 4.5GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
16.4 fps - Intel Xeon E5-2690 @ 2.9GHz ( 8C / 16T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
15.8 fps - Intel i7-6770HQ @ 2.6GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
15.8 fps - Intel Core i5-4690K @ 4.2GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
15.6 fps - Intel Xeon E3 1231 v3 @ 3.4GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
14.7 fps - Intel Xeon E5-2670 @ 2.6GHz ( 8C / 16T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
14.7 fps - Intel Core i7-3930K @ 3.2GHz ( 6C / 12T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
13.9 fps - Intel Core i5-7400 @ 3.0GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
13.8 fps - Intel Core i5-6500 @ 3.2GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
13.5 fps - AMD Ryzen 5 1500X @ 3.5GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
13.3 fps - Intel Core i5-4570S @ 3.6GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
12.1 fps - AMD FX-8320 Eight-Core @ 4.32GHz^ ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1
12.0 fps - Intel Core i5-4460 @ 3.2GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
11.2 fps - Intel Core i7-3770K @ 3.5GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
9.7 fps - Intel Core i3-7100 @ 3.9GHz ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
8.8 fps - AMD Ryzen 3 1300X @ 3.5GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
8.3 fps - Intel Core i5-2400 @ 3.7GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
7.8 fps - Intel i7-3612QM @ 2.1GHz ( 4C / 8T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
7.6 fps - Intel Core i7-7500U @ 3.5GHz^ ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2
6.1 fps - Intel Celeron G3900 @ 4.0GHz^ ( 2C / 2T ) MMX2 SSE2Fast SSSE3 SSE4.2 LZCNT
5.9 fps - AMD Athlon X4 760K Quad Core @ 4.5GHz^ ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX XOP FMA4 FMA3 LZCNT BMI1
5.6 fps - Intel Pentium G3258 @ 4.2GHz^ ( 2C / 2T ) MMX2 SSE2Fast SSSE3 SSE4.2 LZCNT
5.5 fps - Intel Xeon X5470 @ 3.33GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
4.8 fps - Intel Core i3-3220 @ 3.3GHz ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
4.4 fps - Intel Core2 Quad Q8200 @ 2.8GHz^ ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
4.2 fps - Intel Core i3-2100 @ 3.1GHz ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX
3.7 fps - Intel Core2 Quad Q8200 @ 2.33GHz ( 4C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
3.6 fps - Intel Core i3-4005U @ 1.7GHz ( 2C / 4T ) MMX2 SSE2Fast SSSE3 SSE4.2 AVX AVX2 FMA3 LZCNT BMI2

[pradeeprama]

well, with 4K encoding with this command line:




|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| CPU | x264 | x265 | LAVC | auto | MMX2 | SSE | SSE2 | SSE3 | SSE4 | AVX | AVX2 | All |
|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| Core i9-7900X | 32.97 | 6.24 | 157 | 4.70 | 1.57 | 1.58 | 2.50 | 2.74 | 4.07 | 3.98 | 4.82 | N/A |
|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|
| Threadripper 1950X | 37.59 | 6.50 | 136 | 4.65 | 2.02 | 2.00 | 2.95 | 3.10 | 3.89 | 4.10 | 4.26 | N/A |
|---------------------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|---------|



With core i9-7900X @4.5 Ghz and 1950X @stock

at stock, core i9-7900X will be at 27.97 fps for x264 and 5.29 fps for x265

As I always say, massive instance encoding is real problem for Rysen.

Anyway certainely that i9-7960X 16C/32T or i9-7980XE 18C/36T will make really better result than 1950X for x264 and x265 encoding. But it's not the case for i9-7800X 10C/20T even with massive OC at 4.5 Ghz.

If you are trying to benchmark x265 with ffmpeg, I recommend that you use libx265 that is inside ffmpeg instead of using x265 application to avoid any IO problems that occur due to system-level pipes. When doing 4K encoding, I have faced some performance issues in the past.

[Sagittaire]

Well rules are the same for all cpus in my benchmark. Besides Intel with less cores has more things to do than Threadripper. The speed penalty should be even higher there. I'm not going to "optimize" my benchmark to show one particular cpu in better light.
Besides 2 extra instances should not be a big problem. Look at older CPUs 2C/2T or 4C/4T. Scalling is good despite running 5 x 265 at the same time.


I don't know. Anyway result are not the same.

If you have more than 20 fps with i7 4C/8T and 1080p, certainely that you use faster profil for x265 than default "medium" preset.

historically speed are always better for Intel CPU in the fastest mode preset (for x264 and x265). It's perhaps the more simple explication.

[Sagittaire]

If you are trying to benchmark x265 with ffmpeg, I recommend that you use libx265 that is inside ffmpeg instead of using x265 application to avoid any IO problems that occur due to system-level pipes. When doing 4K encoding, I have faced some performance issues in the past.

No I use ffmpeg just for frame serving (always less than 5% for CPU charge in stream decoding). I want use particular x264 and x265 for make compilator test and use the best possible compilation.

[Atak_Snajpera]

If you have more than 20 fps with i7 4C/8T and 1080p, certainely that you use faster profil for x265 than default "medium" preset.
Unlike to your benchmark I decided to use x265 DEFAULT settings. So CRF 28 and preset medium instead of your --crf 24 --preset medium --tune grain.

[Sagittaire]

Unlike to your benchmark I decided to use x265 DEFAULT settings. So CRF 28 and preset medium instead of your --crf 24 --preset medium --tune grain.

crf 24 vs crf 28 or --tune grain are not big problem for speed hierarchy. Moreover --crf 24 --preset medium --tune grain is by far more realistic setting in real world encoding. crf 28 is really low quality level even for 4K.

well multiple and intensive instance seem definitely big problem for Rysen and x265.

[Atak_Snajpera]

Moreover --crf 24 --preset medium --tune grain is by far more realistic setting in real world encoding.
Have you done some survey that you know how people encode? I don't think so. You are just guessing looking in your glass ball. There is not such thing as "far more realistic setting in real world encoding".
Everybody encodes using completely different settings. You basically can't pick some --tune grain and magical --crf 24 (why 24 and not 23 or 22???) and announce the world that this is some sort of gold standard.

well multiple and intensive instance seem definitely big problem for Rysen and x265.
BTW. It is Ryzen not Rysen.

[Balthazar2k4]

Sorry guys, I run my 1950x at 3.9ghz on all cores all day long without issue. I have been a staunch Intel user for over 15 years and and have owned several Extreme edition processors including the 980X, 5960X, and 6950X. I am very pleased with the 1950X. It might not have the IPC of Intel, but the additional cores allow me to do more while I am encoding.

[RanmaCanada]

GPU Fork - x265 HEVC OpenCL or CUDA Encoder

gcc>=7 , -O2 -fopenacc

https://bitbucket.org/vovagubin/x265-hevc-opencl-or-cuda-encoder

has anyone actually compiled this and tried it out yet? Just curious as to how it compares to NVENC, or if it even works.

[LigH]

x265 2.5+14-2718cb5dd67f (https://www.mediafire.com/file/7imced5a87fy3nd/x265_2.5%2B14-2718cb5dd67f.7z) (merge with stable)

cli: Align color primaries names to ffmpeg; Re-evaluate vbv lookahead in the encode that uses --analysis-reuse-mode load

[brumsky]

has anyone actually compiled this and tried it out yet? Just curious as to how it compares to NVENC, or if it even works.

I just compiled it and ran it. It doesn't seem to be any faster than the normal x265. I didn't wait for it to complete to check the quality just a very simple speed test. I'm running a 1080 TI with the latest drivers.

It doesn't look like the help section of the tool has been updated yet. I can't find anything specific to enable Cuda or OpenCL support.

I think we need more info about how to use it at this point.

I did find the author added a new preset called ultraslow but it doesn't work for me.

[x265_Project]

You'll love this, x265 fans...
http://blog.beamr.com/2017/09/08/x265-beamr-5-epic-face-off/

Be sure to download the video files, and compare them side by side. Let us know whose video you prefer.

media2.beamrvideo.com/media/blog1709/fastest/4k/aerial/beamr.265
media2.beamrvideo.com/media/blog1709/fastest/4k/aerial/x.265
media2.beamrvideo.com/media/blog1709/fastest/4k/bar/beamr.265
media2.beamrvideo.com/media/blog1709/fastest/4k/bar/x.265
media2.beamrvideo.com/media/blog1709/fastest/4k/dinner/beamr.265
media2.beamrvideo.com/media/blog1709/fastest/4k/dinner/x.265
media2.beamrvideo.com/media/blog1709/fastest/4k/driving/beamr.265
media2.beamrvideo.com/media/blog1709/fastest/4k/driving/x.265
media2.beamrvideo.com/media/blog1709/fastest/4k/pierseaside/beamr.265
media2.beamrvideo.com/media/blog1709/fastest/4k/pierseaside/x.265
media2.beamrvideo.com/media/blog1709/fastest/4k/ritualdance/beamr.265
media2.beamrvideo.com/media/blog1709/fastest/4k/ritualdance/x.265
media2.beamrvideo.com/media/blog1709/fastest/4k/tango/beamr.265
media2.beamrvideo.com/media/blog1709/fastest/4k/tango/x.265
media2.beamrvideo.com/media/blog1709/fastest/4k/windnature/beamr.265
media2.beamrvideo.com/media/blog1709/fastest/4k/windnature/x.265
media2.beamrvideo.com/media/blog1709/medium/4k/aerial/beamr.265
media2.beamrvideo.com/media/blog1709/medium/4k/aerial/x.265
media2.beamrvideo.com/media/blog1709/medium/4k/bar/beamr.265
media2.beamrvideo.com/media/blog1709/medium/4k/bar/x.265
media2.beamrvideo.com/media/blog1709/medium/4k/dinner/beamr.265
media2.beamrvideo.com/media/blog1709/medium/4k/dinner/x.265
media2.beamrvideo.com/media/blog1709/medium/4k/driving/beamr.265
media2.beamrvideo.com/media/blog1709/medium/4k/driving/x.265
media2.beamrvideo.com/media/blog1709/medium/4k/pierseaside/beamr.265
media2.beamrvideo.com/media/blog1709/medium/4k/pierseaside/x.265
media2.beamrvideo.com/media/blog1709/medium/4k/ritualdance/beamr.265
media2.beamrvideo.com/media/blog1709/medium/4k/ritualdance/x.265
media2.beamrvideo.com/media/blog1709/medium/4k/tango/beamr.265
media2.beamrvideo.com/media/blog1709/medium/4k/tango/x.265
media2.beamrvideo.com/media/blog1709/medium/4k/windnature/x.265
media2.beamrvideo.com/media/blog1709/medium/4k/windnature/beamr.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/aerial/beamr.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/aerial/x.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/bar/beamr.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/bar/x.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/dinner/beamr.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/dinner/x.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/driving/beamr.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/driving/x.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/pierseaside/beamr.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/pierseaside/x.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/ritualdance/beamr.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/ritualdance/x.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/tango/beamr.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/tango/x.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/windnature/beamr.265
media2.beamrvideo.com/media/blog1709/veryslow/4k/windnature/x.265

[Atak_Snajpera]

Cool but where is download link to some trial version at least?

[Selur]

Took a fast look at some of the very slow encodes.
(repacked the stream into mp4 and used Vapoursynth to compare them side-by-side and frame-alternating; using a 5k and a 4k monitor)

Aerial:
The sky look bad on x265s side. Better Details in x265. Especially with faster motion
-> For me: Win for x265 on this one.

Bar Scene:
Dark areas better in x265, light areas better in beamr. When more motion occured x265 looked better.
-> For me: No winner on this one.

Dinner Scene:
Less Banding in x265, more details.
-> For me: x265 is the clear winner here.

PierSeaside:
The sky look bad on x265s side, but x265 has more details in dark areas.
-> For me: Win for Beamr on this one.

Cu Selur

Ps.: Not sure whether I'll take a look at some of the other streams.

[LigH]

I wonder about one point: BEAMR explains that their software is superior i.a. because they use wave-front parallelism (explained in the summary, fact 5.), or brief in 4.:

Beamr 5 supports full codec multithreading while x265 uses slices and tiles for parallelism.

That surprises me: IIRC, x265 supports slices and tiles optionally, but uses WPP per default as well.

But I believe that the deeper explanations of Beamr 5 advantages may give x265 developers some inspirations to think about algorithmic speed-up potential.

One more claim from the summary, fact 4.:

x265 will begin encoding frames before all reference frames are finished, which limits motion estimation to only the parts of reference frames that are available.

The x265 developers will know whether to confirm or not.

[x265_Project]

I wonder about one point: BEAMR explains that their software is superior i.a. because they use wave-front parallelism (explained in the summary, fact 5.), or brief in 4.:

That surprises me: IIRC, x265 supports slices and tiles optionally, but uses WPP per default as well.

You're correct. We support WPP by default, and we had support for WPP long before Vanguard did. They also claim that we don't have early termination heuristics. We have many early termination heuristics. When it comes to x265, it's clear they don't know what they're talking about. When it comes to determining whether the visual quality of their encoder is better than x265, I also don't think they know what they are talking about. I see much better detail retention in the x265 encodes, despite the fact that in most cases the x265 file is smaller. It's not even close.

[x265_Project]

But I believe that the deeper explanations of Beamr 5 advantages may give x265 developers some inspirations to think about algorithmic speed-up potential.

Keep in mind that they designed this test, and they selected the test parameters, including the test sequences to use, which machine to run on, how many threads to allocate, the rate control mode and bit rates, and which x265 presets to compare with.

[WhatZit]

When it comes to determining whether the visual quality of their encoder is better than x265, I also don't think they know what they are talking about.

Yes, it's very strange that they attempt to back up their claim by publishing samples and captures that show the exact opposite.

Too much truth in advertising, for once...

Ominously, this is a taste of how Multicoreware will soon have to defend its product against a litany of snake-oil claims once all the Johnny-Come-Lately HEVC developers like Beamr jump on the iOS 11 bandwagon.

The tangible danger is that mainstream consumers will ultimately prefer to sacrifice quality for speed, which means that lower quality, faster encoders could pose a significant threat.

Look at how many one-click instant AVC encoders there are which output absolute garbage, but do it quickly. There's a market for speed over quality. A big one.

Remember, Beamr based this charade on SPEED, with all due apology to quality. In that unfortunate sense alone, they won this test.

[LigH]

Knowing some of the efforts Multicoreware did to develop x265, I believe we can summarize already beforehand: Being both faster and better is a miracle... ;)

Speed is an objective metric, you can measure it.

Quality is a subjective metric, you have to ask people for their opinions; the more people participate in giving their opinions, the better the result should cover a majority of opinions.

Better quality is usually preserved by more efforts, which require more time; or it requires more space. For a fair speed-vs-quality comparison, at least the size should be as similar as possible. If there is already a remarkable size difference, then you don't need to care about the algorithmic efforts taken for quality preservation anymore, the bitrate difference already makes the test unfair. (Just like comparing accelerating cars: Nothing substitutes cylinder capacity, except more cylinder capacity.)

[Atak_Snajpera]

The tangible danger is that mainstream consumers will ultimately prefer to sacrifice quality for speed, which means that lower quality, faster encoders could pose a significant threat.
I already see this when people use crappy nVidia/Intel/AMD HEVC encoder instead of x264/x265.

[NikosD]

Intel's HW H.264 has a decent quality for its speed and it's perfect for easy transcoding, like DVD rip-to-H.264 file.

Easy, because the resolution and the quality of MPEG2 is low and the MKV DVD rip it's huge.

Using Intel's HW H.264 encoder you get 1/10 th of the size of the DVD rip in a few minutes with comparable (almost the same) quality.

No drawbacks at all.

[stax76]

@Atak_Snajpera

Did you actually compare (probably not with your GUI ;)) with sufficient bitrate like 10 Mb/s?

[Atak_Snajpera]

@Atak_Snajpera

Did you actually compare (probably not with your GUI ;)) with sufficient bitrate like 10 Mb/s?

10 Mbps? Why not 20Mbps? With 10 MBps budget even Xvid looks decent.

[stax76]

Are you sure your storage and bandwidth budget is in balance with your CPU budget? Doesn't appear so.

[x265_Project]

Knowing some of the efforts Multicoreware did to develop x265, I believe we can summarize already beforehand: Being both faster and better is a miracle... ;)

Speed is an objective metric, you can measure it.

Quality is a subjective metric, you have to ask people for their opinions; the more people participate in giving their opinions, the better the result should cover a majority of opinions.

Better quality is usually preserved by more efforts, which require more time; or it requires more space. For a fair speed-vs-quality comparison, at least the size should be as similar as possible. If there is already a remarkable size difference, then you don't need to care about the algorithmic efforts taken for quality preservation anymore, the bitrate difference already makes the test unfair. (Just like comparing accelerating cars: Nothing substitutes cylinder capacity, except more cylinder capacity.)
Why didn't they compare speed when you give both encoders 16 threads or more? Why didn't they conduct this test on a Skylake, Skylake-X or Purley Xeon system, instead of a 4 year old Haswell system? Do you think they didn't test our other performance presets before they decided to show a comparison against Ultrafast, Medium and Veryslow? Why didn't they test 1080P or smaller picture sizes? Do you think that these were the only test sequences (videos) they tried?

Obviously, a competitor can run many tests to find some combination of conditions that enables their product to compare most favorably, and cherry-pick these results. We can't do the same because they won't provide their encoder to us, or to 3rd parties for a fair comparison.

But in the end, even with a cherry-picked test design, when I compare the video, I see nothing but a big win for x265.

[LigH]

But in the end, even with a cherry-picked test design, when I compare the video, I see nothing but a big win for x265.

And it's hard to counter this test without a copy of their encoder to run the "flan case" tests on a large variety of machines and with a more equal selection of parameters. Even if you can find a machine very similar to their test environment, you could only run the freely available software.

[Atak_Snajpera]

And it's hard to counter this test without a copy of their encoder to run the "flan case" tests on a large variety of machines and with a more equal selection of parameters. Even if you can find a machine very similar to their test environment, you could only run the freely available software.

Exactly. It very fishy that they do not provide encoder for testing.
For me Beam "something" is just another rip-off company selling nothing but "fake news".
I'm 100% sure that their "superior" encoder would fall apart to tiny pieces in park_joy or crowd_run.

[NikosD]

@all

Don't be afraid of the competition.

The way system works, it's probably the only way to get things better.

But it has to be real and fair competition in order to work.

[Andouille]

Why didn't they conduct this test on a Skylake, Skylake-X or Purley Xeon system, instead of a 4 year old Haswell system?

Because the average users computer age is that old ?

[Atak_Snajpera]

@all

Don't be afraid of the competition.

The way system works, it's probably the only way to get things better.

But it has to be real and fair competition in order to work.

How can we talk about fair competition if their encoder is NOT available for testing? We all have seen over last years bold claims that some new "super-codec" beats x264 by 50% for example.

[LigH]

Indeed, just remember V-Nova Perseus ... which turned out to be no codec on its own, just a high-frequency spectral band (noise) modeller, like HE-AAC or mp3Pro.

[roo1234]

Indeed, just remember V-Nova Perseus ... which turned out to be no codec on its own, just a high-frequency spectral band (noise) modeller, like HE-AAC or mp3Pro.No further news or testing on this? It seemed promising for ultra low bandwidth.

[x265_Project]

Because the average users computer age is that old ?
Actually, it was a Xeon E5 v2 (Ivy Bridge) processor, with no AVX2 support. No, I don't think it was because the average user's computer is that old. Beamr isn't trying to win any consumer business - they're shooting for commercial customers who run on servers. I think it's clear this was hand selected from among the possible options because it seems to favor their encoder the most.

[x265_Project]

My response to Beamr - http://x265.org/beamr-hevc-encoder-comparison/

[LigH]

Hmm ... from "Epic Face Off" to "Epic Burn"? :cool:

[WhatZit]

My response to Beamr - http://x265.org/beamr-hevc-encoder-comparison/

Beamr are even gunning for your UHDcode Pro Player, as well: http://beamr.com/h264-hevc-video-comparison-player/

Watch out they don't file a sniper patent, like McDonalds (https://patentscope.wipo.int/search/en/detail.jsf?docId=WO2006068865&recNum=1&maxRec=&office=&prevFilter=&sortOption=&queryString=&tab=PCT+Biblio) did with sandwiches. That way, they can list 24 pending patents as (dubious) benefit no. 1 instead of only 23 :rolleyes:

[x265_Project]

Beamr are even gunning for your UHDcode Pro Player, as well: http://beamr.com/h264-hevc-video-comparison-player/

Yes, Vanguard copied our Pro Player years ago, before Beamr bought them.

[_kermit]

Good day,

my first post, although I follow this thread for a long time now, so first things first:
I'd like to thank you for your work. It's amazing how much effort you put into such a great and free ! solution. Really appriciated!

I'd like to re-encode some UHD material but while I found quite a bit about Quality Tuning, I'm lost when it comes to just re-encoding it, using less bandwidth, but keeping everything else the same.
In particular the HDR Parameters.

Examples:
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312680 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 1000.0000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 96 cd/m2


Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0000 cd/m2, max: 1000.0000 cd/m2


Color range : Limited
Color primaries : BT.2020
Transfer characteristics : SMPTE ST 2084
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : R: x=0.680000 y=0.320000, G: x=0.265000 y=0.690000, B: x=0.150000 y=0.060000, White point: x=0.312680 y=0.329000
Mastering display luminance : min: 0.0050 cd/m2, max: 1000.0000 cd/m2


they all have a bit different Parameters.
How would I re-encode those, while preserving all those values for each file?
I guess there is no "take those Parameters from the source file and re-use them in the target file" Option and I have to provide them manually for every file?

Can you provide an example on how to re-encode an mkv (I use ffmpeg and pipe), maybe with some good tunning tips included?

thanks!!

[sneaker_ger]

Example for your first file:
ffmpeg -i "input.mkv" -pix_fmt yuv420p10 -strict -1 -f yuv4mpegpipe - | x265 - --y4m --output-depth 10 --colorprim 9 --transfer 16 --colormatrix 9 --range limited --chromaloc 2 --max-cll "1000,96" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15634,16450)L(10000000,50)" -o "output.265"
(--chromalog 2 is usually used for 4K HDR so I have set it. But MediaInfo doesn't show this about your source.)
remux with audio/subs from source: mkvmerge -o "output.mkv" "output.265" --no-video "input.mkv"

You can find some more examples/discussion here:
https://forum.doom9.org/showthread.php?t=174491
http://x265.readthedocs.io/en/default/cli.html#vui-video-usability-information-options

[stax76]

It's now --transfer smpte2084

edit:

Can anybody provide a sample file which such HDR metadata?

[sneaker_ger]

It's now --transfer smpte2084
Ah, I forgot. Thx. Edited.

Can anybody provide a sample file which such HDR metadata?
Knock yourself out:
http://demo-uhd3d.com/

[_kermit]

Example for your first file:
ffmpeg -i "input.mkv" -pix_fmt yuv420p10 -strict -1 -f yuv4mpegpipe - | x265 - --y4m --output-depth 10 --colorprim 9 --transfer 16 --colormatrix 9 --range limited --chromaloc 2 --max-cll "1000,96" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15634,16450)L(10000000,50)" -o "output.265"
(--chromalog 2 is usually used for 4K HDR so I have set it. But MediaInfo doesn't show this about your source.)
remux with audio/subs from source: mkvmerge -o "output.mkv" "output.265" --no-video "input.mkv"

You can find some more examples/discussion here:
https://forum.doom9.org/showthread.php?t=174491
http://x265.readthedocs.io/en/default/cli.html#vui-video-usability-information-options

that was fast :)

so basically only --max-cll changes accordingly to the source?
Is there a need/benefit using any of the uhd/hdr Options like "--hdr-opt"?

You have some advice on the remaining regular settings for UHD? (preset, CRF value)?

thanks!

[sneaker_ger]

so basically only --max-cll changes accordingly to the source?
Other parameters might change as well but it seems most of the sources floating around use the same parameters, mostly. It's your job to check.

Also, some sources have parameters that don't make much sense. Like your second file which has "Mastering display luminance : min: 0.0000 cd/m2, max: 1000.0000 cd/m2".
Minimum luminance of 0? I don't think such a display is on the market.

Is there a need/benefit using any of the uhd/hdr Options like "--hdr-opt"?

You have some advice on the remaining regular settings for UHD? (preset, CRF value)?
[/QUOTE]
--hdr-opt is supposed to increase compression for HDR but I haven't actually tested it nor see other comparisons. I suggest you read the thread I linked and look around a bit around the forum. It's subjective.
Preset: as slow as you are willing to wait
CRF: as low as you are willing to sacrifice HDD space

[stax76]

@sneaker_ger

You can't really trust the documentation, it's not always in sync with the code, I would always use strings instead of integers for flags.

[sneaker_ger]

The integers should be the integers as they are stored in the bitstream, i.e. taken right out of the HEVC specs. I assume .. well .. hope they will never change. In this case I just chose them so it works with old and new x265 version.

[stax76]

I think if you compare with the console and online help you'll probably find more then one issue.

static const char * const x265_source_csp_names[] = { "i400", "i420", "i422", "i444", "nv12", "nv16", 0 };
static const char * const x265_video_format_names[] = { "component", "pal", "ntsc", "secam", "mac", "unknown", 0 };
static const char * const x265_fullrange_names[] = { "limited", "full", 0 };
static const char * const x265_colorprim_names[] = { "reserved", "bt709", "unknown", "reserved", "bt470m", "bt470bg", "smpte170m", "smpte240m", "film", "bt2020", "smpte428", "smpte431", "smpte432", 0 };
static const char * const x265_transfer_names[] = { "reserved", "bt709", "unknown", "reserved", "bt470m", "bt470bg", "smpte170m", "smpte240m", "linear", "log100",
"log316", "iec61966-2-4", "bt1361e", "iec61966-2-1", "bt2020-10", "bt2020-12",
"smpte2084", "smpte428", "arib-std-b67", 0 };
static const char * const x265_colmatrix_names[] = { "gbr", "bt709", "unknown", "", "fcc", "bt470bg", "smpte170m", "smpte240m",
"ycgco", "bt2020nc", "bt2020c", "smpte2085", "chroma-derived-nc", "chroma-derived-c", "ictcp", 0 };

[sneaker_ger]

I don't.

[stax76]

Maybe the order is correct, there are some incorrect names however like smpte-st-428 -> smpte428

[cap5lock]

Is there any h.265 parameters that remove digital noise and make background really still ?
I have no problem with color banding
Any possibilities to do it without additional filtering (avisynth, etc.)?

[birdie]

Is there any h.265 parameters that remove digital noise and make background really still ?
I have no problem with color banding
Any possibilities to do it without additional filtering (avisynth, etc.)?

None, it's not the codec's job to do.

Besides there are over several dozen of ways to remove noise and artifacts depending on the source.

[Boulder]

There are the --nr-intra and --nr-inter options available. Also the dreaded --sao a.k.a. Smooth All Objects could be helpful in your case.

[birdie]

sao is enabled by default, the two other options are not meant for removing noise or smoothing backgrounds because they will as well smooth everything else. If one wants to remove noise, use avisynth filters for that.

[Natty]

Is there any h.265 parameters that remove digital noise and make background really still ?
I have no problem with color banding
Any possibilities to do it without additional filtering (avisynth, etc.)?
u can set deblocking -3:0, raise qcomp, disable all smoothings, but these wont be enough until u use filters.

[Midzuki]

x265.exe 2.5+20-0967d0add97e

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2497549&viewfull=1#post2497549

[Barough]

x265 v2.5+20-0967d0add97e (http://ge.tt/6zNsfkm2) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.5+20-0967d0add97e
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 2.5+22-8db95a1da9f8 (http://www.mediafire.com/file/2no1g79b81oakl6/x265_2.5%2B22-8db95a1da9f8.7z) (MSYS/MinGW, GCC 7.1.0) ... does XhmikosR still update?

Fixes for analysis load, WPP, bitstream payload size, VBV hanging; new (internal?) parameter for disabling lookahead; Windows DLL will export x265_encoder_ctu_info()

[benwaggoner]

sao is enabled by default, the two other options are not meant for removing noise or smoothing backgrounds because they will as well smooth everything else. If one wants to remove noise, use avisynth filters for that.

--nr-inter works sort of like an adaptive deadzone for predicted blocks. It absolutely will reduce random noise with a high spatial and temporal frequency, and will help stabalize the background of noisy sources. This can also yield significant bitrate reduction since encoding all those high frequency residuals every frame is expensive.

Of course it can also lose detail in moving areas as well.

[Barough]

x265 v2.5+25-4b95f82c9fb1 (http://ge.tt/1PDysom2) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.5+25-4b95f82c9fb1
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


https://bitbucket.org/multicoreware/x265/commits/branch/default

[RieGo]

hey there. are there any commands to improve multithreading on x265?
i'm running an i9 @ 12/24x3.5ghz i end up with 70-80% cpu usage at most, using presets medium slow slower slowest / main10
it's running at ~5/6fps on a slower 4k encode
or do you think something else is bottlenecking me?

[birdie]

hey there. are there any commands to improve multithreading on x265?
i'm running an i9 @ 12/24x3.5ghz i end up with 70-80% cpu usage at most, using presets medium slow slower slowest / main10
it's running at ~5/6fps on a slower 4k encode
or do you think something else is bottlenecking me?

This has been discussed numerous times already. x265 doesn't scale past a certain number of cores. You either buy and use UHDKit or run several copies of x265 simultaneously.

[RieGo]

This has been discussed numerous times already. x265 doesn't scale past a certain number of cores. You either buy and use UHDKit or run several copies of x265 simultaneously.

thanks for explaining.
i was thinking x265 team wrote it scales up to 20(??) threads or something, but i wasn't sure
i also tried to disable HT to run with (only) 12 threads, which doesn't sound like much to me, but same result.
i'll run 2 instances of x265 then. ::thanks:

[Atak_Snajpera]

thanks for explaining.
i was thinking x265 team wrote it scales up to 20(??) threads or something, but i wasn't sure
i also tried to disable HT to run with (only) 12 threads, which doesn't sound like much to me, but same result.
i'll run 2 instances of x265 then. ::thanks:

You won't notice huge fps boost because HT on intel cpus gives only extra ~15%
http://i.cubeupload.com/4hEisV.png

If you see cpu utilization at ~75% then this means that in practice you get ~93% of your CPU.
100-15/50*(100-75)=92.5

[AMED]

x265 v2.5+25-4b95f82c9fb1 (http://ge.tt/1PDysom2) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.5+25-4b95f82c9fb1
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


https://bitbucket.org/multicoreware/x265/commits/branch/defaultBarough's link doesn't seem to work for me, just goes to a page saying "Drop to share files".

[excellentswordfight]

thanks for explaining.
i was thinking x265 team wrote it scales up to 20(??) threads or something, but i wasn't sure
i also tried to disable HT to run with (only) 12 threads, which doesn't sound like much to me, but same result.
i'll run 2 instances of x265 then. ::thanks:
I ran a few benchmarks on some machines a few weeks ago, I thought that x265 scaled quite nicely.

2x Intel Xeon E5-2690 v3 @ 2.9Ghz (24C48T): 3.36 fps
2x Intel Xeon E5-2643 v4 @ 3.6Ghz (12C24T): 2.37 fps

[Barough]

Barough's link doesn't seem to work for me, just goes to a page saying "Drop to share files".


No issues with DL'ing the archive here.

[Barough]

x265 v2.5+27-0e168bdeb48b (http://www93.zippyshare.com/v/54EYlZED/file.html) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.5+27-0e168bdeb48b
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


https://bitbucket.org/multicoreware/x265/commits/branch/default

[d3rd3vil]

If I have an m2ts file with 2 layers and HDR10 PLUS Dolby Vision but the TV only recognizes HDR10, is there a way to force Dolby Vision somehow?

[x265_Project]

If I have an m2ts file with 2 layers and HDR10 PLUS Dolby Vision but the TV only recognizes HDR10, is there a way to force Dolby Vision somehow?

If there is metadata for multiple HDR standards, the TV decides which HDR format to use. If it has a choice between HDR10 (static HDR) and Dolby Vision (dynamic HDR), it will certainly choose Dolby Vision.

[d3rd3vil]

Yeah well but it doesnt. MKVToolNix shows 2 streams one with 4k and one with 1080p. Ofc thats not really accurate cause MKVToolNix doesnt support Dolby Vision but both standards are there. The TV doesnt play the m2ts.

So I have to convert the m2ts to mkv which THEN only seems to support HDR10.

As an example this one: http://4kmedia.org/lg-dolby-vision-uhd-4k-demo/

Once I've used MKVToolNix, the Dolby Vision is gone

Is there at least a way to see if I am using Dolby Vision or not? The TS and the MKV files look pretty much the same in MediaInfo for example. But one has DV the other doesnt....

[Thunderbolt8]

are you sure your TV supports Dolby Vision or 12-bit in general? From what Ive read most panels dont.

[d3rd3vil]

12 bit doesnt matter atm. No TV supports that, thats true.

I got an LG Oled B6. All these Oleds support Dolby Vision. So as I said the TS file has DV and it works fine! After using MKVToolNix, cause the program doesnt support DV, Dolby Vision is gone from the MKV.

But still some information wether the file has DV or not would be nice. But MediaInfo, nor MPC or VLC or any program show anything regarding Dolby Vision....its like it doesnt exist yet. Unfortunate

[nevcairiel]

This entire discussion is rather off-topic for the x265 thread, since x265 cannot encode Dolby Vision, nor is it in any way related to handling your existing Dolby Vision files.

[jlpsvk]

Hi... how can I use extracted Dolby Vision Enhancement layer to encode it to HEVC stream directly with x265?

[d3rd3vil]

And how to even detect it properly with eac3to

[LigH]

Why do you add a question about eac3to to a thread specifically discussing the development of x265? Stay in each thread, separately, please.

[jlpsvk]

Why do you add a question about eac3to to a thread specifically discussing the development of x265? Stay in each thread, separately, please.

I asked about using the layer in x265! :)

[LigH]

@jlpsvk: I directed that to d3rd3vil. Being interested in enhancing x265 is a valid intention here. But using eac3to is best discussed in a thread about eac3to, instead. And there I already expressed my doubts that eac3to is the first choice software to treat video streams, because it was originally made to handle audio streams.

[jlpsvk]

@LigH
Yeah. Ok. :) But. Can I use the demuxed Dolby Vision stream and mux it to encoded video with x265? in MKV new eac3to (3.22) is recognizing Dolby Vision Enhancement Layer too.

[nevcairiel]

x265 has no support for anything Dolby Vision, you would need external tools that support this, including writing the required metadata for Dolby Vision.

[LigH]

... yet?

[x265_Project]

x265 has no support for anything Dolby Vision, you would need external tools that support this, including writing the required metadata for Dolby Vision.

All dynamic HDR requires external tools to analyze the color volume of the video, frame by frame, saving this metadata to a file. For example, Samsung contributed code to x265 enabling us to parse this metadata and insert it into the HEVC bitstream as SEI messages. We are always working with partners in the video ecosystem to find ways to make these kinds of integrations easier and more reliable for our mutual end-users.

[jlpsvk]

if i will mux the second dolby layer to encoded mkv...will it work?

[nevcairiel]

if i will mux the second dolby layer to encoded mkv...will it work?

No. MKV has no support for Dolby Vision. Not to mention the additional metadata to even identify the streams as Dolby Vision.

[byteshare]

@x265_Project, is it possible to have metric data, such as SSIM scores put into the media info like the encoding settings are?

[d3rd3vil]

All dynamic HDR requires external tools to analyze the color volume of the video, frame by frame, saving this metadata to a file. For example, Samsung contributed code to x265 enabling us to parse this metadata and insert it into the HEVC bitstream as SEI messages. We are always working with partners in the video ecosystem to find ways to make these kinds of integrations easier and more reliable for our mutual end-users.

Well that sounds very good. Hopefully you can achieve sth. sooner or later :)

With mkv not supporting DV you mean Matroska as the stream, right? Cause there are mkv containers with mpeg-ts Dolby Vision streams, that seems to work. But the matroska stream doesnt work?!

For example this one is an mkv: https://drive.google.com/file/d/0BwxFVkl63-lEc3k0aldZaGtaVm8/view

[SeeMoreDigital]

Oh jeez @d3rd3vil,

That so-called 'sample' is a classic example where some idiot has simply changed the file extension from .ts to .mkv :eek:

The sample has not been muxed into the .mkv container!

[LigH]

Just in case you do not yet know already: The intel C++ compiler under Linux is not compatible with glibc 2.24-9 and newer (https://software.intel.com/en-us/articles/intel-compiler-not-compatible-with-glibc-224-9-and-newer), because:

According to x86-64 psABI, xmm0-xmm7 can be used to pass function parameters. But ICC also uses xmm8-xmm15 to pass function parameters which violates x86-64 psABI.

As a workaround, you can set environment variable LD_BIND_NOW=1 by

# export LD_BIND_NOW=1

This seems to be exposed especially on CPU's with AVX support. Of course, x265 will mainly use hand-crafted assembly where possible. But where this is not yet available ... you may have to be aware of possible risks if a recent version of glibc is used (well, I am not sure if x265 uses that, but I believe it is a quite basic library).

There are bug reports from the glibc project (https://sourceware.org/bugzilla/show_bug.cgi?id=21236) and RedHat (https://bugzilla.redhat.com/show_bug.cgi?id=1499012).

Please don't mind me if this issue is irrelevant for x265. I just assumed that a cross-platform project using AVX instructions may be among the possibly affected.

[Archimondro]

Hey Guys

Im encoding some Videos to h.265 using megui and x265 Encoder.
In 95% everything runs smooth, but from time to time i encounter an error. Half of the time when i restart the encode, it works, withouth changing anything.

Here is the Log:
[Error] Log for job3 (video, Matrix.(03).2003.Revolutions.German.AAC51.DL.1080p.BluRay.x264-Kristallprinz.mkv.avs -> Matrix.(03).2003.Revolutions.German.AAC51.DL.1080p.BluRay.hevc)
-[Information] [18.10.2017 10:08:19] Started handling job
-[Information] [18.10.2017 10:08:19] Preprocessing
-[Information] [18.10.2017 10:08:19] AviSynth input script
--[NoImage] global MeGUI_darx = 120
--[NoImage] global MeGUI_dary = 49
--[NoImage] #resize
--[NoImage] LoadPlugin("C:\Users\Gandolf\Desktop\meGUI\tools\lsmash\LSMASHSource.dll")
--[NoImage] LWLibavVideoSource("F:\MeguiWorking\1g2hykjs.0bm\Matrix.(03).2003.Revolutions.German.AAC51.DL.1080p.BluRay.x264-Kristallprinz.mkv")
-[Information] [18.10.2017 10:08:30] resolution: 1920x784
-[Information] [18.10.2017 10:08:30] frame rate: 24000/1001
-[Information] [18.10.2017 10:08:30] frames: 185956
-[Information] [18.10.2017 10:08:30] aspect ratio (avs): 120:49 (2.449)
-[Information] [18.10.2017 10:08:30] custom command line: --bframes 6 --pmode --pools 24,0 --pme --wpp --me star
-[Information] [18.10.2017 10:08:31] Job command line: "C:\Users\Gandolf\Desktop\meGUI\tools\x265\avs4x26x.exe" --x26x-binary "C:\Users\Gandolf\Desktop\meGUI\tools\x265\x64\x265.exe" --preset slow --crf 24.0 --bframes 6 --pmode --pools 24,0 --pme --wpp --me star --sar 1:1 --output "F:\MeguiWorking\1g2hykjs.0bm\Matrix.(03).2003.Revolutions.German.AAC51.DL.1080p.BluRay.hevc" "F:\MeguiWorking\1g2hykjs.0bm\Matrix.(03).2003.Revolutions.German.AAC51.DL.1080p.BluRay.x264-Kristallprinz.mkv.avs"
-[Information] [18.10.2017 10:08:31] Process started
-[Information] [18.10.2017 10:08:31] Standard output stream
--[Information] [18.10.2017 15:44:42] avs [info]: AviSynth 2.60, build:Mar 31 2015 [16:38:54]
--[Information] [18.10.2017 15:44:42] avs [info]: Video colorspace: YV12
--[Information] [18.10.2017 15:44:42] avs [info]: Video resolution: 1920x784
--[Information] [18.10.2017 15:44:42] avs [info]: Video framerate: 24000/1001
--[Information] [18.10.2017 15:44:42] avs [info]: Video framecount: 185956
--[Information] [18.10.2017 15:44:42] avs4x26x [info]: "C:\Users\Gandolf\Desktop\meGUI\tools\x265\x64\x265.exe" - --preset slow --crf 24.0 --bframes 6 --pmode --pools 24,0 --pme --wpp --me star --sar 1:1 --output F:\MeguiWorking\1g2hykjs.0bm\Matrix.(03).2003.Revolutions.German.AAC51.DL.1080p.BluRay.hevc --frames 185956 --fps 24000/1001 --input-res 1920x784 --input-csp i420
-[Error] [18.10.2017 10:08:31] Standard error stream
--[Information] [18.10.2017 10:08:42] yuv [info]: 1920x784 fps 24000/1001 i420p8 sar 1:1 unknown frame count
--[Information] [18.10.2017 10:08:42] raw [info]: output file: F:\MeguiWorking\1g2hykjs.0bm\Matrix.(03).2003.Revolutions.German.AAC51.DL.1080p.BluRay.hevc
--[Information] [18.10.2017 10:08:42] x265 [info]: HEVC encoder version 2.5+2-18fa144d453e
--[Information] [18.10.2017 10:08:42] x265 [info]: build info [Windows][GCC 7.1.0][64 bit] 8bit+10bit+12bit
--[Information] [18.10.2017 10:08:42] x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
--[Warning] [18.10.2017 10:08:42] x265 [warning]: Limit reference options 2 and 3 are not supported with pmode. Disabling limit reference
--[Information] [18.10.2017 10:08:42] x265 [info]: Main profile, Level-4 (Main tier)
--[Information] [18.10.2017 10:08:42] x265 [info]: Thread pool 0 using 24 threads on numa nodes 0
--[Information] [18.10.2017 10:08:42] x265 [info]: Slices : 1
--[Information] [18.10.2017 10:08:42] x265 [info]: frame threads / pool features : 4 / wpp(13 rows)+pmode+pme
--[Information] [18.10.2017 10:08:42] x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
--[Information] [18.10.2017 10:08:42] x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
--[Information] [18.10.2017 10:08:42] x265 [info]: ME / range / subpel / merge : star / 57 / 3 / 3
--[Information] [18.10.2017 10:08:42] x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
--[Information] [18.10.2017 10:08:42] x265 [info]: Lookahead / bframes / badapt : 25 / 6 / 2
--[Information] [18.10.2017 10:08:42] x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
--[Information] [18.10.2017 10:08:42] x265 [info]: References / ref-limit cu / depth : 4 / off / off
--[Information] [18.10.2017 10:08:42] x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
--[Information] [18.10.2017 10:08:42] x265 [info]: Rate Control / qCompress : CRF-24.0 / 0.60
--[Information] [18.10.2017 10:08:42] x265 [info]: tools: rect limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
--[Information] [18.10.2017 10:08:42] x265 [info]: tools: rskip signhide tmvp strong-intra-smoothing lslices=4
--[Information] [18.10.2017 10:08:42] x265 [info]: tools: deblock sao
--[Error] [18.10.2017 15:44:42] avs [error]: Error occurred while writing frame 149307
--[Information] [18.10.2017 15:44:42] (Maybe x26x closed)
-[Error] [18.10.2017 15:44:42] Process exits with error: 0xC0000025 STATUS_NONCONTINUABLE_EXCEPTION (-1073741787)
-[Information] [18.10.2017 15:44:42] Job completed


My System:
-WIndows 10 64bit
-64gb RAM
-2x Xeon e5-2697-v3 (36C/72T)
&
-WIndows 10 64bit
-64gb RAM
-2x Xeon e5-2670-v3 (24C/48T)

There is more than enough free HDD space, that cant be the problem.

I run two Workers simulatneously, one with --pools 36,0 and the other --pools 0,36

It also happens when i set --pools 36,36 (running two or a single worker)

If you need any more information, let me know.

Cheers

[microchip8]

@Archimondro

no help on pirated content. Read the rules!

[Archimondro]

@froggy1 Not illegal where i live, but ok.

[benwaggoner]

If I have an m2ts file with 2 layers and HDR10 PLUS Dolby Vision but the TV only recognizes HDR10, is there a way to force Dolby Vision somehow?
Wow, a lot of Dolby Vision questions!

First off, there aren't any extant Dolby Vision titles that use HDR10 as a base layer. The two modes you'll see in streaming or discs today are:

SDR base layer + enhancement layer + dynamic metadata
Non-backwards compatible base layer + dynamic metadata

The enhancement layer is quarter res of the base layer, so a 2160p title would have a 1080p base layer.

The non-backwards compatible base layer dynamically shifts the code values to make maximal use of the 10-bit space, and is in ICtCp. Playing it back as itself would be very trippy, but sub VideoCD quality.

In both cases, the layers and metadata are combined to render a 12-bit ICtCp frame. From there it gets tone mapped to the actual display's characteristics using yet more metadata. Lots of science and tricks go into the playback process, including dynamic backlight control for non-OLED displays.

As far as reusing or reencoding these streams, that would require a LOT of tooling. There's a lot of metadata (both for rendering out the source to the intermediate space, and then rendering from that to the current display) that needs to get transferred correctly for DoVi playback. And you'd need to be able to feed that content back into a DoVi player.

Reencoding is going to be even more fraught. By default DoVi uses ICtCp instead of Y'CbCr color space; that's what the non-backwards compatible stream is in. And for dual layer, the enhancement layer is its own thing that doesn't look like natural images at all. So reencoding using traditional psychovisual tuning may result in...issues.

Dolby Vision has a whole lot of other modes, some implemented in shipping devices, some not. But AFAIK everything available to consumers today uses one of the above.

If 12-bit decoders become broadly available in CE devices someday (NVidia starting with Pascal is the only thing I know of doing it today), then DoVi could just use 12-bit ICtCp + playback metadata, which would make for simpler implementations. The content would already be in the intermediate format, leaving the (highly complex) tone mapping to display stage.

I don't know if anything particularly interesting or useful could be done with DoVi today without licensing the Dolby Vision SDK.

[benwaggoner]

Yeah well but it doesnt. MKVToolNix shows 2 streams one with 4k and one with 1080p. Ofc thats not really accurate cause MKVToolNix doesnt support Dolby Vision but both standards are there. The TV doesnt play the m2ts.

So I have to convert the m2ts to mkv which THEN only seems to support HDR10.

As an example this one: http://4kmedia.org/lg-dolby-vision-uhd-4k-demo/

Once I've used MKVToolNix, the Dolby Vision is gone

Is there at least a way to see if I am using Dolby Vision or not? The TS and the MKV files look pretty much the same in MediaInfo for example. But one has DV the other doesnt....
Per my previous post, it is extremely unlikely that any existing open-source tools would be able to preserve all the required DoVi metadata. I haven't heard about a MKV mapping for DoVi. A whole lot of spec would need to be available for both the muxing and the playback for this work, even running on an app where there is an OS-level DoVi decoder and display tone mapper.

[SeeMoreDigital]

Wow, a lot of Dolby Vision questions!
Indeed... Perhaps they would be better merged into one topic ;)

[d3rd3vil]

Thank you very much benwaggoner for the detailed information. Its interesting and YET disappointing its thats difficult meaning no Dolby Vision for us noses soon :( Cant be helped aparently.

At least Dolby itself could release a DV software that would be nice :)

[benwaggoner]

Thank you very much benwaggoner for the detailed information. Its interesting and YET disappointing its thats difficult meaning no Dolby Vision for us noses soon :( Cant be helped aparently.

At least Dolby itself could release a DV software that would be nice :)
Dolby Vision is a quite complex set of technologies. In essence,


Starts with 12-bit Y'CtCp PQ 2020 HDR content, typically 4000 nits peak and using the P3 subset of color volume.
Plus creative intent metadata where a colorist indicates what parts of what frames are important to preserve on displays that are less than 4000 nit P3 (like blue sky or bright sky)
Encodes it into one or two lower precision layers with metadata so it can be decoded with existing HW decoders
On a device, decodes and then reverses the 1/2 layer coding to the native 12-bit Y'CtCp color space
Then uses information about the particulars of the display it is being played back, combined with the creative intent metadata, to determine the optional way to map the 4000 nit P3 into whatever the display is capable of, so the sky comes out in the right mix of bright and blue
And some even more complex pixel mapping and metadata stuff to make it work over HDMI


This isn't a simple incremental technology, but a complex set of interlocking technologies that need to get implemented together to be useful.

If one already has DoVi elementary streams and wants to play them back on a device that's enabled with DoVi playback, that seems potentially feasible as a pure muxing project. But even then there is a whole lot of metadata that needs to be handled correctly. I don't know of any open-source muxers are capable of this. Not that I've tried personally.

[LigH]

Trying to switch from MSYS (XhmikosR) to MSYS2 (MABS); it's not so simple, using separate runs in MinGW32 and MinGW64 as workaround for now to avoid patching the cross compilation toolchain file.

x265 2.5+27-0e168bdeb48b (https://www.mediafire.com/file/kt6nbpcyathtypy/x265_2.5%2B27-0e168bdeb48b.7z) (GCC 7.2.0)

[Barough]

x265 v2.5+31-df2de6ea407d (http://www38.zippyshare.com/v/3TcWZa0E/file.html) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.5+31-df2de6ea407d
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit


https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 2.5+31-df2de6ea407d (http://www.mediafire.com/file/312jxn7145vbbco/x265_2.5%2B31-df2de6ea407d.7z)

Support for more monochrome video source formats; plus a few fixed nits.

[LigH]

Support for Visual Studio 2017 will probably be available soon.

No reply to my request for MSYS2 yet, though.

[Barough]

Visual Studio 2017 build folders have been added now
https://bitbucket.org/multicoreware/x265/commits/0bc372b7ca7847f8e85b9f407dfdd336073dbb8d?at=default

[Midzuki]

No reply to my request for MSYS2 yet, though.

Regarding https://www.mail-archive.com/x265-devel@videolan.org/msg10362.html

my piece of advice is,
if you want to use MSYS2, then use the real, the standalone MSYS2 itself, not the Media Autobuild Suite --- at least if your only goal is keep compiling x265.exe.

FWIW, the GCC packages provided by Nev and redistributed by XhmikosR can be used without modifications in the mingw32 directory of an MSYS2 environment, so that updating the "all-in-one" x265.exe building script (i.e., makemulti.sh) would be unnecessary. But as I said, I'm talking about a "normal" MSYS2 environment, because I really don't know what the MABS thing actually does. Also, this question: if you manage to make MSYS2 do exactly what MSYS1 does, regarding the "fully-automated" compilation of x265.exe, ¿then what is the point of the upgrade? :confused:

[LigH]

I see it as an advantage that MABS uses pacman as package manager to keep its MSYS2 environment up to date automatically each time you run it. Apart from that, the media tools compilation script is based on a pretty generic MSYS2 environment and installs additional packages for those tools which need extras. That means, chances are good that all the tools required to build x265 are more recent than waiting for any other person uploading a package and manually exchanging files (in fact, only overwriting or adding, but not removing outdated ones, which a package manager will do instead).

As I already wrote, I discovered that I am not able to run the MSYS script provided by Multicoreware in the MSYS2 environment which gets installed by MABS from official package sources. The differences are in the presence of cross compilation twins of GCC applications, which are used when Win64 flavours of x265 should be built in a MinGW32 environment. The differences are:

toolchain-x86_64-w64-mingw32.cmake
SET(CMAKE_SYSTEM_NAME Windows)
SET(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc)
SET(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g++)
SET(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres)
SET(CMAKE_RANLIB x86_64-w64-mingw32-ranlib)
SET(CMAKE_ASM_YASM_COMPILER yasm)

In XhmikosR's MSYS environment, several binaries named "x86_64-w64-mingw32-*.exe" do exist, more than binaries named "i686-w64-mingw32-*.exe"; they all are missing in the directory msys64/mingw32/bin of MABS. I have no knowledge about the nature of these files. I wonder if they belong to a "GNU C++ cross-compilation package" which MABS does not need because MABS uses separate MinGW32 and MinGW64 system branches to build matching binaries natively.

If one knew that they are indeed the mirrored binaries of the opposite MinGW bitness, I guess one could add symbolic links to each opposite MinGW branch, enabling an optional cross-compilation of either the Win64 build of x265 using MinGW32 compilers (analogue to the behaviour in the current MSYS scripts) or the Win32 build of x265 using MinGW64 compilers (possibly preferred for more efficiency).

But if they differ in their functionality (e.g. have to be aware of building a binary not matching the native bitness of the environment), then they may have to get installed at least once manually into the MSYS2 system, hoping that the MABS updater will keep them up to date just along with the packages MABS needs, simply because pacman will find updates for these cross-compilation packages as well.

[nevcairiel]

if you want to use MSYS2, then use the real, the standalone MSYS2 itself, not the Media Autobuild Suite

Thats what I do, just use plain vanilla MSYS2 for the shell, and my own compiler package (https://files.1f0.de/mingw/) extracted somewhere in PATH, and stuff just works like it did before with MSYS1. Native 32-bit compilers and 64-bit "cross" compilers (not really cross compilers, but they have the prefix).
Stuff like MABS is just way too annoying to handle.

[LigH]

But why waste twice the space with two separate MSYS2 environments (one automatically updated by MABS which I still occasionally use to build everything, and the other manually updated on demand but only specifically used to build x265)?

If the MSYS scripts provided by Multicorecare generally work in MSYS2 too, then all I need to know is why some cross-compilation GCC binaries are missing, and how to add them in a way that pacman is aware of them, to possibly update them along.
__

P.S.:

Apparently (https://stackoverflow.com/questions/39422894/mingw-x86-64-w64-mingw32-gcc-not-found) I would need to install MinGW-w64 (http://mingw-w64.org/) as cross-compilation package...

[Midzuki]

First of all, one really should forget the auto-update mania.
Updating for the sake of updating is pointless: if the system works, there is no need to fix it.

When I switched to MSYS2 many moons ago I used pacman only for downloading the missing stuff, EXCEPT the MinGW_w64+GCC packages. In the beginning I used the archives provided by Nev, but later I learned how to compile (and organize) the compilers themselves =)

IMHO the point of MSYS2 is *simplicity*:
build 32-bit binaries through mingw32,
build 64-bit binaries through mingw64, case closed :)

[LigH]

Well, okay ... so my "workaround" will become my habit.

[nevcairiel]

But why waste twice the space with two separate MSYS2 environments (one automatically updated by MABS which I still occasionally use to build everything, and the other manually updated on demand but only specifically used to build x265)?


Why indeed. I build everything just fine with my manual environment. :)

[mandarinka]

Apparently x265 can be up to 5% faster on AMD Ryzens if it doesn't use AVX2: link (https://forums.anandtech.com/threads/intel-skylake-kaby-lake.2428363/page-662#post-39149633) (RZN = Ryzen, CFL = Coffee Lake, SKL-X = Skylake-X)

Can we get some change to CPU detection/dispatcher that would make x265 not use AVX2 assembly on Zen cores? (this also hapens on Excavator) AFAIK.

I know I can override the autodetection in commandline, but it should really be done by default, because most people aren't going to know about this, plus it gets more iffy for GUI/frontend users.

[LigH]

I would suspect that the optimum may not be disabling it completely, but restricting it to specific thread pools ... just a wild guess, uneducated.

[jaiden190]

Hello. First time post here. I am trying to get HDR working. I Compiled a 10bit ffmpeg.exe and I can get everything else like bt.2020 to work. But I can't seem to get the metadata for the -master-display to work. Comes up with Unrecognized option 'master-display' when I start.

Bit of a nub with this. Any help would be appreciated.

[LigH]

Which version of x265 do you use? And do you prepend it with a double dash?

--master-display <string> SMPTE ST 2086 master display color volume info SEI (HDR)
format: G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min)

is present in x265 v2.5, but I would not immediately know when it was introduced. Probably before v2.0 already.

Oh, wait, you said ffmpeg. So, it would be a part of

-x265-params <string> E..V.... set the x265 configuration using a :-separated list of key=value parameters

ffmpeg does not expose all x265 parameters as ffmpeg native parameters, only those which are quite common, especially common among several encoders.

[jaiden190]

Which version of x265 do you use? And do you prepend it with a double dash?

--master-display <string> SMPTE ST 2086 master display color volume info SEI (HDR)
format: G(x,y)B(x,y)R(x,y)WP(x,y)L(max,min)

is present in x265 v2.5, but I would not immediately know when it was introduced. Probably before v2.0 already.

Oh, wait, you said ffmpeg. So, it would be a part of

-x265-params <string> E..V.... set the x265 configuration using a :-separated list of key=value parameters

ffmpeg does not expose all x265 parameters as ffmpeg native parameters, only those which are quite common, especially common among several encoders.


I compiled it with media-autobuild_suite-master. I assume it gets the latest x265.

double dash has the same error.

-max-cll "1000,400" has the same problem also.

[LigH]

Once again: Did you try putting it into -x265-params (with a syntax like: -x265-params master-display=string:max-cll=1000,400 etc.) for ffmpeg?

[jaiden190]

Once again: Did you try putting it into -x265-params (with a syntax like: -x265-params master-display=string:max-cll=1000,400 etc.) for ffmpeg?

ahhh sorry about that. Didn't read you correctly.

Im getting somewhere now. I no longer get the Unrecognized option error now but when I run it i get this instead.

"Unable to find a suitable output format for 'G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1)'
G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1): Invalid argument"


this is what I am using.
x265-params -master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

[microchip8]

ahhh sorry about that. Didn't read you correctly.

Im getting somewhere now. I no longer get the Unrecognized option error now but when I run it i get this instead.

"Unable to find a suitable output format for 'G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1)'
G(0.265000,0.690000)B(0.150000,0.060000)R(0.680000,0.320000)WP(0.312700,0.329000)L(1000,1): Invalid argument"


this is what I am using.
x265-params -master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

it should be...

x265-params master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

[jaiden190]

it should be...

x265-params master-display="G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,50)"

ahhhhh thats it. I have only really used handbrake GUI. Not used to CLI. Thank you both for your help.

[LigH]

One more thought regarding MSYS2 ... MABS seems to be able to switch from the MinGW32 to the MinGW64 environment. Once I discover how it does that, I may be able to fully automate my own x265-only build script to generate one after another, each using the native compiler bitness.

[Barough]

x265 v2.5+33-6a310b24c6a2 (http://www81.zippyshare.com/v/eL7yBYrw/file.html) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[_kermit]

Hi,

CRF has obviously a direct influence on the Bitrate and therefor on the Quality.

but is guess the assumption is correct that:

- the slower the preset, the higher the Bitrate?
- using "--tune grain" also increases the Bitrate?

How big is the influence on those two?

if those two increase Bitrate, would it be feasible to increase CRF to a higher value while preserving the Quality and use a faster preset and skip --tune grain which could also speed up the encoding?

Basically I'll aks because I usually use CRF 22, "slower" and --tune grain, which is kind of slow of course and I'm wondering if there is an good alternative to that but faster?

cheers, roland

[Boulder]

--tune grain increases the need for bitrate. When I started using x265 as a replacement for x264, I just used --tune grain --preset slower and various CRF values to find out the spot where the visual quality is good enough for me to not notice degrading while watching. For what it's worth, I now use CRF 21.8 for my 720p encodes. I have cherry picked some items from the even slower presets though.

In x264, a slower preset usually means a lower bitrate with the same CRF.

[excellentswordfight]

--tune grain increases the need for bitrate. When I started using x265 as a replacement for x264, I just used --tune grain --preset slower and various CRF values to find out the spot where the visual quality is good enough for me to not notice degrading while watching. For what it's worth, I now use CRF 21.8 for my 720p encodes. I have cherry picked some items from the even slower presets though.

In x264, a slower preset usually means a lower bitrate with the same CRF.
One could think that it would work like that in x265, that it hit's the same quality (since it's crf) at a lower bitrate. But from what i've seen it's the other way arround, I get almost half the bitrate at preset fast compared to slow. The faster presets probably skips alot of fine detail retention.


Basically I'll aks because I usually use CRF 22, "slower" and --tune grain, which is kind of slow of course and I'm wondering if there is an good alternative to that but faster?

cheers, roland
Try to compare it to crf18, preset slow and --no-sao. No sao doesnt hurt speed and helps with detail retention at higher bitrates (and hurt overall image quality at lower). Should be 3-4x as fast, there will ofc be tradeoffs in compression (it doesn't just waste all that time).

[LoRd_MuldeR]

Hi,

CRF has obviously a direct influence on the Bitrate and therefor on the Quality.

but is guess the assumption is correct that:

- the slower the preset, the higher the Bitrate?
- using "--tune grain" also increases the Bitrate?

How big is the influence on those two?

if those two increase Bitrate, would it be feasible to increase CRF to a higher value while preserving the Quality and use a faster preset and skip --tune grain which could also speed up the encoding?

Basically I'll aks because I usually use CRF 22, "slower" and --tune grain, which is kind of slow of course and I'm wondering if there is an good alternative to that but faster?

cheers, roland

You should not expect that the same CRF value still gives the same (approximately) quality after influential settings - especially the Preset/Tune - have been changed.

All you really know is that:

The same CRF value gives the same (approximately) quality for different sources, as long as no other settings are changed.
Using a slower preset improves the "quality per bit" ratio. Conversely, using a faster preset hurts the "quality per bit" ratio. But, in both cases, the absolute bitrate - at a fixed CRF value - may change more or less arbitrarily.


Or, in other words, when influential settings - especially the Preset/Tune - are changed, then the "meaning" of CRF values (in terms of resulting quality) can change as well!

Therefore, I would suggest to first pick the slowest Preset that you are willing to accept (in terms of encoding time). Then, while sticking with the chosen Preset, find the highest CRF value that still gives satisfying quality....

(And for testing Tune options, you should use 2-Pass mode, so that you get a "fair" comparison of files with identical average bitrates. Visually comparing files of different average bitartrates is misleading!)

[_kermit]

One could think that it would work like that in x265, that it hit's the same quality (since it's crf) at a lower bitrate. But from what i've seen it's the other way arround, I get almost half the bitrate at preset fast compared to slow. The faster presets probably skips alot of fine detail retention.


Try to compare it to crf18, preset slow and --no-sao. No sao doesnt hurt speed and helps with detail retention at higher bitrates (and hurt overall image quality at lower). Should be 3-4x as fast, there will ofc be tradeoffs in compression (it doesn't just waste all that time).

my bad, I already use "slow", not slower. so I guess that wouldn't make a difference, but using CRF 18 certainly increases size a lot.
But does "slower" make it 3-4 times slower?

[_kermit]

You should not expect that the same CRF value still gives the same (approximately) quality after influential settings - especially the Preset/Tune - have been changed.

All you really know is that:

The same CRF value gives the same (approximately) quality for different sources, as long as no other settings are changed.
Using a slower preset improves the "quality per bit" ratio. Conversely, using a faster preset hurts the "quality per bit" ratio. But, in both cases, the absolute bitrate - at a fixed CRF value - may change more or less arbitrarily.


Or, in other words, when influential settings - especially the Preset/Tune - are changed, then the "meaning" of CRF values (in terms of resulting quality) can change as well!

Therefore, I would suggest to first pick the slowest Preset that you are willing to accept (in terms of encoding time). Then, while sticking with the chosen Preset, find the highest CRF value that still gives satisfying quality....

(And for testing Tune options, you should use 2-Pass mode, so that you get a "fair" comparison of files with identical average bitrates. Visually comparing files of different average bitartrates is misleading!)

alright. so far CRF 22 worked pretty well while using slow and grain.
So, if I skip grain, which costs a lot of time, I would either need to lower CRF (to what?) or use a slower preset (in my case "slower")?

Skipping "grain" may speed up encoding, "slower" would slow it down again and using a lower CRF improves Quality, compensating for the changes?

BTW: I already use --no-sao.

And that is applicable to 1080p and UHD?

[LoRd_MuldeR]

alright. so far CRF 22 worked pretty well while using slow and grain.
So, if I skip grain, which costs a lot of time, I would either need to lower CRF (to what?) or use a slower preset (in my case "slower")?

Skipping "grain" may speed up encoding, "slower" would slow it down again and using a lower CRF improves Quality, compensating for the changes?

BTW: I already use --no-sao.

And that is applicable to 1080p and UHD?

IMO, you should first decide what is the slowest Preset you are willing to use, in terms of encoding time. Then stick with that in the following.

Secondly, decide wether to use "--tune grain" or not. This can only be decided visually. And visual comparison requires both files to be compared to have exactly the same average bitrate - otherwise your visual comparison would be "unfair" and therefore meaningless/misleading. So, do two 2-Pass encodes - one with option "--tune grain" and one without it. And be sure to pick the same target average bitrate for both encodes. Also, the chosen target average bitrate for these 2-Pass encodes needs to be "reasonable", which means that it should be in the same range that your final encodes will be as well (i.e. the target average bitartrate should neither be unrealistically low, nor unrealistically high). Furthermore, you need to do this test with a source that represents the kind of stuff you are going to encode. Use the two resulting encodes to decide, visually, whether you prefer "--tune grain" or not. Then stick with that in the following.

Finally, now that you have decided the Preset and Tune, go figure out the highest possible CRF value that still gives satisfying result, quality-wise. Again this needs to be done visually, with an appropriate source, or a set of sources...

[_kermit]

IMO, you should first decide what is the slowest Preset you are willing to use, in terms of encoding time. Then stick with that in the following.

Secondly, decide wether to use "--tune grain" or not. This can only be decided visually. And visual comparison requires both files to be compared to have exactly the same average bitrate - otherwise your visual comparison would be "unfair" and therefore meaningless/misleading. So, do two 2-Pass encodes - one with option "--tune grain" and one without it. And be sure to pick the same target average bitrate for both encodes. Also, the chosen target average bitrate for these 2-Pass encodes needs to be "reasonable", which means that it should be in the same range that your final encodes will be as well (i.e. the target average bitartrate should neither be unrealistically low, nor unrealistically high). Furthermore, you need to do this test with a source that represents the kind of stuff you are going to encode. Use the two resulting encodes to decide, visually, whether you prefer "--tune grain" or not. Then stick with that in the following.

Finally, now that you have decided the Preset and Tune, go figure out the highest possible CRF value that still gives satisfying result, quality-wise. Again this needs to be done visually, with an appropriate source, or a set of sources...

thanks!

[excellentswordfight]

my bad, I already use "slow", not slower. so I guess that wouldn't make a difference, but using CRF 18 certainly increases size a lot.
But does "slower" make it 3-4 times slower?
Slower together with tune grain is that much slower yes, or atleast if the source is of very high quality/detailed/grainy.

I use slow, no-sao, crf18 for 1080p and crf22 for UHD. This is my sweetspot for compression/speed ratio. It doesnt give me visually lossless encodes (which i wouldnt use x265 for anyway), but they are most definitely transparent under normal viewing conditions. I found that for 1080p crf22 without tune grain isnt enough to keep fine details on grainy/detailed sources, but that crf18 with only no-sao is close enough.

LoRd_MuldeR is giving you a very good base for doing tests that will lead you to your sweetspot.

[Boulder]

--tune grain disables recursion skip which makes things really slow. I forgot to mention that I use --rskip to re-enable it, I've not seen any side effects for doing that.

[_kermit]

Slower together with tune grain is that much slower yes, or atleast if the source is of very high quality/detailed/grainy.

I use slow, no-sao, crf18 for 1080p and crf22 for UHD. This is my sweetspot for compression/speed ratio. It doesnt give me visually lossless encodes (which i wouldnt use x265 for anyway), but they are most definitely transparent under normal viewing conditions. I found that for 1080p crf22 without tune grain isnt enough to keep fine details on grainy/detailed sources, but that crf18 with only no-sao is close enough.

LoRd_MuldeR is giving you a very good base for doing tests that will lead you to your sweetspot.

grain on 1080p is actually ok, it's UHD were it gets really slow and I might use rskip as mentioned.
We have similar Settings, so I guess I'm good as Long as I can Speed up uhd a bit also.

[_kermit]

--tune grain disables recursion skip which makes things really slow. I forgot to mention that I use --rskip to re-enable it, I've not seen any side effects for doing that.

that's a good tip. thanks.

[Midzuki]

x265.exe 2.5+37-aa9649a2aa8c

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2501168#post2501168

[LigH]

Version 2.5+38 will introduce a new parameter pair to "denote VBV emptiness after inserting all the frames into it".

This enables basic support for chunk-parallel encoding where each segment can specify the starting and ending state of the VBV buffer so that VBV compliance can be maintained when chunks are independently encoded and stitched together.

Release withheld due to a cosmetic issue in the produced help text (missing line breaks).

[LigH]

x265 2.5+47-6a882a9300c2 (https://www.mediafire.com/file/5q3fbi4taakcs19/x265_2.5%2B47-6a882a9300c2.7z)

Speed-ups, API changes, more internal analysis features, new CLI parameters:

--vbv-end <float> Final VBV buffer emptiness (fraction of bufsize or in kbits). Default 0 (disabled)
--vbv-end-fr-adj <float> Frame from which qp has to be adjusted to achieve final decode buffer emptiness. Default 0
--lowpass-dct Use low-pass subband dct approximation. Default disabled
--refine-mv-type <string> Reuse MV information received through API call. Supported option is avc. Default disabled - 0

Docs: refine-mv-type (http://x265.readthedocs.io/en/default/cli.html?highlight=refine-mv-type#cmdoption-refine-mv-type), vbv-end (http://x265.readthedocs.io/en/default/cli.html?highlight=vbv-end#cmdoption-vbv-end)

[Magik Mark]

Thanks for the new switches.

I was just wondering what could be a good value for these switches in order to optimize my encoding? Does it have any prerequisites?

[x265_Project]

Thanks for the new switches.

I was just wondering what could be a good value for these switches in order to optimize my encoding? Does it have any prerequisites?
None of these are likely to help you.
--vbv-end
--vbv-end-fr-adj
are only useful for companies who want to do segmented encoding

--lowpass-dct has potential to speed up encoding for faster presets, but it was just contributed (thank you!), and we haven't had a chance to run the experiments that will help us understand where and when it makes sense to use in terms of speed vs. efficiency.
--refine-mv-type <string> is only useful for 2 pass encoding where the first encoder is different than x265... like, a hardware encoder that can do a lower efficiency, but fast first pass. This won't help anyone doing x265 software encodes. This is all still highly developmental.

[Selur]

@MagikMark:
As far as I see:
'vbv-end' is only useful if you want to stitch together multiple encodes and 'vbv-end-fr-adj' requires the use of '--frames' when used with pipe input so that x265 does know the frame count of the input.
'lowpas-dct' is only for those in the need for speed and quality isn't your concern. ('Empirical analysis shows marginal loss in compression and performance gains up to 10%, paticularly at moderate bit-rates.' see: https://x265.readthedocs.io/en/latest/cli.html?highlight=lowpass%20dc#cmdoption-lowpass-dct)
'refine-mv-type' <- not sure how to use this and when this could really help, see: http://x265.readthedocs.io/en/latest/cli.html?highlight=refine-mv-type#cmdoption-refine-mv-type
-> you probably don't want to use these values at all :)


Cu Selur

Ps.: x265_Project was faster :)

[LigH]

A recent API change made libx265 temporarily incompatible with e.g. ffmpeg calling it in C convention; a patch converting C++ style to C style is submitted in the mailing list but not yet commited to the repo...

[Blue_MiSfit]

What's the usefulness of these new VBV params when you're doing segment encoding?

[x265_Project]

What's the usefulness of these new VBV params when you're doing segment encoding?

Yes, I think our documentation could be a bit better for this feature. If you want the whole video (after assembling your segments) to comply to specific VBV settings, set --vbv-end to the same value as you use for --vbv-init. In other words, the fullness of the decoder's buffer at the end of segment X needs to match the initial buffer fullness for segment X+1.

For example, if we assume the buffer is 90% full when we start a new segment, we need to make sure it wasn't more than 90% full when we finished encoding the last segment.

[Blue_MiSfit]

I see.

[LigH]

x265.h: change references into pointers for C compatibility (https://bitbucket.org/multicoreware/x265/commits/533c167774e879f00c0e4e6ee247c628fb81315b)

Building ffmpeg with libx265 should work again.

[MonoS]

Is there any reason why HDR-opt can be enabled only on 4:2:0 stream?

[SeeMoreDigital]

Is there any reason why HDR-opt can be enabled only on 4:2:0 stream?Currently all video encoded for use with DVD, Blu-ray, Ultra HD, internet streaming and television broadcasts is 4:2:0...

[MonoS]

Currently all video encoded for use with DVD, Blu-ray, Ultra HD, internet streaming and television broadcasts is 4:2:0...

So not something like "quantizer for != 4:2:0 encode should be different than the one coded in the codec", just there's no content out there?

[pradeeprama]

Is there any reason why HDR-opt can be enabled only on 4:2:0 stream?

The MPEG study group that recommended the changes x265 has implemented under the --hdr-opt option focused their study only on consumer grade video (HDR10 4:2:0). That is why it is recommended to use with 4:2:0 for now.

If there are other such recommendations for other color spaces, please do share it here.

[LigH]

x265 2.5+55-dd9772385d15 (https://www.mediafire.com/file/unaun0p506mhce9/x265_2.5%2B55-dd9772385d15.7z)

Add CLI option to enable or disable picture copy to internal frame buffer

--[no-]copy-pic Copy buffers of input picture in frame. Default enabled

Allow encoder to copy input x265 pictures to internal frame buffers. When disabled, x265 will not make an internal copy of the input picture and will work with the application's buffers. While this allows for deeper integration, it is the responsbility of the application to (a) ensure that the allocated picture has extra space for padding that will be done by the library, and (b) the buffers aren't recycled until the library has completed encoding this frame (which can be figured out by tracking NALs output by x265)

I can imagine that when x265 is linked inside an application or as DLL; but how is that supposed to work for x265 as a separate CLI application? I doubt it would have access to memory pointers of a calling application.

[pradeeprama]

x265 2.5+55-dd9772385d15 (https://www.mediafire.com/file/unaun0p506mhce9/x265_2.5%2B55-dd9772385d15.7z)

Add CLI option to enable or disable picture copy to internal frame buffer

--[no-]copy-pic Copy buffers of input picture in frame. Default enabled



I can imagine that when x265 is linked inside an application or as DLL; but how is that supposed to work for x265 as a separate CLI application? I doubt it would have access to memory pointers of a calling application.

I understand the confusion this might cause. Let me try to clarify.

If you invoke the x265 application, you won't be able to access the invoking application's memory buffers as you are in separate processes and therefore this option isn't useful. This option is applicable only when you do an integration of the x265 library with another application. In that case, the option is useful because we advocate that you use the x265_param_parse() API call to populate the right fields of the param structure instead of directly writing the struct yourself; doing it through the API ensures that all checks are done by the library. For every param, the string that you pass to populate the param is the cli-option string and therefore, exposing this as a CLI option enables folks who do deep integration to use this option in a clean fashion

[Selur]

Exposing an option to the CLI which con't be used through the CLI seems strange,.. (or did I misunderstand the above?)

[LigH]

As far as I hope to understand, it may not be helpful to the pure x265 CLI encoder, but possibly to other applications derived from this structure, configuring itself internally with a CLI parameter string as well.

[Selur]

So cli parameter that's not for the CLI,... <- this still seems like it shouldn't be exposed through the cli,.. :D

[x265_Project]

So cli parameter that's not for the CLI,... <- this still seems like it shouldn't be exposed through the cli,.. :D
I asked Pradeep the same question today. As the GM and the primary product manager, I agree that we don't want to confuse people who use our command line interface (CLI) to run x265 by exposing options that are invalid when run from the CLI. I understand that the x265_param_parse() function is a part of the CLI, and that it is useful to validate and organize/prioritize parameters when you run x265 via the API, but this looks like something that we could restructure to eliminate confusion for CLI users. It could be as simple as labeling some options as API only, such that if you attempt to run them from the CLI you'll get an error, or we'll recognize them but they will just be ignored with a warning.

Our documentation has a lot to do with x265's usability. You'll notice that most of x265's parameters are documented as CLI options. There are a few things, for example reconfiguring x265 on the fly, that are only possible through the API. Some things are documented in our online docs (http://x265.readthedocs.io/en/default/api.html), and other things are found in header files. As with most software, there is always room for improving our documentation. Suggestions and contributions are welcomed!

[MonoS]

The MPEG study group that recommended the changes x265 has implemented under the --hdr-opt option focused their study only on consumer grade video (HDR10 4:2:0). That is why it is recommended to use with 4:2:0 for now.

If there are other such recommendations for other color spaces, please do share it here.

Not that i know, i just want to encode a 1080p 4:4:4 HDR stream :)

[Midzuki]

..............
As with most software, there is always room for improving our documentation. Suggestions and contributions are welcomed!

How about finally correcting/updating this piece of (mis)information?

--bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4

[Barough]

x265 v2.5+58-06979c042350 (http://www90.zippyshare.com/v/DuTCLjnQ/file.html) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Midzuki]

..............
As with most software, there is always room for improving our documentation. Suggestions and contributions are welcomed!
How about finally correcting/updating this piece of (mis)information?

--bframes <integer> Maximum number of consecutive b-frames (now it only enables B GOP structure) Default 4

Apparently I will have to return to the x265 mailing list.
Or pester Steve Borho.
Probably both things...

[x265_Project]

Apparently I will have to return to the x265 mailing list.
Or pester Steve Borho.
Probably both things...
Or contribute a patch

[Midzuki]

Or contribute a patch

Yeah, something so difficult as erasing some bytes from a lazily-written help screen really requires an official patch created by someone who stopped programming decades ago :rolleyes:

P.S.: welcome to my Ignore List (again)

[LigH]

Ah, come on ... I am not experienced in creating correct patches either, but when I knew how to improve things, suggesting the kernel of a diff in the mailing list was usually sufficient that another developer included that in a following full patch. They may be a bit picky about the exact style when it comes to official patches, but a professional project with commercial customers requires that amount of pedantism, and amateur suggestions are still welcome.

In your case with the consecutive B frames, I would not be sure which new content would be optimal, but I would know how I would submit a "snippet of a patch" to the mailing list.

[Ma]

Or contribute a patch

It's not always enough -- the patch https://patches.videolan.org/patch/15688/ is forgotten, x265cli.h has changed and now this patch doesn't apply cleanly.

[x265_Project]

I'm just trying to encourage participation. Sure, ideally we'd love patches to be in the right format, able to be applied cleanly to the latest development tip. But for our documentation, we can certainly handle an email to the developer mailing list with your suggested update to the documentation for a particular feature. Our team can figure out how to turn this into the official patch. Developing x265 is a big job... but this is open source, so we want to encourage participation.

Ma - I'm sorry if something was missed. We'll check into it.

[hajj_3]

are there going to be any nice quality improvements in the near future in x265 or are you getting towards x265's limit?

[LigH]

Not speaking for the developers, just my personal guess: I would not expect a revolution anymore, at least in the home consumer area (8-10 bit depth), rather evolution - at most finetuning. "Miracle time" is over, the HEVC specs indicate the range of algorithms which can be used (how to search for redundancies to spare and how to encode the video stream efficiently), and "revolutionary" improvements may not be supported by HEVC specs anymore (but there is e.g. AOMedia AV1). The biggest change I hope for would be integration of libav and AviSynth input modules.

But I could imagine room for more features for professional and specific "niche" usage cases. And of course, steady improvements of speed-up technologies, from more assembly to smarter algorithms in depth.

[pradeeprama]

It's not always enough -- the patch https://patches.videolan.org/patch/15688/ is forgotten, x265cli.h has changed and now this patch doesn't apply cleanly.

My bad - sorry. This patch is now pushed in and the outdated commit message has finally been updated!

[LigH]

x265 2.5+65-a7c2f80c18af (https://www.mediafire.com/file/jv56696q032e6og/x265_2.5%2B65-a7c2f80c18af.7z)

Disable opt-qp-pps and opt-ref-list-length-pps by default; use AVC CU analysis data in anlysis-reuselevel 7 and 8; update an outdated help message for --bframes

[LigH]

Should have waited one more day...

x265 2.5+66-dae558b40d99 (https://www.mediafire.com/file/8842c8ddjaax4ye/x265_2.5%2B66-dae558b40d99.7z)

merge with stable + fixed compiler warning (parentheses)

Milestone v2.6 is in sight!
_

P.S.:

The compilation of x265 will switch from YASM to NASM (min. v2.13); I wonder which were the main reasons: Instruction set support, compilation efficiency, bugs?

[Ma]

the compilation of x265 will switch from yasm to nasm (min. V2.13); i wonder which were the main reasons: Instruction set support, compilation efficiency, bugs?

Only nasm supports AVX-512.

[nevcairiel]

For the record, x264 did the same switch some weeks ago for the same reason.

[Aurelio]

Yasm is more or less EOL. No real development anymore. I also read once that YASM would need a rewrite to support AVX-512. So not going to happen anytime soon.

Some quotes from the x264 mailing list:

"Yes, but I don't see anyone willing to add support for AVX-512. the entire instruction syntax is different so it's a lot of work.
I have 0 hope of yasm ever getting avx-512 support since the instruction encoding is completely different from the old stuff, so it'd be tons of work to add it.
Yes. Yasm is essentially dead. Nasm is actively maintained.
Intel adds support to all new instruction sets to nasm themselves."

[nevcairiel]

Its unfortunate that nasm still suffers from a bunch of shortcomings that yasm didn't have. But maybe there is hope they'll fix it .... after all the years? :p

[jlpsvk]

any benefit of avx-512 in x265? i got i7-7820X, co can't wait.

[LigH]

Again, and again, and again ... there is no AVX-512 source code yet ... so there is no AVX-512 supporting binary yet ... so nobody could have measured an advantage yet.

[burfadel]

I wouldn't be surprised if the most useful instructions for encoding in x265 aren't in the supported feature sets of the mainstream processors. AVX-512 is broken down into several feature sets, only required one is foundation. Heavy AVX-512 use may also be am issue thermal wise but that remains to be seen.

[x265_Project]

You'll need to be patient.

[nevcairiel]

I wouldn't be surprised if the most useful instructions for encoding in x265 aren't in the supported feature sets of the mainstream processors. AVX-512 is broken down into several feature sets, only required one is foundation.

While in theory that is true, in practice there is currently only two "sets" of AVX512 features, one which is used in Purley Xeons and in Skylake-X, and one in Knights Landing - which is entirely uninteresting outside of HPC. (and the one in Skylake-X/Purley is the one we want for video)
Who knows why they split it up like this, maybe in the future there will be CPUs with smaller subsets, but right now the one "mainstream" CPU core that supports it supports all of the relevant things. But its also the first SIMD instruction set that was built "extensible" like this, previously we got AVX2 to extend AVX1 with integer instructions, now we get AVX512-BW/DQ

On that note, its already confirmed that Cannonlake and Icelake will only extend the current AVX512 instructions, and not take away features again. Of course no-one knows what happens if AMD ever implements AVX512.

The bigger problem with AVX512 is the thermal behavior and as such the downclocking it entails. So for AVX512 to be worthwhile to be used, you need to spend a significant amount of time doing AVX512 things, or the downclocking will slow down other things more then the AVX512 helps.

I believe the x265 developers have had experience with this with AVX2 in the past, which also causes a downclock to some degree, although with more optimized nodes that effect has gone down in newer CPUs.

[x265_Project]

The bigger problem with AVX512 is the thermal behavior and as such the downclocking it entails. So for AVX512 to be worthwhile to be used, you need to spend a significant amount of time doing AVX512 things, or the downclocking will slow down other things more then the AVX512 helps.
That's right.
I believe the x265 developers have had experience with this with AVX2 in the past, which also causes a downclock to some degree, although with more optimized nodes that effect has gone down in newer CPUs.
Yes, we do.

[benwaggoner]

Not speaking for the developers, just my personal guess: I would not expect a revolution anymore, at least in the home consumer area (8-10 bit depth), rather evolution - at most finetuning. "Miracle time" is over, the HEVC specs indicate the range of algorithms which can be used (how to search for redundancies to spare and how to encode the video stream efficiently), and "revolutionary" improvements may not be supported by HEVC specs anymore (but there is e.g. AOMedia AV1). The biggest change I hope for would be integration of libav and AviSynth input modules.
A revolution gets built out of lots of little evolutions. 20% improvement a year is still reasonable for HEVC.

But I could imagine room for more features for professional and specific "niche" usage cases. And of course, steady improvements of speed-up technologies, from more assembly to smarter algorithms in depth.
And performance improvements turn into quality improvements, because instead of encoding faster you can choose to encode better.

[LigH]

And performance improvements turn into quality improvements, because instead of encoding faster you can choose to encode better.

Partially ... more efforts don't guarantee better quality retention in every case (objective vs. subjective metrics). I would prefer increasing the bitrate over passing a "threshold of sanity" (which would be somewhere near preset "slower" for me, personally; provided I had potent hardware). :sly:

[pradeeprama]

x265 version 2.6 is now out! The key new improvements include support for segmented encoding, and introducing the ability of x265 to reuse and refine analysis from previously done HEVC and AVC encodes. The tarball of this release can be downloaded from the downloads page.

Release date - 29th November, 2017.
============================

New features
------------------
1) x265 can now refine analysis from a previous HEVC encode (using options --refine-inter, and --refine-intra), or a previous AVC encode (using option --refine-mv-type). The previous encode’s information can be packaged using the x265_analysis_data_t data field available in the x265_picture object.
2) Basic support for segmented (or chunked) encoding added with --vbv-end that can specify the status of CPB at the end of a segment. String this together with --vbv-init to encode a title as chunks while maintaining VBV compliance!
3) --force-flush can be used to trigger a premature flush of the encoder. This option is beneficial when input is known to be bursty, and may be at a rate slower than the encoder.
4) Experimental feature --lowpass-dct that uses truncated DCT for transformation.

Encoder enhancements
--------------------------------
1) Slice-parallel mode gets a significant boost in performance, particularly in low-latency mode.
2) x265 now officially supported on VS2017.
3) x265 now supports all depths from mono0 to mono16 for Y4M format.

API changes
-----------------
1) Options that modified PPS dynamically (--opt-qp-pps and --opt-ref-list-length-pps) are now disabled by default to enable users to save bits by not sending headers. If these options are enabled, headers have to be repeated for every GOP.
2) Rate-control and analysis parameters can dynamically be reconfigured simultaneously via the x265_encoder_reconfig API.
3) New API functions to extract intermediate information such as slice-type, scenecut information, reference frames, etc. are now available. This information may be beneficial to integrating applications that are attempting to perform content-adaptive encoding. Refer to documentation on x265_get_slicetype_poc_and_scenecut, and x265_get_ref_frame_list for more details and suggested usage.
4) A new API to pass supplemental CTU information to x265 to influence analysis decisions has been added. Refer to documentation on x265_encoder_ctu_info for more details.

Bug fixes
-------------
1) Bug fixes when --slices is used with VBV settings.
2) Minor memory leak fixed for HDR10+ builds, and default x265 when pools option is specified.
3) HDR10+ bug fix to remove dependence on poc counter to select meta-data information.

Happy compressing!

[LigH]

x265 2.6+2-32e6f04b8713 (https://www.mediafire.com/file/bbbvs61dxhlu76x/x265_2.6%2B2-32e6f04b8713.7z)

[pradeeprama]

The default branch of x265 has now moved to use nasm. The stable and release tips will continue to use yasm until the next release of x265.

If you are source-compiling x265, please download and install the nasm release 2.13 or newer from here and make sure that the binary is in your path before compiling.

Let us know if you run into any trouble with getting nasm installed on your machine

[LigH]

For people compiling in pre-installed MSYS environments: Both MABS and XhmikosR (+nevcairiel) already provide nasm 2.13.01, no problem to be expected with them; x265 2.6+5 just passed in both. Visual Studio integration may be more interesting.

[Magik Mark]

Hi!

Can you recommend a professional video editor & Encoder that uses this software?

[Midzuki]

The default branch of x265 has now moved to use nasm. The stable and release tips will continue to use yasm until the next release of x265.

If you are source-compiling x265, please download and install the nasm release 2.13 or newer from here and make sure that the binary is in your path before compiling.

Let us know if you run into any trouble with getting nasm installed on your machine

I have tried to compile the latest source-code on my ancient quadcore, but I had to cancel the process because it became incredibly slow :confused:

[ 25%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/ipfilter16.asm.obj

is taking more than 3 minutes :eek: It even seemed I was using my deceased Pentium 4. What happened? The ASM code itself was changed, OR nasm is too slow by default and should be configured to be faster like the previous release of yasm?

OR "none of the above"? :confused:

[Ma]

Yep, nasm is very slow.

[Midzuki]

Then what about switching to FASM?
At least you could check whether it is actually fast =)

http://flatassembler.net/download.php

[qyot27]

I have tried to compile the latest source-code on my ancient quadcore, but I had to cancel the process because it became incredibly slow :confused:

[ 25%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/ipfilter16.asm.obj

is taking more than 3 minutes :eek: It even seemed I was using my deceased Pentium 4. What happened? The ASM code itself was changed, OR nasm is too slow by default and should be configured to be faster like the previous release of yasm?

OR "none of the above"? :confused:
make -j$(nproc)? Or better, just use the Ninja generator instead of make.

Not that it'll speed up nasm on single files, but at least the build process will use all the cores.

[nevcairiel]

Then what about switching to FASM?
At least you could check whether it is actually fast =)

http://flatassembler.net/download.php

The code relies quite a lot on the nasm macro language, which is supported by nasm/yasm, so any other assemblers are not feasible.

[Midzuki]

The code relies quite a lot on the nasm macro language, which is supported by nasm/yasm, so any other assemblers are not feasible.

Thanks for the explanation *THUMBS UP*

P.S.: for the notes, latest nasm version is 2.13.02 since November 29.

https://forum.videohelp.com/attachments/43876-1512111306/nasm-version.png

[Barough]

x265 v2.6+8-fc0570b8d8f9 (http://www.mediafire.com/?077qpb7750kug46) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.6+8-fc0570b8d8f9
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit


https://bitbucket.org/multicoreware/x265/commits/branch/default

[Barough]

x265 v2.6+11-94dc146c5f67 (http://www.mediafire.com/?lwqyaha1uyyf2ac) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

x265 [info]: HEVC encoder version 2.6+11-94dc146c5f67
x265 [info]: build info [Windows][GCC 7.2.0][32/64 bit] 8bit+10bit+12bit


https://bitbucket.org/multicoreware/x265/commits/branch/default

[Stephen R. Savage]

I wonder if x265 developers are even still working on the project anymore, or if all the development effort is going into their proprietary enterprise stuff. There hasn't been any meaningful change to the core encoder in terms of encoding strategy/quality for many versions now. In fact, the public repository sees only a handful of commits a month. Meanwhile, the picture quality is still not competitive with x264, which is similarly inactive, but actually good.


Detail retention is still not competitive with x264. Disabling stuff like SAO helps with this, but then x265 loses all its advantages in edge artifacts.
Ghosting artifacts have existed since the beginning (see the Bitbucket issues), but no sign of any developer interest in a solution.
The recent lambda table change causes massive ringing artifacts on animated content, unless AQ strength is lowered.
x265 still tends to produce bizarre circular artifacts in flat areas. Banding is also persistent.


Maybe the derailing of HEVC by patent licensing and the next-generation AOM has caused MultiCoreWare to pull out of x265.

[x265_Project]

I wonder if x265 developers are even still working on the project anymore, or if all the development effort is going into their proprietary enterprise stuff. There hasn't been any meaningful change to the core encoder in terms of encoding strategy/quality for many versions now. In fact, the public repository sees only a handful of commits a month. Meanwhile, the picture quality is still not competitive with x264, which is similarly inactive, but actually good.


Detail retention is still not competitive with x264. Disabling stuff like SAO helps with this, but then x265 loses all its advantages in edge artifacts.
Ghosting artifacts have existed since the beginning (see the Bitbucket issues), but no sign of any developer interest in a solution.
The recent lambda table change causes massive ringing artifacts on animated content, unless AQ strength is lowered.
x265 still tends to produce bizarre circular artifacts in flat areas. Banding is also persistent.


Maybe the derailing of HEVC by patent licensing and the next-generation AOM has caused MultiCoreWare to pull out of x265.
The x265 Developers are wondering who Steven R Savage is, and what he is working on.

[videoh]

That's pretty lame, Mr. x265. Get over yourself. How about responding to the content instead of indulging in ad hominems?

[x265_Project]

Yeah it's a bit weird when someone is publicly wondering about your commitment and/or competence, as if you aren't in the room.

This is the official x265 HEVC encoder thread, which I started 4 years ago. I get email alerts for new posts, and I check it most every day. If you have a question or concern that you want me to answer, ask me. It's strange to read a post criticizing x265 where I or my team is being referred to in the 3rd person, as if I'm not in the room.

Mr. x265 is a bit formal. I'm on this list publicly, while most people are using anonymous usernames. You can call me Tom. But now I'm also wondering who videoh is, and what he works on. Seriously... I am. Don't you like to know who you're talking to?

If you have examples of content and settings that you feel x265 is not performing well on, let us know through our bug tracker. Yes, we are a business, and we're working to get a return on the millions of dollars of R&D investment we've made in x265.

There is still a very substantial R&D effort on x265 itself, but some improvements take a lot of time, and don't make sense to push into the public repo until they are fully ready.

Take a look at the code (https://bitbucket.org/multicoreware/x265/src). Take a look at the HEVC specifications (http://www.itu.int/rec/T-REC-H.265-201612-I/en). This stuff isn't easy.

For comparison...
git pull http://git.videolan.org/git/x264.git
git rev-list --all --count
x264 has 2851 commits in roughly 13 1/2 years.

hg pull -u https://bitbucket.org/multicoreware/x265
hg up tip
x265 has 11948 commits in roughly 4 1/2 years.

Thanks to funding from our customers, and our own investment, our full-time funded commercial development team (and our contributors) have been able to make 4.2x the commits in 1/3 the time.

If you aren't happy with x265, don't worry...it's open source, so you have multiple options...
1 - clone the repo and improve x265 yourself
2 - pay someone to improve it
3 - ask us nicely to improve it
4 - criticize us publicly
5 - use a different encoder

I'm not a big fan of option 4.

[_kermit]

Yeah it's a bit weird when someone is publicly wondering about your commitment and/or competence, as if you aren't in the room.

This is the official x265 HEVC encoder thread, which I started 4 years ago. I get email alerts for new posts, and I check it most every day. If you have a question or concern that you want me to answer, ask me. It's strange to read a post criticizing x265 where I or my team is being referred to in the 3rd person, as if I'm not in the room.

Mr. x265 is a bit formal. I'm on this list publicly, while most people are using anonymous usernames. You can call me Tom. But now I'm also wondering who videoh is, and what he works on. Seriously... I am. Don't you like to know who you're talking to?

If you have examples of content and settings that you feel x265 is not performing well on, let us know through our bug tracker. Yes, we are a business, and we're working to get a return on the millions of dollars of R&D investment we've made in x265.

There is still a very substantial R&D effort on x265 itself, but some improvements take a lot of time, and don't make sense to push into the public repo until they are fully ready.

Take a look at the code (https://bitbucket.org/multicoreware/x265/src). Take a look at the HEVC specifications (http://www.itu.int/rec/T-REC-H.265-201612-I/en). This stuff isn't easy.

For comparison...
git pull http://git.videolan.org/git/x264.git
git rev-list --all --count
x264 has 2851 commits in roughly 13 1/2 years.

hg pull -u https://bitbucket.org/multicoreware/x265
hg up tip
x265 has 11948 commits in roughly 4 1/2 years.

Thanks to funding from our customers, and our own investment, our full-time funded commercial development team (and our contributors) have been able to make 4.2x the commits in 1/3 the time.

If you aren't happy with x265, don't worry...it's open source, so you have multiple options...
1 - clone the repo and improve x265 yourself
2 - pay someone to improve it
3 - ask us nicely to improve it
4 - criticize us publicly
5 - use a different encoder

I'm not a big fan of option 4.

1+

cheers

[Barough]

x265 v2.6+12-7bd8751a8183 (http://www.mediafire.com/?q6zcl5a1o5iiy5l) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[WhatZit]

Maybe the derailing of HEVC by patent licensing and the next-generation AOM has caused MultiCoreWare to pull out of x265.

What the...? It'd be the exact OPPOSITE, I reckon!

I fully expect a sane Multicoreware to be focusing on greater HEVC industry acceptance in general, and prioritising x265 market penetration in particular.

That they haven't evolved the non-API version of their product much in the last few months might annoy the non-commercial bedroom encoders, but there's a much bigger picture to be seen here.

[LigH]

I keep providing build packages including a DLL, where are all the OpenSource GUI tools using x265 as DLL? ... Just as much demanding as other people demanding progress.

No, I don't want to sound demanding. I want to be curious, at most. And contributing if my little experience permits. Sometimes I do. I hope it was useful when I did.

[sneaker_ger]

I wonder if x265 developers are even still working on the project anymore, or if all the development effort is going into their proprietary enterprise stuff. There hasn't been any meaningful change to the core encoder in terms of encoding strategy/quality for many versions now.
Encoder development is difficult. Like rocket science or maybe even harder. It seems all the low-hanging fruits have been picked...

[excellentswordfight]

Encoder development is difficult. Like rocket science or maybe even harder. It seems all the low-hanging fruits have been picked...
I think most people get that, and I do belive that x265 is an amazing encoder and that the devs and contributers have done amazing work the last couple of years, but I do understand the naysayers that complains beacuse x264 is still superior for near visually lossless HD encodes. And while I think that x265 outperformance x264 even here when you get down to preset slow (and use no-sao), but something like preset fast and tune grain is still both slower and retains less details to slower/tune film with x264.

Personally this is a limitation that isnt that big of deal (just use x264!), but I dont think it's unreasonable that people expect x265 to outperform (or at least match!) it's predecessor for this purpose as well as the other ones were it's already ahead (low bitrate, high res etc).

[Barough]

x265 v2.6+13-6b079854e56e (http://www.mediafire.com/?8alj4y8997ci27j) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[x265_Project]

Encoder development is difficult. Like rocket science or maybe even harder. It seems all the low-hanging fruits have been picked...
Of course, it always makes sense to pick the low-hanging fruit first. But don't take the statistics I posted as a sign that there isn't much room for improvement. I just wanted to point out that HEVC is significantly more complex than AVC, so developing an optimal encoder is just a much bigger job.

[LigH]

And I wish your team all the best success. https://cosgan.de/images/smilie/liebe/h053.gif

[mandarinka]

Same here, good luck!

[x265_Project]

Thanks! We really appreciate the contributions and constructive feedback / ideas we get from the community, including Doom9 forum members LigH (Mario) and Ma0 (Mateusz). If you track our developer mailing list you'll see that outside contributions and feedback have been picking up nicely. Thanks to all!

[divxmaster]

Lol, Steven R Savage....
x264 better detail than x265? No way. I'm getting WAY WAY more detail in x265, yet the x265 file is much smaller. Just reencoded voyager s1ep1, x264 is 700mb, x265 is 402mb, with x265 having so much more detail they arent even comparable.

divxmaster.

[LigH]

I guess it's the old debate about "SAO vs. grain retention": yes, HEVC can look a lot smoother with one set of options...

[Cole_Turner]

@divxmaster

Can you tell me what is your CLI options to get best results?
To 1080p and 2160p.

[Stephen R. Savage]

Lol, Steven R Savage....
x264 better detail than x265? No way. I'm getting WAY WAY more detail in x265, yet the x265 file is much smaller. Just reencoded voyager s1ep1, x264 is 700mb, x265 is 402mb, with x265 having so much more detail they arent even comparable.

divxmaster.
400 MB? Are you kidding me? I compared 1080p x264 at 10 GB/hr to x265 at 10 GB/hr and there's no question. No matter how many bits you put into x265, it always removes details. No problem in x264.

I guess it's the old debate about "SAO vs. grain retention": yes, HEVC can look a lot smoother with one set of options...
Yes, disabling SAO improves the detail retention, but it's clear that x265 was not tuned with this in mind. As soon as you remove SAO, you start encountering all manner of bizarre artifacts ("worms") in flat areas and around edges. This is at any bitrate, including 10+ GB/hr.

[LigH]

I suggest both sides will need to provide samples (preferably public lossless sources, including full command line and used versions) where they can point at and say: "Look, here, this looks {good|bad}".

[Majorlag]

Stephen R. Savage,
I had at one point an issue with x265 10bit hardware acceleration on Nvidia graphics playback that exhibited the same issues of unusual artifacts. Have you tried turning off HEVC hardware decoding or playing on AMD or Intel hardware to see if that resolves issues?

You could also use avisynth to export the same frame from source and encoding file therby bypassing Hardware acceleration to compare in your chose flavor of image viewer.

~Mjoarlag

[divxmaster]

400 MB? Are you kidding me? I compared 1080p x264 at 10 GB/hr to x265 at 10 GB/hr and there's no question. No matter how many bits you put into x265, it always removes details. No problem in x264.

10GB/hr?? Are you kidding me? Theres no point in even using that high a bit rate. Unless you are a publishing house/tv studio.
Try 1GB/hr. That produced x265 1080p that you cannot distinguish from the 20gb/hr original at a sane viewing distance. normally 2-3m. I test comparisons on 48" tv and 102" projector at these distances.

[Stephen R. Savage]

10GB/hr?? Are you kidding me? Theres no point in even using that high a bit rate. Unless you are a publishing house/tv studio.
Try 1GB/hr. That produced x265 1080p that you cannot distinguish from the 20gb/hr original at a sane viewing distance. normally 2-3m. I test comparisons on 48" tv and 102" projector at these distances.

Sorry, but if the quality is bad at 10 GB/hr, it can't be better at 1 GB/hr.

Stephen R. Savage,
I had at one point an issue with x265 10bit hardware acceleration on Nvidia graphics playback that exhibited the same issues of unusual artifacts. Have you tried turning off HEVC hardware decoding or playing on AMD or Intel hardware to see if that resolves issues?

You could also use avisynth to export the same frame from source and encoding file therby bypassing Hardware acceleration to compare in your chose flavor of image viewer.

~Mjoarlag

I always use software decoders for this exact reason.

[WhatZit]

No matter how many bits you put into x265, it always removes details.

I recently spent two weeks explaining to everyone how one single option utterly neutralises this default behavior. You must have missed it.

As soon as you remove SAO, you start encountering all manner of bizarre artifacts ("worms") in flat areas and around edges.

I haven't had that problem since x265 v2.0, and I routinely encode at 30-50% of "transparent" (using naughty flick-screen frame comparisons) x264 bitrates.

That you can't get x265 to perform superbly is YOUR fault, not Multicoreware's.

[FranceBB]

400 MB? Are you kidding me? I No matter how many bits you put into x265, it always removes details.

We have been airing in UHD 2160p HEVC 10bit at 25 Mbit/s for a while now and it looks very good, actually. Quality wise, in broadcast we just moved from an XDCAM 50 Mbit/s master and 6 Mbit/s MPEG-2 1080i 8bit encode to an XAVC 500 Mbit/s master and an HEVC 25 Mbit/s 2160p 10bit encode. HEVC does a really good job and delivers a good quality file to our end users.

[Stephen R. Savage]

I recently spent two weeks explaining to everyone how one single option utterly neutralises this default behavior. You must have missed it.



I haven't had that problem since x265 v2.0, and I routinely encode at 30-50% of "transparent" (using naughty flick-screen frame comparisons) x264 bitrates.

That you can't get x265 to perform superbly is YOUR fault, not Multicoreware's.

I am afraid that you must be either blind or misinformed. With 2.6 and even the latest hg version, it is still impossible to disable SAO and avoid massive artifacts. In fact, since they changed the lambda tables a few versions ago, it has regressed further.

We have been airing in UHD 2160p HEVC 10bit at 25 Mbit/s for a while now and it looks very good, actually. Quality wise, in broadcast we just moved from an XDCAM 50 Mbit/s master and 6 Mbit/s MPEG-2 1080i 8bit encode to an XAVC 500 Mbit/s master and an HEVC 25 Mbit/s 2160p 10bit encode. HEVC does a really good job and delivers a good quality file to our end users.

I could not care less about your "end users." x265 does not deliver good quality for me. It does not outperform x264, and even introduces many artifacts and detail losses not present in the "previous generation" codec.

[burfadel]

I don't see how you could be having so many issues with it. Have you eliminated other possibilities like the video decoder? In any case, if you don't like it don't use it! Constructive criticism with examples would help. Upload a small troublesome clip, take a screenshot of frames with issues, and then they could maybe recreate the issue and work on it. B!tch!ng helps no one.

[WhatZit]

I am afraid that you must be either blind or misinformed. With 2.6 and even the latest hg version, it is still impossible to disable SAO

SAO?! You think I was talking about SAO?

"Misinformed"... hahah, pot meet kettle.

In fact, since they changed the lambda tables a few versions ago, it has regressed further.

Sure, I had to extensively test & retune for the new tables, but it wasn't hard, just very time consuming (involving hundreds of frame comparisons).

After that, it was back to transparent x265 encoding at bitrates that would leave x264 exploding into lego blocks.

So, if you love x264 so much, then keep using it! But don't come here poking your neanderthal spear at those who've evolved beyond it.

[LigH]

Still no shared samples to compare objectively?

[jd17]

I recently spent two weeks explaining to everyone how one single option utterly neutralises this default behavior. You must have missed it.

I must have missed that too.
Would you be so kind as to enlighten me?

I am not unhappy with the performance of x265, a combination of 10bit, CRF17, no-sao and preset slow looks transparent to me.

However, I am very interested in the option you are talking about and I would like to do some comparisons myself, so please share! :)


Edit:
I searched for even older posts from you than I did before and stumbled over this:
https://forum.doom9.org/showthread.php?p=1800261#post1800261

Is that what you are talking about? Using --tune grain?

If that is the case, I agree that --tune grain can work wonders, I used to encode with that option too.
However, while I am convinced of the --tune grain results when using --preset medium, I found that --tune grain added to --preset slow (or slower presets than slow) does too much.
This may sound weird, but it looked to me as if it then introduces noise/grain where there is none in the source.
I assume that the high --psy-rdoq (10) might be the root cause for what I consider artificial noise/grain.

[WhatZit]

I found that --tune grain added to --preset slow (or slower presets than slow) does too much.
This may sound weird, but it looked to me as if it then introduces noise/grain where there is none in the source.

You're not imagining any of it, JD. :)

The slower the preset, the more "overboard" the detail retention gets (ridiculously so at veryslow). Also, the new lambda tables seem to have made the phantom grain effect more pronounced.

That's why you always need to think in opposites with --tune grain: go faster with lower bitrates, and let the special algorithms for stable quantization & high-frequency bias do the work of traditional slower presets and higher bitrates.


Still no shared samples to compare objectively?

Having to use 3rd party sites to host these dissuades a lot of people, I reckon. Including myself, who's already wasted too much time on frame-grab comparisons that are now auto-deleted.

Now, if doom9 had it's own flick-tool feature...

[jd17]

You're not imagining any of it, JD. :)

The slower the preset, the more "overboard" the detail retention gets (ridiculously so at veryslow). Also, the new lambda tables seem to have made the phantom grain effect more pronounced.

That's why you always need to think in opposites with --tune grain: go faster with lower bitrates, and let the special algorithms for stable quantization & high-frequency bias do the work of traditional slower presets and higher bitrates.

That is interesting, I'm glad that you share my assessment. :)

After my trials, I pretty much concluded that I get very comparable results by either going medium/grain or slow/no-sao, both with CRF17.
While the medium/grain version is quicker to encode, the resulting bitrate is considerably higher.
This is why I use the before mentioned slow/no-sao now.


I have not seen the negative effects of --no-sao Stephen R. Savage refers to. Not even at close inspection during my trials.

Accordingly, I too would like to see a sample demonstrating the phenomenon.

[Barough]

x265 v2.6+14-f09f3b4a2115 (http://www.mediafire.com/?vy3jcbv8tzatyxq) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 2.6+14-f09f3b4a2115 (https://www.mediafire.com/file/fsr6u62dtu88bgf/x265_2.6%2B14-f09f3b4a2115.7z)

New options:

--fullhelp Show all options and exit
--gop-lookahead <integer> Extends gop boundary if a scenecut is found within this from keyint boundary. Default 0
_

I wonder ... how much GOP lookahead would you consider sensible, in relation to min and max keyframe intervals.

[divxmaster]

I don't see how you could be having so many issues with it. Have you eliminated other possibilities like the video decoder? In any case, if you don't like it don't use it! Constructive criticism with examples would help. Upload a small troublesome clip, take a screenshot of frames with issues, and then they could maybe recreate the issue and work on it. B!tch!ng helps no one.

Thanks Burfadel, I was about to post exactly that, but you beat me to it!

And just to confirm, I have calculated (roughly) 10GB/hr is a bit rate of 22.755mbps.... bad output of x265 1080p at 22.755mbps??? I dont think so.

[Weyoun]

I could not care less about your "end users." x265 does not deliver good quality for me.

I am so glad x265 was not created for you.

[birdie]

Sorry, but if the quality is bad at 10 GB/hr, it can't be better at 1 GB/hr.

This topic was created to discuss x265 development.

If you have issues with the codec, please create a new thread and post your sources and encoding settings, so that we could all decide whether what you're trying to convey is true or not, and if there's something we or you have overlooked.

As mentioned earlier, 10GB/hr translates to 10*1024*1024*1024*8/3600/1024/1024 = 22.755Mb/sec which will be 100% transparent (unless you want a lossless compression) using x264.

[divxmaster]

As mentioned earlier, 10GB/hr translates to 10*1024*1024*1024*8/3600/1024/1024 = 22.755Mb/sec which will be 100% transparent (unless you want a lossless compression) using x264.

Haha, I think you meant "100% transparent (unless you want a lossless compression) using x265" ??

[Boulder]

Out of interest, there was earlier some discussion that --qcomp 0.8 would be better than the default 0.6. Has anyone made any recent tests, especially with --tune grain?

[birdie]

Haha, I think you meant "100% transparent (unless you want a lossless compression) using x265" ??

I did mean x264.

[divxmaster]

I did mean x264.

Oh Ok,
Well 22.755Mbps will be transparent in x264 or x265. Thats a higher bitrate than some bluray masters.

Cheers,
Divxmaster

[Barough]

x265 v2.6+15-57eaef9abfd8 (http://www.mediafire.com/?s841p3e947h8i76) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Majorlag]

Out of interest, there was earlier some discussion that --qcomp 0.8 would be better than the default 0.6. Has anyone made any recent tests, especially with --tune grain?

I found --qcomp 0.8 to work perfectly for my needs, but I use --rc-grain since I don't want to change my --qpstep to 1. I use the higher qcomp since x264 days. I lean towards less fluctuation in quantizer compression so I change a few of the settings to reflect that, such as"--qpmin 4 --qpmax 44 --qpstep 4 --qcomp 0.8 --rc-lookahead 30 --rc-grain"

[Motenai Yoda]

I found a discrepancy between documentation and source about qg-size, docs sayz [maxCUSize], source 32, maybe it's related to f0b9b9e?
also dc5d584 set it to 32 for "commandlines with medium and all slower presets", but as fast and faster doesn't change it againg, actually it's 32 for all presets

[Barough]

x265 v2.6+17-7a6d244c922b (http://www.mediafire.com/file/j95clsuoxxlf8k6/) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[pingfr]

Merry Christmas to all! :cool:

[dipje]

This might have been posted, but if I wanted to re-encode some youtube-HDR files to make them compatible with my set, how do I translate the HDR metadata?
ffprobe gives this:
Content Light Level Metadata, MaxCLL=2000, MaxFALL=300
Mastering Display Metadata, has_primaries:1 has_luminance:1 r(0.6800,0.3200) g(0.2649,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290) min_luminance=0.009900,max_luminance=2000.000000
and this:
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt709/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)

am I correct that x265 needs:
--master-display "G(2649,6900)B(1500,0600)R(6800,3200)WP(3127,3290)L(99,20000000)" --max-cll 2000,300 --range limited --colorprim bt2020 --colormatrix bt709 --transfer smpte2084

Specially the order for --max-cll which is listed as cll,fall in the help text, and the master-display string where I did every ffprobe value * 10000, is that correct?

[Barough]

x265 v2.6+22-ff02513b92c0 (http://www.mediafire.com/file/8zg33ajm1u4eu9z/) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Selur]

What to use for master-display when MediaInfo reports 'Display P3' ?
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2

[Motenai Yoda]

What to use for master-display when MediaInfo reports 'Display P3' ?
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color primaries : Display P3
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2

from x265.readthedocs.io

Example for a P3D65 1000-nits monitor, where G(x=0.265, y=0.690), B(x=0.150, y=0.060), R(x=0.680, y=0.320), WP(x=0.3127, y=0.3290), L(max=1000, min=0.0001):

G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)

[Selur]

Okay, but there is also DCI P3 Theater which has a different white point, so might be good to know which is which. ;)

[Motenai Yoda]

Okay, but there is also DCI P3 Theater which has a different white point, so might be good to know which is which. ;)
:rolleyes:

maybe (0.314,0.351)

[Boulder]

In the docs, it says that --hdr-opt should be used with AQ-mode on. --tune grain disables AQ-mode, so is it OK to use --hdr-opt anyway or better to leave it out? Also, it is said that the input video should be 10-bit 4:2:0. Is it safe to input 16-bit video (because of processing things in Vapoursynth in 16-bit land) if the original source is 10-bit 4:2:0 and signal --input-depth 16?

[benwaggoner]

Okay, but there is also DCI P3 Theater which has a different white point, so might be good to know which is which. ;)
DCI P3 is different in a bunch of other ways. If content is meant for display on an HDR TV, it won't use the DCI white point.

[benwaggoner]

In the docs, it says that --hdr-opt should be used with AQ-mode on. --tune grain disables AQ-mode, so is it OK to use --hdr-opt anyway or better to leave it out? Also, it is said that the input video should be 10-bit 4:2:0. Is it safe to input 16-bit video (because of processing things in Vapoursynth in 16-bit land) if the original source is 10-bit 4:2:0 and signal --input-depth 16?
--tune grain may not be appropriate to many HDR sources anyway. It's not a panacea. For content that doesn't need --tune-grain you waste a lot of bits to get the same output quality.

[LigH]

x265 2.6+24-69cfe46e8a3b (https://www.mediafire.com/file/a596qautmz4a5lq/x265_2.6%2B24-69cfe46e8a3b.7z) – merge with stable

Several fixes e.g. in analysis and VBV handling; added support for RADL pictures; renamed options:

--radl <integer> Number of RADL pictures allowed in front of IDR. Default 0

( --analysis-reuse-mode <string|int> removed )
--analysis-save <filename> Dump analysis info into the specified file. Default Disabled
--analysis-load <filename> Load analysis buffers from the file specified. Default Disabled

[benwaggoner]

x265 2.6+24-69cfe46e8a3b (https://www.mediafire.com/file/a596qautmz4a5lq/x265_2.6%2B24-69cfe46e8a3b.7z) – merge with stable

Several fixes e.g. in analysis and VBV handling; added support for RADL pictures; renamed options:
I hadn’t dealt with RADL before. Based on some documentation, it sounds like it relates to the frames before an IDR in an open GOP. That it requires a fixed IDR cadence suggests a pretty specific use case, like broadcast stream switching.

Anyone have some context to offer?

[x265_Project]

I hadn’t dealt with RADL before. Based on some documentation, it sounds like it relates to the frames before an IDR in an open GOP. That it requires a fixed IDR cadence suggests a pretty specific use case, like broadcast stream switching.

Anyone have some context to offer?

While an Instantaneous Decoder Refresh (IDR) picture cannot depend on any pictures before it in decoding order (nor can any pictures that follow the IDR picture), there is a concept of leading pictures that is allowed. Random Access Decodable Leading (RADL) B pictures precede the IDR in presentation order and immediately follow it in decoding order. This allows the encoder to exploit the benefits of prediction from a following frame (in presentation order). So, if there is a scene change just prior to the end of a Group of Pictures (GOP), x265 can use RADL B pictures referencing the next IDR picture (in the subsequent GOP) to get the benefits of prediction.

[Selur]

What would happen if one sets radl to max key int? :)

[x265_Project]

What would happen if one sets radl to max key int? :)
I realize you're joking, but for clarity...

**Range of values: Between 0 and `--bframes`

[benwaggoner]

While an Instantaneous Decoder Refresh (IDR) picture cannot depend on any pictures before it in decoding order (nor can any pictures that follow the IDR picture), there is a concept of leading pictures that is allowed. Random Access Decodable Leading (RADL) B pictures precede the IDR in presentation order and immediately follow it in decoding order. This allows the encoder to exploit the benefits of prediction from a following frame (in presentation order). So, if there is a scene change just prior to the end of a Group of Pictures (GOP), x265 can use RADL B pictures referencing the next IDR picture (in the subsequent GOP) to get the benefits of prediction.
So, it's sort of an enhanced Open GOP that can apply to the last frames in the prior GOP, not just the first frames in the new GOP?

I can see how that could reduce keyframe strobing and improve efficiency with fixed cadence encodes. Are there any downsides to it? Any compatibility issues?

[Asmodian]

It actually sounds like a feature for closed GOP, because the importance of closed v.s. open GOP is during decoding, frames that are decoded after an IDR frame can be presented before it while only requiring data (in the decoded picture buffer) from the current GOP. Any RADL B frames would simply be dropped when seeking to the IDR frame.

[fisherwei]

from 2.6(+22 and +24), it seems some problem in my computer.

y4m [info]: 1920x800 fps 24000/1001 i420p10 unknown frame count
raw [info]: output file: D:\x265-workspace\output\harrypotter2001\00001.1080.hevc
x265 [info]: HEVC encoder version 2.6+24-69cfe46e8a3b
x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: Turning on repeat-headers for HDR compatibility
x265 [info]: Main 10 profile, Level-5.1 (High tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(25 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : star / 25 / 5 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 1 / 360 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
x265 [info]: Intra 32x32 TU penalty type : 1
x265 [info]: Lookahead / bframes / badapt : 60 / 9 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / on / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.9 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-19.0 / 0.70
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: limit-modes rd=4 ssim-rd rdoq=2 psy-rdoq=8.00 limit-tu=3
x265 [info]: tools: signhide tmvp b-intra lslices=4 deblock(tC=-1:B=-1)
Error: fwrite() call failed when writing frame: 77, plane: 0, errno: 32
Output 82 frames in 139.43 seconds (0.59 fps)
DONE


2.5 is OK, and sometimes 2.6 is OK too.

Anybody know what's wrong?

Windows 10 64bit

Update:
2.6+17 was OK.
2.6+22/+24 was wrong.
source stream from vspipe.exe

[Ma]

from 2.6(+22 and +24), it seems some problem in my computer.

Your options are far from default -- could you post your command line to easier reproduce the problem.

[x265_Project]

It actually sounds like a feature for closed GOP, because the importance of closed v.s. open GOP is during decoding, frames that are decoded after an IDR frame can be presented before it while only requiring data (in the decoded picture buffer) from the current GOP. Any RADL B frames would simply be dropped when seeking to the IDR frame.

Yes, if someone was seeking to (starting playback from) the IDR frame, any RADL B frames (which come after the IDR frame in decoding order) would be dropped, as they represent frames that come before the IDR frame in presentation order.

The term "current GOP" can be a bit confusing when we're talking about leading pictures. RADL B pictures require the IDR picture (the first frame of the next GOP) as a reference. But the decoder knows this already, as the NAL unit type of the IDR picture will indicate that leading pictures (from the previous GOP) follow the IDR picture in decode order (it will be an IDR_W_RADL as opposed to an IDR_N_LP - IDR with no leading pictures).

[Barough]

x265 v2.6+26-b4edf9b44d23 (http://www.mediafire.com/file/ehdt064y73u5r2o/) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[EDIT]
DL Link to v2.6+26-b4edf9b44d23 have been fixed.

[divxmaster]

Am I right in presuming that the latest "Meltdown" security issue, and the implemented KPTI fix, will not impact x265 much or at all?
From what I understand, its only multiple/regular kernel calls/ints that will cause a slowdown (TLB flush), and presumably x265 doesnt do many? (only file read and writes + text output)
Although for me at least, I have Haswell (soon to be 8700k), so it has PCID, which will mitigate TLB flushes.

Cheers
Divxmaster

[fisherwei]

Your options are far from default -- could you post your command line to easier reproduce the problem.

"C:\Program Files (x86)\VapourSynth\core64\vspipe.exe" --y4m "D:\x265-workspace\output\harrypotter2001\00001.1080.vpy" - | "D:\x265-workspace\bin\x265\x265-2.6+24-69cfe46_vs2015-AVX\x265.exe" --y4m --pool "15,-" --preset slower --tune ssim --profile main10 --level-idc 5.1 --crf 19 --cbqpoffs -2 --crqpoffs -2 --rc-lookahead 60 --me 3 --subme 5 --merange 25 --b-adapt 2 --bframes 9 --ref 5 --aq-mode 3 --aq-strength 0.9 --qcomp 0.70 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --limit-modes --limit-refs 2 --output-depth 10 --rd 4 --rdoq-level 2 --psy-rd 2.0 --psy-rdoq 8 --ssim-rd --deblock -1 --no-sao --no-open-gop --no-rect --no-amp --no-strong-intra-smoothing --no-rskip --tu-intra-depth 2 --tu-inter-depth 2 --ctu 32 --limit-tu 3 --max-tu-size 32 --qg-size 32 --b-intra --weightb --rdpenalty 1 --keyint 360 --min-keyint 1 --vbv-bufsize 100000 --vbv-maxrate 100000 --hdr-opt --aud --hrd --chromaloc 2 --max-cll "552,190" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --log-level 2 --csv "D:\x265-workspace\output\harrypotter2001\00001.1080.csv" --output "D:\x265-workspace\output\harrypotter2001\00001.1080.hevc" -


import vapoursynth as vs
core = vs.get_core()
video = core.lsmas.LWLibavSource(source=r'E:\Harry.Potter.und.der.Stein.der.Weisen.2001.MULTi.COMPLETE.UHD.BLURAY-NIMA4K\00001.m2ts')
video = core.std.CropRel(clip=video, left=0, right=0, top=280, bottom=280)
video.set_output()

[divxmaster]

Am I right in presuming that the latest "Meltdown" security issue, and the implemented KPTI fix, will not impact x265 much or at all?
From what I understand, its only multiple/regular kernel calls/ints that will cause a slowdown (TLB flush), and presumably x265 doesnt do many? (only file read and writes + text output)
Although for me at least, I have Haswell (soon to be 8700k), so it has PCID, which will mitigate TLB flushes.

Cheers
Divxmaster

Just to confirm, I have done some testing with the Meltdown/Spectre patches and x265 doesnt seem slowed at all. (within normal variance).

Run before patching: 9.73fps
After software meltdown patch 9.67fps
after hardware spectre patch 9.60fps (dell 7559 laptop)

If you havent looked into these meltdown/spectre issues yet, do it asap, this is very serious.

Cheers,
Divxmaster

[mikeq]

This might have been posted, but if I wanted to re-encode some youtube-HDR files to make them compatible with my set, how do I translate the HDR metadata?
ffprobe gives this:
Content Light Level Metadata, MaxCLL=2000, MaxFALL=300
Mastering Display Metadata, has_primaries:1 has_luminance:1 r(0.6800,0.3200) g(0.2649,0.6900) b(0.1500 0.0600) wp(0.3127, 0.3290) min_luminance=0.009900,max_luminance=2000.000000
and this:
Stream #0:0(eng): Video: vp9 (Profile 2), yuv420p10le(tv, bt709/bt2020/smpte2084), 3840x2160, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 1k tbn, 1k tbc (default)

am I correct that x265 needs:
--master-display "G(2649,6900)B(1500,0600)R(6800,3200)WP(3127,3290)L(99,20000000)" --max-cll 2000,300 --range limited --colorprim bt2020 --colormatrix bt709 --transfer smpte2084

Specially the order for --max-cll which is listed as cll,fall in the help text, and the master-display string where I did every ffprobe value * 10000, is that correct?

As near as I can tell it's every ffprobe value * 500 - if you look at the "standard" one - that's what it works out to.

[Ma]

@fisherwei
Thanks for command line -- I can reproduce x265 crash:
f:\speed\2.6+24>ffmpeg -i ../tearsofsteel-4k.y4m -v warning -strict -1 -pix_fmt yuv420p10 -f yuv4mpegpipe - | x265 --y4m --pool "15,-" --preset slower --tune ssim --profile main10 --level-idc 5.1 --crf 19 --cbqpoffs -2 --crqpoffs -2 --rc-lookahead 60 --me 3 --subme 5 --merange 25 --b-adapt 2 --bframes 9 --ref 5 --aq-mode 3 --aq-strength 0.9 --qcomp 0.70 --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --limit-modes --limit-refs 2 --output-depth 10 --rd 4 --rdoq-level 2 --psy-rd 2.0 --psy-rdoq 8 --ssim-rd --deblock -1 --no-sao --no-open-gop --no-rect --no-amp --no-strong-intra-smoothing --no-rskip --tu-intra-depth 2 --tu-inter-depth 2 --ctu 32 --limit-tu 3 --max-tu-size 32 --qg-size 32 --b-intra --weightb --rdpenalty 1 --keyint 360 --min-keyint 1 --vbv-bufsize 100000 --vbv-maxrate 100000 --hdr-opt --aud --hrd --chromaloc 2 --max-cll "552,190" --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50)" --log-level 2 --csv "D:\x265-workspace\output\harrypotter2001\00001.1080.csv" --output "D:\x265-workspace\output\harrypotter2001\00001.1080.hevc" -
[yuv4mpegpipe @ 000001b607414760] Warning: generating non standard YUV stream. Mjpegtools will not work.
y4m [info]: 4096x1714 fps 24/1 i420p10 unknown frame count
raw [info]: output file: D:\x265-workspace\output\harrypotter2001\00001.1080.hevc
x265 [info]: HEVC encoder version 2.6+24-69cfe46e8a3b
x265 [info]: build info [Windows][MSVC 1900][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: Turning on repeat-headers for HDR compatibility
x265 [info]: Main 10 profile, Level-5.1 (High tier)
x265 [info]: Thread pool created using 12 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / wpp(54 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 2 inter / 2 intra
x265 [info]: ME / range / subpel / merge : star / 25 / 5 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 1 / 360 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
x265 [info]: Intra 32x32 TU penalty type : 1
x265 [info]: Lookahead / bframes / badapt : 60 / 9 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / on / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 0.9 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-19.0 / 0.70
x265 [info]: VBV/HRD buffer / max-rate / init : 100000 / 100000 / 0.900
x265 [info]: tools: limit-modes rd=4 ssim-rd rdoq=2 psy-rdoq=8.00 limit-tu=3
x265 [info]: tools: signhide tmvp b-intra lslices=4 deblock(tC=-1:B=-1)
av_interleaved_write_frame(): Broken pipe
Error writing trailer of pipe:: Broken pipe
------------------------------
Finally I found the bug -- x265 is trying to write 2195 bytes to allocated 2000 bytes memory. Preparing the patch...

[psyside]

How does one play VP9/HEVC videos on youtube without insane stuttering? i got i5 2400/GTX960?

[Midzuki]

How does one play VP9/HEVC videos on youtube without insane stuttering? i got i5 2400/GTX960?

VP9 is not HEVC, and AFAIK YouTube does not use HEVC.
Also, your question is rather off-topic.

[psyside]

VP9 is not HEVC, and AFAIK YouTube does not use HEVC.
Also, your question is rather off-topic.

I'm a noob, i couldnt find any other thread to ask.

Alsoi have downloaded video from youtube, which in the media info states VP9/HEVC?

[microchip8]

I'm a noob, i couldnt find any other thread to ask.

Alsoi have downloaded video from youtube, which in the media info states VP9/HEVC?

if you haven't found a thread, start a new one! it's that simple

[benwaggoner]

Yes, if someone was seeking to (starting playback from) the IDR frame, any RADL B frames (which come after the IDR frame in decoding order) would be dropped, as they represent frames that come before the IDR frame in presentation order.

The term "current GOP" can be a bit confusing when we're talking about leading pictures. RADL B pictures require the IDR picture (the first frame of the next GOP) as a reference. But the decoder knows this already, as the NAL unit type of the IDR picture will indicate that leading pictures (from the previous GOP) follow the IDR picture in decode order (it will be an IDR_W_RADL as opposed to an IDR_N_LP - IDR with no leading pictures).
Is there a recommendation on using RADL? Is it something that can be safely used in all fixed-GOP encodes to potentially increase quality?

From the description, it sounds like the fundamental technology could also be used in variable duration Closed GOP as well.

[Ma]

from 2.6(+22 and +24), it seems some problem in my computer.
[...]
2.6+17 was OK.
2.6+22/+24 was wrong.

In commit a3334a2 (https://bitbucket.org/multicoreware/x265/commits/a3334a263d26920696091ccfcfe8e0db8be16364) (ver. 2.6+19) there are 2 new options: "analysis-load" and "analysis-save". In function x265_param2string all options are written to a memory buffer in text form (readable), the buffer size was only 2000 bytes, with example that hangs in my system it was 2028 bytes to write.

The bug is critical (even if it not hangs it writes to unknown memory) so we should fix this -- you can try patch 19377 (https://patches.videolan.org/patch/19377/) and report back if it helps.

I've prepared binaries with this patch (and patches 19378, 19379 which are not so important): x265p-2.6+27-2f3c415_vs2015.7z (http://msystem.waw.pl/x265/x265p-2.6+27-2f3c415_vs2015.7z)

[Boulder]

Can anyone explain the situation where --rd-refine could be useful? I.e. is it meant to battle against some specific issue?

[burfadel]

Can anyone explain the situation where --rd-refine could be useful? I.e. is it meant to battle against some specific issue?

I found when used it seems to improve the picture quality, sujectively of course. I think it may affect detailed low light scenes more so than other situations. Admittedly I haven't tried it on and off for a while, other changes may negate its benefits.

[Dclose]

Since when does x265 have a sub-CTU quantization group setting of 8 (instead of minimum 16) available? That's new, isn't it? Maybe it's been there a while and I'm just not remembering.

[fisherwei]

In commit a3334a2 (https://bitbucket.org/multicoreware/x265/commits/a3334a263d26920696091ccfcfe8e0db8be16364) (ver. 2.6+19) there are 2 new options: "analysis-load" and "analysis-save". In function x265_param2string all options are written to a memory buffer in text form (readable), the buffer size was only 2000 bytes, with example that hangs in my system it was 2028 bytes to write.

The bug is critical (even if it not hangs it writes to unknown memory) so we should fix this -- you can try patch 19377 (https://patches.videolan.org/patch/19377/) and report back if it helps.

I've prepared binaries with this patch (and patches 19378, 19379 which are not so important): x265p-2.6+27-2f3c415_vs2015.7z (http://msystem.waw.pl/x265/x265p-2.6+27-2f3c415_vs2015.7z)

It works for me. Thanks in advance. :thanks:

[LigH]

x265_2.6+31-3712d13c09bf (https://www.mediafire.com/file/nxo94z3lljqfuf1/x265_2.6%2B31-3712d13c09bf.7z)


important stability fix when using very verbose parameters like zones and additional files (could exceed a too small internal buffer)
input: change from ifstream to stdio stream
change date to 2018 in output file header

[x265_Project]

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start. But I need to let you know that I've decided to move on, joining Beamr as VP Strategy. x265 has a strong team, and it's in good hands. I'll hand this Doom9 account over to someone on the MulticoreWare team.

Tom

[Selur]

Sad to hear you leave the x265 project, but wish you good luck&co at Beamr.

[Barough]

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start. But I need to let you know that I've decided to move on, joining Beamr as VP Strategy. x265 has a strong team, and it's in good hands. I'll hand this Doom9 account over to someone on the MulticoreWare team.

TomSad to hear that ur leaving x265. Good luck with Beamr.

Sent from my SM-G935F via Tapatalk

[LigH]

Be well and best success, Tom. And we will appreciate your (team's) continued contact and support – here and elsewhere.

[pingfr]

Thanks for everything Tom! Be well, good luck in your future endeavors!

[_kermit]

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start. But I need to let you know that I've decided to move on, joining Beamr as VP Strategy. x265 has a strong team, and it's in good hands. I'll hand this Doom9 account over to someone on the MulticoreWare team.

Tom

thanks for everything and good luck

[nakTT]

Hi everyone.
I've been the head of the x265 project and the head of MulticoreWare's video business from the start. But I need to let you know that I've decided to move on, joining Beamr as VP Strategy. x265 has a strong team, and it's in good hands. I'll hand this Doom9 account over to someone on the MulticoreWare team.

Tom

Thanks for everything and best of luck in your future endeavors.

[chen]

My raw picture size varies from time to time. For instance, I get 250 frames in 1080p for the first 10 secs, and then another 250 frames in 720p in the second 10 secs, and so on. And i need to encode all these frames into a same HEVC bit stream. I found no appropriate command line option, and thus looked into the apis. The x265_encoder_reconfig() seems to be a possible solution, but I am not sure. Can someone share some ideas or experiences?

[LigH]

Sounds like DVB with different programmes; I believe this works only on a container level?!

Gosh, 5,000. :o

[Boulder]

Gosh, 5,000. :o

OT: I'm more scared of the year 2001 :p Where did all the years go?

[chen]

Sounds like DVB with different programmes; I believe this works only on a container level?!

Gosh, 5,000. :o

yes, containers supports video sections with different resolutions, and the output of my encoder will be put in a container.
Question is whether I have to create a new encoder when my picture size has changed or I just need to reconfigure my current encoder?

[nevcairiel]

Considering you need a full decoder and bitstream reset anyway to change resolution, might as well create a new encoder? At least that is known to work.

[Sachin]

X265 encoding in my system uses only Intel uhd graphic card(almost 100%) but Nvidia graphic card is not utilized(0% usage).

My graphic card GEFORCE MX150.
Processor Intel i7-8550@1.8ghz
Ram 16gb

Encoder "x265_2.6+31-3712d13c09bf" with avs2pipemod.

I searched in Google for solution but I don't got one. Please help

[LigH]

The x265 encoder uses no GPU at all; no GPU offers any useful features which would actually speed up x265 without reducing the achievable quality. If your intel GPU is utilized, then the reason may be decoding the source via QuickSync?! Unfortunately you did not post any details about your AviSynth script. But anyway, no matter how the video source is provided, x265 will not use any GPU for encoding.

[Sachin]

Thanks for reply. My doubts are cleared.

[Barough]

x265 v2.6+32-b763c22920f6 (http://www.mediafire.com/file/hs9gg177jwmhmo7/) (GCC 7.2.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[FranceBB]

The x265 encoder uses no GPU at all.

Exactly. I remember having this conversation before in 2015 when we were talking about x264-like OpenCl encoding acceleration. x265 team said that the encoder was still in the main phase of its development and many things were changing, so they didn't have time implement OpenCl. Now it's 2018, years passed, x265 has become a very good codec, with many enhancement since 2015. Perhaps it's time to implement OpenCl encoding acceleration?

[chen]

Because HEVC max qp is 51, i wonder if there's some special reason that x265 takes 69 as the max qp. Does someone have a clue?

[sneaker_ger]

Probably to control vbv emergency denoising.

[chen]

Probably to control vbv emergency denoising.

Oh, i see. Nice design. Thanks for the hint.

[3ngel]

Hi to all,
i've starting recently experimenting x265 as an alternative to x264
I've done a test to a clip with the same bitrate, and the result is not what i was hoping.

These are the screens

Original
http://thumbs2.imagebam.com/de/6c/8a/f8a907729052473.jpg (http://www.imagebam.com/image/f8a907729052473)

x264
--pass 1 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414

http://thumbs2.imagebam.com/78/e3/d4/ea8af4729052553.jpg (http://www.imagebam.com/image/ea8af4729052553)

x265
--pass 1 --slow-firstpass --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --preset veryslow --tune grain --bitrate 5414


avs [info]: AviSynth+ 0.1 (r1576, x64)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x816
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 205
avs4x26x [info]: "x265.exe" - --pass 1 --slow-firstpass --preset veryslow --tune
grain --bitrate 5414 -o 1pass.hevc --frames 205 --fps 24000/1001 --input-res 1
920x816 --input-csp i420
yuv [info]: 1920x816 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: 1pass.hevc
x265 [info]: HEVC encoder version 2.6+31-3712d13c09bf
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 B
MI2 AVX2
x265 [warning]: Rc Grain removes qp fluctuations caused by aq/cutree, Disabling
aq,cu-tree
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: Rate Control / qCompress : ABR-5414 kbps / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=4.00 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: limit-tu=4 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock stats-write

x265 [info]: frame I: 3, Avg QP:27.67 kb/s: 8761.29
x265 [info]: frame P: 30, Avg QP:27.57 kb/s: 5084.63
x265 [info]: frame B: 172, Avg QP:27.61 kb/s: 4393.54
x265 [info]: Weighted P-Frames: Y:3.3% UV:0.0%
x265 [info]: Weighted B-Frames: Y:5.8% UV:1.7%
x265 [info]: consecutive B-frames: 12.1% 0.0% 0.0% 9.1% 9.1% 21.2% 9.1% 18.2% 21
.2%

encoded 205 frames in 155.38s (1.32 fps), 4558.59 kb/s, Avg QP:27.60

-----
avs [info]: AviSynth+ 0.1 (r1576, x64)
avs [info]: Video colorspace: YV12
avs [info]: Video resolution: 1920x816
avs [info]: Video framerate: 24000/1001
avs [info]: Video framecount: 205
avs4x26x [info]: "x265.exe" - --pass 2 --slow-firstpass --preset veryslow --tune
grain --bitrate 5414 -o 2pass.hevc --frames 205 --fps 24000/1001 --input-res 1
920x816 --input-csp i420
yuv [info]: 1920x816 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: 2pass.hevc
x265 [info]: HEVC encoder version 2.6+31-3712d13c09bf
x265 [info]: build info [Windows][GCC 6.3.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 B
MI2 AVX2
x265 [warning]: Rc Grain removes qp fluctuations caused by aq/cutree, Disabling
aq,cu-tree
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(13 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 4
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / on
x265 [info]: Rate Control / qCompress : ABR-5414 kbps / 0.60
x265 [info]: tools: rect amp limit-modes rd=6 psy-rd=4.00 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: limit-tu=4 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock stats-read

x265 [info]: frame I: 3, Avg QP:25.33 kb/s: 13683.28
x265 [info]: frame P: 30, Avg QP:26.53 kb/s: 5932.95
x265 [info]: frame B: 172, Avg QP:26.47 kb/s: 5163.89
x265 [info]: Weighted P-Frames: Y:3.3% UV:0.0%
x265 [info]: Weighted B-Frames: Y:5.8% UV:1.7%
x265 [info]: consecutive B-frames: 12.1% 0.0% 0.0% 9.1% 9.1% 21.2% 9.1% 18.2% 21
.2%

encoded 205 frames in 160.23s (1.28 fps), 5401.11 kb/s, Avg QP:26.46

http://thumbs2.imagebam.com/46/8a/c0/e19d15729052633.jpg (http://www.imagebam.com/image/e19d15729052633)

As you can see, x264 does overally a better job than x265.
In particular you can see banding and more "encoding artifact".
Is this the expected behaviour at this stage of x265 development or I'm missing parameters?

Thank you very much for your work

[benwaggoner]

Hi to all,
i've starting recently experimenting x265 as an alternative to x264
I've done a test to a clip with the same bitrate, and the result is not what i was hoping.

These are the screens

Original
http://thumbs2.imagebam.com/de/6c/8a/f8a907729052473.jpg (http://www.imagebam.com/image/f8a907729052473)

x264
--pass 1 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --profile high --level 4.1 --preset veryslow --tune grain --bitrate 5414

http://thumbs2.imagebam.com/78/e3/d4/ea8af4729052553.jpg (http://www.imagebam.com/image/ea8af4729052553)

x265
--pass 1 --slow-firstpass --preset veryslow --tune grain --bitrate 5414
--pass 2 --slow-firstpass --preset veryslow --tune grain --bitrate 5414


http://thumbs2.imagebam.com/46/8a/c0/e19d15729052633.jpg (http://www.imagebam.com/image/e19d15729052633)

As you can see, x264 does overally a better job than x265.
In particular you can see banding and more "encoding artifact".
Is this the expected behaviour at this stage of x265 development or I'm missing parameters?

Thank you very much for your work
--tune grain are designed pretty differently for x264 and x265 IIRC. I wouldn't expect identical results even at the same net psychovisual preference. And from the still it isn't obvious to me that --tune grain is appropriate for this source. I would probably have tried --tune film in x264 (which doesn't have a x265 preset implementation).

These are relatively subtle differences; can you see the difference when playing at full speed?

Also, these are pretty high bitrates for VBR in either case. The point of x265 is for bitrates where x264 isn't good enough. Maybe try 2000 to see some bigger differences.

[3ngel]

@benwaggoner

Thanks for the reply, i'll try --tune film out of my curiosity.

Concerning subtle differences, my concept was to use x265 for "archival purposes", but i realize reading more and more around that x265 currently (or by design?) isn't aimed toward "archival" (high bitrates) but for "streaming" (low bitrates) and you confirm this too

The point of x265 is for bitrates where x264 isn't good enough.

So i can conclude i have to remain on x264 for archival for now.

Thanks

[pradeeprama]

Is there a recommendation on using RADL? Is it something that can be safely used in all fixed-GOP encodes to potentially increase quality?

From the description, it sounds like the fundamental technology could also be used in variable duration Closed GOP as well.

We have some broadcast partners using 3-4 frames of RADL pictures reporting that it helps improve efficiency for them in closed GOP scenarios, and to switch between streams easily. I don't see any downside in using it for fixed-GOP encodes as long as the decoder on the downstream can support it.

[pradeeprama]

My raw picture size varies from time to time. For instance, I get 250 frames in 1080p for the first 10 secs, and then another 250 frames in 720p in the second 10 secs, and so on. And i need to encode all these frames into a same HEVC bit stream. I found no appropriate command line option, and thus looked into the apis. The x265_encoder_reconfig() seems to be a possible solution, but I am not sure. Can someone share some ideas or experiences?

x265 does not support changing resolution of the encode on the fly for a single instance of x265. Although this should be possible by just changing the resolution with a new SPS/PPS, from my experience, decoders don't always support this flawlessly in a single stream without a new VPS.

[mini-moose]

Hi

I'm trying x265 for the first time now.

Is pausing encode by clicking on the console window safe and won't cause any corruptions?

i.e touch to pause and then space bar to resume.

I've been told to use avs2pipemod64 to pipe x265 through. Don't know if that could have any effect on pausing.

thanks in advance.

[FranceBB]

@mini-moose... I did it accidentally more than once and it didn't corrupt my encode; everything resumed fine and the final output wasn't affected. I think x265 *just* waits for frames from the pipe to encode them. Clicking on the console prevents the pipe from processing frames, therefore x265 waits.

[Selur]

From my experience only thing that might be 'off' are encoding speed/time indications/estimations when pausing an encoding,...

[birdie]

@mini-moose

100% safe unless you press Ctrl + C which will simply terminate your encoding.

[mini-moose]

thanks for all the answers!

[dcxero]

Does anyone have any CLI tricks for cutting down on the grid of "squares" that pop up during encoding? I'm still trying out various options, trying to keep most options near placebo level, but this seems to be a common occurrence, am I misusing a switch?

Example, Source:
http://thumbs2.imagebam.com/e8/89/19/976108731537323.jpg (http://www.imagebam.com/image/976108731537323)

Encode
http://thumbs2.imagebam.com/1a/8f/55/eda72c731537283.jpg (http://www.imagebam.com/image/eda72c731537283)

--ctu 64 --bframes 8 --b-adapt 2 --rc-lookahead 60 --lookahead-slices 1 --ref 6 --limit-refs 0 --me 3 --merange 92 --subme 5 --rect --amp --limit-modes --max-merge 5 --no-rskip --no-fast-intra --b-intra --limit-sao --weightb --rd 6 --rdoq-level 2 --tu-intra-depth 4 --tu-inter-depth 4 --cbqpoffs -3 --crqpoffs -3 --deblock -3:-3 --no-strong-intra-smoothing --psy-rd 2.10 --psy-rdoq 4 --qcomp .75 --input-res 3840x2160 --fps 24000/1001 --aq-strength 1.00 --ipratio 1.3 --pbratio 1.2 --crf 16.5 --vbv-bufsize 160000 --vbv-maxrate 160000

[Taurus]

Sorry, my english is maybe bad.
But I cant see grid of "squares" in your pictures.
Just the normal encoding artefacts.
Your --input-res 3840x2160 and your posted images are 1280x720.
Even bumping up the monitor brightness and magnifying the png
shows no squares on my side.
Or maybe my eyesight is vanishing.
Just an old horse with dull eyes :D!

[Asmodian]

Does anyone have any CLI tricks for cutting down on the grid of "squares" that pop up during encoding?

-3 is probably too weak deblocking for x265, try -1 or -2 at most.

[microchip8]

-3 is probably too weak deblocking for x265, try -1 or -2 at most.

I doubt it, I use -3 for all my encodes and don't experience any blocking here

[dcxero]

-3 is probably too weak deblocking for x265, try -1 or -2 at most.

Cheers, that seemed to be it. I guess I assumed the deblocking was more like x264, but I ran the same CLI a dozen more times, only changing deblock between -3,-3 -2,-2... all the way back to +3,+3 and then disabled. +2,+2 had the least offensive blocking (practically none) while remaining closer to the source (+3,+3 started to alter it)

[microchip8]

Cheers, that seemed to be it. I guess I assumed the deblocking was more like x264, but I ran the same CLI a dozen more times, only changing deblock between -3,-3 -2,-2... all the way back to +3,+3 and then disabled. +2,+2 had the least offensive blocking (practically none) while remaining closer to the source (+3,+3 started to alter it)

I can't see any blocking in your image you posted. Maybe my display isn't good enough?

[jlpsvk]

any cons to using --no-deblock in CLI? i I want to preserve as much sharpness as ist gets? my CLI:

--crf 18 --profile main10 --level-idc 5.1 --output-depth 10 --ctu 32 --amp --vbv-bufsize 160000 --vbv-maxrate 160000
--me star --max-merge 5 --rc-lookahead 40 --lookahead-slices 4 --ref 5 --min-keyint 24 --keyint 240 --colorprim bt709
--colormatrix bt709 --transfer bt709 --no-info --no-deblock --no-sao --no-strong-intra-smoothing --high-tier

[dcxero]

I can't see any blocking in your image you posted. Maybe my display isn't good enough?

Maybe? I'm using a BenQ 2160p/10-bit (8-bit+RFC) display. I find it more prominent in grainy sources, here's a quick/better example which you might be able to see

Source:
http://thumbs2.imagebam.com/fb/5a/7c/b6a9ca732092083.jpg (http://www.imagebam.com/image/b6a9ca732092083)

-3,-3 deblock:
http://thumbs2.imagebam.com/11/33/39/0ffa8c732092103.jpg (http://www.imagebam.com/image/0ffa8c732092103)

+2,+2 deblock:
http://thumbs2.imagebam.com/5e/67/39/ab7854732092133.jpg (http://www.imagebam.com/image/ab7854732092133)

[microchip8]

Maybe? I'm using a BenQ 2160p/10-bit (8-bit+RFC) display. I find it more prominent in grainy sources, here's a quick/better example which you might be able to see

Source:
http://thumbs2.imagebam.com/fb/5a/7c/b6a9ca732092083.jpg (http://www.imagebam.com/image/b6a9ca732092083)

-3,-3 deblock:
http://thumbs2.imagebam.com/11/33/39/0ffa8c732092103.jpg (http://www.imagebam.com/image/0ffa8c732092103)

+2,+2 deblock:
http://thumbs2.imagebam.com/5e/67/39/ab7854732092133.jpg (http://www.imagebam.com/image/ab7854732092133)

Still can't see it. All I can see is that the +2 one looks smoother than the -3 one. Can't see blocking, though. But indeed, the +2 one is closer to the source

Anyways, if you're happy with +2, use it :p

[dcxero]

Still can't see it.

You definitely need a new monitor then! :D

I suppose it's harder to see if you look at it unless zooming, or blown up on a TV/projector. Try flipping back and forth between the source image zoomed in, there's a faint grid of squares about 16x16 pixels wide across the whole image

It seems to be something inherent to HEVC (or just more noticeable), because I've seen it in some retail UHD discs as well (unless they're just using x264 too! :cool:)

[microchip8]

You definitely need a new monitor then! :D

I suppose it's harder to see if you look at it unless zooming, or blown up on a TV/projector. Try flipping back and forth between the source image zoomed in, there's a faint grid of squares about 16x16 pixels wide across the whole image

It seems to be something inherent to HEVC (or just more noticeable), because I've seen it in some retail UHD discs as well (unless they're just using x264 too! :cool:)

Perhaps. My monitor is a plain 6 bit+FRC from AOC (LG Display panel). My TV has a PVA panel (Samsung) at true 8 bits

I don't have any 4K displays here, all are FHD and on FHD I can't see it on any of my displays

[burfadel]

It doesn't look like a true transfer from the film original. Is it The Fifth Element? It's a movie I thought they would have done a proper 4k transfer for. The grain doesn't help much either, as the grain acts as detail that needs to be encoded. If it changes each frame it is probably using most of the bandwidth and bit allocation for the grain and not the actual picture. I think you'll find using a denoiser first could greatly improve the success of your output. Maybe give my mClean (v2.1) a go? https://forum.doom9.org/showthread.php?t=174804

I'm not specifically spruiking my script! This situation is just one of many that it is designed to help with. You will need to use the latest Avisynth+, updated RGTools, MVTools, Masktools, Modplus, f3kdb, as the script utilises new functions that weren't available in older versions of these. It's designed in such a way that the base settings should be adequate and retain some grain in a way that it will be more encoder bit friendly.

[Sp00kyFox]

hi there. I was wondering what are the thoughts about the aq-motion option regarding cartoon or anime content. In my experience it's beneficial to use with real world content where the higher quantization of moving parts is masked by the motion blur they introduce. but with drawn content moving parts are usually as sharp as still areas. I made a little encoding test to see the effect on bitrate and with drawn content it doesn't seem to do much anyways. any experiences with this option here?

[divxmaster]

@burfadel, thats interesting, I will have to check your filter out! I am currently getting very good results with smdegrain:

vid = haf.SMDegrain(vid, tr=3,thSAD=150,RefineMotion=True,contrasharp=True,pel=2)

varying thSAD from 100-400 depending on grain, or smdegrain off if no grain (ironman3, Star Trek Beyond).

Cheers,
Divxmaster

[WhatZit]

any cons to using --no-deblock in CLI? i I want to preserve as much sharpness as it gets?

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6324414

The --deblock loop filter uses a PAIR of values that correspond to STRENGTH,DECISION.

STRENGTH needs no explanation, but DECISION (literally) decides how often to employ the filter on coding units.

The default value of 0 activates on relatively balanced values between the block boundaries.

The maximum value of 6 activates on ALL block boundaries regardless of disparity, producing whole-scene smoothing.

The minimum value of -6 activates only on those block boundaries which have significant threshold disparity, producing virtually no deblocking on anything other than already unwatchable artifacts.

To answer your question, unless you are using a high enough bitrate to never create blocking artifacts in the first place, you should always have some level of deblocking active (even -6,-6), because blocking is something that the eye just spots immediately.

To figure out what values the filter should be set to FOR YOU and your bitrates, get yourself a high-detail sample with stationary foreground elements & rapidly moving background elements. A sunny panning shot of people running in front of plants or other complex backgrounds is perfect.

Adjust DECISION until the background blocking stops (or is acceptable) whilst the foreground remains untouched. Then adjust STRENGTH to suit.

I personally use -2,-3.

[LigH]

A sunny panning shot of people running in front of plants or other complex backgrounds is perfect.

For short lossless clips, check derf's collection at xiph.org (https://media.xiph.org/video/derf/), in sections "HD Content and Above" and below, e.g. "crowd_run", "rush_field_cuts", or something with a water surface.
__

The "founder and chairman of MPEG", Leonardo Chiariglione, discovered that the patent licensing model gets obsolete (http://blog.chiariglione.org/2018/01/28/) with the success of OpenSource media formats like Opus audio and soon AOMedia AV1 video ... all the investments for an uncertain future of MPEG technologies. Including HEVC.

No immediate reason for Multicoreware to panic, I believe. Established uses of MPEG technologies won't disappear quickly. And when their substitution with more advanced and free OpenSoure formats comes closer, it's not improbable that their development gets paid for as well.
__

P.S.: Holding back new builds until [PATCH] CMake: blacklist mingw implicit link libraries gets committed. If I understand its intention correctly, this should slim down the binary base a little by avoiding superfluous linked libraries?

[jlpsvk]

http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6324414

The --deblock loop filter uses a PAIR of values that correspond to STRENGTH,DECISION.

STRENGTH needs no explanation, but DECISION (literally) decides how often to employ the filter on coding units.

The default value of 0 activates on relatively balanced values between the block boundaries.

The maximum value of 6 activates on ALL block boundaries regardless of disparity, producing whole-scene smoothing.

The minimum value of -6 activates only on those block boundaries which have significant threshold disparity, producing virtually no deblocking on anything other than already unwatchable artifacts.

To answer your question, unless you are using a high enough bitrate to never create blocking artifacts in the first place, you should always have some level of deblocking active (even -6,-6), because blocking is something that the eye just spots immediately.

To figure out what values the filter should be set to FOR YOU and your bitrates, get yourself a high-detail sample with stationary foreground elements & rapidly moving background elements. A sunny panning shot of people running in front of plants or other complex backgrounds is perfect.

Adjust DECISION until the background blocking stops (or is acceptable) whilst the foreground remains untouched. Then adjust STRENGTH to suit.

I personally use -2,-3.

I am using CRF16 with x265 4K HDR encodes. So the bitrate is not limiting, i think. :)

[Midzuki]

x265.exe 2.6+37-1949157705ce

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2510642#post2510642

[Barough]

x265 v2.6+37-1949157705ce (http://www.mediafire.com/file/kzkmtkg0wa8nou6/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

@Barough - interesting, your version info strings still work:

x265 [info]: HEVC encoder version 2.6+37-1949157705ce
x265 [info]: build info [Windows][GCC 7.3.0][64 bit] 8bit+10bit+12bit

Mine only display "(null)". Possibly because my MSYS2 environment updated to a buggy binutils version or similar... I hope the MABS developers will find a workaround until the package providers offer updates.

[Barough]

@LigH - I ran the update on MABS today and it updated just fine. Have done 2 test encodes with the new x265 through MeGUI and it worked perfect

[Ma]

@LigH - the bug in binutils 2.30 for mingw target is huge, the compiler cannot create executables. If you build the x265.exe encoder it means you probably use binutils 2.29.1.

Mercurial was moved from mercurial.selenic.com to mercurial-scm.org and this is prime suspect for the problem. You can try to execute hg clone https://bitbucket.org/multicoreware/x265 from msys2 shell to some new location and use new x265 folder only with new version of HG (from msys2).

[LigH]

I can build it ... despite:
[2018-01-29 21:24] [ALPM] upgraded mingw-w64-x86_64-binutils (2.29.1-1 -> 2.30-1)
If I knew how to tell the MSYS2 environment of MABS to downgrade, I could do that. And I am pretty sure that wiiaboo knows about this issue.

And because updating x265 failed with an "unresolved merge", I recently let the whole x265 source get cloned anew, by deleting the whole build/x265-hg directory.

There is a new proposed patch to generate the hg version information in a different way, this is not yet committed.

It's so confusing ... so many reasons why the base system of two users can be different enough that doing the same which is supposed to bring both systems to the same state still produces different results.

[LigH]

After re-installing MABS completely, which updated only to binutils-2.29, version strings are back. Other important changes:

32-bit builds made with GCC can open large files too; MinGW compiles exclude some superfluous libraries; fixes in special conditions with BREF frames, rate control with both weightp and cutree, and unnecessary luma calculations in CSV output

x265 2.6+37-1949157705ce (https://www.mediafire.com/file/ix8c963vei5mk65/x265_2.6%2B37-1949157705ce.7z) (MSYS2/MinGW, GCC 7.3.0)

[Motenai Yoda]

I would suggest a possible tune animation:
aq-mode 3 aq-strength 0.6 aq-motion qg-size 16 rc-lookahead +20 psy-rd 1.2 rdoq-level 2 psy-rdoq 0.3 deblock 1:-1 cbqpoffs -1 crqpoffs -1
under evalutation (some unclear detail loss)
ref +1 bframes +2

[Ma]

I would suggest a possible tune animation:

I've prepared first version of anime patch with main part:
+ else if (!strcmp(tune, "anime"))
+ {
+ param->rc.aqMode = 3;
+ param->rc.aqStrength = 0.6;
+ param->bAQMotion = 1;
+ param->rc.qgSize = 16;
+ param->lookaheadDepth += 20;
+ param->psyRd = 1.2;
+ param->rdoqLevel = 2;
+ param->psyRdoq = 0.3;
+ param->bEnableLoopFilter = 1;
+ param->deblockingFilterTCOffset = 1;
+ param->deblockingFilterBetaOffset = -1;
+ param->cbQpOffset = -1;
+ param->crQpOffset = -1;
+ }
Windows binaries for testing + patch file anime.7z (http://msystem.waw.pl/x265/anime.7z)

[Motenai Yoda]

I'd rather be glad to take into account somebody else's opinion about it too

[LigH]

With a readily provided test encoder, that's easier than in theory. :) Or with lengthy CLI param lists.

[Ma]

From my tests the option '--qg-size 16' is broken -- in all bitrates decrease quality.
I don't like '--aq-motion', so my 'anime' proposition is:
--rc-lookahead *= 2;
--psy-rd /= 2;
--keyint *= 2;
if (rdoq-level > 0)
{
--cbqpoffs -1; --crqpoffs -1;
}
if (preset >= 7) // slower, veryslow & placebo
{
--frame-threads 1;
}

[Arhu]

I always use aq-mode 3 (10 bit) but regularly had banding issues with aq-strength < 1. Could anyone else observe this?

[LigH]

MSYS2 released binutils-2.30-2; static binaries should work again.

[Ma]

I've made some tests about '--qg-size'. For my eyes '--qg-size 32' is better than '--qg-size 16'. After checking all possible values (8, 16, 32 and 64) the best is 64 (PSNR/SSIM and for my eyes). It is a bit strange, the default value in x265 is 32.

My test was encoding first 2222 frames of big_buck_bunny_1080p24.y4m with preset slower, tune anime (which I renamed to cartoon), 10-bit output, ABR mode with bitrates: 300, 450, 750, 1200 and 1950, qg-size from 8 to 64.
Command line:
for %b in (300 450 750 1200 1950) do (for %q in (8 16 32 64) do
(x265 -D10 --psnr --ssim -p7 -f2222 --tune cartoon --bitrate %b --qg-size %q ../big_buck_bunny_1080p24.y4m m%b-%q.hevc))

The result Global PSNR/SSIM Mean Y dB is (bitrate\qg-size):

8 16 32 64
300 37.554/11.452 37.538/11.520 37.643/11.568 37.781/11.638
450 39.056/12.742 39.026/12.781 39.143/12.843 39.281/12.907
750 40.993/14.407 40.962/14.445 41.099/14.522 41.225/14.559
1200 42.835/16.004 42.802/16.032 42.958/16.117 43.065/16.136
1950 44.746/17.661 44.713/17.692 44.866/17.774 44.950/17.781


Samples to watch:
bitrate 300: qg-size 16 (http://msystem.waw.pl/x265/m300-16.mkv), qg-size 64 (http://msystem.waw.pl/x265/m300-64.mkv)
bitrate 450: qg-size 16 (http://msystem.waw.pl/x265/m450-16.mkv), qg-size 64 (http://msystem.waw.pl/x265/m450-64.mkv)

So my question is: what should I look at to see the advantages of qg-size 16?

[Selur]

It is a bit strange, the default value in x265 is 32.
Hmm,....
--qg-size <64|32|16|8>

Enable adaptive quantization for sub-CTUs. This parameter specifies the minimum CU size at which QP can be adjusted, ie. Quantization Group size. Allowed range of values are 64, 32, 16, 8 provided this falls within the inclusive range [maxCUSize, minCUSize]. Default: same as maxCUSize
source: http://x265.readthedocs.io/en/latest/cli.html?highlight=qg-size#cmdoption-ctu
--ctu, -s <64|32|16>

Maximum CU size (width and height). The larger the maximum CU size, the more efficiently x265 can encode flat areas of the picture, giving large reductions in bitrate. However this comes at a loss of parallelism with fewer rows of CUs that can be encoded in parallel, and less frame parallelism as well. Because of this the faster presets use a CU size of 32. Default: 64
source: http://x265.readthedocs.io/en/latest/cli.html?highlight=qg-size#cmdoption-ctu

-> Shouldn't the default be 64 and not 32?

[LigH]

I remember that there was an issue with 64 (loss of details, or improper segmentation?)... but I do not remember if it was fixed yet.

[Ma]

In documentation the default value of qg-size is 64, in real code it is 32. 'x265 --help' prints options and default values, if you encode there is line
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
It was probably changed from 64 to 32 and the documentation is not updated.
Anyway, the 32 value is a bit strange for me.
-----------
It was changed in 2015-08-03 by https://bitbucket.org/multicoreware/x265/commits/dc5d58411210549d288b991ccfc4da4450e9f84e

[Selur]

@Ma: thanks for the insight

Cu Selur

[burfadel]

I wonder whether lookahead could be repurposed to allow more efficient use of large CU size, or only use it when it appears most efficient to do so.

[Anthonytex]

Hello everyone, I know that this question was posted a lot of time so apologize: is it true that it's better to encode a 8bit video to 10bit even if the source it's 8 bit? What's the difference? Does the x265 encoder works better? Thank you

[Selur]

is it true that it's better to encode a 8bit video to 10bit even if the source it's 8 bit?
-> Why does 10-bit save bandwidth (even when content is 8-bit)? (http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)

[Boulder]

I've made some tests about '--qg-size'. For my eyes '--qg-size 32' is better than '--qg-size 16'. After checking all possible values (8, 16, 32 and 64) the best is 64 (PSNR/SSIM and for my eyes). It is a bit strange, the default value in x265 is 32.

Funny thing is that in the "--tune film" thread, the exact opposite was suggested: http://forum.doom9.org/showthread.php?t=172458

Could you repeat the test with some high-detail film content, please?

[Anthonytex]

-> Why does 10-bit save bandwidth (even when content is 8-bit)? (http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)Thank you :) I've read that article, I was looking for something x265 specific rather than a general case:)

[Dope]

I haven't seen x265 to compress more efficiently in 10-bit. x264 - yes. But not x265.

[poisondeathray]

I haven't seen x265 to compress more efficiently in 10-bit. x264 - yes. But not x265.

Those are my findings too

[Anthonytex]

Thank you :)

[Selur]

Still 10bit makes sense to avoid introducing banding artifacts,..

[Asmodian]

10-bit is still more efficient, only it is a very small improvement with x265 compared to x264. x265 uses a higher bit depth in important places internally, even when set to 8 bit; its internal data structures are not all required to use the same bit depth as the output video.

Also, banding is never good so that is also a quality/size efficiency boost. :p

[sneaker_ger]

The problem is x265 can produce banding even at 10 bit. x264 10bit doesn't have those problems, it's "fire and forget". Hard to beat if you aim for high bitrate/high quality.
https://forum.doom9.org/showthread.php?p=1762253#post1762253

[Ma]

The problem with qg-size could be related to 8bit vs. 10bit question.
I've made tests with 10bit output and I prefer qg-size 64 (for 10bit output).
Maybe the change from 64 to 32 for qg-size was for 8bit output?

[IgorC]

The problem is x265 can produce banding even at 10 bit. x264 10bit doesn't have those problems, it's "fire and forget". Hard to beat if you aim for high bitrate/high quality.
https://forum.doom9.org/showthread.php?p=1762253#post1762253
Filmgrain preservation is overrated

Filmgrain is just a noise. Pleasant noise, but still noise.
I’d prefer video source without filmgrain than with it. Two reasons for that. First reason, microscopic details aren’t drowned in grain. Second reason, significantly better compressibility. In the end you have better both: visual quality and compressibility. Win-win situation.

Good news that new Netflix series/shows have much less filmgrain or don’t have it at all.
Instead of blaming x265 developers for not preserving grain it’s time to forget about useless filmgrain to begin with

[Sp00kyFox]

I would suggest a possible tune animation:
aq-mode 3 aq-strength 0.6 aq-motion qg-size 16 rc-lookahead +20 psy-rd 1.2 rdoq-level 2 psy-rdoq 0.3 deblock 1:-1 cbqpoffs -1 crqpoffs -1
can somebody actually provide an encoding example where aq-mode 3 is beneficial? made some tests a while ago and really can't say that it's better or worse than mode 1. both seem better than mode 2 though.

Hello everyone, I know that this question was posted a lot of time so apologize: is it true that it's better to encode a 8bit video to 10bit even if the source it's 8 bit? What's the difference? Does the x265 encoder works better? Thank you
10bit-depth prevents banding artifacts better and since HEVC hardware decoders also support it unlike with AVC I don't see a reason not to use it.

Instead of blaming x265 developers for not preserving grain it’s time to forget about useless filmgrain to begin with
it's the classic problem of video filtering to distinguish between grain and details. so a video encoder that fails to keep this picture information also has issues with keeping details. despite that grain can also create details over the temporal axis.

anyways, since the introduction of the new lambda tables (in v2.4) x265 does a great job with keeping grain. for me it has made x264 obsolete.

[IgorC]

anyways, since the introduction of the new lambda tables (in v2.4) x265 does a great job with keeping grain. for me it has made x264 obsolete.
Great.Thank you for clarifying that as I didn't followed x265 devt last year.

[LigH]

x265 2.6+39-01b685d6fa33 (https://www.mediafire.com/file/or25qe6mbnrzcb5/x265_2.6%2B39-01b685d6fa33.7z)

CMake: fix generation of version info from .hg_archival.txt; fix output to pipe on Windows (enable binary mode)

[Barough]

x265 v2.6+42-52782aeb2081 (http://www.mediafire.com/file/gignib95e2xax34/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[VoodooFX]

The problem is x265 can produce banding even at 10 bit. x264 10bit doesn't have those problems, it's "fire and forget". Hard to beat if you aim for high bitrate/high quality.
https://forum.doom9.org/showthread.php?p=1762253#post1762253

Definitely I had same problem with aq-mode=2 (and maybe with 3 too, I don't remember now), using default aq-mode=1 solved exact banding like in those screenshots.

[hajj_3]

x265 v2.7 is out, can't find a changelog though.

[Barough]

https://bitbucket.org/multicoreware/x265/commits/all

Version 2.7
===========

Release date - 21st Feb, 2018.

New features
------------
1. : option: '--gop-lookahead' can be used to extend the gop boundary (set by '--keyint'). The GOP will be extended, if a scene-cut frame is found within this many number of frames.
2. Support for RADL pictures added in x265.
: option: '--radl' can be used to decide number of RADL pictures preceding the IDR picture.

Encoder enhancements
--------------------
1. Moved from YASM to NASM assembler. Supports NASM assembler version 2.13 and greater.
2. Enable analysis save and load in a single run. Introduces two new cli options `--analysis-save <filename>` and `--analysis-load <filename>`.
3. Comply to HDR10+ LLC specification.
4. Reduced x265 build time by more than 50% by re-factoring ipfilter.asm.

Bug fixes
---------
1. Fixed inconsistent output issue in deblock filter and --const-vbv.
2. Fixed Mac OS build warnings.
3. Fixed inconsistency in pass-2 when weightp and cutree are enabled.
4. Fixed deadlock issue due to dropping of BREF frames, while forcing slice types through qp file.

[Barough]

x265 v2.7+1-2aa737a99f51 (http://www.mediafire.com/file/pqabb8z0pk344jk/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/all

[LigH]

Is there possibly a merge missing with the default branch?! I get only v2.6+49 there. apparently I need to get the stable branch or the tip, because the merge happened before the milestone...

There used to be reasons why I prefer the default branch.

[Midzuki]

Is there possibly a merge missing with the default branch?! I get only v2.6+49 there. apparently I need to get the stable branch or the tip, because the merge happened before the milestone...


hg clone -r 2aa737a99f51 https://bitbucket.org/multicoreware/x265

[Barough]

Is there possibly a merge missing with the default branch?! I get only v2.6+49 there. apparently I need to get the stable branch or the tip, because the merge happened before the milestone...

There used to be reasons why I prefer the default branch.I used MABS as usual and it output v2.7. Haven't made any adjustments/tweaks to it. (My knowledge in that area is close to zero.)

Sent from my SM-G935F via Tapatalk

[LigH]

In this case, the main issue was knowing that the tip was in stable, not in default. Which ever branch or state you select, there is always a possible case where it would miss one or more commits. I may always have to study the current network of branches, commits, and merges, to decide which revision to update to.

MABS may always use tip; this can be wrong when the most current commit belongs to the rarely updated stable branch, and there was no merge with the often updated default branch yet. Therefore, my additional x265 building scripts prefer the default branch, usually, but it takes only one additional parameter to update to a custom target.

[LigH]

New upload: x265 2.7+1-2aa737a99f51 (https://www.mediafire.com/file/of7jx40crg7f7mh/x265_2.7%2B1-2aa737a99f51.7z)

limitTU: Save intra CU's TU depth when analysis save/load is enabled; dHDR10 parsing fixes; ipfilter kernels split into several separate source files; v2.7 milestone

[Ma]

After some tests I notice that I prefer qg-size 64, 10-bit encoding and options close to default. So I renamed old tune 'anime' to 'cartoon' and added new tune 'anime':
--rc-lookahead *= 2;
--psy-rd /= 2;
--qg-size = 64;
if (preset >= slow) --cbqpoffs = --crqpoffs = -1;
if (preset >= slower) {--frame-threads = 1; --subme += 2;}

Win64 binaries (only 10bit+8bit) and patch file anime2.7z (http://msystem.waw.pl/x265/anime2.7z)

For my tune anime please use option
--tune anime
for Motenai Yoda version please use option
--tune cartoon

[excellentswordfight]

Did a round of some tests from a tears of steal encode in 1080p (x264 25Mbps bluray compatable).

x264 crf18 settings (my usual settings for 1080p rips)
--preset slow --profile high --level 4.1 --crf 18 --keyint 240 --min-keyint 24 --rc-lookahead 48 --tune film
x265 crf18 settings
--preset slow --profile main10 --level-idc 41 --crf 18 --keyint 240 --min-keyint 24 --rc-lookahead 48 --no-sao
x264 2pass settings
--preset veryslow --profile high --level 4.1 --bitrate 7000 --keyint 240 --min-keyint 24 --rc-lookahead 48 --tune film
x265 2pass settings
--preset slow --profile main10 --level-idc 41 --bitrate 7000 --keyint 240 --min-keyint 24 --rc-lookahead 48 --no-sao


Both CRF encodes were pretty much visually lossless, but with a 30% bitrate reduction with x265 (10Mbps vs 7Mbps). And x265 retained visable more detail in the more apples to apples 2pass test.

It's official I'm switching to x265 even for 1080p blurays rips now. The days were x265 just wasnt a good option for high quality (detail retention) 1080p encodes are long gone imo. There have been some great improvement by the x265 devs over the last couple of years imo, bravo!

[Ashok Kumar Mishra]

We are working on efficient aq mode which gives better compression efficiency, it may come in next release.

[burfadel]

What about --ssim-Rd and psy together? I haven't heard any more since it was classed as experimental and disabled psy-rd. I found no issues with using them together.

[Ashok Kumar Mishra]

First I would like to make it clear that both --ssim-rd and --psy-rd can't be applied together. There are three different ways to compute the rd cost in analysis for mode decision.
a) psy-rd: Use psycho visual rate distortion strength
b) ssim-rd: Use ssim value
c) Use only distortion So you can use anyone among the above three to compute the rd cost for mode decision. When ssim-rd is enabled, it uses ssim value of the block for rdo cost calculation and makes psy-rd value 0.
psy-rdoq is a different parameter used for rdoq analysis. It is enabled when you are using --rdoq-level 1. So it can be used along with psy-rd or ssim-rd parameter, since both are two different things used for different purpose.

Hope the above explanation will clarify the conflict between these parameters.

[Heaud]

After some tests I notice that I prefer qg-size 64, 10-bit encoding and options close to default. So I renamed old tune 'anime' to 'cartoon' and added new tune 'anime':
--rc-lookahead *= 2;
--psy-rd /= 2;
--qg-size = 64;
if (preset >= slow) --cbqpoffs = --crqpoffs = -1;
if (preset >= slower) {--frame-threads = 1; --subme += 2;}


I agree with the preset adjustments to rc-lookahead and psy-rd, but I have not tested the other options before. Is setting qg-size to 64 a benefit to compression, quality, or both? Same can be asked on setting frame-threads and boosting the subme value.

Have you tried out --tskip with --tskip-fast enabled? Another user by the name of benwaggoner had suggested these two settings in another thread after noticing positive results.

[Boulder]

Qg-size 64 at least helps in compression based on my experiences.

[sneaker_ger]

"Quality" and "compression" are usually 2 sides of the same coin. You get better quality for same file size, smaller file size for same quality or a bit of both. Only depends on how you set bitrate/crf.

[Ma]

Is setting qg-size to 64 a benefit to compression, quality, or both?

I've made tests with fixed bitrate -- encoding big_buck_bunny_1080p24.y4m with '--tune anime' and without (old tune anime that now I renamed to cartoon). PSNR and SSIM was better with tune anime but for me the quality was wrong. At the beginning in big_buck_bunny_1080p24.y4m there are two birds in top right corner (they flying very far from 'camera'). With qg-size 16 and low bitrate they are fading/disappear too soon and they are not consistent in time/position. With default qg-size 32 the birds looks better but with qg-szie 64 even better. PSNR and SSIM are better with qg-size 64.

You can try encode
x265 -p slow --bitrate 500 --psnr --ssim big_buck_bunny_1080p24.y4m bb1.hevc --tune cartoon
vs.
x265 -p slow --bitrate 500 --psnr --ssim big_buck_bunny_1080p24.y4m bb2.hevc --tune cartoon --qg-size 64
vs.
x265 -p slow --bitrate 500 --psnr --ssim big_buck_bunny_1080p24.y4m bb3.hevc --tune anime

and observe smoothness of flying the birds (not one frame but the move).

[LigH]

Well, BBB is not exactly classical Cartoon/Anime ... unfortunately, I still don't know any original cartoon movie in high resolution. The closest are still computer graphic supported cartoons.

[Ma]

Yes, good samples for trying options for anime are welcome.
I'm testing on:
big_buck_bunny_1080p24.y4m
elephants_dream_1080p24.y4m
lighthouse_lossless.mp4 (not pure anime)
tearsofsteel-4k.y4m (also not pure anime, downsized to 2K)
sintel (4K png version, downsized to 2K)
original.mkv (301762111 bytes anime sample I don't remember where I found it)

I decided to encode all samples at bitrate 1500 with my tune anime (preset veryslow, 10-bit) and watch for blocking/annoying imperfections. Unfortunately I found such annoying scene in BigBuckBunny at time 00:51 -- around bunny's left hand the background is moved/changed (old encode (http://msystem.waw.pl/x265/BigBuckBunny1500old.mkv)). The problem is mostly with rskip option, so I changed tune anime a little bit (subme += 2) and start encoding at preset palcebo -- I hope that quality will be acceptable at bitrate 1500.

Encoded samples with current tune anime at preset placebo (10-bit):
original1500.mkv (http://msystem.waw.pl/x265/original1500.mkv) -- grainy source after encoding is almost without grain (with dead/not moving grain). I don't like noise/grain so it is OK for me.
lighthouse1500.mkv (http://msystem.waw.pl/x265/lighthouse1500.mkv) -- the sky is without banding, OK for me.
ElephantsDream1500.mkv (http://msystem.waw.pl/x265/ElephantsDream1500.mkv) -- dark scenes looks a little bit worse, but it is acceptable for me.
Next samples in preparation...

[sneaker_ger]

If you need anime samples:
https://mega.nz/#!s0kQTbQQ!-6WkTrqXemhegSyjKwBteGYr9Iow_DRJwG3_d0pKr-4
https://mega.nz/#!VtdB2CLB!Y2Qwi6KivN87sl0ENjxJejPp3jDGjSGjvQiywopHcgU
https://mega.nz/#!5hc0VYpL!xWcGqQUmqxYq_Flzmx4RIclmZ5IBoxpXz21HKS6lYRM
https://mega.nz/#!w5tDnC5S!C9MmdwG0xrPtibWT907vWccjYq7uCX-TeurLKZmxvmQ (grainy)

[LigH]

Is this all Creative Commons material? And at least FullHD?

[sneaker_ger]

3/4 are 1080p, one is 480p.

[Ma]

Thanks for samples! They are not similar to BigBuckBunny.

[Gser]

I'm encoding HDR footage so I need to set max luma but I'm getting this error message
x265 [warning]: extra unused command arguments given <--max-luma=4000>
It defaults to 1000.

[Boulder]

Try --max-luma 4000.

[Gser]

Try --max-luma 4000.

Thanks that worked, funny how some commands work with "=" and others don't.

Also the command seems to have no effect, it is still showing max: 1000 cd/m2.

Setting min luma to 0.0050 also doesn't work, I'm guessing because the parameter is an integer.

[sneaker_ger]

--max-luma is for clipping input. It is usually not needed for HDR. You probably want to use the max/min luminance of "master-display (http://x265.readthedocs.io/en/default/cli.html#cmdoption-master-display)". (4000 is very high. Haven't seen such samples yet. Is this plausible for your source?)

[Gser]

--max-luma is for clipping input. It is usually not needed for HDR. You probably want to use the max/min luminance of "master-display (http://x265.readthedocs.io/en/default/cli.html#cmdoption-master-display)". (4000 is very high. Haven't seen such samples yet. Is this plausible for your source?)

Yes indeed it was mastered on a Dolby pulsar screen and it says so in the media information. This is the standard for Netflix or at least that's what I've been told. 4000 nits is also standard for Dolby vision. It works fine now just changed L(10000000,0) to L(40000000,5000).

[Midzuki]

x265.exe 2.7+8-613d9f443769

remove maxCTU size restriction in scaled save/load encodes

analysis: Introduce refine-intra level 4

use MV from analysis-save encode as MVP in load mode for refine-inter levels

Add max-ausize-factor option to control the maximum AU size defined in specification

Add reorderedPts to x265_picture to signal the reordered pts value of each picture in encode order.
Also shared the reordered pts value when analysis load is done by disabling lookahead.

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2513850#post2513850

[LigH]

#metoo

x265 2.7+8-613d9f443769 (https://www.mediafire.com/file/4o50tl4n753k7st/x265_2.7%2B8-613d9f443769.7z)

[brumsky]

Generally speaking, what has a greater effect on fine detail retention --tu-inter-depth or subme? It's for anime and I'm currently using --tu-inter-depth 4 subme 3 and --limit-tu 3. Would I get better results by upping subme and droping limit-tu to 4? Trying to find the best size\quality.

[Majorlag]

Generally speaking, what has a greater effect on fine detail retention --tu-inter-depth or subme? It's for anime and I'm currently using --tu-inter-depth 4 subme 3 and --limit-tu 3. Would I get better results by upping subme and droping limit-tu to 4? Trying to find the best size\quality.

The first part of your question asks what has better detail retention. the higher --subme value, the higher chance of fine detail retention. --tu-inter-depth does not effect detail retention as I understand it.

--tu-inter-depth is for compression or size. It is how much compression to shoot for. higher value, try to compress more. --limit-tu value effects how long to spend on compression target of --tu-inter-depth.

Hopefully I have read the command line options correctly. Try these set of options to see if they help you, it is what I use for anime "--qcomp 0.8 --rc-lookahead 30 --rc-grain --me 2 --subme 4 --no-strong-intra-smoothing --no-sao"

[Barough]

x265 v2.7+12-98e48e8dd6ab (http://www.mediafire.com/file/x17ujzzt2dxz36w/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[brumsky]

The first part of your question asks what has better detail retention. the higher --subme value, the higher chance of fine detail retention. --tu-inter-depth does not effect detail retention as I understand it.

--tu-inter-depth is for compression or size. It is how much compression to shoot for. higher value, try to compress more. --limit-tu value effects how long to spend on compression target of --tu-inter-depth.

Hopefully I have read the command line options correctly. Try these set of options to see if they help you, it is what I use for anime "--qcomp 0.8 --rc-lookahead 30 --rc-grain --me 2 --subme 4 --no-strong-intra-smoothing --no-sao"

Thanks for the info! It does help and makes sense! I'll give some of those settings a try as well. I read a different thread where BenWaggner mentioned using --tskip and --tskip-fast with good results with anime. I've read the description a few times and can't quiet figure out what exactly it is skipping... any tips on those?

[Asmodian]

The residual, the difference between the predicted image and the original image, is coded after a DCT-like transformation, except with tskip this transformation can be skipped. The encoder compares the size of the coded block after the transformation to its size without a transformation and picks whichever is smaller. As a speed boost tskip fast does not compare the size after skipping the transformation at all the possible block size combinations, only a good subset of them.

[LigH]

x265 2.7+12-98e48e8dd6ab (https://www.mediafire.com/file/5oibs47vn3jpbm1/x265_2.7%2B12-98e48e8dd6ab.7z)

--refine-intra <0..4> Enable intra refinement for encode that uses analysis-load.
...
- 4 : Re-evaluate all intra blocks, does not reuse data from save encode.

--[no-]dynamic-refine Dynamically changes refine-inter level for each CU. Default disabled

--[no-]idr-recovery-sei Emit recovery point infor SEI at each IDR frame

[Barough]

x265 v2.7+15-b9f5b5d7bf95 (http://www.mediafire.com/file/kkupnoml2ka8b7p/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[enctac]

Problem about x265 2.7+17 and L-SMASH r1459/r1450

L-SMASH : https://github.com/l-smash/l-smash
r1459 binary : http://www.mediafire.com/file/b7w5m1bfh7b5wk6/L-SMASH_rev1459_20180310.zip

x265 2.7+14-d7c26df32fae:[Windows][MSVC 1913][64 bit] 8bit+10bit+12bit
x265 2.7+17-2e370d98c806:[Windows][MSVC 1913][64 bit] 8bit+10bit+12bit

sample.avs
#---
ColorBarsHD(1280,720).Trim(0,500).ConvertToYV12()
ShowFrameNumber(scroll=true,size=128)
#---

ffmpeg.exe -i sample.avs -f yuv4mpegpipe - | x265.exe --y4m - --pass 1 --bitrate 1000 -o sample.265
ffmpeg.exe -i sample.avs -f yuv4mpegpipe - | x265.exe --y4m - --pass 2 --bitrate 1000 -o sample.265

muxer.exe -i "sample.265"?fps=30000/1001 -o sample.mp4


Result

x265 2.7+14 -> No problem.

x265 2.7+17 -> muxer.exe freeze or crash.

Which is wrong ? x265 ? or L-SMASH ?

[LigH]

Let's check the last 3 commits (https://bitbucket.org/multicoreware/x265/commits/all) ... which may be the most probable: 5be53f0 (https://bitbucket.org/multicoreware/x265/commits/5be53f09eee6ab28bd9dbb2c0ac447f50eb29655) (Clean up SEI::write function)? Sounds like it changed the output in important values.

[Sp00kyFox]

edit: seems the artifacts were caused by aq-motion. qg-size 8 just counteracts that but the default qg-size 32 without aq-motion actually looks better.
https://mega.nz/#F!DMYT2ICb!4aufAuilmDJAn-Bj-Gzcpg
__________

original post:
about the qg-size discussion. a friend of mine recently asked me about some artifacts he noticed with his x265 encodings. turned out the default qg-size was the culprit.
--qg-size <64|32|16|8>
Enable adaptive quantization for sub-CTUs. This parameter specifies the minimum CU size at which QP can be adjusted, ie. Quantization Group size. Allowed range of values are 64, 32, 16, 8 provided this falls within the inclusive range [maxCUSize, minCUSize].

from what I understand a lower qg-size allows the adaptive quantization to better adjust itself to small details. so why even use a higher value than the lowest one possible? at least for HD resolutions or lower it seems essential to simply set it to 8 to avoid artifacts that can appear otherwise. without being familiar with the parameters of the encoder people would be tempted to just increase their crf value instead.

here check out this scene. source is included if you wanna experiment yourself with it.
link removed

this is the general commandline I used. the different clips only differ at the chosen qg-size value, see the file names for that.
--preset slow --crf 23 --profile main10 --no-sao --aq-motion

after the first scene cut focus on the two guys walking back to their truck. notice the artifact corona that surrounds them. qg-size 8 pretty much fixes it. this also slightly increased the bitrate. so I'm not saying that using --qg-size 8 improves quality at the same file size. but when using crf it might be useful to do that to avoid artifacts you otherwise would need to generally lower crf for.

I suppose the default value is set to 32 instead because the codec is designed for 4k content in mind where it's probably useful to avoid a subblock adaptation at the lowest level due to details being larger.

what's your opinion on this?

[Motenai Yoda]

coz all was 32x based at early development stages

[brumsky]

Is it possible to use a UHD HDR source to create an HD SDR encode? I ask because I'm having issues with the encode being desaturated due to the HDR source and BT2020.

How can I convert the color palette and convert to SDR?

[sneaker_ger]

x265 library/cli doesn't offer HDR->SDR conversion by itself. You can do it using other software, e.g. ffmpeg or VapourSynth and then feed that to x265 (or use the x265 integrated in ffmpeg).

https://forum.doom9.org/showthread.php?t=175125
https://forum.doom9.org/showthread.php?p=1800675
https://github.com/ifb/vapoursynth-tonemap/

[enctac]

Problem about x265 2.7+17 and L-SMASH r1459/r1450
...

Result

x265 2.7+14 -> No problem.

x265 2.7+17 -> muxer.exe freeze or crash.

Which is wrong ? x265 ? or L-SMASH ?

Let's check the last 3 commits (https://bitbucket.org/multicoreware/x265/commits/all) ... which may be the most probable: 5be53f0 (https://bitbucket.org/multicoreware/x265/commits/5be53f09eee6ab28bd9dbb2c0ac447f50eb29655) (Clean up SEI::write function)? Sounds like it changed the output in important values.

x265 2.7+17 outputs broken SEI. (maybe SEIuserDataUnregistered, extra 16bytes)
Not only 2pass encoding.
Need to fix this.

Left side: 2pass encoding
Right side: 1pass encoding

[LigH]

I already mentioned that in the x265 developer mailing list. Maybe you would like to register there as well and attach your report.

[enctac]

OK, I sent a mail.

[Boulder]

qg-size 8 pretty much fixes it. this also slightly increased the bitrate.

It seems to increase the bitrate quite a lot. I just tested on a 4000-frame 720p encode:

qg-size 64 : 3147,41 kbps
qg-size 32 : 3648,01 kbps
qg-size 16 : 3954,23 kbps

Didn't test qg-size 8 yet.

Average QP is about the same, a little bit less than 21.

[Ashok Kumar Mishra]

Problem about x265 2.7+17 and L-SMASH r1459/r1450

L-SMASH : https://github.com/l-smash/l-smash
r1459 binary : http://www.mediafire.com/file/b7w5m1bfh7b5wk6/L-SMASH_rev1459_20180310.zip

x265 2.7+14-d7c26df32fae:[Windows][MSVC 1913][64 bit] 8bit+10bit+12bit
x265 2.7+17-2e370d98c806:[Windows][MSVC 1913][64 bit] 8bit+10bit+12bit

sample.avs
#---
ColorBarsHD(1280,720).Trim(0,500).ConvertToYV12()
ShowFrameNumber(scroll=true,size=128)
#---

ffmpeg.exe -i sample.avs -f yuv4mpegpipe - | x265.exe --y4m - --pass 1 --bitrate 1000 -o sample.265
ffmpeg.exe -i sample.avs -f yuv4mpegpipe - | x265.exe --y4m - --pass 2 --bitrate 1000 -o sample.265

muxer.exe -i "sample.265"?fps=30000/1001 -o sample.mp4


Result

x265 2.7+14 -> No problem.

x265 2.7+17 -> muxer.exe freeze or crash.

Which is wrong ? x265 ? or L-SMASH ?

Thank you for reporting this bug. We are fixing it.

[Sp00kyFox]

It seems to increase the bitrate quite a lot. I just tested on a 4000-frame 720p encode
how does it visually compare? (inb4: well ok, more bitrate is probably gonna look better) I would think at 720p or even SD a smaller qg-size is even more important since the situation demonstrated in the clip I uploaded is even more likely to appear. from what I've tested edges and details when adjacent to flat areas become more refined with lower qg-size.

[Boulder]

Didn't do any visual comparisons with those ones yet. I'll now run a 2-pass encode with all four values, using the lowest bitrate (3147 kbps) for all of them as the average bitrate and see how they look. Previously when I just tested changing qg-size and kept all the rest the same, qg-size 32 looked best compared to the original frame (least distortion) on a frame-by-frame comparison.

[microchip8]

my experience with qg-size on movies (full hd) is that the lower it is, the more fine detail it preserves but also increases ringing around smaller objects. the higher it is, the more smoother the picture and also the less ringing you get. i keep mine at 32 most of the time

[Sp00kyFox]

wanted to let you know that my first conclusion was overhasty. seems the artifacts were caused by aq-motion. theoretically this options seems to be a nice idea but the approach can cause problem with this kind of scene where you have some small moving details that get crippled by this option. qg-size 8 counteracts that but the result is still worse than the default qg-size 32 without aq-motion. I'm doing some more comparisons regarding qg-size wihout aq-motion this time.

edit: well after further tests I can say qg-size 32 is a good default value. SSIM-wise it seems to be the best choice for general content. in the scene I provided earlier qg-size 64 is little bit too smooth while 32 gives a good balance. 16 and 8 both produce noticeable artifacts.

[Barough]

x265 v2.7+19-1fafca24a399 (http://www.mediafire.com/file/pl4imr5zqppo4jc/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[Boulder]

edit: well after further tests I can say qg-size 32 is a good default value. SSIM-wise it seems to be the best choice for general content. in the scene I provided earlier qg-size 64 is little bit too smooth while 32 gives a good balance. 16 and 8 both produce noticeable artifacts.

Yes, I agree that the default 32 is a good choice. Fortunately so, as the 25% bitrate increase from the smaller values was a bit steep :)

[enctac]

Don't use 2.7+15 - 2.7+19.
2.7+14 maybe safe.
We should wait until developers fixes SEI bug.

Result

x265 2.7+14 -> No problem.

x265 2.7+17 -> muxer.exe freeze or crash.

Which is wrong ? x265 ? or L-SMASH ?

x265 2.7+17 outputs broken SEI. (maybe SEIuserDataUnregistered, extra 16bytes)
Not only 2pass encoding.
Need to fix this.


Thank you for reporting this bug. We are fixing it.

[pradeeprama]

For the curious, of course we will be at NAB in Vegas from April 9th - 12th! We will be one of the demos at the MulticoreWare booth in SU-14708. If you want to discuss all things media, swing by the booth! Suggested topics include, but are certainly not limited to the soon-to-publish AVX512 acceleration, content adaptive optimizations for ABR encoding with x265, upcoming overhaul of AQ and associated visual improvements. or a request to take a selfie with the creators of the world’s most popular HEVC encoder.

See you in Vegas!

PS: Make sure to mention this post on doom9 if you stop by to stand a chance to win some open-source memorabilia!

[Midzuki]

x265.exe 2.7+20-3440a56acc78

fix bug in SEI::write clean up

https://forum.videohelp.com/threads/357754-%5BHEVC%5D-x265-EXE-mingw-builds?p=2516009#post2516009

[Asmodian]

Midzuki, I get a report "Trojan:Script/Cloxer.A!cl" for that link and Windows 10 automatically deletes it. This is the first time I have had a warning from x265.exe, is it a false alarm?

[LigH]

Your antivirus (which?) probably caught a JavaScript related to advertizing in a forum site. It seems not to be related to the attached x265 build.

If you use NoScript and an ad blocker (like uBlock Origin) in your web browser, you will probably not get any advertizing network scripts confusing you before you even see the Video Help forum thread.

[Midzuki]

Midzuki, I get a report "Trojan:Script/Cloxer.A!cl" for that link and Windows 10 automatically deletes it. This is the first time I have had a warning from x265.exe, is it a false alarm?

LigH answered well. I stopped using anti-virus software ages ago because 1) they became bloatware and 2) too many false positives.

Regarding browsers's add-ons: I use NoScript against most sites, but not against the ones I visit regularly (such as Doom9 and Videohelp). My HUGE hosts file is sufficient to block most /all ads on most sites, except on the anti-social networks (Twitter and Fakebook specifically).

TL; DR — Get rid of Windows 10, problem solved ;)

P.S.: for what it's worth...... https://www.virustotal.com/#/file/1da62a91f04465432f4805b5bb7b5cb715b798554449e77a65133b891be1e336/detection

[LigH]

x265 2.7+20-3440a56acc78 (https://www.mediafire.com/file/goscyr6whgpllca/x265_2.7%2B20-3440a56acc78.7z)

fix bug in SEI::write clean up

[Barough]

x265 v2.7+22-946f82dbf4e8 (http://www.mediafire.com/file/p97a266kp5wazj7/) (GCC 7.3.0, 32 & 64-bit 8/10/12bit Multilib Windows Binaries)

https://bitbucket.org/multicoreware/x265/commits/branch/default

[LigH]

x265 2.7+22-946f82dbf4e8 (https://www.mediafire.com/file/b909czo6z3og1hq/x265_2.7%2B22-946f82dbf4e8.7z)

dynamic-refine tunings

Can anyone report advantages of this feature?

[K.i.N.G]

I've been wondering what's the difference between your binaries, Barough's and LigH's?

Also, i read in the x265 online manual (x265.readthedocs.io (http://x265.readthedocs.io/en/default/cli.html#cmdoption-aq-mode)) that AQ-Mode 3 is good for low bitrate 10bit encodes... But what is considered low bitrates for Full-HD and 4K?

I backup my bluray movie collection @ Full-HD between 4000 and 8000kbs (depends mostly on the amount of grain, some movies can go higher but those are the exception. Animations tend to go lower)...
Is that considered low bitrates?

[LigH]

I've been wondering what's the difference between your binaries, Barough's and LigH's?

No clue how exactly Barough builds them ... but probably negligible.

I use the media-autobuild_suite as MSYS2 base environment, but still run separate build scripts in MinGW32 and MinGW64. No additional optimizations, just semi-automatic preparation for building the archive to be uploaded.

[Barough]

No clue how exactly Barough builds them ... but probably negligible.

I use the media-autobuild_suite as MSYS2 base environment, but still run separate build scripts in MinGW32 and MinGW64. No additional optimizations, just semi-automatic preparation for building the archive to be uploaded.Default MABS compiles here

Sent from my SM-G965F via Tapatalk

[K.i.N.G]

Ok, thank you both for the answers!

Although I know absolutetly nothing about compiling so that doesn't tell me much... :D

[LigH]

Means: We use the same tools to build them, and very similar ways to do that. You may not notice any differences (e.g. in speed) when comparing both while encoding the same material with the same parameters.

[K.i.N.G]

Allright, thank you :)

[RieGo]

x265 2.7+22-946f82dbf4e8 (https://www.mediafire.com/file/b909czo6z3og1hq/x265_2.7%2B22-946f82dbf4e8.7z)

dynamic-refine tunings

Can anyone report advantages of this feature?

was wondering the same.
i did some test encodes with default parameters and "--dynamic-refine --refine-intra 4" @1000kbit/s Two Pass
i couldn't really tell a difference...
how are you supposed to see a difference when changing one parameter? that's almost impossible in my eyes - without picking single frames, which doesn't make much sense anyways.
decoding at ultra low bitrate?

so in theory this setting should be an improvement, right?

[LigH]

Well, I did not expect obvious differences for random material and convenient bitrates; someone with more insight might know academic cases where an improvement can be expected. My guess would be: questionable cost-benefit ratio.

But surprise me who can!

[Sp00kyFox]

had some thoughts about the aq-motion option I wanted to share. on the previous pages I referred to a scene where this option creates serious and very noticeable artifacts. here is the source clip and encodings to compare. focus on the two guys walking back to the truck after the first scene cut:
https://mega.nz/#F!DMYT2ICb!4aufAuilmDJAn-Bj-Gzcpg

commandline that was used with --aq-motion / --no-aq-motion resp.:

--preset slow --crf 23 --profile main10 --no-sao

this is the description of the feature from the x265 documentation

--aq-motion, --no-aq-motion
Adjust the AQ offsets based on the relative motion of each block with respect to the motion of the frame. The more the relative motion of the block, the more quantization is used. Default disabled. Experimental Feature

this is apparently also applied when the frame doesn't move at all. so even when the scene is still, moving parts will use more quantization. I'd assume the original intention of this option is to only use more quantization in moving scenes where the block in question doesn't follow the global motion direction.

with a faster moving scene more quantization should be less noticeable on blocks with alternate direction. so to make this option more viable I'd suggest to scale the option with the speed of the global motion. with this still scenes shouldn't be affected at all and slow scenes less which avoids ugly results like demonstrated with the sample.

[foxyshadis]

this is apparently also applied when the frame doesn't move at all. so even when the scene is still, moving parts will use more quantization. I'd assume the original intention of this option is to only use more quantization in moving scenes where the block in question doesn't follow the global motion direction.

with a faster moving scene more quantization should be less noticeable on blocks with alternate direction. so to make this option more viable I'd suggest to scale the option with the speed of the global motion. with this still scenes shouldn't be affected at all and slow scenes less which avoids ugly results like demonstrated with the sample.

By the time the encoder would have even a rough idea of the global motion of the frame, more than half the blocks would already be quantized and done. x265 doesn't do any global motion estimation in the lookahead phase, it just decides if a scenecut is warranted, and everything else happens in a huge combined phase that outputs blocks as it gobbles them up.

Maybe a check for the inverse of emergency VBV could be enabled: Once the frame is over, go back and say "hey, that frame was pretty easy after all and didn't need to be so overcompressed." Or since global motion is known by the end, look back and see the oops before flushing the frame. Performance would take a pretty big hit every time it happened, especially if it affects future frames that are already mid-encode, but you need quality modes too. --aq-motion has promise in increasing overall quality, managing it just seems difficult.

[Sp00kyFox]

thanks foxyshadis for your explanations, I'm not that familiar with the inner workings of the encoder. well, there goes my idea. maybe there are some other approaches to improve aq-motion. I think it definitely has potential and behaves well in many cases.

[LigH]

x265 v2.7+25 introduces the CLI option single-sei (to write all SEI messages in one single NAL, which may cause compatibility issues with reference decoders); but its documentation is missing in the full help, so I'll wait for the next patch.

[benwaggoner]

By the time the encoder would have even a rough idea of the global motion of the frame, more than half the blocks would already be quantized and done. x265 doesn't do any global motion estimation in the lookahead phase, it just decides if a scenecut is warranted, and everything else happens in a huge combined phase that outputs blocks as it gobbles them up.

Maybe a check for the inverse of emergency VBV could be enabled: Once the frame is over, go back and say "hey, that frame was pretty easy after all and didn't need to be so overcompressed." Or since global motion is known by the end, look back and see the oops before flushing the frame. Performance would take a pretty big hit every time it happened, especially if it affects future frames that are already mid-encode, but you need quality modes too. --aq-motion has promise in increasing overall quality, managing it just seems difficult.

Good analysis. That said, doing a coarse estimate of global motion in a downrezzed frame during lookahead is a perfectly reasonable strategy. Also the 1st pass global motion is known in later passes, so the above could work with 2-pass or even refine analysis. Global motion should be pretty consistent across frame sizes, so data from a lower Rez can be reused it doing an adaptation set.

[LigH]

https://cosgan.de/images/smilie/konfus/g080.gif

307 patches with AVX-512 (and other improved assembly) code uploaded to the developer mailing list. That will take a little while to review.

[pingfr]

https://cosgan.de/images/smilie/konfus/g080.gif

307 patches with AVX-512 (and other improved assembly) code uploaded to the developer mailing list. That will take a little while to review.

Sounds like a good candidate for x265-3.0 to me.

[Kavitha]

x265 2.7+22-946f82dbf4e8 (https://www.mediafire.com/file/b909czo6z3og1hq/x265_2.7%2B22-946f82dbf4e8.7z)

dynamic-refine tunings

Can anyone report advantages of this feature?



x265 has static levels of refinement(--refine inter <level>/refine intra <level>) which can be used with --analysis-reuse-level 10.
Efficiency in terms of quality increases as the levels of refinement increases. This quality increase results from additional computation thereby increasing the overall encoding time.
For a better quality-speed trade-off, dynamic refinement was introduced where the encoder dynamically switches between different inter refine levels.
This basically exploits the fact that not all CUs are required to be encoded with same level for better performance/quality.
Considering the complexity of video content and the analysis information from first pass, the encoder can intelligently decide the optimal level of refinement for each CU.
Intra frames are usually encoded with best quality as they are used as references by the consecutive frames. Hence error introduced in intra frames due to reusing analysis data can propagate to frames that use these intra frames as reference.
To minimize the chances of error propagation, refine-intra 4 (level with best quality) restricts reusing analysis data for intra frames and forces the encoder to perform full intra analysis in the second pass.
This is why x265 documentation suggests to use dynamic refinement along with refine-intra 4 and this setting is expected to give improved quality than other refine intra levels for some videos.

[LigH]

:thanks: @Kavitha; so I believe quality enthusiasts who are willing to spend a sensible amount of time will probably use this as default...

[RieGo]

yeah, i think i will use this as default, combined with slow preset.
afaik there are some settings that haven't really been adopted to presets. are there any plans to revise presets?
btw. can't wait for that avx 512 - ready to overheat my cpu :)

[LigH]

afaik there are some settings that haven't really been adopted to presets. are there any plans to revise presets?

I'm no developer, but ... probably; presets have been revised in x264 several times as well. And in addition, there are also tunings to be revised and added. But first: Satisfy needs of paying customers. Second: e.g. complete spec coverage as much as sensible; etc. etc. The developers will surely face no boredom. :rolleyes: