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).