x265 HEVC Encoder

[benwaggoner]

I'm aware of x265's --dhdr10-opt, but I prefer to keep it the same as the source (which seems to always be for every frame).
Not sure if it would affect compatibility as well.
That's just the way the source gets generated. No need to put it on every frame for playback.

[stax76]

Somebody reported an error, encoding finishes but returns exit code 1 at the end, has that a special meaning? What could be the reason?

CPU : AMD Ryzen 9 3900X 12-Core Processor

---------- Video encoding using x265 3.1+11-de920e0 Wolfberry ----------

"C:\Program Files (x86)\VapourSynth\core\vspipe.exe" K:\Downloads\SampleVideo_1280x720_1mb_temp\SampleVideo_1280x720_1mb.vpy - --y4m | C:\Users\Renor\Desktop\StaxRip\Apps\Encoders\x265\x265.exe --crf 20 --output-depth 12 --aq-mode 1 --frames 132 --y4m --output K:\Downloads\SampleVideo_1280x720_1mb_temp\SampleVideo_1280x720_1mb_out.hevc -

The system cannot find the path specified.
y4m [info]: 1280x720 fps 25/1 i420p8 frames 0 - 131 of 132
raw [info]: output file: K:\Downloads\SampleVideo_1280x720_1mb_temp\SampleVideo_1280x720_1mb_out.hevc
x265 [info]: HEVC encoder version 3.1+11-de920e0a3183
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 12 profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 24 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(12 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 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=4 deblock sao
Output 132 frames in 1.92 seconds (68.61 fps)
x265 [info]: frame I: 1, Avg QP:20.28 kb/s: 21838.80
x265 [info]: frame P: 31, Avg QP:20.75 kb/s: 4661.11
x265 [info]: frame B: 100, Avg QP:27.32 kb/s: 311.44
x265 [info]: Weighted P-Frames: Y:0.0% UV:0.0%
x265 [info]: consecutive B-frames: 3.1% 9.4% 3.1% 40.6% 43.8%
encoded 132 frames in 2.28s (57.92 fps), 1496.04 kb/s, Avg QP:25.73

------- Error Video encoding using x265 3.1+11-de920e0 Wolfberry -------

Video encoding using x265 3.1+11-de920e0 Wolfberry failed with exit code: 1 (0x1)

The exit code might be a system error code: STATUS_WAIT_1

The exit code might be a system error code: Incorrect function.

[stax76]

The issue was solved:

https://forum.doom9.org/showthread.php?p=1883020#post1883020

[markiemarcus]

Regarding RDOQ, am I the only one who really doesn't like the look of it? Though it's effective at maintaining grain motion, it seems to make it awfully boxy. I realise that this is subjective, but I find the results from disabling RDOQ entirely (--rdoq-level 0 --psy-rdoq 0) and increasing Psy-rd (to anywhere between 2.5 to 3.5) to be consistently more pleasing, assuming the same bitrate. Especially in grainy animation. The only explanation I can come up with for this comes from the documentation: that underlying flat colours reveal the shortcomings of RDOQ "biasing towards energy in general" as opposed to "energy in the source". On live action it seems okay, but I've found a number of instances in animation where anything other than tiny amounts can be quite ugly and make a right mess of fine grain or dither, regardless of the bitrate.

My apologies if that sounds overly negative; I realise that there are folks here who know a lot more than I do. Perhaps I'm missing something? Outside of a few difficulties with deep reds, this is really the only head-scratcher I've run into with x265. The only thing I long for is a way to control the strength of SAO. I like it, but sometimes I think half as much or even less would do.

[Barough]

x265 v3.1+14-f08461fdae33 (https://www.mediafire.com/file/fotm20z6d2kouyh/x265-3.1+14-f08461fdae33_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[filler56789]

Regarding v3.1+14-f08461fdae33...

sadly the compiler warnings are back — for example,

D:/KOMPILES/MCW/x265/source/encoder/analysis.cpp:2498:54: warning: this statement may fall through [-Wimplicit-fallthrough=]
2498 | case 3: mvpSelect[2] = mode.amvpCand[list][ref][!(mode.cu.m_mvpIdx[list][pu.puAbsPartIdx])];
| ~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/analysis.cpp:2499:33: note: here
2499 | case 2: mvpSelect[1] = mvp;
| ^~~~
[ 77%] Building CXX object encoder/CMakeFiles/encoder.dir/search.cpp.obj
D:/KOMPILES/MCW/x265/source/encoder/search.cpp: In member function 'void x265_12bit::Search::predInterSearch(x265_12bit::Mode&, const x265_12bit::CUGeom&, bool, uint32_t*)':
D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2276:42: warning: this statement may fall through [-Wimplicit-fallthrough=]
2276 | mvpIdxSel[2] = !mvpIdx;
| ~~~~~~~~~~~~~^~~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2277:21: note: here
2277 | case 2: mvpSel[1] = interMode.amvpCand[list][ref][mvpIdx];
| ^~~~
D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2278:42: warning: this statement may fall through [-Wimplicit-fallthrough=]
2278 | mvpIdxSel[1] = mvpIdx;
| ~~~~~~~~~~~~~^~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/search.cpp:2279:21: note: here
2279 | case 1: mvpSel[0] = interDataCTU->mv[list][cuIdx + puIdx].word;
| ^~~~

And last but not least (since I-don't-know-when, really):

-- cmake version 3.15.2
CMake Deprecation Warning at CMakeLists.txt:10 (cmake_policy):
The OLD behavior for policy CMP0025 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.


CMake Deprecation Warning at CMakeLists.txt:16 (cmake_policy):
The OLD behavior for policy CMP0054 will be removed from a future version
of CMake.

The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.

[Boulder]

I'd expect there's be a lot of convergence at high bitrates. I'm most interested in how the different modes do when they don't have enough bits to do it right.

I'm also replicating the procedure from my encoding challenge, for apples-to-apples

https://forum.doom9.org/showthread.php?t=175776

Do you have any results from this aq-mode comparison? It would be interesting to know if mode 4 has any useful real-world applications. Of course, HDR encodes are a different story then.

[LigH]

@filler56789 - I do not remember anymore when I mentioned "deprecated CMake policies" to the developer mailing list ... could be more than a year ago already. They are still supported, and I can only hope that abandoning them won't break it for long.

[benwaggoner]

Do you have any results from this aq-mode comparison? It would be interesting to know if mode 4 has any useful real-world applications. Of course, HDR encodes are a different story then.
I encoded them and then went on vacation and forgot to look at them :)!

I'll try to mux and upload before I head to IBC.

[LigH]

Just a side note:

Recently I found archives of images stored in BPG format (Better Portable Graphics), a variant of HEIF. Trying to view them, I found that some famous Windows image viewers don't support it well, partially due to license doubts (IrfanView). For XnView I found a plugin which substitutes the partial support (bpgdec) by basic support via an encoder using x265, but it is not easily configurable (only via configuration file, globally). Web browsers can display BPG images via a JavaScript decoder for the HTML5 Canvas, written by the format author Fabrice Bellard.

The decoders I found so far are not very optimized, especially not multithreaded. Decoding a 150 MPx image takes several seconds. (You will probably guess well if you ask yourself who owns one of such 50K$ cameras...)

[benwaggoner]

Just a side note:

Recently I found archives of images stored in BPG format (Better Portable Graphics), a variant of HEIF. Trying to view them, I found that some famous Windows image viewers don't support it well, partially due to license doubts (IrfanView). For XnView I found a plugin which substitutes the partial support (bpgdec) by basic support via an encoder using x265, but it is not easily configurable (only via configuration file, globally). Web browsers can display BPG images via a JavaScript decoder for the HTML5 Canvas, written by the format author Fabrice Bellard.

The decoders I found so far are not very optimized, especially not multithreaded. Decoding a 150 MPx image takes several seconds. (You will probably guess well if you ask yourself who owns one of such 50K$ cameras...)
It should be straightforward to write a version that would hand off the frame to system-level decoders from Edge and Safari. That'd be HW in most cases, but a well optimized assembly decoder is going to be faster than JS by a lot too.

Chrome and Firefox have been hard-coded to explicitly not pass through HEVC streams to the system decoders, although they do so for H.264. It'd be a trivial tweak to Chromium to re-enable that.

[LigH]

I also mean the decoding speed in separate image viewers. Especially sad for IrfanView, which used to be among the fastest for several formats, but is afraid of license trouble when implementing a HEIF decoder. (Or is it the encoder part, to implement the support only wholesome or not at all?)

Has libavcodec a multi-threaded HEVC decoder? I believe so...

[suarsg]

x265-3.1+11-de920e0-win64-static-multilib (https://drive.google.com/open?id=1NwszYdl291EZgbP2Fo51Tq7La6iXIWaO)

x265 [info]: HEVC encoder version 3.1+11-de920e0a3183
x265 [info]: build info [Windows][GCC 9.2.1][64 bit] 8bit+10bit+12bit
x265 [info]: (libavcodec 58.55.101)
x265 [info]: (libavformat 58.31.104)
x265 [info]: (libavutil 56.33.100)
x265 [info]: (lsmash 2.16.1)

Added a new option --lavf to force the use of lavf demuxer regardless of file extension, but this option has no effect on Y4M files.

x265-3.1+11-de920e0-win64-static-multilib+svt (https://drive.google.com/open?id=1kltkuJM_NginwiC67ADNX0RSOyXD-9Cj) (linked with SVT-HEVC, bigger file size)

Hello Wolfberry,

Did you change the order of the printed parameters in x265_param2string()? The "Encoding settings"-field in the produced metadata header from your binary is in a completely different order than what is the default on x265. It's really weird to see that when you're used to certain parameters being in a particular place. Can't say I'm a fan of this "customization".

[Atak_Snajpera]

Hello Wolfberry,

Did you change the order of the printed parameters in x265_param2string()? The "Encoding settings"-field in the produced metadata header from your binary is in a completely different order than what is the default on x265. It's really weird to see that when you're used to certain parameters being in a particular place. Can't say I'm a fan of this "customization".

Yes he did. Use builds from user barough

[Barough]

x265 v3.1+19-c4b098f973e6 (http://www.mediafire.com/file/d04tkl6pg74edkk/x265-3.1%252B19-c4b098f973e6_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[redbtn]

What about new option --selective-sao? Anybody knows should i disable it, like --no-sao earlier?
https://bitbucket.org/multicoreware/x265/commits/5ac4c74c54188f968f53397f9b9cb15bec46df47?at=default

[quietvoid]

What about new option --selective-sao? Anybody knows should i disable it, like --no-sao earlier?
https://bitbucket.org/multicoreware/x265/commits/5ac4c74c54188f968f53397f9b9cb15bec46df47?at=default

Yes, --selective-sao 4 (default) enables --sao even if you have --no-sao.
You can disable it all with --selective-sao 0 --no-sao

[Selur]

The confusing part is that
a. just using '--no-sao' doesn't disable SAO, you get
[warning]: SAO turned ON when selective-sao is ON
so to turn sao off you need to use '--selective-sao 0 --no-sao' ,'--no-sao' or '--selective-sao' on it's own isn't enough.
b. With 'selective-sao' is described as 'Disable SAO for all slices', what is SAO used on if you use '--selective-sao 0 --sao' ?

looking at the code:
if (!!m_param->selectiveSAO)

{

Slice* slice = frameEnc->m_encData->m_slice;

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 1;

switch (m_param->selectiveSAO)

{

case 3: if (!IS_REFERENCED(frameEnc))

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0;

break;

case 2: if (!!m_param->bframes && slice->m_sliceType == B_SLICE)

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0;

break;

case 1: if (slice->m_sliceType != I_SLICE)

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0;

break;

}

}

else

{

Slice* slice = frameEnc->m_encData->m_slice;

slice->m_bUseSao = curEncoder->m_frameFilter.m_useSao = 0;

}
here are a few conclusions:

'--selective-sao 0 --sao' and '--selective-sao 4 --sao' and '--selective-sao 4 --no-sao' all do the same thing, they do the same as the old '--sao' (should be no surprise this causes confusion)
only '--selective-sao 0 --no-sao' disabled SAO
'--selective-sao X' with X > 0
man, that is a fugly coding style


Cu Selur

[Boulder]

--no-sao should definitely mean switching SAO off completely. It's ridiculous to add some other parameter affecting the choice.

[redbtn]

Another issue with selective-sao is no space between rd and selective-sao
MediaInfo shows rd=4selective-sao=0
I don't know how propertly create issue on bitbucket.
Hex Editor:

[LigH]

Possibly best choice to report a bug: x265 developer mailing list.

I forwarded your report, redbtn.

[Boulder]

Using the latest VS2019 AVX build (3.1+19-c4b098f) from here: http://msystem.waw.pl/x265/ crashes the encoder in the beginning. Does anyone else have the same issue? I'm using a Ryzen 1800X with AVX2 disabled in the x265 command line.

[benwaggoner]

What about new option --selective-sao? Anybody knows should i disable it, like --no-sao earlier?
https://bitbucket.org/multicoreware/x265/commits/5ac4c74c54188f968f53397f9b9cb15bec46df47?at=default
The broader question is what are the psychovisual and compression efficiency impact of the different modes. The documentation is tragically light on the "why" of this feature. SAO is fast enough that I don't see any direct perf advantage of this, although perhaps it might help parallelization in some esoteric way to only do SAO on non-predicted frames or something.

But if SAO detail loss varies somewhat by frame type, only using it on intra stuff might enhance detail with less of a compression efficiency hit than turning it off outright.

[LigH]

The media-autobuild suite now introduced experimental support for ccache.

About at the same time, I have issues building a multilib x265 encoder with the manually fiddled build script which usually worked for years already. But building in MABS passes without error.

I am not sure if I have too many linking flags which may interfere with either ccache or with the current development state of x265. It fails linking the DLL:

[ 84%] Linking CXX shared library libx265.dll
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x2c): undefined reference to `x265::setupIntrinsicDCT_sse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x39): undefined reference to `x265::setupIntrinsicDCT_ssse3(x265::EncoderPrimitives&)'
E:/MABS/msys64/mingw32/bin/../lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld.exe: CMakeFiles/x265-shared.dir/objects.a(vec-primitives.cpp.obj):vec-primitives.cpp:(.text+0x4f): undefined reference to `x265::setupIntrinsicDCT_sse41(x265::EncoderPrimitives&)'
collect2.exe: error: ld returned 1 exit status

For a Win32 build, it fails only for the 8 bit precision library where assembler is used at all. For the Win64 build, it fails for all precisions as they all use assembler code.

[aymanalz]

Is it normal that x265 is about 20% slower on a Zen+ CPU than a Haswell, even though the Zen+ has a higher clock speed? I remember comments here about the AVX2 in AMD being only half as fast (?) as that in Intel, or something to that effect. Could that be the reason? Or could it be that the x265 developers haven't optimized the code for AMD as much as they have for Intel? It is a bit surprising, because this Zen+ architecture is from late 2018, a good few years later than Haswell.

[nevcairiel]

Is it normal that x265 is about 20% slower on a Zen+ CPU than a Haswell, even though the Zen+ has a higher clock speed? I remember comments here about the AVX2 in AMD being only half as fast (?) as that in Intel, or something to that effect. Could that be the reason?

Yes, the lack of full speed AVX2 is definitely a big factor, x265 uses a lot of it. Zen2 of course "solved" that shortcoming.

[NikosD]

Is it normal that x265 is about 20% slower on a Zen+ CPU than a Haswell, even though the Zen+ has a higher clock speed? I remember comments here about the AVX2 in AMD being only half as fast (?) as that in Intel, or something to that effect. Could that be the reason? Or could it be that the x265 developers haven't optimized the code for AMD as much as they have for Intel? Right on both.
Zen+ has a slower implementation of AVX2 than Haswell onwards, but x265 is also optimized for Intel and favors Intel vs AMD.
Actually, Intel published a paper along with x265 developers working together for AVX-512 optimizations (Intel-only) but they didn't manage to succeed in this, AVX-512 is so ineffective for x265 that most of the times you have to disable it according to Intel, not me.
x265 is an Intel-friendly project but Zen 2 architecture and Ryzen 3000 series managed to be a lot faster in x265 and beat Intel in its own favorite H.265 encoder.

[filler56789]

x265.exe 3.2_RC1+1-00d8df1b3bc6
(x64, multilib, GCC 9.2.0, upxed)

http://www.mediafire.com/file/k72pa2akgzo82m6/x265_3.2_RC1%252B1-00d8df1b3bc6.rar/file

[LigH]

I borrowed the toolchain files from the CMake call in MABS, now it builds again.

[mini-moose]

Zen2 of course "solved" that shortcoming.

The quotes on solved means they didn't solve it at all?

[Natty]

no changelog for 3.2?

[MeteorRain]

The quotes on solved means they didn't solve it at all?

Means it wasn't really an issue. So usually you say they improved the performance.

[Stereodude]

The quotes on solved means they didn't solve it at all?
They made a huge improvement in performance. I don't know why he used the quotes.

[Atak_Snajpera]

Improvements in Zen2 architecture are huge!
https://i.imgsafe.org/63/63a2e61a55.png

[FranceBB]

Very interesting chart indeed.
Is there another one which includes AVX512 as well?

[RanmaCanada]

Very interesting chart indeed.
Is there another one which includes AVX512 as well?

AVX512 is currently Intel only, and is "completely useless" for x265 as it produces way too much heat for the results.

https://forum.doom9.org/showthread.php?t=175476

https://www.reddit.com/r/programming/comments/8dhp7q/by_how_much_does_avx512_slow_down_your_cpu_a/

[Boulder]

I tested HME some more, and got quite interesting results.

Source 1080p filtered with my standard methods and downsized to 720p, merange 26 and my standard settings in x265. 1000 frames.

umh,umh,umh 2.05 fps / 5313,76 kbps
umh,umh,star 2.24 fps / 5314,31 kbps
umh,star,star 2.00 fps / 5327,91 kbps
star,star,star 2.01 fps / 5316,15 kbps
hex,umh,umh 2.03 fps / 5299,69 kbps

no HME, umh 2.64 fps / 5323,86 kbps
no HME, star 2.79 fps / 5325,69 kbps

I've now upgraded to 3700X and ran a similar test with that. The order of the results is still the same.

Can any of the devs (or anyone else, of course) explain why the combination "umh, umh, star" is clearly the fastest one? Without HME, the star method is clearly faster so I would expect "star, star, star" to be the fastest one with HME.

[mini-moose]

Can any of the devs (or anyone else, of course) explain why the combination "umh, umh, star" is clearly the fastest one? Without HME, the star method is clearly faster so I would expect "star, star, star" to be the fastest one with HME.

How is me=3 (star) faster than me=2 (umh)? thought the higher --me is, the slower it's supposed to be, maybe I'm wrong, I'm not expert.

Also, HME, is that a good feature to use?

[aymanalz]

How is me=3 (star) faster than me=2 (uhm)? thought the higher --me is, the slower it's supposed to be, maybe I'm wrong, I'm not expert.

Also, HME, is that a good feature to use?

Based on all user reports I have read, star gives comparable or better quality to umh but is equally fast. I'd like to know the truth of this as well - could any knowledgeable person please tell me if this is right?

Is Star a better method than umh in terms of:

1) Quality
2) Speed
3) Quality and speed

I's also like to take this opportunity to point out that there is a dearth of easily understandable documentation for x265. By that, I mean something for dummies like me. There are so many elementary questions that I cannot find answers to, despite all my googling.

[Boulder]

There's something broken in the latest versions, I've now tried two different builds but both have the same problem.

y4m [info]: 1920x1080 fps 24000/1001 i420p16 sar 1:1 unknown frame count
raw [info]: output file: f:\temp\captures\testclip.hevc
Error: fwrite() call failed when writing frame: 4, plane: 0, errno: 32
Output 22 frames in 1.66 seconds (13.23 fps)

This is just by loading the source in a Vapoursynth script and feeding it to x265 with vspipe. Many other clips work just fine.

The clip that causes this one can be found here:
https://drive.google.com/open?id=1AUVkTVe0FKTY9paTjdFwqqFfOZLgNr4M

x265-3.1+14 works fine.

[Boulder]

And my question that I posted to the x265 mailing list still has not been approved so I don't know if any dev saw the question regarding the motion search methods.

[Selur]

did a quick test trying to reproduce this here (did no filtering, just decoded with ffmpeg and piped to x265), for me too uhm was slower than star, but the speeds were similar.

--me star:
"I:\Hybrid\64bit\x265.exe" --preset medium --input - --output-depth 10 --y4m --profile main10 --me star --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --lookahead-slices 0 --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --output "E:\Temp\19_56_10_6810_02.265"
-> "encoded 2868 frames in 325.41s (8.81 fps), 4606.13 kb/s, Avg QP:23.78"
--me uhm:
"I:\Hybrid\64bit\x265.exe" --preset medium --input - --output-depth 10 --y4m --profile main10 --me umh --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --lookahead-slices 0 --crf 18.00 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --output "E:\Temp\20_03_51_9010_02.265"
-> "encoded 2868 frames in 326.89s (8.77 fps), 4605.07 kb/s, Avg QP:23.78"
I used:
x265 [info]: HEVC encoder version 3.1+20-913823aa15cd
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
on a Ryzen 7 1800X

Ran the calls a second time this time I got:
--me star: "encoded 2868 frames in 320.13s (8.96 fps), 4606.13 kb/s, Avg QP:23.78"
--me umh: "encoded 2868 frames in 322.27s (8.90 fps), 4605.07 kb/s, Avg QP:23.78"

-> So here too, uhm is slower, but not a lot, so this might still be source depended.

[Boulder]

-> So here too, uhm is slower, but not a lot, so this might still be source depended.

There are some early exits in star which probably don't exist in umh, so that source dependency would make sense. The method is some kind of an adaptation of what's in HM encoder.

https://xevc.wordpress.com/2014/01/23/motion-estimation-of-hm-encoder/

[markiemarcus]

I've seen some gains from using umh instead of star on animated sources. Admittedly slight at 1080p, but definitely visible at 720p and below. On live action I really can't spot the difference.

[Barough]

x265 v3.2+3-fdd69a766881 (https://www.mediafire.com/file/qatcw0oquayw838/x265-3.2+3-fdd69a766881_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[Natty]

release notes for v3.2

https://bitbucket.org/multicoreware/x265/raw/353572437201d551381002aebf20d244bd49ef17/doc/reST/releasenotes.rst

[LigH]

The speed of "far" motion search algorithms depends on the average amount of motion. Some of them can terminate early if the optimum is found close to an intermediate step. Disclaimer: If I understood these algorithms correctly...

[Ma]

The clip that causes this one can be found here:
https://drive.google.com/open?id=1AUVkTVe0FKTY9paTjdFwqqFfOZLgNr4M

x265-3.1+14 works fine.

Could you specify your x265 options to reproduce the problem?

[Boulder]

Could you specify your x265 options to reproduce the problem?

This is what I've used for that one:
--input - --y4m --input-depth 16 --dither --sar 1:1 --profile main10
--rc-lookahead 120 --min-keyint 5 --keyint 480 --splitrd-skip --colorprim "bt709" --transfer "bt709" --colormatrix "bt709"
--preset slower --rd-refine --subme 4 --ctu 32 --qg-size 16 --limit-refs 1 --limit-tu 3 --bframes 16 --deblock -2:-1 --no-sao
--cbqpoffs -3 --crqpoffs -3 --hme --hme-search umh,umh,star --merange 26 --qcomp 0.7 --max-merge 2 --aq-mode 3 --aq-strength 0.6 --crf 18.5

[Selur]

does anyone have a current x265 build with stv ?

[Selur]

thanks!

[-QfG-]

Has anyone results between AQ1 and AQ4? I've made 2 test encodes and see no difference in the movie, but have a smaller filesize with AQ4. Or i'm blind...

[pistacho]

Hi,

Possible bug:

Commit 21db162 (https://bitbucket.org/multicoreware/x265/commits/21db162c8622677c41a4fc77a14a59eb7326b46a) causes slowdown even is not used aq-mode 4 and output is identical.

Command line used:

"T:\TEST\x265\3108\x265_x64.exe" - --y4m --frames 1000 --crf 20.0 --preset "medium" --aq-mode 3 --keyint 240 --no-open-gop
--colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --output "T:\TEST\encode.265"


dec [info]: Intel Quick Sync: API LEVEL 1.29, HW
dec [info]: 1920x1080, YV12, 24000/1001 fps, 1000 frames
y4m [info]: 1920x1080 fps 24000/1001 i420p8 sar 1:1 unknown frame count
raw [info]: output file: T:\TEST\encode.265
x265 [info]: HEVC encoder version 3.1+7-147fb92c5ed5
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / 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 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 240 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I: 11, Avg QP:16.20 kb/s: 6958.02
x265 [info]: frame P: 275, Avg QP:20.60 kb/s: 3482.34
x265 [info]: frame B: 714, Avg QP:25.57 kb/s: 356.63
x265 [info]: Weighted P-Frames: Y:10.9% UV:6.5%
x265 [info]: consecutive B-frames: 22.4% 4.5% 4.5% 38.1% 30.4%

encoded 1000 frames in 17.71s (56.47 fps), 1288.81 kb/s, Avg QP:24.10



dec [info]: Intel Quick Sync: API LEVEL 1.29, HW
dec [info]: 1920x1080, YV12, 24000/1001 fps, 1000 frames
y4m [info]: 1920x1080 fps 24000/1001 i420p8 sar 1:1 unknown frame count
raw [info]: output file: T:\TEST\encode.265
x265 [info]: HEVC encoder version 3.1+8-21db162c8622
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / 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 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 240 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I: 11, Avg QP:16.20 kb/s: 6958.02
x265 [info]: frame P: 275, Avg QP:20.60 kb/s: 3482.34
x265 [info]: frame B: 714, Avg QP:25.57 kb/s: 356.63
x265 [info]: Weighted P-Frames: Y:10.9% UV:6.5%
x265 [info]: consecutive B-frames: 22.4% 4.5% 4.5% 38.1% 30.4%

encoded 1000 frames in 19.56s (51.13 fps), 1288.81 kb/s, Avg QP:24.10


Outputs seems bit-identical since the QP's and bitrates match so no "slow for best quality" is justified.

[-QfG-]

AQ4 is the new feature of version 3.2 from x265. AQ3 ist still good for BT709 output.
But the question is, have anyone see differences with YUV420P10 BT2020 HDR AQ1 and AQ4?

[pistacho]

I don't mean this. I'm talking about the new "AQ mode 4" function causing slowdown even when it's not used.

[pistacho]

I found the cause:

Some code related to AQ mode 4 is executed always.

This patch restores previous performance and not break anything (i think).

On file slicetype.cpp

line 481 replace

#define AQ_EDGE_BIAS 0.5
#define EDGE_INCLINATION 45
uint32_t numCuInHeight = (maxRow + param->maxCUSize - 1) / param->maxCUSize;
int maxHeight = numCuInHeight * param->maxCUSize;
intptr_t stride = curFrame->m_fencPic->m_stride;
pixel *edgePic = X265_MALLOC(pixel, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)));
pixel *gaussianPic = X265_MALLOC(pixel, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)));
pixel *thetaPic = X265_MALLOC(pixel, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)));
memset(edgePic, 0, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)) * sizeof(pixel));
memset(gaussianPic, 0, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)) * sizeof(pixel));
memset(thetaPic, 0, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)) * sizeof(pixel));
if (param->rc.aqMode == X265_AQ_EDGE)
edgeFilter(curFrame, edgePic, gaussianPic, thetaPic, stride, maxRow, maxCol);

int blockXY = 0, inclinedEdge = 0;

with

#define AQ_EDGE_BIAS 0.5
#define EDGE_INCLINATION 45

pixel *edgePic = NULL;
pixel *gaussianPic = NULL;
pixel *thetaPic = NULL;

if (param->rc.aqMode == X265_AQ_EDGE)
{
uint32_t numCuInHeight = (maxRow + param->maxCUSize - 1) / param->maxCUSize;
int maxHeight = numCuInHeight * param->maxCUSize;
intptr_t stride = curFrame->m_fencPic->m_stride;
edgePic = X265_MALLOC(pixel, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)));
gaussianPic = X265_MALLOC(pixel, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)));
thetaPic = X265_MALLOC(pixel, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)));
memset(edgePic, 0, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)) * sizeof(pixel));
memset(gaussianPic, 0, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)) * sizeof(pixel));
memset(thetaPic, 0, stride * (maxHeight + (curFrame->m_fencPic->m_lumaMarginY * 2)) * sizeof(pixel));
edgeFilter(curFrame, edgePic, gaussianPic, thetaPic, stride, maxRow, maxCol);
}

int blockXY = 0, inclinedEdge = 0;

and line 510


pixel *edgeImage = edgePic + curFrame->m_fencPic->m_lumaMarginY * stride + curFrame->m_fencPic->m_lumaMarginX;
pixel *edgeTheta = thetaPic + curFrame->m_fencPic->m_lumaMarginY * stride + curFrame->m_fencPic->m_lumaMarginX;

with


pixel *edgeImage = edgePic + curFrame->m_fencPic->m_lumaMarginY * curFrame->m_fencPic->m_stride + curFrame->m_fencPic->m_lumaMarginX;
pixel *edgeTheta = thetaPic + curFrame->m_fencPic->m_lumaMarginY * curFrame->m_fencPic->m_stride + curFrame->m_fencPic->m_lumaMarginX;

and line 545


X265_FREE(edgePic);
X265_FREE(gaussianPic);
X265_FREE(thetaPic);


with


if (param->rc.aqMode == X265_AQ_EDGE)
{
X265_FREE(edgePic);
X265_FREE(gaussianPic);
X265_FREE(thetaPic);
}



And binary with this patch applied: x265 v3.2 patched x64 GCC 9.2.0 (http://www.mediafire.com/file/nhflci5lxcvr6ej/x265_v3.2%252B2_patched.rar/file)

[LigH]

You should send your patch to the x265 Developer mailing list. They prefer it in "diff" format and in the mail body.
_

x265 3.2+3-fdd69a766881 (https://www.mediafire.com/file/vmt60ob57kxfemg/x265_3.2+3-fdd69a766881.7z/file) (MSYS2/MinGW, GCC 9.2.0)

[pistacho]

Diff patch send to mailing list.

[Boulder]

I couldn't replicate that difference between the two versions on my 3700X. I used the VS 2019 AVX2 builds from http://www.msystem.waw.pl/x265/

With 3.1+7, encoded 2000 frames in 461.37s (4.33 fps), 3467.58 kb/s, Avg QP:20.97
With 3.1+8, encoded 2000 frames in 459.33s (4.35 fps), 3467.58 kb/s, Avg QP:20.97

[qtwigg]

I have been having this issue; I give my x265 a movie and the x265 chooses how much it wants to encode. I give it a 45 minute show, it does 30 minutes. I give it a 1:40 hour movie, it decides not to do the last 10 minutes. I say it decides because it is not erroring. It literally finishes, mux into a container and says, Done! Why does it do this? Never had this problem before and the last 6 months maybe been having this issue randomly, off and on. Any ideas?

[RanmaCanada]

I have been having this issue; I give my x265 a movie and the x265 chooses how much it wants to encode. I give it a 45 minute show, it does 30 minutes. I give it a 1:40 hour movie, it decides not to do the last 10 minutes. I say it decides because it is not erroring. It literally finishes, mux into a container and says, Done! Why does it do this? Never had this problem before and the last 6 months maybe been having this issue randomly, off and on. Any ideas?

That is usually an indication that there is corruption in your original file.

[qtwigg]

That is usually an indication that there is corruption in your original file.

That is what one would think, however the file plays fine (till the end) and without closing the GUI or re-applying my settings or anything, I just press start within the same original GUI that I used before that only encoded some of the file, and it always works second time.
I open the program, add my video, add my settings and AVS, press start.
It does not encode the whole video
I just delete the files
And press start again in the same window
It encodes the whole video
Weird huh? Like I said it is random, not often.

[redbtn]

That is what one would think, however the file plays fine (till the end) and without closing the GUI or re-applying my settings or anything, I just press start within the same original GUI that I used before that only encoded some of the file, and it always works second time.

I open the program, add my video, add my settings and AVS, press start.

It does not encode the whole video

I just delete the files

And press start again in the same window

It encodes the whole video

Weird huh? Like I said it is random, not often.You have to ask about it the author of your GUI. This problem is not related to x265.

[pistacho]

I couldn't replicate that difference between the two versions on my 3700X. I used the VS 2019 AVX2 builds from http://www.msystem.waw.pl/x265/

With 3.1+7, encoded 2000 frames in 461.37s (4.33 fps), 3467.58 kb/s, Avg QP:20.97
With 3.1+8, encoded 2000 frames in 459.33s (4.35 fps), 3467.58 kb/s, Avg QP:20.97

In my system (Intel 9700k) the difference persist with these builds:


y4m [info]: 1920x1080 fps 24000/1001 i420p8 sar 1:1 unknown frame count
raw [info]: output file: T:\TEST\encode.265
x265 [info]: HEVC encoder version 3.1+7-147fb92c5ed5
x265 [info]: build info [Windows][MSVC 1921][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / 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 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 240 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I: 11, Avg QP:16.20 kb/s: 6958.02
x265 [info]: frame P: 275, Avg QP:20.60 kb/s: 3482.34
x265 [info]: frame B: 714, Avg QP:25.57 kb/s: 356.63
x265 [info]: Weighted P-Frames: Y:10.9% UV:6.5%
x265 [info]: consecutive B-frames: 22.4% 4.5% 4.5% 38.1% 30.4%

encoded 1000 frames in 17.26s (57.95 fps), 1288.81 kb/s, Avg QP:24.10



y4m [info]: 1920x1080 fps 24000/1001 i420p8 sar 1:1 unknown frame count
raw [info]: output file: T:\TEST\encode.265
x265 [info]: HEVC encoder version 3.1+8-21db162c8622
x265 [info]: build info [Windows][MSVC 1921][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main profile, Level-4 (Main tier)
x265 [info]: Thread pool created using 8 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 3 / 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 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 240 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-20.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing lslices=6 deblock sao
x265 [info]: frame I: 11, Avg QP:16.20 kb/s: 6958.02
x265 [info]: frame P: 275, Avg QP:20.60 kb/s: 3482.34
x265 [info]: frame B: 714, Avg QP:25.57 kb/s: 356.63
x265 [info]: Weighted P-Frames: Y:10.9% UV:6.5%
x265 [info]: consecutive B-frames: 22.4% 4.5% 4.5% 38.1% 30.4%

encoded 1000 frames in 18.76s (53.31 fps), 1288.81 kb/s, Avg QP:24.10

[LigH]

Diff patch send to mailing list.

It arrived safely :D

[ShortKatz]

Diff patch send to mailing list.

Did you als sign the Contributor License Agreement? See
https://bitbucket.org/multicoreware/x265/wiki/Contribute
They rejected all my patches until I sended them back the signed Contributor License Agreement. It is also important to format it correctly. One of my former patches couldn't be applied, because the formatting was wrong. And don't be surprised if it takes some time. For my patches it normally takes several weeks until they get applied.

[pistacho]

My patch is a bug fix (slowdown of 10% for no reason in a stable branch). I don't care if they don't apply my patch as is. I guess someone will correct it somehow...

[Selur]

Looks like
https://bitbucket.org/multicoreware/x265/commits/cdd80b53c90d224fd9281ad13de3ca9a1b6e1d39
and
https://bitbucket.org/multicoreware/x265/commits/d4c4624fdc9af25738e000a9c9f10c31238d6bf1
commit are meant to fix the "slowdown even is not used AQ mode 4."

Cu Selur

[filler56789]

x265.exe 3.2+5-354901970679

--- Fix: AQ mode 4 commit (21db162) introduces slowdown even when AQ mode 4 is not used;

--- Adaptive Frame duplication
This patch does the following:
1. Replaces 2-3 near-identical frames with one frame and sets pic_struct based on frame doubling / tripling;
2. Add option "--frame-dup" and "--dup-threshold' to enable frame duplication and to set threshold for frame similarity (optional);

http://www.mediafire.com/file/ado1h89ndmsdybp/x265_3.2%252B5-354901970679.rar/file

[benwaggoner]

x265.exe 3.2+5-354901970679--- Adaptive Frame duplication
This patch does the following:
1. Replaces 2-3 near-identical frames with one frame and sets pic_struct based on frame doubling / tripling;
2. Add option "--frame-dup" and "--dup-threshold' to enable frame duplication and to set threshold for frame similarity (optional);[/I]
I see the default value of dup-threshold is 70. It would be helpful to know if higher numbers require more or less similarity, and ballpark how much similarity is requires for 70. I hope it is sub-psychovisual at least.

I could see this helping efficiency and encoding speed for stuff like a title card displayed for a couple of seconds.

[fauxreaper]

--frame-dup makes output duration smaller than input. Is it a decoder problem of not duplicating/triplicating frame duration when needed? Or is it a muxing problem when using matroska as a container?

[nevcairiel]

I wonder if that mode is really that beneficial. If it detects dupes, it could just code them as all-skip P or B frames with minimal bitstream overhead. Sure, that single frame is being saved, but in the grand scheme of things for a small scene of a static shot that seems insignficant. Nevermind that repeat flags are likely to trip up decoders and/or muxers, as you basically generate a VFR bitstream.

[vpupkind]

I wonder if that mode is really that beneficial. If it detects dupes, it could just code them as all-skip P or B frames with minimal bitstream overhead. Sure, that single frame is being saved, but in the grand scheme of things for a small scene of a static shot that seems insignficant. Nevermind that repeat flags are likely to trip up decoders and/or muxers, as you basically generate a VFR bitstream.
All-skip frame is way more expensive than changing a pic_struct value.
The reason for doing such a weird VFR is that the same mechanism used for 3:2 pulldown and 24->60p conversion is used here.

[vpupkind]

I see the default value of dup-threshold is 70. It would be helpful to know if higher numbers require more or less similarity, and ballpark how much similarity is requires for 70. I hope it is sub-psychovisual at least.

I could see this helping efficiency and encoding speed for stuff like a title card displayed for a couple of seconds.

The threshold is PSNR value between consecutive pictures

[nevcairiel]

All-skip frame is way more expensive than changing a pic_struct value.

Sure, in relative terms. But in absolute terms, in a sea of actually coded and changing frames, how much of a difference are we talking here? 0.01%? Likely not even that.


The reason for doing such a weird VFR is that the same mechanism used for 3:2 pulldown and 24->60p conversion is used here.

A mechanism thats already rarely used in HEVC, and likely not well supported, or intentionally ignored, because original 24p content is just better then stuttery 30p. :)

[WhatZit]

I could see this helping efficiency and encoding speed for stuff like a title card displayed for a couple of seconds.

I could see this being as big a pain-in-the-arse as traditional VFR. Luckily, it is disabled by default.

Still, one of Multicoreware's corporate clients probably asked for it (anime OTT?), so there it is.

[LigH]

x265 3.2+5-354901970679 (https://www.mediafire.com/file/7vq9ld7us08rp6y/x265_3.2%2B5-354901970679.7z/file)

[mandarinka]

I could see this being as big a pain-in-the-arse as traditional VFR. Luckily, it is disabled by default.

Still, one of Multicoreware's corporate clients probably asked for it (anime OTT?), so there it is.

Actually it's not really a good idea for anime. The duplicate removal filters like this can mishandle a very common scenario where the whole picture doesn't move at all, but there is just mouth movement in a tiny part. It can be just few pixels, but killing that and replacing with wrong duplicate is a terrible sort of artifact.

[vpupkind]

Actually it's not really a good idea for anime. The duplicate removal filters like this can mishandle a very common scenario where the whole picture doesn't move at all, but there is just mouth movement in a tiny part. It can be just few pixels, but killing that and replacing with wrong duplicate is a terrible sort of artifact.
I am unsure whether these two frames will have a PSNR of 70dB -- you will still have a significant absolute distance between a couple of co-located pixels, which should bring it below the threshold. Would be very interested in test results -- don't have a decent anime source.

[Magik Mark]

Hey Guys,

Are there any new switches that would speed up multi pass encoding?

[RanmaCanada]

Hey Guys,

Are there any new switches that would speed up multi pass encoding?

Yes the -Buy Ryzen 3900x switch :)

[aymanalz]

Yes the -Buy Ryzen 3900x switch :)

He has raised a valid and pertinent point. After all these years, x265 is still painfully slow on "normal" processors. You are right that the only way to encode faster is to get faster processors with more cores. I wish that wasn't the case, and that by now the developers could have made it faster. Maybe it is mathematically/programatically impossible to get any more speed improvements. That's a pity.

[FranceBB]

He has raised a valid and pertinent point. After all these years, x265 is still painfully slow on "normal" processors. You are right that the only way to encode faster is to get faster processors with more cores. I wish that wasn't the case, and that by now the developers could have made it faster. Maybe it is mathematically/programatically impossible to get any more speed improvements. That's a pity.

It was pretty much the same when there was the shift from MPEG-2 and then Xvid to H.264: the computational complexity was way higher and the old single core single thread CPUs weren't able to cope with the amount of resources required. The fact that H.264 has been the de-facto standard for several years kinda got us used to high encoding speed. As a matter of fact, MPEG-2 encoders like x262 and MPEG-4 ASP encoders (Xvid) were not parallelized at all or were poorly parallelized, while x264 is able to max out a very high number of cores and thread depending on the settings.
A thing it won't use properly, though, is the second CPU, for instance I noticed that if you have a dual socket configuration like a Dual Xeon with an high number of cores and threads respectively, x264 will use only one of the CPUs, thus reducing the speed.
Anyway, x264 is generally so fast by now that it's fine, also because of modern assembly optimizations (manually written intrinsics) that were not available for x262 and Xvid encoders like AVX2.
x265 on the other hand has been developed with modern hardware in mind and not only it uses modern assembly optimizations (like x264) but it is also heavily parallelized, it uses both CPUs in a dual socket environment and it also enables you to use some additional settings if your CPU has so many cores that it's not maxed out by it.

You mentioned the mathematical complexity and indeed H.264 was based on a Discrete Cosine Transform (which works with real numbers and is continuous in 2phi) and the Hadamard Transform which is very light and is meant to take care of what the DCT couldn't compress well enough. As to H.265 it is indeed more demanding in terms of computational cost as it's using the Discrete Cosine Transform and the Discrete Sine Transform, but keep in mind that it could have been even more demanding 'cause years ago, before 2013, there were propositions about using the Karhunen-Loeve transform which is the heaviest transform that I know and it's very demanding in terms of computational cost, this is because back in the days it seemed impossible to achieve a 40% reduction compared to H.264 based on a linear-algebra only approach. The thing was that according to the results, the KLT did achieve better results compared to the DCT, however the improvements were so small in some cases and the computational cost was so high that they decided not to proceed with that approach, which then led to the modern DCT, DST approach.
If you take a look at the "future", you'll see 8K and H.266 VVC which inherited the Discrete Cosine Transform and Discrete Sine Transform approach from H.265 HEVC, but it's also using an adaptive multiple transform (AMT) scheme for residual coding for both inter-coded and intra-coded blocks. This approach basically consists of a set of five DCT and DST based transform, namely DCT-II, DCT-V, DCT-VIII, DST-I, and DST-VII and a Signal
Dependent Transform (SDT) is competed to the AMT output. The SDT approximates the optimal Karhunen-Loéve
transform (KLT), which is a signal dependent transform, by estimating current signal to code (transform block) with
similar signals (i.e. reference patch) available at the decoder (already coded). This way a lot of computational power is actually saved by not using the KLT directly which is far too demanding in terms of computational cost.

Anyway, you can be sure of one thing: it will be even more demanding, but, you know, in a world in which we have configurations with Intel Xeons CPUs like this Intel Xeon Platinum 9282 56c/112th (https://www.intel.com/content/www/us/en/products/processors/xeon/scalable/platinum-processors/platinum-9282.html), this doesn't seem to be a problem. For instance, I myself encode with an Intel Xeon 28c/56th at work with 64GB of RAM and a Quadro GPU even though I've been asking them several times to upgrade the CPU as it's been like this ever since 2017 and it's now "old" for what I gotta do on a daily basis.

What do I have at home? Well, a crappy i7 4c/8th with 32 GB DDR4 and an RTX NVIDIA GPU but it doesn't matter since the PC I use at home is for general purpose: browsing (replying to you folks here on Doom9 :P), occasionally watching videos (although I do have my 4K Panasonic Bluray for that), listening to music and studying (I'm in the middle of my master at university while I'm working as encoder for a company).

In a nutshell: computational cost will always get higher and higher but CPUs will get better and better. :P

[RanmaCanada]

FranceBB hits the nail on the head. It's also why AV1 is a literal order of magnitude slower than x265. As you get more complex with your codecs and your compression, the processing power required is basically a bell curve. There are ways around this, like the SVT implementations of HEVC and AV1, but they are seriously garbage in comparison to a dedicated CPU encode. In time they might get better, but currently, no.

[soresu]

There are ways around this, like the SVT implementations of HEVC and AV1, but they are seriously garbage in comparison to a dedicated CPU encode. In time they might get better, but currently, no.
SVT is purely CPU encode, there's no GPU, ASIC or other accelerator code in there - just a great parallel scaling framework that seemingly loses no quality as you pile on threads (per the BAV conference), that and oodles of AVX2 and AVX 512 SIMD code.

It's not a question of whether it 'might' get better though, the SVT codecs are owned/controlled by Intel, with Netflix working on it too, so unless they get bored and shelve them, it will continue to get developed because its a perfect way to show off and benchmark their super-mega-core-a-paloosa CPU's.

The libaom encoder is more of a development platform/reference implementation of AV1 optimised into a working encoder, much like libvpx for VP8/VP9 from Google - I wouldn't ever expect it to reach the speed performance of the other implementations because they are also developing the next gen codec on an experimental branch at the moment.

[NikosD]

Anyway, you can be sure of one thing: it will be even more demanding, but, you know, in a world in which we have configurations with Intel Xeons CPUs like this Intel Xeon Platinum 9282 56c/112th (https://www.intel.com/content/www/us/en/products/processors/xeon/scalable/platinum-processors/platinum-9282.html), this doesn't seem to be a problem. This is not a real world CPU.
It's practically not existent, it doesn't have a written price and it's probably never sold to anyone. Only rumors.
Just for papers.
For instance, I myself encode with an Intel Xeon 28c/56th at work with 64GB of RAM and a Quadro GPU even though I've been asking them several times to upgrade the CPU as it's been like this ever since 2017 and it's now "old" for what I gotta do on a daily basis. Since your needs are that high, you should convince your boss at work to buy some serious processing power with half the money.
Try a 64C/128T EPYC CPU and you will get double processing power with half the money of the Xeon 28C/56T
Yes, it's that simple.

[MeteorRain]

He has raised a valid and pertinent point. After all these years, x265 is still painfully slow on "normal" processors. You are right that the only way to encode faster is to get faster processors with more cores. I wish that wasn't the case, and that by now the developers could have made it faster. Maybe it is mathematically/programatically impossible to get any more speed improvements. That's a pity.

Things designed for future are supposed to be used with future technologies.

May I ask what is a "normal" processor. When x264 was released, I was among one of the pioneers to use x264 for daily driving. What is a normal processor by then? An Athlon 64 4000+ with 1 core 1 thread at 2.4GHz is probably a HEDT(?) processor. A Sempron 2400+ is probably a fairly normal processor with 1c1t at 1.66GHz. Does the latest x264 run faster on a Sempron 2400+? Probably not.

Within 5 years after that, at around 2010 we got Phenom II X6 1055T at a reasonable price, with 6c6t at 2.8GHz, which is about 10x fast as an Athlon 64 4000+. You used to get 3 fps from x264, now it's 30 fps, which sounds very reasonable.

Now regarding x265, it was released at around 2013, a year which Haswell released. i7-4770K comes with 4c8t at 3.5GHz. Within 5 years, what do we get? Core i9-9900K that's 8c16t at 4GHz if you can afford that. From passmark score it's barely 2x performance to 4770K, and even you take AVX2 into consideration it's not gonna be 3x 4x performance. You used to get 3 fps, now it's 9 fps, which is still slow.

So, blame the CPU manufacturers, not developers.

Also you probably made an assumption that code can be optimized by a good portion. That's not very true if you are talking about the versions after full AVX2 optimization is done. Yes, before they did that, it was a bit slow because the full advantage of a modern CPU is not being used. For now, the AVX2 code (and AVX512 code as we speak) has little room to further optimize. We may be able to squeeze little time by applying some early exiting and skipping algorithm optimizations. Again, marginal difference.

HEVC is designed for (near) future, with the ability to reduce processor demands by downgrading the parameters. If you want something fast, use a lower setting. Full feature enabled high setting encoding is supposed and desired to be slow even on a high-end processor, let alone a "normal" one.

Hope this helps.

[excellentswordfight]

A thing it won't use properly, though, is the second CPU, for instance I noticed that if you have a dual socket configuration like a Dual Xeon with an high number of cores and threads respectively, x264 will use only one of the CPUs, thus reducing the speed.
Anyway, x264 is generally so fast by now that it's fine, also because of modern assembly optimizations (manually written intrinsics) that were not available for x262 and Xvid encoders like AVX2.
x265 on the other hand has been developed with modern hardware in mind and not only it uses modern assembly optimizations (like x264) but it is also heavily parallelized, it uses both CPUs in a dual socket environment and it also enables you to use some additional settings if your CPU has so many cores that it's not maxed out by it.
I have not seen any multi socket issues with x264, I think it handles it fine, maybe not as good as x265, but it can use the second socket if needed. You will see more load on one socket, but isnt that the logical way? Most of the time you wont saturate all threads in a multi socket system, and it will prioritize one socket ofc to minimize cross socket communication.

And tbh, I dont think x265 is better parallelized then x264, at default settings its actaully worse for resolutions under 4k cause of the large CU size. And both x264 and x265 have a hard time to scale beyond 24'ish threads for 1080p at slower settings. Above that clock speeds should be prioritized over threads if not doing chunk encoding. And this is by no means a criticism for x264 or x265, the paralazation and thread scaling is already very impressive for this task. And I dont think we can assume this to get much better without sacrificing something else. To increase speed and to utilize renderfarms, chunk encoding will be the way forward. And for live/realtime content, it will be hw-encoding doing the job.

Now regarding x265, it was released at around 2013, a year which Haswell released. i7-4770K comes with 4c8t at 3.5GHz. Within 5 years, what do we get? Core i9-9900K that's 8c16t at 4GHz if you can afford that. From passmark score it's barely 2x performance to 470K, and even you take AVX2 into consideration it's not gonna be 3x 4x performance. You used to get 3 fps, now it's 9 fps, which is still slow.
4770k have AVX2 to, if I'm not mistaken it was introduced with haswell. I own an 4790k and have some experience with 9900, I would say that there is about an 2,5x performance difference for x265.

[aymanalz]

Things designed for future are supposed to be used with future technologies.

May I ask what is a "normal" processor. When x264 was released, I was among one of the pioneers to use x264 for daily driving. What is a normal processor by then? An Athlon 64 4000+ with 1 core 1 thread at 2.4GHz is probably a HEDT(?) processor. A Sempron 2400+ is probably a fairly normal processor with 1c1t at 1.66GHz. Does the latest x264 run faster on a Sempron 2400+? Probably not.

Within 5 years after that, at around 2010 we got Phenom II X6 1055T at a reasonable price, with 6c6t at 2.8GHz, which is about 10x fast as an Athlon 64 4000+. You used to get 3 fps from x264, now it's 30 fps, which sounds very reasonable.

Now regarding x265, it was released at around 2013, a year which Haswell released. i7-4770K comes with 4c8t at 3.5GHz. Within 5 years, what do we get? Core i9-9900K that's 8c16t at 4GHz if you can afford that. From passmark score it's barely 2x performance to 4770K, and even you take AVX2 into consideration it's not gonna be 3x 4x performance. You used to get 3 fps, now it's 9 fps, which is still slow.

So, blame the CPU manufacturers, not developers.

Also you probably made an assumption that code can be optimized by a good portion.
...

But HEVC is no longer for the future, is it? Successors to HEVC are in development, so HEVC is the present.

The part about how processors haven't improved much is absolutely right, and I had that in mind as well. From the year 2000 to 2010, processors (low end, mid grade, high end, everything) became several times faster, and sold for the same or even lower prices, probably due to the Intel-AMD competition. But incremental improvements have been a lot less in this decade, especially after Sandybridge or Haswell.

I could blame the CPU manufacturers, or blame the x265 developers for not anticipating that processing power per price will not keep increasing at the rate it used to, but I'm not really trying to assign blame; just making an observation that x265 is extremely slow on "normal" processors - by which I meant a reasonable home desktop without a gazillion cores and threads. (I'd say a quad core i7 or hexacore is the mainstream now.)

I wasn't assuming that code can be optimized further - I was wondering out loud whether it could. I was lamenting that perhaps they have reached a point where further optimizations for speed just isn't possible - in which case, only professional encoders or studios with 16+ core machines can use it at decent speeds. Not the casual home users.

[LigH]

CPUs are not developed with the one and only purpose to encode video.

If you want video encoding at top speed, use a dedicated video encoder chip... but as always, there are the usual conflicts between speed, accuracy/complexity, and other factors: "You can't have them all at maximum at the same time."

[Rousseau]

On UHD rips with 3.2 , the image looks darker when played in MPV than with rips made in 3.1 . They look the same in MPC with no tone mapping. I made no change other than the encoder.

[Boulder]

Have you compared the metadata between the two encodes?

[Barough]

x265 v3.2+6-f46aa2bc1c341 (https://www.mediafire.com/file/7jca2pcj5eobv2b/x265-3.2+6-f46aa2bc1c34_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[MeteorRain]

And tbh, I dont think x265 is better parallelized then x264, at default settings its actually worse for resolutions under 4k cause of the large CU size. And both x264 and x265 have a hard time to scale beyond 24'ish threads for 1080p at slower settings.

4770k have AVX2 to, if I'm not mistaken it was introduced with haswell. I own an 4790k and have some experience with 9900, I would say that there is about an 2,5x performance difference for x265.

x264 used to suffer from high thread count causing reduction of encoding quality. Later the threading is greatly improved and people are no longer limited to the (more optimized option of) 8 - 12 threads and can go beyond without much loss of quality.

Haswell is the first generation that introduced AVX2. However the performance of AVX2 is not consistent across multiple generations. The manufacturer is constantly improving instruction speed, and AVX2 on Haswell is slower than AVX2 on Skylake or later generations by some percent. That's why I said the performance difference on AVX2 needs to be taken into consideration.

[MeteorRain]

But HEVC is no longer for the future, is it? Successors to HEVC are in development, so HEVC is the present.

The part about how processors haven't improved much is absolutely right, and I had that in mind as well. From the year 2000 to 2010, processors (low end, mid grade, high end, everything) became several times faster, and sold for the same or even lower prices, probably due to the Intel-AMD competition. But incremental improvements have been a lot less in this decade, especially after Sandybridge or Haswell.

I could blame the CPU manufacturers, or blame the x265 developers for not anticipating that processing power per price will not keep increasing at the rate it used to, but I'm not really trying to assign blame; just making an observation that x265 is extremely slow on "normal" processors - by which I meant a reasonable home desktop without a gazillion cores and threads. (I'd say a quad core i7 or hexacore is the mainstream now.)

I wasn't assuming that code can be optimized further - I was wondering out loud whether it could. I was lamenting that perhaps they have reached a point where further optimizations for speed just isn't possible - in which case, only professional encoders or studios with 16+ core machines can use it at decent speeds. Not the casual home users.

From different point of view, you can say HEVC is the present, you can say it's not. For example, online streaming still uses AVC (some like Youtube may be using VP9 but still), we still buy Blu-rays instead of UHDs, majority of the content distributors are still using AVC. The use of HEVC would still be quite limited so far, even if assuming HEVC can be encoded at a faster speed. I admit there are other factors like royalty, but still.

For casual home users you can still use x265, just with a lower settings. On one of a workstation that I have, with only 6 cores Sandy Bridge, I can still get 4-5 FPS on 1080P with a reasonable settings (10-bit, medium preset, LP tuning). Today a $199 6 cores AMD is already twice the speed of that SNB, so 10 FPS is what you get if you max it out. I personally feel like this is an acceptable speed for casual home users. If someone needs to do extensive HEVC encoding at a decent speed, a higher performance CPU is inevitable. (Ryzen 3900X is only $499 which is still kinda in the affordable range.)

And I apologize for my incorrect assumption. Thanks for your input.

[RanmaCanada]

And we already know that the current highest end Epyc 7742 (64 cores) can do 8k encoding in faster than real time (79fps). Now imagine what a 32 core Zen2 Threadripper will be able to do. Heck I wish someone here who has a 3900x would run Sagitare's benchmark and post their results. We haven't had any of the new Zen 2 chips benched. Though I think he would need to update all the binaries to reflect the changes that have been made in x265 as the benchmark is 2 years old.

[Natty]

On UHD rips with 3.2 , the image looks darker when played in MPV than with rips made in 3.1 . They look the same in MPC with no tone mapping. I made no change other than the encoder.

i have observed the same issue with 3.2, but with HD. somehow managed to not make it darker or lighter through avisynth.

[Rousseau]

Have you compared the metadata between the two encodes?

I'm getting some contradictory results now so this may just be some mpv wonkiness. I did notice that 3.1 stable (3.1.2+4-dc2dcb5) concatenates the cll settings with the master-display settings which might be an issue. Other versions have them separate.

3.1.2+4-dc2dcb5
master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)cll=0,0

3.2+5-354901970679
master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) / cll=0,0



I've also noticed AQ2 seems to have problems in HDR encodes (3.1 & 3.2 builds I've tested), leaving a lot of blotchy grain/puddling in flat areas of some scenes. AQ1 does much better. It's not that visible when you look at it without tone mapping, but in MPV it's very obvious. I tried AQ3 & 4 with no improvement.

[NikosD]

Oh guys, please.

How many times do I have to post it ?

x265 is not optimized for speed/multi-threading and AMD CPUs.

64C/128T EPYC processor managed to encode faster than real-time 8K H.265 stream, using Beamr H.265 encoding software, which is optimized for speed/multi-threading and EPYC.

H.265 is different than x265.

https://www.tomshardware.com/news/amd-epyc-rome-8k-real-time-encoding,40400.html

[Boulder]

I'm getting some contradictory results now so this may just be some mpv wonkiness. I did notice that 3.1 stable (3.1.2+4-dc2dcb5) concatenates the cll settings with the master-display settings which might be an issue. Other versions have them separate.

3.1.2+4-dc2dcb5
master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)cll=0,0

3.2+5-354901970679
master-display=G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1) / cll=0,0



I've also noticed AQ2 seems to have problems in HDR encodes (3.1 & 3.2 builds I've tested), leaving a lot of blotchy grain/puddling in flat areas of some scenes. AQ1 does much better. It's not that visible when you look at it without tone mapping, but in MPV it's very obvious. I tried AQ3 & 4 with no improvement.
Did you try a higher aq-strength for mode 2? I think some people reported that HDR encoding requires that.
EDIT: I forgot that I was "there" as well : https://forum.doom9.org/showthread.php?t=175631 . I've not done any HDR encodes in a long time but I would probably go for aq-mode 1 at the default strength.

I think you should report an issue for both of these cases at https://bitbucket.org/multicoreware/x265/issues.

I have a feeling that HDR encoding is not optimal (and also opened an issue regarding this without a response), pointing to how much you need to change aq-strength and CRF compared to SDR encodes.

[excellentswordfight]

x265 is not optimized for speed/multi-threading and AMD CPUs.

What are the basis for that statement? The lower clocked 3700X is on par or faster then 9900k at the same amount of threads. First and second gen wasnt that strong per thread, but that is much cause of avx speed and other cpu-design causes. And I have recieved several Epyc 7402p servers, no issue there either, blazing fast.

[redbtn]

I've also noticed AQ2 seems to have problems in HDR encodes (3.1 & 3.2 builds I've tested), leaving a lot of blotchy grain/puddling in flat areas of some scenes. AQ1 does much better. It's not that visible when you look at it without tone mapping, but in MPV it's very obvious. I tried AQ3 & 4 with no improvement.
I always use AQ2 for HDR encodes, and I never thought about it, cuz somewhere here I read that AQ2 is optimal for HDR. But now, it seems like I should make some tests.
How much bigger bitrate you get with AQ1 vs AQ2?

[mandarinka]

What are the basis for that statement? The lower clocked 3700X is on par or faster then 9900k at the same amount of threads. First and second gen wasnt that strong per thread, but that is much cause of avx speed and other cpu-design causes. And I have recieved several Epyc 7402p servers, no issue there either, blazing fast.

I think what he meant is that results with Beamr can't be taken as something indicating how fast will x265 run.

[mini-moose]

How much bigger bitrate you get with AQ1 vs AQ2?

I think that's because in AQ1 the aq-strength for all frames is the same, while AQ2 uses auto-variance, and x265 applies separate aq-strength for each frame (based on complexity).

At least on paper AQ2 sounds better to me and it is now the default.

One would hope the devs switched to that for a good reason (i.e it's not just slightly faster but also gives a better result).

[rco133]

There seems to be a lot of discussion about AQ mode 1 vs 2.

When it comes to 4k HDR encodes what I found is that with mode 2 the Average QP result is in average 1 higher in mode 2.

For example mode 1 is 21.33 and mode 2 is 22.15.

I have measured the vmaf values of quite a few 4k HDR encode cuts, and not in one single instance has the vmaf score been worse on the aq mode 2 encode. Every single time the vmaf value is higher on the aq mode 2 encode.

Yes, the file size is smaller, and the average QP a bit higher.

The switch from aq mode 1 to aq mode 2 must have been made for a reason. If mode 2 gives worse quality than mode 1, why would the devs change the default.

Either the devs knows nothing about qhat they are doing, or the actually know what they are doing.

All I can say is that I am yet to find a mode 1 encode with a higher vmaf score than the identical mode 2 encode.

rco133

[Boulder]

But have you made any visual comparisons? In my old tests, I found out that mode 2 causes problems in flat backgrounds.

Many of the changes in the default values have been made without any explanation, so we don't really know what the use case for each of them has been. I sometimes feel that many settings are based on squeezing everything out of the material with the least possible amount of bits, even if it means oversmoothing etc. which can then be irritating to others (like me).

[redbtn]

But have you made any visual comparisons? In my old tests, I found out that mode 2 causes problems in flat backgrounds.

Many of the changes in the default values have been made without any explanation, so we don't really know what the use case for each of them has been. I sometimes feel that many settings are based on squeezing everything out of the material with the least possible amount of bits, even if it means oversmoothing etc. which can then be irritating to others (like me).Can I ask what settings do you use for 4k HDR encodes? I mean like --aq-strength --qcomp and CFR. I would like to know for example aq-strength is depends of bitrate or not. Cuz with low bitrate video may be very blocky and requires high aq-strength, but what about for bitrate ~ 20-22mb?
I usually use aq-strength 0.8 and I'm thinking should I raise it to 0.9 or even 1.0?

[Boulder]

Can I ask what settings do you use for 4k HDR encodes? I mean like --aq-strength --qcomp and CFR. I would like to know for example aq-strength is depends of bitrate or not. Cuz with low bitrate video may be very blocky and requires high aq-strength, but what about for bitrate ~ 20-22mb?
I usually use aq-strength 0.8 and I'm thinking should I raise it to 0.9 or even 1.0?

It's been quite a long time since I did any HDR encodes, but I would start with aq-mode 1 with the default strength 1.0. I use qcomp 0.7 and HDR requires a much lower CRF. My base for SDR HD is CRF 18 so I would use CRF 13 for HDR.

The encoder has probably gone through many changes so I would need to test things before doing any HDR encodes. But those would be a good starting point.

[redbtn]

It's been quite a long time since I did any HDR encodes, but I would start with aq-mode 1 with the default strength 1.0. I use qcomp 0.7 and HDR requires a much lower CRF. My base for SDR HD is CRF 18 so I would use CRF 13 for HDR.

The encoder has probably gone through many changes so I would need to test things before doing any HDR encodes. But those would be a good starting point.Thx for your reply! For 1080p HDR I use crf 10-13, but for 2160p HDR crf 13 is too low. With crf 20 I usually get 17-18mb and for grainy films I get 22-24mb.
I'll try to use strength 1.0, but I did some tests and it raise bitrate by 10-11%.

[Boulder]

Yes, CRF 13 is probably quite low for UHD because any problems arising from too few bits will not be as apparent on a 4K TV as with 1080p and lower where they are enlarged during playback.
With aq-strength, you could probably go down to 0.8 or so with grainy sources as grain tends to attract bits anyway, so the flat parts of the image will not look bad.

[benwaggoner]

From different point of view, you can say HEVC is the present, you can say it's not. For example, online streaming still uses AVC (some like Youtube may be using VP9 but still), we still buy Blu-rays instead of UHDs, majority of the content distributors are still using AVC. The use of HEVC would still be quite limited so far, even if assuming HEVC can be encoded at a faster speed. I admit there are other factors like royalty, but still.
There are tons of devices where HEVC is the only supported 10-bit codec. I'd expect pretty much all streaming of 4K or HDR content to those devices to be in HEVC. I don't know of anyone doing HDR or >1080p in H.264.

It'd probably take something like Wireshark to figure out what is being used in other cases. In the adaptive streaming world, there can be dozens of encoded variants of a given title, in different frame sizes, bitrates, DRM, and codecs.

As a wild personal guess, I'd expect a lot more premium content is delivered in HEVC than in VP9+AV1. The On2 stuff has always been most focused on browser-based user generated content without DRM, and there aren't any AV1 HW DRM + decode products in the market, or even announced.

As for quality versus speed, At the same encoding speed, x265 beats x264 in the cases I've tested in the last couple of years. Sure, it doesn't take full advantage of what HEVC can do, but it's still better for most content (there are likely edge cases with a lot of grain). The fastest possible x264 will be faster than the fastest possible x265, of course. x265 and HEVC in general takes better advantage of AVX, multithreading, and 64-bit than x264, so the newer the processor, the better quality @ perf HEVC has.

[sonnati]

There are tons of devices where HEVC is the only supported 10-bit codec. I'd expect pretty much all streaming of 4K or HDR content to those devices to be in HEVC. I don't know of anyone doing HDR or >1080p in H.264.

It'd probably take something like Wireshark to figure out what is being used in other cases. In the adaptive streaming world, there can be dozens of encoded variants of a given title, in different frame sizes, bitrates, DRM, and codecs.

As a wild personal guess, I'd expect a lot more premium content is delivered in HEVC than in VP9+AV1. The On2 stuff has always been most focused on browser-based user generated content without DRM, and there aren't any AV1 HW DRM + decode products in the market, or even announced.

As for quality versus speed, At the same encoding speed, x265 beats x264 in the cases I've tested in the last couple of years. Sure, it doesn't take full advantage of what HEVC can do, but it's still better for most content (there are likely edge cases with a lot of grain). The fastest possible x264 will be faster than the fastest possible x265, of course. x265 and HEVC in general takes better advantage of AVX, multithreading, and 64-bit than x264, so the newer the processor, the better quality @ perf HEVC has.

I would be no surprised if Netflix delivered H.265 to connectedTV even when content is below 4K. This would increase the market share of H.265 considerably because vast majority of Netflix's traffic is on TV and a wide % of those TV has H.265 decoding capabilities. Add to this the 100s millions of iOS devices supporting H.265 (with possible use by Netflix) and the real share should be higher than what can be derived classically from the share seen by cloud encoders vendors or similar.

[Barough]

x265 v3.2+7-37648fca915b (https://www.mediafire.com/file/l9y4j41a6uin5dk/x265-3.2+7-37648fca915b_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[stax76]

x265 v3.2+7-37648fca915b (https://www.mediafire.com/file/l9y4j41a6uin5dk/x265-3.2+7-37648fca915b_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

Thanks for the build. Why is it that large? 20 MB is too much for staxrip as it consumes 550 MB disk space and 200 MB download space, build by Patman is 2 MB.

[Barough]

Thanks for the build. Why is it that large? 20 MB is too much for staxrip as it consumes 550 MB disk space and 200 MB download space, build by Patman is 2 MB.I guess that Patman use some kind of compression on his EXE.

Skickat från min SM-G975F via Tapatalk

[Atak_Snajpera]

Thanks for the build. Why is it that large? 20 MB is too much for staxrip as it consumes 550 MB disk space and 200 MB download space, build by Patman is 2 MB.

UPX is your friend.
https://upx.github.io/

[stax76]

UPX is your friend.
https://upx.github.io/

I'll use that if it's easy enough, thanks.

[Atak_Snajpera]

I'll use that if it's easy enough, thanks.

Basically drag and drop ;)

[stax76]

That's easy. I use context menu.

https://github.com/stax76/OpenWithPlusPlus

[LigH]

^ Nice extension.

[brumsky]

I was wondering where does HME currently stand? Use it, don't use?

Is it good for anime or film?

I experimented with it a bit a few months ago when it came out. It seems to take longer and I can't really tell a differences in quality. At best I was able to get a file 2.2% smaller but it was around a 50% increase in encoding time.

[stax76]

My newest GUI is for MediaInfo which supports now a presentation for encoder parameters, maybe it's useful for somebody here.

https://forum.doom9.org/showthread.php?t=176886

https://i.postimg.cc/0Q3RNTMD/image.png

[microchip8]

I was wondering where does HME currently stand? Use it, don't use?

Is it good for anime or film?

I experimented with it a bit a few months ago when it came out. It seems to take longer and I can't really tell a differences in quality. At best I was able to get a file 2.2% smaller but it was around a 50% increase in encoding time.

HME shows good benefits at high resolutions. For FHD and lower, the benefit is much smaller and as you say, it has a performance hit. I only use it for anything higher that FHD resolution

[brumsky]

HME shows good benefits at high resolutions. For FHD and lower, the benefit is much smaller and as you say, it has a performance hit. I only use it for anything higher that FHD resolution

Well that's good to know! haha I've been mostly doing UHD encodes. My tests are normally done with 1080p content though... Hmmm I'll have to find a good 4K test clip.

What settings do you typically use for HME and UHD? What has your experience been with HME?

[microchip8]

Well that's good to know! haha I've been mostly doing UHD encodes. My tests are normally done with 1080p content though... Hmmm I'll have to find a good 4K test clip.

What settings do you typically use for HME and UHD? What has your experience been with HME?

For 4k I use hme=1 and hme-search=umh,umh,star. This gives pretty good quality without sacrificing performance too much. It still has a performance hit but is faster (at least here on my Core i7 7700K) than any other combinations I did excluding hex (so all possible combinations of umh and star)

[brumsky]

For 4k I use hme=1 and hme-search=umh,umh,star. This gives pretty good quality without sacrificing performance too much. It still has a performance hit but is faster (at least here on my Core i7 7700K) than any other combinations I did excluding hex (so all possible combinations of umh and star)

Do you see an improvement in quality or a reduction in file size? How much of a performance hit have you seen?

[_kermit]

My newest GUI is for MediaInfo which supports now a presentation for encoder parameters, maybe it's useful for somebody here.

https://forum.doom9.org/showthread.php?t=176886

https://i.postimg.cc/0Q3RNTMD/image.png

Thank you!

[microchip8]

Do you see an improvement in quality or a reduction in file size? How much of a performance hit have you seen?

Quality improvement is difficult to spot in moving frames. You have to look at stills to notice it and you won't always notice it. I was able to spot it in some stills but not in moving frames.

File size reduction here is about a few %. Performance hit is the same as for FHD here. The best compromise between speed and quality seems to be hme-search=umh,umh,star. Excluding hex/dia, other combinations don't bring noticable difference in quality while have slightly bigger performance hit.

[Blue_MiSfit]

My newest GUI is for MediaInfo which supports now a presentation for encoder parameters, maybe it's useful for somebody here.

https://forum.doom9.org/showthread.php?t=176886

https://i.postimg.cc/0Q3RNTMD/image.png

VERY nice!!

[stax76]

Next release will have it sorted alphabetically.


Rate Control
aq-mode=1 / no-aq-motion / aq-strength=1.00
bitrate=4200 / cbqpoffs=0 / no-const-vbv
crqpoffs=0 / cutree / ipratio=1.40 / no-lossless
nr-inter=0 / nr-intra=0 / pbratio=1.30
qcomp=0.60 / qg-size=32 / qpmax=69 / qpmin=0
qpstep=4 / rc=abr / no-rc-grain / no-strict-cbr
zone-count=0

Analysis
amp / analysis-reuse-level=5 / b-intra
ctu=64 / no-cu-lossless / dynamic-rd=0.00
no-dynamic-refine / no-early-skip / no-fast-intra
no-hevc-aq / limit-modes / limit-refs=2
limit-tu=4 / max-tu-size=32 / min-cu-size=8
psy-rdoq=0.00 / qp-adaptation-range=1.00
rd=3 / rdoq-level=2 / rdpenalty=0 / no-rd-refine
rect / refine-ctu-distortion=0 / refine-inter=0
refine-intra=0 / refine-mv=0 / rskip / scale-factor=0
no-splitrd-skip / no-ssim-rd / no-tskip
no-tskip-fast / tu-inter-depth=2 / tu-intra-depth=2

Slice Decision
b-adapt=2 / bframe-bias=0 / bframes=4 / b-pyramid
ctu-info=0 / gop-lookahead=0 / no-intra-refresh
keyint=100 / lookahead-slices=4 / min-keyint=100
no-open-gop / radl=0 / rc-lookahead=30
ref=4 / refine-analysis-type=0 / scenecut=0
scenecut-bias=0.05

Motion Search
no-analyze-src-pics / max-merge=3 / me=3
merange=57 / subme=3 / temporal-mvp / no-weightb
weightp

Loop Filter
deblock=0:0 / no-limit-sao / sao / no-sao-non-deblock

VUI
chromaloc=0 / colormatrix=9 / colorprim=9
no-dhdr10-opt / display-window=0 / no-hdr
no-hdr-opt / max-cll=0,0 / max-luma=1023
min-luma=0 / overscan=0 / range=0 / sar=1
transfer=18 / videoformat=5

Bitstream
annexb / no-aud / hash=0 / no-hrd / no-idr-recovery-sei
info / log2-max-poc-lsb=8 / no-multi-pass-opt-rps
no-opt-cu-delta-qp / no-opt-qp-pps / no-opt-ref-list-length-pps
no-repeat-headers / no-single-sei / no-temporal-layers
vui-hrd-info / vui-timing-info

Input/Output
input-csp=1 / input-res=3840x2160 / interlace=0
total-frames=0

Performance
copy-pic=1 / frame-threads=1 / no-pme / no-pmode
slices=1 / wpp

Statistic
log-level=2 / no-psnr / no-ssim / stats-read=0
stats-write=0

Other
cpuid=1111039 / high-tier=1 / level-idc=0
max-ausize-factor=1.0 / no-allow-non-conformance
no-constrained-intra / no-lowpass-dct / no-splice
psy-rd=2.00 / signhide / strong-intra-smoothing
uhd-bd=0


probably also easy to built would be columns like so:


Rate Control
aq-mode=1 no-aq-motion aq-strength=1.00
bitrate=4200 cbqpoffs=0 no-const-vbv
crqpoffs=0 cutree ipratio=1.40
no-lossless nr-inter=0 nr-intra=0
pbratio=1.30 qcomp=0.60 qg-size=32
qpmax=69 qpmin=0 qpstep=4
rc=abr no-rc-grain no-strict-cbr
zone-count=0

[aymanalz]

Is enabling --rect worth the increased encoding time? Does it give enough quality improvement? It slows down my encode by 41%. :(

My settings are approximately the same as the "slow" preset, except that I use CTU 32 instead of 64, and merange of 26. (2 pass encode, 1080p.)

Should I change parameters other than rect, to gain more quality per bit? Or does rect bring enough quality improvement to justify the 41% increase in encode time?

[Boulder]

I find it usable at least in frame-by-frame checks. Make sure you have --limit-refs 3 and --limit-modes set to gain some performance back, but I think 'slow' already uses them.

[filler56789]

.EXE 3.2+9-971180b is ready.

http://msystem.waw.pl/x265/

[aymanalz]

I find it usable at least in frame-by-frame checks. Make sure you have --limit-refs 3 and --limit-modes set to gain some performance back, but I think 'slow' already uses them.

I have set limits-refs 3 and limit modes, and yet I get a 41% increase in encode time.

Of all the settings in the "slow" preset, this is the one that causes the biggest speed hit for me. That's why I'm wondering if it is really worth it.

[redbtn]

I'd like to know lowering --cbqpoffs -3 and --crqpoffs -3 makes x265 spend more bits to chroma taking them from luma, or it just lowers QP for chroma but don't touch luma?




Of all the settings in the "slow" preset, this is the one that causes the biggest speed hit for me. That's why I'm wondering if it is really worth it.
I decided that it's not worth it, at least for me. My target bitrate 17-18mb for FHD. Maybe at lower bitrate it gives more quality, I don't know.

[microchip8]

I have set limits-refs 3 and limit modes, and yet I get a 41% increase in encode time.

Of all the settings in the "slow" preset, this is the one that causes the biggest speed hit for me. That's why I'm wondering if it is really worth it.

Not worth it. You won't notice a difference in moving frames, only still ones and not always

if you want to squeeze out a bit more quality and lower file size by a % or few, better use --hme=1 --hme-search=umh,umh,star

[Blue_MiSfit]

I decided that it's not worth it, at least for me. My target bitrate 17-18mb for FHD. Maybe at lower bitrate it gives more quality, I don't know.

At those rates you may very well get better results with AVC, to be honest.

[aymanalz]

Not worth it. You won't notice a difference in moving frames, only still ones and not always

if you want to squeeze out a bit more quality and lower file size by a % or few, better use --hme=1 --hme-search=umh,umh,star

Thanks. Ironically, I started off by using and tweaking your own settings posted in this thread, in which you had enabled rect. :D

Is --hme=1 beneficial for 1080p? I am targeting around 5-6 mbps.

[Boulder]

At those rates you may very well get better results with AVC, to be honest.

That's true. For a regular, non-grainy source, over 10 Mbps at 1080p is already quite a lot. My 720p encodes with rather sharp downsizing and very light denoising, I usually get bitrates around 3-7 Mbps at CRF 18. Some episodes of Dark Matter have been below 2 Mbps :D

[aymanalz]

Not worth it. You won't notice a difference in moving frames, only still ones and not always

if you want to squeeze out a bit more quality and lower file size by a % or few, better use --hme=1 --hme-search=umh,umh,star

I just did that, and found that the resulting speed decrease is almost exactly the same as having --rect enabled. ie, using rect or using --hme umh,umh,star causes exactly the same amount of fps loss.

So if --hme gives better quality improvement than --rect, the takeaway should be to use hme and eschew rect, for squeezing out more quality for bitrate. I question whether the "slow" preset should have --rect enabled by default.

I notice that with --hme enabled, the second pass is much faster than the first. I wonder why that is.

[microchip8]

Thanks. Ironically, I started off by using and tweaking your own settings posted in this thread, in which you had enabled rect. :D

Is --hme=1 beneficial for 1080p? I am targeting around 5-6 mbps.

I had it enabled as I was testing a few things :sly:

In my encoding, I no longer use it as it's slow here too. --hme seems to run faster here, at least for me on a Core i7 7700K on Linux

HME is a bit beneficial for 1080p. But it really shows its strength for 2160p and higher

[Boulder]

In this case, VMAF could be useful in determining if it's worth it or not. Just need to make sure that the compared streams are decoded frame accurately so I would probably encode a sample clip, mux to mkv and index and decode with DGDecNV tools.

[benwaggoner]

I'd like to know lowering --cbqpoffs -3 and --crqpoffs -3 makes x265 spend more bits to chroma taking them from luma, or it just lowers QP for chroma but don't touch luma?
If limited by --bitrate or VBV, luma QP will go up to compensate for the bits spent by lower QP chroma.

If doing CRF, it'll just make the file larger.

In general, those values will reduce compression efficiency of most content in most scenarios.

[nghiabeo20]

Is there any option to limit CPU usage of x265 (used via ffmpeg)? I have time & patience, and I just want to limit x265 to 2 cores 4 threads, because I can't do anything when it consumes all 4 cores I have.

[Boulder]

Is there any option to limit CPU usage of x265 (used via ffmpeg)? I have time & patience, and I just want to limit x265 to 2 cores 4 threads, because I can't do anything when it consumes all 4 cores I have.

You could try --frame-threads 1 to limit encoding to one frame at a time.

If your only problem is that your computer becomes unusable, run the process at a lower priority. You can do that in command prompt by using "start /belownormal ...your encoder stuff here..."

[nghiabeo20]

You could try --frame-threads 1 to limit encoding to one frame at a time.

If your only problem is that your computer becomes unusable, run the process at a lower priority. You can do that in command prompt by using "start /belownormal ...your encoder stuff here..."

I use pools=4, and it does use only 4 threads of my 4C8T. Does it affect anything? I thought --frame-threads would severvely affect the performance.

Furthermore, I use htop to see CPU utilization. This is my third run, and the exact same 4 threads are used. Does it imply that ffmpeg only runs on those same 2 cores (or 4 cores) over and over? I know next to nothing about CPU architecture & organization, but if it implies so, does it have a long term effect on those cores? I thought that the OS should shuffle the workload among cores (between run), still I want to confirm.

[Atak_Snajpera]

I use pools=4, and it does use only 4 threads of my 4C8T. Does it affect anything? I thought --frame-threads would severvely affect the performance.

Why don't you try runing x265 in idle priority? What you do is not optimal.

[Boulder]

I thought that the OS should shuffle the workload among cores (between run), still I want to confirm.

The OS scheduler does do that, unless you set the process to use only specific cores (=CPU affinity). But as I and Atak_Snajpera said, set the process priority lower (idle or just below normal) and let the encoder use whatever resources are available to it after other processes.

[birdie]

Is there any option to limit CPU usage of x265 (used via ffmpeg)? I have time & patience, and I just want to limit x265 to 2 cores 4 threads, because I can't do anything when it consumes all 4 cores I have.

Windows: https://blogs.msdn.microsoft.com/santhoshonline/2011/11/24/how-to-launch-a-process-with-cpu-affinity-set/

Linux: man taskset

OS X: You're f*cked.

[redbtn]

If I want to get the same bitrate, which option is better for quality?
1) --no-cutree with higher CRF
2) --cutree with lower CRF

[nghiabeo20]

The OS scheduler does do that, unless you set the process to use only specific cores (=CPU affinity). But as I and Atak_Snajpera said, set the process priority lower (idle or just below normal) and let the encoder use whatever resources are available to it after other processes.

Why don't you try runing x265 in idle priority? What you do is not optimal.

It's a laptop, so I still don't want 90+% usage for an extended period of time. I'm saving money for a Ryzen rig anyway.

Windows: https://blogs.msdn.microsoft.com/santhoshonline/2011/11/24/how-to-launch-a-process-with-cpu-affinity-set/

Linux: man taskset

OS X: You're f*cked.

:p Yes i'm a fucked TM user here.

[Forteen88]

You could try --frame-threads 1 to limit encoding to one frame at a time.Yeah, I'd do this if I were the person you answered to, since this also increases the picture-quality of the encode.

[redbtn]

At those rates you may very well get better results with AVC, to be honest.I've done tests, 1080p with bitrate 22mb, x264 10bit (placebo, subme 11, bframes 8, etc) and x265 10bit (slow, no-rect, subme 4, bframes 8 and some other tweaks). In the end I get almost the same encoding speed. And x265 looks much better. I don't know why many people say that at high bitrate x264 beats x265.

[Atak_Snajpera]

I've done tests, 1080p with bitrate 22mb, x264 10bit (placebo, subme 11, bframes 8, etc) and x265 10bit (slow, no-rect, subme 4, bframes 8 and some other tweaks). In the end I get almost the same encoding speed. And x265 looks much better. I don't know why many people say that at high bitrate x264 beats x265.

BS. 22 Mbps is insanelly high for 1080p. That's basicaly a blu-ray teoritory. You are lieing saying that x265 looks MUCH BETTER.

[redbtn]

BS. 22 Mbps is insanelly high for 1080p. That's basicaly a blu-ray teoritory. You are lieing saying that x265 looks MUCH BETTER.

I know that 22 is very high for 1080p, I did it specially for test. After encode I upscaled FHD to UHD and compared them. I don't say that x265 MUCH better, but it significantly better at preserving small details. And I can definitely say it's not worse anyway.

[Blue_MiSfit]

It's definitely not impossible that x265 would produce better results than x264 at 22 Mbps for 1080p. I think it's fair to say that for MOST content the difference would be quite negligible, especially at the same encoding speed. Even if you can get a small improvement when encoding several times slower, is it really worth it?

In many use cases, probably not. But for some? Absolutely.

[redbtn]

It's definitely not impossible that x265 would produce better results than x264 at 22 Mbps for 1080p. I think it's fair to say that for MOST content the difference would be quite negligible, especially at the same encoding speed. Even if you can get a small improvement when encoding several times slower, is it really worth it?

In many use cases, probably not. But for some? Absolutely.Yes, you are right, it absolutely impossible notice the difference at 22mb between x264 and x265 just by watching video. Like I said, I upscaled screens to 4K for noticing difference.
But IMO, if x265 better at low bitrates and better at high bitrates, I don't see why I should use x264 at any cases.

[Magik Mark]

I'm getting this warning. I'm trying to test the new frame duplication switch:

x265 [warning]: Frame-duplication require NAL HRD and VBV parameters. Disabling frame duplication

How do I address this?

[microchip8]

I'm getting this warning. I'm trying to test the new frame duplication switch:

x265 [warning]: Frame-duplication require NAL HRD and VBV parameters. Disabling frame duplication

How do I address this?

--hrd --vbv-maxrate <value> --vbv-bufsize <value>

[Magik Mark]

--hrd --vbv-maxrate <value> --vbv-bufsize <value>

What value shall I use?

[microchip8]

What value shall I use?

This depends. maxrate sets a specific maximum bitrate ceiling while buffer size sets a buffer, which usually should be higher than maxrate

[Majorlag]

What value shall I use?

For the values, you can use anything you want, but I would recommend using values to meet a certain Tier and Level so you can get Hardware accelerated decoding. You can see those at https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding, under Tiers and levels section.

I usually set bufsize and maxrate as the same. I cannot find anywhere that shows how high bufsize can be set to to maintain DXVA hardware decoding, so I use the following for all my encodes for x265.

480p:--vbv-bufsize 12000 --vbv-maxrate 12000
1080p:--vbv-bufsize 20000 --vbv-maxrate 20000
2160p:--vbv-bufsize 25000 --vbv-maxrate 25000

These have all resulted in DXVA compatible files.

[aymanalz]

With my settings above and HME turned on, I can shave ~100 MiB of an encode. Encoded Blade Runner once with and once without HME. The result was 100 MiB in size reduction with better subjective quality when HME is on

What was the total filesize, from which you shaved off 100 Mb? I mean, what was the percentage reduction in bitrate? Also, what was the video resolution?

I'm trying to figure out if HME is worthwhile for me, given that the encoding is significantly slower.

[jlpsvk]

For the values, you can use anything you want, but I would recommend using values to meet a certain Tier and Level so you can get Hardware accelerated decoding. You can see those at https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding, under Tiers and levels section.

I usually set bufsize and maxrate as the same. I cannot find anywhere that shows how high bufsize can be set to to maintain DXVA hardware decoding, so I use the following for all my encodes for x265.

480p:--vbv-bufsize 12000 --vbv-maxrate 12000
1080p:--vbv-bufsize 20000 --vbv-maxrate 20000
2160p:--vbv-bufsize 25000 --vbv-maxrate 25000

These have all resulted in DXVA compatible files.

encoding 2160p with 25000??? Level 5.1 @ High10 allows 160000 for vbv

[excellentswordfight]

encoding 2160p with 25000??? Level 5.1 @ High10 allows 160000 for vbv
And main teir is 40000.

If the only concern is level compatibility then I usually just set --level in the command line and x265 will automatically set the vbv and limit max ref frames etc to be compliant. But afaik some decoders will not handle such big bufsize even though they specification says that it supports a specific level, so there is viability to set custom (lower) values to ensure playback on an targeted device. But all my hevc level 5.1 devices have had no playback issues with encodes using the values in high teir though.

[microchip8]

What was the total filesize, from which you shaved off 100 Mb? I mean, what was the percentage reduction in bitrate? Also, what was the video resolution?

I'm trying to figure out if HME is worthwhile for me, given that the encoding is significantly slower.

Resolution was 1080p and file size with HME on was 3.7 GiB while with HME off was a bit over 3.8 GiB. Slowdown, IIRC, was about 5-6%

In the end, I recommend doing your own tests and see if it's worthy :)

[Majorlag]

encoding 2160p with 25000??? Level 5.1 @ High10 allows 160000 for vbv

I guess I could expand my reasoning as for why I would use those settings, since I do only encodes of 29.97fps video, then according to the graph I only need level 5.0, (4,096x2,160@30.0). I could set 5.1 spec, which allows up to 60fps, I don't encode 60fps, but I always use 10bit. I also use the 4k Ultra Blu-ray specifications at http://www.blu-raydisc.com/assets/Downloadablefile/BD-ROM_Part3_V3.0_WhitePaper_150724.pdf which says Main10 (which I understand to be Main10bit) or High (which I understand to be High8bit) or 5.1 Level max settings.

So I try to make sure I am as compatible with all my encodes as I can possible be. I hope I read the specs correctly.

[benwaggoner]

And main teir is 40000.

If the only concern is level compatibility then I usually just set --level in the command line and x265 will automatically set the vbv and limit max ref frames etc to be compliant. But afaik some decoders will not handle such big bufsize even though they specification says that it supports a specific level, so there is viability to set custom (lower) values to ensure playback on an targeted device. But all my hevc level 5.1 devices have had no playback issues with encodes using the values in high teir though.
Lots of real-world devices support > main tier but not all of high tier. UHD Blu-ray supports 80 Mbps Level 5.1, for example. For typical long-GOP distribution encoding, the Main Tier limits are fine for transparent quality with most sources.

[excellentswordfight]

Lots of real-world devices support > main tier but not all of high tier. UHD Blu-ray supports 80 Mbps Level 5.1, for example. For typical long-GOP distribution encoding, the Main Tier limits are fine for transparent quality with most sources.

Table 2-3–Specification of BD-ROM Primary video streams: Primary VideoCodec: HEVC (Main 10, High Tier,Level 5.1) Max. bitrate 100Mbps

http://www.blu-raydisc.com/assets/Downloadablefile/BD-ROM_Part3_V3.0_WhitePaper_150724.pdf

The different disctypes will then have different maximum ts bitrates though, I guess that the discs that allow for 81.7 Mbps are the most common.

But when it comes to bufsize, is it common that that devices has a smaller buffer then the allowed maxrate for the supported level? If I remember it correctly HD blurays specified a smaller one (30 vs 40Mbps), and the same was true for PS3 and xbox360 compliant encodings.

If I read the whitepaper correctly, it looks like this is the bufsize specificaiton for UHD-Bluray for the HEVC stream:

"DPB1 Decoded picture buffer for HEVC stream: 93312000 [bytes]"

[cap5lock]

Other than using external film grain filter,
Is there any x265 parameters to ignore bluray film grain/noise to further reduce size ?

[RanmaCanada]

Other than using external film grain filter,
Is there any x265 parameters to ignore bluray film grain/noise to further reduce size ?
Anything with high grain should only be encoded in x264 (or just remuxed) as x265 still can not handle it anywhere near as well. I believe the last time someone tested it, they were doing the original Alien, and the re-encode came out larger than the source.

Unless it's magically gotten better since then.

[Blue_MiSfit]

Depends on the intended use case. If you're going for total transparency you might have a harder time. If you're trying to get down to 10-15 Mbps for 1080p you'll probably get good results with the grain tuning and some nice slow settings, but it might be hard to get a reduction if you're coming from a BluRay source.

Getting down to a lower bitrate without blowing up and maintaining some of the grain texture is usually possible, but always difficult. Grain is hard no matter what.

I'm hoping the film grain synthesis tools in AV1 get explored soon - I've always thought this was a great idea.

I also wonder if the new MPEG-5 LC-EVC / enhancement layer systems could be used to encode a cleaner version of the video and then grain synthesis information as an enhancement layer / noise model, kind of like V-Nova Perseus but tuned for grain.

[Zebulon84]

I'm hoping the film grain synthesis tools in AV1 get explored soon - I've always thought this was a great idea.
It seams Netflix is working on an AV1 film grain synthesis : AOMedia 2019 Research Symposium - 04 : Netflix (https://youtu.be/M1vwnI0vbMI?t=147).

[excellentswordfight]

Anything with high grain should only be encoded in x264 (or just remuxed) as x265 still can not handle it anywhere near as well. I believe the last time someone tested it, they were doing the original Alien, and the re-encode came out larger than the source.

Unless it's magically gotten better since then.
Its gotten alot better then the early days. In my experience x265 have no issue with grain and fine detail, and is imo better then x264 at ”normal” levels (crf18 ~6-9Mpbs if we are discussing 1080p SDR). The issue is that it needs at least preset slow (combined with no-sao and some deblock), and that makes it much slower then x264. I have yet seen x265 be tuned at then same speed as x264 (slower/veryslow with tune film) with better detail retention.

With that said, is x264 better for 1080p sdr to achive near lossless quality at high bitrates? Sure, especialiy if speed also is concidered. But that is not the focus for x265 or most hevc encoders.

[K.i.N.G]

It seams Netflix is working on an AV1 film grain synthesis : AOMedia 2019 Research Symposium - 04 : Netflix (https://youtu.be/M1vwnI0vbMI?t=147).

The danger of that is that many people/companies will use that as an excuse to apply exagerated loss of detail information and 'mask' it with some added synthetic film grain applied to give the false illusion of detail retention (while the information that 'makes sense' is gone). If you know what i mean...
Lets hope they use a good implementation that prevents this as good as possible.

[Fishman0919]

Odd there are no x265 3.2.1 builds around...

[redbtn]

Odd there are no x265 3.2.1 builds around...Yeah, it was released a few days ago but there is no build anywhere.

[agressiv]

Is there any guide to compiling x265 on Windows with an LAVF/Smash patch?

I grabbed the Yuuki source and threw it into my cross-compile script, but get a ton of errors lavf.cpp on and I'm not knowledgeable enough to troubleshoot. I had to hack apart the script as it was to not overwrite the Yuuki version with the current mercurial branch.

One of 50+ errors:
/home/agressiv/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x11): undefined reference to `avcodec_free_context'

[agressiv]

Yeah, it was released a few days ago but there is no build anywhere.

https://mega.nz/#!vBgRzKbD!SoaO5Lgh9hvtltX4Fgdsp8P3GePNMDVyCiVv9IemkT0

Here's one I compiled - 3.2.1, x64 bit MSVC compiled with 8/10/12 bit support.

[MeteorRain]

Is there any guide to compiling x265 on Windows with an LAVF/Smash patch?

I grabbed the Yuuki source and threw it into my cross-compile script, but get a ton of errors lavf.cpp on and I'm not knowledgeable enough to troubleshoot. I had to hack apart the script as it was to not overwrite the Yuuki version with the current mercurial branch.

One of 50+ errors:
/home/agressiv/ffmpeg-windows-build-helpers/sandbox/cross_compilers/mingw-w64-x86_64/lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x11): undefined reference to `avcodec_free_context'

cmake -DENABLE_LSMASH=ON -DENABLE_LAVF=ON -DENABLE_STATIC_LAVF=ON path/

You'll need windows gcc compiled ffmpeg being installed in your x86_64 include & lib.

I have full rakefile to compile Yuuki and Asuna binaries.

[redbtn]

Thank you HolyWu
Can I find somewhere information how to build x265 with gcc or clang? I tried google it, but I fail.

[agressiv]

Yes, thanks HolyWu for the lavf-enabled new build! Any chance you can upload a non-upx packed EXE? Or maybe even your source and compile script?

[fauxreaper]

HME is nondeterministic? Using --hme hex, I got slightly different file sizes on multiple encodes with same input file and x265 config.

[microchip8]

HME is nondeterministic? Using --hme hex, I got slightly different file sizes on multiple encodes with same input file and x265 config.

--hme does not accept any parameters
--hme-search does (where you set the motion estimation algo, such as hex)

[nghiabeo20]

I encode my clip in 5 parts, using -ss and -t to seek to cut position. Now mkvmerge refuses to merge the file, warning that "codec private data doesn't match". After checking the encoding settings, I found that only the --numa-pool change in the first 2 file. How can I edit SPS/PPS data to fool mkvmerge into merging my files? Thanks!

[MeteorRain]

If you don't mind, join files using MP4Box on MP4s.

Other option is to strip the SEI/VPS/SPS/PPS data for part 2-5 and simply join the raw bitstream. (Stripping is optional.)

If you really want to join using mkvmerge, try using a binary editor to change the text inside SEI, however to be honest I don't think that text should make a difference.

[stax76]

Is the estimated file size feature an official feature or a patch? It gets requested frequently, somebody needs to make an official feature request.

[sneaker_ger]

Now mkvmerge refuses to merge the file, warning that "codec private data doesn't match".
I don't think mkvmerge actually refuses to append the files. It is merely displaying a warning message, saying "there may (or may not) be problems".

[foxyshadis]

The danger of that is that many people/companies will use that as an excuse to apply exagerated loss of detail information and 'mask' it with some added synthetic film grain applied to give the false illusion of detail retention (while the information that 'makes sense' is gone). If you know what i mean...
Lets hope they use a good implementation that prevents this as good as possible.

How is that any different from physical film grain on actual film stock? That x264 and x265 completely neglected it because it was hard to test doesn't mean a little noise generation isn't valuable.

[Barough]

x265 v3.2+15-04db2bfee5d6 (https://www.mediafire.com/file/ym8fls6a3dgnfgf/x265-3.2+15-04db2bfee5d6_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[Forteen88]

x265 v3.2+15-04db2bfee5d6 (https://www.mediafire.com/file/ym8fls6a3dgnfgf/x265-3.2+15-04db2bfee5d6_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)Is this version newer than x265-3.2.1+1?

[Barough]

Yes it is, this is compiled from the default branch and not the stable one.

Skickat från min SM-G975F via Tapatalk

[benwaggoner]

How is that any different from physical film grain on actual film stock? That x264 and x265 completely neglected it because it was hard to test doesn't mean a little noise generation isn't valuable.
The grain generation is often done in wrong ways that make it much harder to encode than real world grain. I especially see this in 4K and HDR, where grain gets rendered at the pixel level with SDR code values and so comes out way too bright and too fine-grained. I've seen synthetic film grain that made content impossible to encode at even vaguely acceptable quality at 40 Mbps.

We're also seeing silly amounts of film grain in restored rescans of movies. It isn't creative intent to preserve all kinds of noise that wouldn't have been visible on the perf screens and foot lamberts that the creatives actually approved the content on.

[Blue_MiSfit]

I hear you on the remastering, Ben.

Home Alone is an astounding example of this.

[benwaggoner]

I encode my clip in 5 parts, using -ss and -t to seek to cut position. Now mkvmerge refuses to merge the file, warning that "codec private data doesn't match". After checking the encoding settings, I found that only the --numa-pool change in the first 2 file. How can I edit SPS/PPS data to fool mkvmerge into merging my files? Thanks!
Also maybe try --hrd-concat if you are using HRD?

[Stereodude]

Watch the 4k77 UHD release of Star Wars if you want to see overdone grain. MCTD is calling its name when I build my new Zen 2 system in the next month or two.

[markiemarcus]

I hear you on the remastering, Ben.

Home Alone is an astounding example of this.

Something definitely looked off with Home Alone. The pitch of the grain was both far too fine and too bright; it didn't gel at all with the image.

I must say though, I like the way the UHD release of Predator looks and it's pretty damn grainy. It looks right to me. Was shaky film stock from the outset IIRC.

[RanmaCanada]

The original Predator, in my view, is the PERFECT example of what a transfer and remaster should look like. I'm old enough to have seen it in the cinema, and watching that 4k copy was everything I remembered. And we all know how we view the past with rose coloured glasses.

[LigH]

Film grain ... I witnessed an attempt to preserve a sensible amount of it while trying to remove the majority that only distracts the MPEG-2 encoder of a "Kinowelt" DVD production. Source: Die Feuerzangenbowle (1944) (https://www.imdb.com/title/tt0036818/) – too much denoising, and the trees on the schoolyard look like forged of concrete.

[markiemarcus]

The original Predator, in my view, is the PERFECT example of what a transfer and remaster should look like. I'm old enough to have seen it in the cinema, and watching that 4k copy was everything I remembered. And we all know how we view the past with rose coloured glasses.

Was quite a treat to watch it again I must say. I wonder what the difference in process was, because it obviously wasn't an easy source to work with.

It's a nice encode too. I've noticed that a number of grainy UHD Blu-rays have issues from time-to-time in that regard. There are a handful of scenes in both Blade Runner and The Fog that completely fall apart. Seems inexcusable given how much space there is to play with. In the case of The Fog, the bit rate actually plummets in the affected scenes.

[benwaggoner]

Was quite a treat to watch it again I must say. I wonder what the difference in process was, because it obviously wasn't an easy source to work with.

It's a nice encode too. I've noticed that a number of grainy UHD Blu-rays have issues from time-to-time in that regard. There are a handful of scenes in both Blade Runner and The Fog that completely fall apart. Seems inexcusable given how much space there is to play with. In the case of The Fog, the bit rate actually plummets in the affected scenes.
Grain is essentially uncompressible random noise. It's random spatially and temporally, includes chroma, and is typically very high frequency. So it can use the vast majority of bits encoding a frame, is sensitive to QP differences between I, P, B, and b frames, and is otherwise a worst-case nightmare.

While encoding 4K content might take only 2x the bitrate as 1080p, doing grain is much more linear. 80 Mbps 4K is only twice that of Blu-ray 1080p. There are cases of grain that is quite literally impossible to encode without perceptible artifacts. Heck, just encoding a flat gray slide with JUST grain on it can be very challenging.

And that grain, even in lossless, can be quite distracting to a viewer. There's certainly way more fine detail grain on the Blade Runner Blu-ray than Ridley Scott ever saw when he was working on it, due to perf screens, dimmer projectors, etcetera. And in HDR, it's also way brighter grain than would have been seen before. One risk with SMPTE 2100 HDR is that any filters that assume gamma instead of linear light will do weird high contrast things in high luma, since the code values have much bigger jumps in luma than 709 gamma had. Conversely, low luma might not get enough filtering if processed assuming 709.

[jlpsvk]

i have a strange problem backuping my Hobbs and Shaw UHD... It has HDR10+ and when i extract HDR10+ metadata (tried all version of hdr10plus_parser, extracting from raw HEVC stream) and use it for encode mediainfo is like this...

source:

Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2094 App 4, Version 1, HDR10+ Profile B compatible
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
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.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 419 cd/m2

encoded mediainfo (no info about HDR10, HDR10+) weird, json metadata file us about 139MB:

Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2094 App 4, Version 1
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 (24000/1001) FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
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.0050 cd/m2, max: 4000 cd/m2
Maximum Content Light Level : 1000 cd/m2
Maximum Frame-Average Light Level : 419 cd/m2

[mini-moose]

i have a strange problem backuping my Hobbs and Shaw UHD... It has HDR10+ and when i extract HDR10+ metadata (tried all version of hdr10plus_parser, extracting from raw HEVC stream) and use it for encode

You should read and post on the hdr10+ thread:
https://forum.doom9.org/showthread.php?t=175947&page=5

I think this happens when the hdr10+ json isn't quite right.

[markiemarcus]

Grain is essentially uncompressible random noise. It's random spatially and temporally, includes chroma, and is typically very high frequency. So it can use the vast majority of bits encoding a frame, is sensitive to QP differences between I, P, B, and b frames, and is otherwise a worst-case nightmare.

While encoding 4K content might take only 2x the bitrate as 1080p, doing grain is much more linear. 80 Mbps 4K is only twice that of Blu-ray 1080p. There are cases of grain that is quite literally impossible to encode without perceptible artifacts. Heck, just encoding a flat gray slide with JUST grain on it can be very challenging.



I hadn't really considered the HDR component, that makes sense! Grain compressibility is definitely something I've run into when playing around with x265 on very grainy animation. Assuming semi-transparency as a goal, you're lucky to see a 30-40% reduction at 1080p over x264. That's still pretty good (on the otherwise flat cells the difficulties with grain retention are more obvious). I find live action easier in that regard. You can definitely get there, it just requires some care. I've started leaning towards slightly elevated Psy-rd values (in the range of 2.5 to 3.0), but greatly reduced Psy-RDOQ values (typically below 0.5). I discovered that by accident, but reading through the documentation, it seems that RDOQ by design is less accurate.

With very grainy animated sources, it's quite apparent that RDOQ exaggerates grain coarseness even at the default value of 1.0. It serves a purpose for sure (it's great at maintaining/approximating the motion), I'm just careful with it; it can make a right mess of flat scenes if the grain is intermittent. I've had really good results with CTU 64 and QG 64 in most animated content, grainy or otherwise. I can absolutely see why CTU 64 is the default; I don't find it to cause any difficulties whatsoever with grain retention. Quite the opposite.

The curious thing with The Fog is that the bit rate falls drastically in the troublesome scenes. Seems like an authoring error.

[redbtn]

I've started leaning towards slightly elevated Psy-rd values (in the range of 2.5 to 3.0), but greatly reduced Psy-RDOQ values (typically below 0.5).
What about turning psy-rdoq off? It gives worse results than 0.5? And what values you use for grainy movies? I use psy-rd 2.0 psy-rdoq 1.2 for movies, but I'm still not sure about that, still looking for optimal values.

[markiemarcus]

What about turning psy-rdoq off? It gives worse results than 0.5? And what values you use for grainy movies? I use psy-rd 2.0 psy-rdoq 1.2 for movies, but I'm still not sure about that, still looking for optimal values.

You can reduce it to zero, yes, but you can also change RDOQ Level to 0 which produces different results again IIRC. You may not be able to capture all the grain and detail though. It depends; a lot of the time you can get away with it. This is with --no-sao --selective-sao 0 by the way. It looks nice and the grain is certainly uniform, but it doesn't have the same presence as with some RDOQ. Like I said, it serves a purpose. If the content is super grainy, you can probably get away with reducing Aq-strength quite a bit also.

You'll have to experiment; most of my testing was done on grainy animation so I don't know how that plays out on live action. On the grainiest of animated content, my values are around Psy-rd 4.0, Psy-rdoq 0.20, AQ-strength 0.7, Deblocking -4:-1, Aq mode 1, CRF 19.5. You'll also need to get your deblocking strength down to around -4 (though -3 is often sufficient). The other values are somewhere in between the slow and slower preset but with rect disabled.

Edit: If the source has extremely fine grain, more like dither, I've seen better results from disabling RDOQ entirely (Level 0) and pushing Psy-rd as high as 4.50. RDOQ just seems to make a mess; I don't know why.
Edit 2: --selective-sao 1 is generally speaking safe enough for grain retention.

[Ajvar]

Grain is essentially uncompressible random noise. It's random spatially and temporally, includes chroma, and is typically very high frequency. So it can use the vast majority of bits encoding a frame, is sensitive to QP differences between I, P, B, and b frames, and is otherwise a worst-case nightmare.

While encoding 4K content might take only 2x the bitrate as 1080p, doing grain is much more linear. 80 Mbps 4K is only twice that of Blu-ray 1080p. There are cases of grain that is quite literally impossible to encode without perceptible artifacts. Heck, just encoding a flat gray slide with JUST grain on it can be very challenging.

And that grain, even in lossless, can be quite distracting to a viewer. There's certainly way more fine detail grain on the Blade Runner Blu-ray than Ridley Scott ever saw when he was working on it, due to perf screens, dimmer projectors, etcetera.

I remember years ago when x265 was at stage of v1.6 - 1.7 people complained about default denoising of HEVC. I remember a grey wall all in terrible grain and HEVC encode then made grain disappear like it never existed and without any artificial look. People complained at x265 encoder exactly for this. Just saying.

[Selur]

What is going on here.
Using 2pass encoding:

1st pass:
i:\Hybrid\64bit\ffmpeg.exe -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf scale=out_range=pc -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | i:\Hybrid\64bit\x265.exe --preset slow --log-level 2 --input - --output-depth 10 --y4m --profile main10 --ctu 32 --no-hme --merange 26 --no-rect --max-merge 2 --tskip --no-open-gop --opt-ref-list-length-pps --bframes 5 --rc-lookahead 40 --pass 1 --slow-firstpass --bitrate 4000 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --fast-intra --psy-rd 2.20 --psy-rdoq 1.20 --splitrd-skip --deblock=-2:-2 --selective-sao 2 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --stats "E:\Temp\result_new.stats" --output "E:\Temp\result_new.265"
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\result_new.265
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(11 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : star / 26 / 3 / 2
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
x265 [info]: Lookahead / bframes / badapt : 40 / 5 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 4 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-4000 kbps / 0.60
x265 [info]: tools: limit-modes rd=4 psy-rd=2.20 rdoq=2 psy-rdoq=1.20 rskip
x265 [info]: tools: splitrd-skip tskip signhide tmvp fast-intra
x265 [info]: tools: strong-intra-smoothing deblock(tC=-2:B=-2) sao
x265 [info]: tools: selective-sao stats-write
x265 [info]: frame I: 3, Avg QP:6.61 kb/s: 6660.13
x265 [info]: frame P: 82, Avg QP:4.37 kb/s: 9294.05
x265 [info]: frame B: 344, Avg QP:8.83 kb/s: 2552.47
x265 [info]: Weighted P-Frames: Y:2.4% UV:1.2%
x265 [info]: consecutive B-frames: 4.7% 0.0% 18.8% 7.1% 1.2% 68.2%

encoded 429 frames in 11.25s (38.14 fps), 3869.80 kb/s, Avg QP:7.96
and then the second pass fails:
i:\Hybrid\64bit\ffmpeg.exe -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf scale=out_range=pc -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | i:\Hybrid\64bit\x265.exe --preset slow --log-level 2 --input - --output-depth 10 --y4m --profile main10 --ctu 32 --no-hme --merange 26 --no-rect --max-merge 2 --tskip --no-open-gop --opt-ref-list-length-pps --bframes 5 --rc-lookahead 40 --pass 2 --bitrate 4000 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --fast-intra --psy-rd 2.20 --psy-rdoq 1.20 --splitrd-skip --deblock=-2:-2 --selective-sao 2 --limit-sao --no-repeat-headers --range limited --colormatrix bt709 --stats "E:\Temp\result_new.stats" --no-dynamic-refine --refine-ctu-distortion 0 --output "E:\Output\result_new.265"
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Output\result_new.265
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-3 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(11 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [error]: different scenecut setting than first pass (40 vs 40)
x265 [error]: failed to open encoder[/code]

x265 [error]: different scenecut setting than first pass (40 vs 40)
40 isn't 40 ?!?

When using a FullHD samples the line with the warning disappears, but the error remains.

Tried multiple sample, with different characteristics, error stays the same, so this does not seem to be source related.

=> Does anyone see that I did wrong, or is this a bug?

Cu Selur

[Selur]

Seems like 2pass is broken or I'm really overlooking something.
Even using a simple settings I end up with the 'different scenecut setting than first pass (40 vs 40)'-error.
I:\Hybrid\64bit>ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | x265 --preset medium --input - --output-depth 10 --y4m --profile main10 --pass 1 --slow-firstpass --bitrate 1500 --range limited --colormatrix bt470bg --stats "E:\Temp\test_19_40_50_2910_01.stats" --output "E:\Temp\test.265"
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\test.265
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(6 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
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 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 25 / 250 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1500 kbps / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 [info]: tools: strong-intra-smoothing deblock sao stats-write
x265 [info]: frame I: 3, Avg QP:13.44 kb/s: 3999.20
x265 [info]: frame P: 119, Avg QP:10.20 kb/s: 3036.26
x265 [info]: frame B: 307, Avg QP:14.84 kb/s: 782.98
x265 [info]: Weighted P-Frames: Y:0.8% UV:0.8%
x265 [info]: consecutive B-frames: 2.5% 0.0% 58.2% 22.1% 17.2%

encoded 429 frames in 10.47s (40.97 fps), 1430.51 kb/s, Avg QP:13.54

I:\Hybrid\64bit>ffmpeg -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | x265 --preset medium --input - --output-depth 10 --y4m --profile main10 --pass 2 --bitrate 1500 --range limited --colormatrix bt470bg --stats "E:\Temp\test_19_40_50_2910_01.stats" --output "E:\Temp\19_40_50_2910_03.265"
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\19_40_50_2910_03.265
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(6 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
x265 [error]: different scenecut setting than first pass (40 vs 40)
x265 [error]: failed to open encoder

[redbtn]

Seems like 2pass is broken or I'm really overlooking something.
Even using a simple settings I end up with the 'different scenecut setting than first pass (40 vs 40)'-error.
http://forum.doom9.org/showthread.php?p=1890848
Possible the same issue.

[filler56789]

x265.exe 3.2+17-4a29e0c5bfaf

Download: http://www.mediafire.com/file/ieswxun22o58sga/x265_3.2%252B17-4a29e0c5bfaf.rar/file

FWIW...

In file included from D:/KOMPILES/MCW/x265/source/encoder/encoder.cpp:27:
D:/KOMPILES/MCW/x265/source/encoder/encoder.cpp: In member function 'void x265::Encoder::destroy()':
D:/KOMPILES/MCW/x265/source/common/common.h:222:37: warning: macro expands to multiple statements [-Wmultistatement-macros]
222 | #define X265_FREE_ZERO(ptr) x265_free(ptr); (ptr) = NULL
| ^~~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/encoder.cpp:882:12: note: in expansion of macro 'X265_FREE_ZERO'
882 | X265_FREE_ZERO(m_edgePic);
| ^~~~~~~~~~~~~~
D:/KOMPILES/MCW/x265/source/encoder/encoder.cpp:881:9: note: some parts of macro expansion are not guarded by this 'if' clause
881 | if(m_edgePic != NULL)
| ^~

:confused:

[Selur]

found an issue about 2pass crashing (https://bitbucket.org/multicoreware/x265/issues/524/2-pass-encoding-failure-with-32-15)
->
scenecut-aware-qp=0 (default) fails
scenecut-aware-qp=1 works

hopefully they will fix this soon,....

[LigH]

@filler56789: Known and about to be fixed (it's really just a question of C source formatting).

[Selur]

'scenecut-aware-qp'-bug is fixed :)

[filler56789]

x265.exe 3.2+18-f0fe46ce379d

(64-bit, multilib, GCC 9.2.0)

http://www.mediafire.com/file/bqmxz9qczu7c8sm/x265_3.2%252B18-f0fe46ce379d.rar/file

[Boulder]

Some new stuff there I see, has anyone made any tests? Once again there are no use cases available from the devs.

[filler56789]

Pooja Venkatesan committed a4e060a

2019-09-11

Add option hme-range to modify search range for HME levels L0, L1 and L2.

https://bitbucket.org/multicoreware/x265/commits/a4e060a4483913e28df2ce8b8549f3ba8b63ac5a

Download the .EXE from: http://msystem.waw.pl/x265/

[_kermit]

those are my current parameters for 1080p encoding and I'll use between CRF 18 to 22, depending on the source material

--preset slow --vbv-maxrate 20000 --deblock=-6:-6 --no-strong-intra-smoothing --amp --aq-strength 1.25 --qcomp 0.7 --no-deblock --no-sao --rskip --output-depth 10

in general I get good results but once in a while there are artifacts, particular in dark areas, looking like this:
(in this case it was CRF 22)

17045

two questions:

any suggestions on improving my parameters in general?

Is there a parameter which would improve in particular on that (besides a lower CRF value of course)?

cheers, roland

[Boulder]

--aq-mode 3 is meant to battle issues with dark areas of the frame. You may want to tune the strength down though, the bitrate will most likely shoot through the roof :)

[markiemarcus]

those are my current parameters for 1080p encoding and I'll use between CRF 18 to 22, depending on the source material

--preset slow --vbv-maxrate 20000 --deblock=-6:-6 --no-strong-intra-smoothing --amp --aq-strength 1.25 --qcomp 0.7 --no-deblock --no-sao --rskip --output-depth 10

in general I get good results but once in a while there are artifacts, particular in dark areas, looking like this:
(in this case it was CRF 22)

17045

two questions:

any suggestions on improving my parameters in general?

Is there a parameter which would improve in particular on that (besides a lower CRF value of course)?

cheers, roland

As mentioned above, I'd also look at Aq mode 3 with the default AQ strength. You may even be able to get better results (at the same file size) with around 0.85, even lower if the source is very grainy.

Additionally, I have yet to see any real detail benefit to no-strong-intra-smoothing. I'd also avoid disabling deblocking and, if grain retention is still a priority, use some light deblocking instead. I've had good results with -4: -1 and -3: -3, with the former being slightly better IMO.

--selective-sao 1 also seems to work well from my testing, subjectively better than disabling it entirely IMO.

[_kermit]

As mentioned above, I'd also look at Aq mode 3 with the default AQ strength. You may even be able to get better results (at the same file size) with around 0.85, even lower if the source is very grainy.

Additionally, I have yet to see any real detail benefit to no-strong-intra-smoothing. I'd also avoid disabling deblocking and, if grain retention is still a priority, use some light deblocking instead. I've had good results with -4: -1 and -3: -3, with the former being slightly better IMO.

--selective-sao 1 also seems to work well from my testing, subjectively better than disabling it entirely IMO.

thanks both.

I've gathered those parameters from many sources, and honestly have mostly no clue about the impact.

Something like this?

--preset slow --vbv-maxrate 20000 --deblock=-4:-1 --amp --aq-strength 0.85 --qcomp 0.7 --selective-sao 1 --rskip --output-depth 10 --Aq-mode 3

I don't care about grain. Grain is IMO just noise.
And while I understand that old material just has to have grain I don't understand why there is grain in newer material.

If grain can be reduced without having other negative effects on a movie, that would also be fine.
I don't analyze still pics, I don't see a point there. I'm not watching still pics.

would the above be a good compromise, sufficient, or is there more to fine tune?

-roland

[markiemarcus]

thanks both.

I've gathered those parameters from many sources, and honestly have mostly no clue about the impact.

Something like this?

--preset slow --vbv-maxrate 20000 --deblock=-4:-1 --amp --aq-strength 0.85 --qcomp 0.7 --selective-sao 1 --rskip --output-depth 10 --Aq-mode 3

I don't care about grain. Grain is IMO just noise.
And while I understand that old material just has to have grain I don't understand why there is grain in newer material.

If grain can be reduced without having other negative effects on a movie, that would also be fine.
I don't analyze still pics, I don't see a point there. I'm not watching still pics.

would the above be a good compromise, sufficient, or is there more to fine tune?

-roland

It's very difficult to compare without 2-pass, but I'd also ditch qcomp 0.7 . Between that and the Aq strength changes, bitrate at CRF 22 is going to drop quite a lot, so I'd maybe look at using a lower CRF. Maybe start around CRF 20.5 and see how you get on?

Perhaps keep AQ strength at the default of 1.0 for the time being. You really need 2-pass and short scene tests to find the optimal value.

[Boulder]

Losing grain means also losing details, but --selective-sao 1 probably helps with that. SAO used to be one option to disable (I still disable it completely myself), because it just smoothed everything. Otherwise, your settings should be a good basis. I don't know much about the inner workings of the deblocking feature, but I use --deblock -2:-2 myself.

[markiemarcus]

Losing grain means also losing details, but --selective-sao 1 probably helps with that. SAO used to be one option to disable (I still disable it completely myself), because it just smoothed everything. Otherwise, your settings should be a good basis. I don't know much about the inner workings of the deblocking feature, but I use --deblock -2:-2 myself.

Deblock -2:-2 usually looks nice from my testing also. I'd definitely give --selective-sao 1 a try. Helps with a few rough edges. You can really see the grain smearing start to kick in with --selective-sao 2 though.

[_kermit]

Deblock -2:-2 usually looks nice from my testing also. I'd definitely give --selective-sao 1 a try. Helps with a few rough edges. You can really see the grain smearing start to kick in with --selective-sao 2 though.

I've tried this on a 1 min. clip:

--vbv-maxrate 15000 --deblock=-2:-2 --amp --aq-strength 0.85 --selective-sao 1 --rskip --output-depth 10 --aq-mode 3

with CRF 18-22 in 1.0 steps.

CRF 18 results in 5.1Mbit/s (the original has 37Mbit), but all still have the same issue.

Anything else that can help?
Obviously otherwise only using very high bitrate might solve this or not re-encoing at all or accepting that this might happen.

[markiemarcus]

I've tried this on a 1 min. clip:

--vbv-maxrate 15000 --deblock=-2:-2 --amp --aq-strength 0.85 --selective-sao 1 --rskip --output-depth 10 --aq-mode 3

with CRF 18-22 in 1.0 steps.

CRF 18 results in 5.1Mbit/s (the original has 37Mbit), but all still have the same issue.

Anything else that can help?
Obviously otherwise only using very high bitrate might solve this or not re-encoing at all or accepting that this might happen.

Perhaps stick with the default Aq strength for the time being. CRF 18 with Aq mode 3 really should look good.

I take it you're running the latest build?

In the interest of narrowing the problem down, maybe try the "slower" preset. I'd also see if --qg-size 64 can help and there's always good old Aq-mode 1.

Is the source very grainy?

[Boulder]

Have you checked the original closely so that it doesn't have the same issue there? Re-encoding could easily amplify it.
It could be worth a try applying an anti-banding filter just to see if it changes the situation.

[_kermit]

Perhaps stick with the default Aq strength for the time being. CRF 18 with Aq mode 3 really should look good.

I take it you're running the latest build?

In the interest of narrowing the problem down, maybe try the "slower" preset. I'd also see if --qg-size 64 can help and there's always good old Aq-mode 1.

Is the source very grainy?

Tried now:

--vbv-maxrate 15000 --deblock=-2:-2 --amp --selective-sao 1 --rskip --output-depth 10 --aq-mode 3 --qg-size 64 --preset slower --crf 20

and

--vbv-maxrate 15000 --deblock=-2:-2 --amp --selective-sao 1 --rskip --output-depth 10 --aq-mode 1 --qg-size 64 --preset slower --crf 18

yes, 3.2.0.18

still shows. It may be less, but still obvious

Interesting part is that it only is that obvious on that region with black/purple texture

it is grainy, but there is worse.

does it help uploading the original and encoded clip?
Onedrive working?

[_kermit]

Have you checked the original closely so that it doesn't have the same issue there? Re-encoding could easily amplify it.
It could be worth a try applying an anti-banding filter just to see if it changes the situation.

the original doesn't have that.

I have no idea how to apply such a filter :)

[Boulder]

A source clip can always be useful. Easier to see what's really happening.

[_kermit]

A source clip can always be useful. Easier to see what's really happening.

see if you can access that (uploading):

https://1drv.ms/u/s!AuVhsELqus7qlI9EOnijrFpkHGSG-g?e=GuXnag

cheers, roland

[Boulder]

see if you can access that (uploading):

https://1drv.ms/u/s!AuVhsELqus7qlI9EOnijrFpkHGSG-g?e=GuXnag

cheers, roland

What frame is the one that shows the issue best? I'm not seeing anything specific in my encode at CRF 18, preset slower and slight tweaks.

[_kermit]

What frame is the one that shows the issue best? I'm not seeing anything specific in my encode at CRF 18, preset slower and slight tweaks.

at 24 seconds, the woman in the middle.

But I've just changed the monitor I play the video on and the other isn't doing it, at least I can't see it.
When using another preset on the first display, I also don't see it anymore.
Can just the preset of a monitor cause that?
(I don't watch them on those, they are just for checking)

[Boulder]

Yes, it's very much possible. Different calibrations or settings can change the image a lot, so you're always on the safe side if you can check it on the display where you will be watching the final video. Of course, for most of us it's not very convenient.

[_kermit]

Yes, it's very much possible. Different calibrations or settings can change the image a lot, so you're always on the safe side if you can check it on the display where you will be watching the final video. Of course, for most of us it's not very convenient.

so, I guess all the fuss for nothing. Sorry for that.

[markiemarcus]

at 24 seconds, the woman in the middle.

But I've just changed the monitor I play the video on and the other isn't doing it, at least I can't see it.
When using another preset on the first display, I also don't see it anymore.
Can just the preset of a monitor cause that?
(I don't watch them on those, they are just for checking)

It's quite a difficult scene, especially leading up to that point. It's prone to grain freezing in the exterior shots and the level is low enough that RDOQ makes it appear more coarse and boxy than it actually is. I've run into this on animated sources that make heavy use of dither. The establishing shot of the bar @ 9 seconds in the red/brown sky is great example. RDOQ level 2 makes a mess of it, even at the default value. If you increase either (Psy-rd or Psy-RDOQ), the situation gets even worse. I'm getting more pleasing and accurate results from RDOQ Level 0, maxing out Psy-rd, and using a lower CRF to arrive at the same file size. Is RDOQ really supposed to behave like this? Because it also blows up the filesize so I can't see how it can be efficiency related.

Default RDOQ and Psy settings:
https://i.ibb.co/vBbXhkh/Psy2-RDOQ1.png

RDOQ Level 0, Psy-rd 5:
https://i.ibb.co/cFK5JhV/RDOQLevel0-Psy5.png

Aq mode 1 is coming out ahead for me. Default AQ strength seems fine.

Grain motion in the exterior shots is definitely helped with --rd 6.

[markiemarcus]

so, I guess all the fuss for nothing. Sorry for that.

I read somewhere on here a while back that 10-bit playback on 8-bit displays can be a little unpredictable.

[_kermit]

I read somewhere on here a while back that 10-bit playback on 8-bit displays can be a little unpredictable.

that does make sense :)

[microchip8]

@_kermit

I can't see anything in your picture you posted (haven't checked the sample yet). Maybe it's a monitor calibration issue?

[_kermit]

@_kermit

I can't see anything in your picture you posted (haven't checked the sample yet). Maybe it's a monitor calibration issue?

it seems what I saw was related to the display used.

[benwaggoner]

I read somewhere on here a while back that 10-bit playback on 8-bit displays can be a little unpredictable.Yeah. If a display controller truncates instead of dithers, you might get more banding than if the conversion to 8-bit was done pre-encode.

Sent from my SM-T837V using Tapatalk

[benwaggoner]

Tried now:



--vbv-maxrate 15000 --deblock=-2:-2 --amp --selective-sao 1 --rskip --output-depth 10 --aq-mode 3 --qg-size 64 --preset slower --crf 20



and



--vbv-maxrate 15000 --deblock=-2:-2 --amp --selective-sao 1 --rskip --output-depth 10 --aq-mode 1 --qg-size 64 --preset slower --crf 18



yes, 3.2.0.18



still shows. It may be less, but still obvious



Interesting part is that it only is that obvious on that region with black/purple texture



it is grainy, but there is worse.



does it help uploading the original and encoded clip?

Onedrive working?If it is in black/purple, try --aq-mode 3. It doesn't take much blocking in the very low luma range to show up as an artifact with 8-bit SDR.

Sent from my SM-T837V using Tapatalk

[alexantr]

...I'm getting more pleasing and accurate results from RDOQ Level 0, maxing out Psy-rd, and using a lower CRF to arrive at the same file size...

rdoq-level=1 can help to retain small noise looking like dither noise. Keep original psy-rd value and try to tune psy-rdoq from 0.5 to 1.0.

[markiemarcus]

rdoq-level=1 can help to retain small noise looking like dither noise. Keep original psy-rd value and try to tune psy-rdoq from 0.5 to 1.0.

Oh definitely, Level 1 I've had better experience with in the past, particularly at lower values of around 0.5. I'm just scratching my head as to why the default is Level 2; I'm struggling to see any positives. It's also slower IIRC.

However, even with Level 1, RDOQ at 1.0 and Psy-rd at 2.0, I'm able to get better grain motion and more consistent results at the same filesize with Level 0 and massively elevated Psy-rd values instead.

It just doesn't seem right. Surely I'm not the only one who's finding this?

[RainyDog]

Oh definitely, Level 1 I've had better experience with in the past, particularly at lower values of around 0.5. I'm just scratching my head as to why the default is Level 2; I'm struggling to see any positives. It's also slower IIRC.

However, even with Level 1, RDOQ at 1.0 and Psy-rd at 2.0, I'm able to get better grain motion and more consistent results at the same filesize with Level 0 and massively elevated Psy-rd values instead.

It just doesn't seem right. Surely I'm not the only one who's finding this?

Frustratingly there's just no perfect PSY/RDOQ setting with x265 unfortunately :(

But hours (probably amounting to days...) of testing has led me to conclude that the most balanced for most sources at mid-high bitrates is usually psy-rd 1.0, psy-rdoq 1.0 and rdoq-level 2.

I know what you mean with rdoq-level 0 though... In motion, it can look the most consistent and easiest on the eye. But if you compare encode frames to source frames you'll never get transparency with level 0. There seems to be some high-pass filter that sort of dulls grain and high-frequency detail even with psy-rd turned up to 5.0.

With rdoq-level 2 and psy-rd 1.0 plus psy-rdoq 1.0, you can usually see that it at least tries to replicate the source even if that can lead to ugly and sometimes weird artifacts if your bitrate isn't sufficient enough to support it.

As for rdoq-level 1, I find this to just be a rougher, less refined or accurate level 2.

If you can get your hands on any internal 'haich dee bits' x265 encodes for, ahem, research purposes then you'll find that they all use rdoq-level 2 with psy-rd 1.0 and psy-rdoq 1.0. Give or take anyway... I've seen psy-rd 1.2 + psy-rdoq 1.1 and psy-rd 1.4 + psy-rd 1.0 but always within those boundries.

They always consistently use no-cutree and usually qg-size 8 too. AQ mode 1 or 3 and often lots of zones as well. EDIT: and always CTU 32 and no-rskip.

[markiemarcus]

Frustratingly there's just no perfect PSY/RDOQ setting with x265 unfortunately :(

But hours (probably amounting to days...) of testing has led me to conclude that the most balanced for most sources at mid-high bitrates is usually psy-rd 1.0, psy-rdoq 1.0 and rdoq-level 2.

I know what you mean with rdoq-level 0 though... In motion, it can look the most consistent and easiest on the eye. But if you compare encode frames to source frames you'll never get transparency with level 0. There seems to be some high-pass filter that sort of dulls grain and high-frequency detail even with psy-rd turned up to 5.0.

With rdoq-level 2 and psy-rd 1.0 plus psy-rdoq 1.0, you can usually see that it at least tries to replicate the source even if that can lead to ugly and sometimes weird artifacts if your bitrate isn't sufficient enough to support it.

As for rdoq-level 1, I find this to just be a rougher, less refined or accurate level 2.

If you can get your hands on any internal 'haich dee bits' x265 encodes for, ahem, research purposes then you'll find that they all use rdoq-level 2 with psy-rd 1.0 and psy-rdoq 1.0. Give or take anyway... I've seen psy-rd 1.2 + psy-rdoq 1.1 and psy-rd 1.4 + psy-rd 1.0 but always within those boundries.

They always consistently use no-cutree and usually qg-size 8 too. AQ mode 1 or 3 and often lots of zones as well. EDIT: and always CTU 32 and no-rskip.

There is definitely some sort of lpf noticeable with level 0 and I totally agree that achieving transparency is pretty much impossible that way. But I still think that subjectively it often looks better, almost always so if you're trying to preserve dither. I don't mind the slight dulling of grain assuming what is there is uniform, the pitch fine and the resulting encode looks nice. It's so impressive to see the bitrate reduction you can achieve, even on grainy content, at bitrates where x264 completely falls apart.

I'm just seeing a lot of instances where RDOQ looks pretty nasty, regardless of the bit rate or values used.

Will definitely check out your suggestions though. Appreciate it.

[Yanak]

Hello,

is anyone having issues trying to build with Intel compiler 2019 integrated in Visual studio 2019 ?

Building the multilib with VS 2019 works,
building the multilib with LLVM Clang integrated inside Visual Studio 2019 works too, ( either the clang 9.0.0.0 version from the VS2019 installer or the last 10.0.0 version of LLVM installed separately and integrated in VS2019 with the LLVM2019 extension from the VS Marketplace. )

But trying to use the Intel compiler brings loads of errors and the build fails, tried also to make the single 10Bits build and it fails too.

Was able to use ICC 2019 inside VS2017 some months ago and it was building correctly so I'm not sure if it's a problem on my side only or more general issue on the code, but after dozen of tries i can't find out what is wrong with Intel compiler so i ask here in case anyone have an idea.

Thank you .

[_kermit]

Frustratingly there's just no perfect PSY/RDOQ setting with x265 unfortunately :(

But hours (probably amounting to days...) of testing has led me to conclude that the most balanced for most sources at mid-high bitrates is usually psy-rd 1.0, psy-rdoq 1.0 and rdoq-level 2.

I know what you mean with rdoq-level 0 though... In motion, it can look the most consistent and easiest on the eye. But if you compare encode frames to source frames you'll never get transparency with level 0. There seems to be some high-pass filter that sort of dulls grain and high-frequency detail even with psy-rd turned up to 5.0.

With rdoq-level 2 and psy-rd 1.0 plus psy-rdoq 1.0, you can usually see that it at least tries to replicate the source even if that can lead to ugly and sometimes weird artifacts if your bitrate isn't sufficient enough to support it.

As for rdoq-level 1, I find this to just be a rougher, less refined or accurate level 2.

If you can get your hands on any internal 'haich dee bits' x265 encodes for, ahem, research purposes then you'll find that they all use rdoq-level 2 with psy-rd 1.0 and psy-rdoq 1.0. Give or take anyway... I've seen psy-rd 1.2 + psy-rdoq 1.1 and psy-rd 1.4 + psy-rd 1.0 but always within those boundries.

They always consistently use no-cutree and usually qg-size 8 too. AQ mode 1 or 3 and often lots of zones as well. EDIT: and always CTU 32 and no-rskip.

can you provide the complete command line you prefer?

[RainyDog]

can you provide the complete command line you prefer?

Sure, the below is always my starting point then I tweak from there if necessary with a dial or two down on --aq-strength and/or a notch or two up on --psy-rd. This is for a broad range of film sources at 1080p resolution.

--preset slow --output-depth 10 --rd 3 --ctu 32 --limit-refs 1 --limit-tu 4 --tu-intra-depth 4 --tu-inter-depth 4 --no-rect --b-intra --aq-mode 1 --aq-strength 0.9 --ipratio 1.3 --pbratio 1.2 --no-cutree --subme 4 --merange 40 --max-merge 4 --weightb --bframes 10 --rc-lookahead 60 --lookahead-slices 0 --deblock -3:-3 --selective-sao 0 --no-sao --psy-rd 1.0

[redbtn]

They always consistently use no-cutree and usually qg-size 8 too. AQ mode 1 or 3 and often lots of zones as well. EDIT: and always CTU 32 and no-rskip.
I often see this also. But I don't understand why they use it. I did tests and noticed that CTU 32 and qg-size 8 is not better than CTU 64 qg-size 32 (and sometimes even worse). And also it seems to me that aq-mode 2 is better than 1. I'm not a professional, it's only my humble opinion.
Ps: I looked at your settings, do you sure that ctu 32 merange 40 is better for 1080p than ctu 64 merange 57?

[markiemarcus]

I often see this also. But I don't understand why they use it. I did tests and noticed that CTU 32 and qg-size 8 is not better than CTU 64 qg-size 32 (and sometimes even worse). And also it seems to me that aq-mode 2 is better than 1. I'm not a professional, it's only my humble opinion.
Ps: I looked at your settings, do you sure that ctu 32 merange 40 is better for 1080p than ctu 64 merange 57?

Found the same thing. I even find CTU 32 worse for grain retention, though it does make it look less boxy if using RDOQ Level 2. No-cutree I've seen cause issues in animation.

Aq mode 1 I find more consistent than 2 if the source has intermittent low luma. Aq mode 3 obviously works well, though in my experience not always better than Aq-mode 1. Metrics don't tell the whole story.

[markiemarcus]

Sure, the below is always my starting point then I tweak from there if necessary with a dial or two down on --aq-strength and/or a notch or two up on --psy-rd. This is for a broad range of film sources at 1080p resolution.

I see I'm not the only one who disables rect! The difference is so fractional on most content I've tested.

[redbtn]

Aq mode 1 I find more consistent than 2 if the source has intermittent low luma. Aq mode 3 obviously works well there, though in my experience not always better than Aq-mode 1. Metrics don't tell the whole story.

I use aq-mode 2 for HDR 10bit encodes. For SDR maybe better 1, I didn't much tests with SDR.

Any thoughts about using no-rskip? Does it make sense?

I see I'm not the only one who disables rect! The difference is so fractional on most content I've tested.

I use no-rect too.

[markiemarcus]

I use aq-mode 2 for HDR 10bit encodes. For SDR maybe better 1, I didn't much tests with SDR.

Any thoughts about using no-rskip? Does it make sense?



I use no-rect too.

I have zero experience with HDR I'm afraid, but at least a few hundred hours with SDR. I've heard a number of people say that too, though.

I never bother with no-rskip. Rskip works very well. Some other preferences:

I use rdLevel 4 and almost exclusively --limit-refs 1. If the performance impact weren't so dramatic, I'd use rdLevel 6. It's just better, there's no getting around that, but it is awfully slow.

Considering the performance boost, early-skip isn't half bad either. You seem to be able to overcome most of its shortcomings with a 0.1 to 0.2 drop in CRF, which is not the case with some of the other settings.

I've seen animated content that benefits from Sub-me 7 (yes, really), RC lookahead 80 and lookahead slices 1. It really doesn't hurt performance all that much either, but otherwise, the slower preset values for those are spot on.

I've seen reproducible grain freezing and other blocking craziness with tu-intra 4, tu-inter 4 so I'm weary of anything other than 1. Limit-tu I don't know what to make of. I don't fully understand it either, or its relation to intra/inter. If the content is super flat animation and clean as a whistle, values of 4, 4 and 4 seem to work well enough.

--cbqpoffs -1 --crqpoffs -2 works well for animation. x265 seems to struggle with deep reds without this.

-tskip is nice. t-skip-fast causes problems in animation.

--aq-motion is decent with Aq-mode 1 and generally allows a 0.5 drop in CRF for the same filesize, for which there is a noticeable benefit. I don't understand the dislike or distrust of the feature.

--weightb I think is a must, along with b-intra.

Both Rect and Amp are of extremely limited use IMO. Perhaps it's just the content I've been testing. I've seen comparable results with both disabled, to having both enabled along with limit-modes. With --no-limit-modes, yes, the difference I could spot, but it's dog slow. This was on animated content though; I haven't tested that on live action.

6 bframes I think is a good compromise for most content, though I've seen some small benefits to using double that on animated content.

--selective-sao 1 is nice and now my go-to.

qg-size 64 works well, even at 1080p. It's great on animated content.

I don't go higher than max-merge 3. I've seen 4 and 5 produce worse results than 3 during fast motion in animated content. I don't know why.

As I'd mentioned previously, I'm really not a fan of RDOQ Level 1 or 2. I much prefer Level 0 with much higher Psy-rd values instead. I understand why people like it, I just think it's ugly.

--deblock -4:-1 on grainy or dithered stuff, --deblock -3:0 or -2:0 otherwise.

--fades seems to work well.

Default Me range and Star. UMH is better, but it's fractional.

refs 4 is generally speaking adequate IMO.

I keep strong-intra-smoothing on.

Aq strength is difficult. Generally the default or 0.9 is fine, but if the content is super, super grainy, I've gone as low as 0.6 and put the difference into a lower CRF for better results.

So my settings are a bit weird. I've arrived at them from probably thousands of 2 pass tests over a few years, aiming for 2:1 over x264 and no more.

[redbtn]

I have zero experience with HDR I'm afraid, but at least a few hundred hours with SDR. I've heard a number of people say that too, though.



I never bother with no-rskip. Rskip works very well. Some other preferences:



I use rdLevel 4 and almost exclusively --limit-refs 1. If the performance impact weren't so dramatic, I'd use rdLevel 6. It's just better, there's no getting around that, but it is awfully slow.



Considering the performance boost, early-skip isn't half bad either. You seem to be able to overcome most of its shortcomings with a 0.1 to 0.2 drop in CRF, which is not the case with some of the other settings.



I've seen animated content that benefits from Sub-me 7 (yes, really), RC lookahead 80 and lookahead slices 1. It really doesn't hurt performance all that much either, but otherwise, the slower preset values for those are spot on.



I've seen reproducible grain freezing and other blocking craziness with tu-intra 4, tu-inter 4 so I'm weary of anything other than 1. Limit-tu I don't know what to make of. I don't fully understand it either, or its relation to intra/inter. If the content is super flat animation and clean as a whistle, values of 4, 4 and 4 seem to work well enough.



--cbqpoffs -1 --crqpoffs -2 works well for animation. x265 seems to struggle with deep reds without this.



-tskip is nice. t-skip-fast causes problems in animation.



--aq-motion is decent with Aq-mode 1 and generally allows a 0.5 drop in CRF for the same filesize, for which there is a noticeable benefit. I don't understand the dislike or distrust of the feature.



--weightb I think is a must, along with b-intra.



Both Rect and Amp are of extremely limited use IMO. Perhaps it's just the content I've been testing. I've seen comparable results with both disabled, to having both enabled along with limit-modes. With --no-limit-modes, yes, the difference I could spot, but it's dog slow. This was on animated content though; I haven't tested that on live action.



6 bframes I think is a good compromise for most content, though I've seen some small benefits to using double that on animated content.



--selective-sao 1 is nice and now my go-to.



qg-size 64 works well, even at 1080p. It's great on animated content.



I don't go higher than max-merge 3. I've seen 4 and 5 produce worse results than 3 during fast motion in animated content. I don't know why.



As I'd mentioned previously, I'm really not a fan of RDOQ Level 1 or 2. I much prefer Level 0 with much higher Psy-rd values instead. I understand why people like it, I just think it's ugly.



--deblock -4:-1 on grainy or dithered stuff, --deblock -3:0 or -2:0 otherwise.



--fades seems to work well.



Default Me range and Star. UMH is better, but it's fractional.



refs 4 is generally speaking adequate IMO.



I keep strong-intra-smoothing on.



Aq strength is difficult. Generally the default or 0.9 is fine, but if the content is super, super grainy, I've gone as low as 0.6 and put the difference into a lower CRF for better results.



So my settings are a bit weird. I've arrived at them from probably thousands of 2 pass tests over a few years, aiming for 2:1 over x264 and no more.Thank you for very useful information! I'll try selective-sao 1 and tu intra inter 1 (if I recall correctly, it's gives 8-10% more bitrate but 10% faster).
I didn't find on my tests that --strong-intra-smoothing is giving better results, but maybe I was wrong. My target bitrate is 16-18mbps for 1080p, so maybe it's a reason?

[markiemarcus]

Thank you for very useful information! I'll try selective-sao 1 and tu intra inter 1 (if I recall correctly, it's gives 8-10% more bitrate but 10% faster).
I didn't find on my tests that --strong-intra-smoothing is giving better results, but maybe I was wrong. My target bitrate is 16-18mbps for 1080p, so maybe it's a reason?

No sweat. I'm only guessing the CRF you're going to need. The results are very sensitive to it; very fine noise requires a low CRF. I'd say that the useful range is CRF 16 to 19. Bear in mind that there's no RDOQ level 2, which immediately knocks around 0.6 off the CRF of any corresponding preset that uses it and another 0.6 from aq-motion. CRF 16 here is more like CRF 17.5 by default.

--crf 16 --preset slow --output-depth 10 --limit-refs 1 --limit-tu 4 --tu-intra-depth 3 --tu-inter-depth 3 --rdoq-level 0 --no-rect --tskip --early-skip --b-intra --qg-size 64 --aq-strength 0.7 --cbqpoffs -1 --crqpoffs -2 --aq-motion --subme 7 --weightb --bframes 6 --rc-lookahead 80 --lookahead-slices 1 --deblock -4:-1 --psy-rd 5 --fades --selective-sao 1 --aq-mode 1

Everybody seems to have their own way of doing these things, this just happens to be mine. It's fast also. There's no reason why Aq-mode 2 wouldn't work if that's what you want, but it is a little less detailed on SDR sources from what I've tested, especially with regards to dither preservation. --qg-size 32 also works, but I prefer the look of 64 and I'd swear it's more detailed in low luma and holds together the deep reds better. --aq-mode 3 also works well if you prefer.

It's worth tuning aq strength. The value depends on the source obviously, but 0.7 is a good a place to start.

RainyDog's suggestion looks really nice and is far better than the default IMO. CRF 19.5 there is about the same size as CRF 16 here. Most of my testing was done on grainy animation, or animation with a lot of dither. They're quite different looking.

[RainyDog]

I often see this also. But I don't understand why they use it. I did tests and noticed that CTU 32 and qg-size 8 is not better than CTU 64 qg-size 32 (and sometimes even worse). And also it seems to me that aq-mode 2 is better than 1. I'm not a professional, it's only my humble opinion.
Ps: I looked at your settings, do you sure that ctu 32 merange 40 is better for 1080p than ctu 64 merange 57?

I've just done another test of CTU 32 vs 64 on my current encode and it's really just splitting hairs at the bitrates I aim for at least. Some parts of the frame might appear slightly better on extreme scrutiny with one then the other but it's generally a wash other than CTU 32 is slighty faster.

Me-range 40 is about the cut off point where you just get diminishing returns for 1080p content at least.

Qg-size is still a bit of ahead scratcher for me. In theory, 8 should yield bigger size encodes with the most detail retention but at the expense of more artifacting. Yet everytime I've tested at the same settings and CRF, qg-size 16 comes out the biggest, size 8 by far the smallest with 32 sat somewhere in between! So I usually just leave it at the default of 32.

[LigH]

@redbtn: Thank you for considering not to quote a several pages long post to reply only briefly. Often a @name is sufficient. Or trim the quote to a relevant part.

[RainyDog]

--selective-sao 1 is nice and now my go-to.

You do realise that all selective sao 1 does is apply SAO to I-frames which are less than 1% of your encode, right? :p

SAO really needs a strength setting more than anything else. I feel it could be highly useful for all content if it could be tuned.

[markiemarcus]

You do realise that all selective sao 1 does is apply SAO to I-frames which are less than 1% of your encode, right? :p

SAO really needs a strength setting more than anything else. I feel it could be highly useful for all content if it could be tuned.

Yup! But I agree.

[markiemarcus]

Qg-size is still a bit of ahead scratcher for me. In theory, 8 should yield bigger size encodes with the most detail retention but at the expense of more artifacting. Yet everytime I've tested at the same settings and CRF, qg-size 16 comes out the biggest, size 8 by far the smallest with 32 sat somewhere in between! So I usually just leave it at the default of 32.

If you restore limit-tu , tu-intra-depth and tu-inter-depth to the default, I suspect things will start behaving like you'd expect with the filesize.

[_kermit]

Sure, the below is always my starting point then I tweak from there if necessary with a dial or two down on --aq-strength and/or a notch or two up on --psy-rd. This is for a broad range of film sources at 1080p resolution.

thanks, I'll give that a try.

Can anyone provide something like that for UHD/HDR?

[RainyDog]

thanks, I'll give that a try.

Can anyone provide something like that for UHD/HDR?

I use the same template for HDR encodes just with the additional required HDR knobs (hdr-opt etc.) turned on. CRF needs to be bumped down a couple of notches for HDR though ie. CRF 17 for SDR = CRF 15 for HDR.

Again, this is all at 1080p resolution. For UHD all I'd probably change is CTU 32 > 64, me-range 40 > 57 and possibly qg-size 32 > 64.

[RainyDog]

If you restore limit-tu , tu-intra-depth and tu-inter-depth to the default, I suspect things will start behaving like you'd expect with the filesize.

I'll have a look at that then.

I've never really seen much difference in quality or size between tu-intra-depth inter-depth and limit-tu all set to 4 versus 1, 1 and 0 anyway. I only really use the former as it's a buffed setting with minor performance hit.

I think the gains from increasing tu-intra and inter-depth are probably only really seen without using limit-tu. But the speed decrease is pretty severe then.

[markiemarcus]

I'll have a look at that then.

I've never really seen much difference in quality or size between tu-intra-depth inter-depth and limit-tu all set to 4 versus 1, 1 and 0 anyway. I only really use the former as it's a buffed setting with minor performance hit.

I think the gains from increasing tu-intra and inter-depth are probably only really seen without using limit-tu. But the speed decrease is pretty severe then.

I don't really understand them to be perfectly honest lol. But I have found instances where tu-intra and tu-inter being set to 4, with limit-tu 0, causes grain freezing and huge blocks on flat textures. It spooked me so I've dodged them since.

[fauxreaper]

Without limit-tu, higher values of tu-intra and tu-inter only increase compression, not visual quality. limit-tu 1 + tu-inter 4 + tu-intra 4 should give better quality than using limit-tu 0.

[markiemarcus]

Without limit-tu, higher values of tu-intra and tu-inter only increase compression, not visual quality. limit-tu 1 + tu-inter 4 + tu-intra 4 should give better quality than using limit-tu 0.

That makes sense. I've also observed less severe versions of the issue with limit-tu 4 + tu-inter 4 + tu-intra 4. Would limit-tu 1 + tu-inter 4 + tu-intra 4 be higher quality?

Edit: Nope. After some more testing I prefer the results with limit-tu 4 + tu-inter 3 + tu-intra 3.

[vpupkind]

...

I use rdLevel 4 and almost exclusively --limit-refs 1. If the performance impact weren't so dramatic, I'd use rdLevel 6. It's just better, there's no getting around that, but it is awfully slow.



Try --dynamic-rd, it typically provides a pretty decent quality boost over rd-level=4

[markiemarcus]

Try --dynamic-rd, it typically provides a pretty decent quality boost over rd-level=4

Cheers for the suggestion. How would one go about using this reliably in CRF mode? Seems to rely on VBV.

[l00t]

Try --dynamic-rd, it typically provides a pretty decent quality boost over rd-level=4

Over? According to the manual it should be helpful at 4 and below...

--dynamic-rd <0..4>
Increases the RD level at points where quality drops due to VBV rate control enforcement. The number of CUs for which the RD is reconfigured is determined based on the strength. Strength 1 gives the best FPS, strength 4 gives the best SSIM. Strength 0 switches this feature off. Default: 0.

Effective for RD levels 4 and below.

[markiemarcus]

Over? According to the manual it should be helpful at 4 and below...

"By comparison to" I assume.

[Yanak]

Hi,
answering to myself about this (https://forum.doom9.org/showthread.php?p=1892638#post1892638), apparently the problem is there since a while now :

Found out this
https://bitbucket.org/multicoreware/x265/issues/487/errors-in-asm-primitivescpp-when-using
It fixes the cli if you make it with a single lib, but trying to make a multilib exe you end up with this :
https://bitbucket.org/multicoreware/x265/issues/488/error-lnk2005-__intel_cpu_indicator_init

Then in the end i found the full fix needed for the code, it's this :
https://github.com/msg7086/x265-Yuuki-Asuna/commit/5a62786ae6d479d72c4b605fbb35c659d71beac9

Multilib 8+10+12Bit compiles correctly now with ICC 1910 from latest Intel System Studio 2020 integrated in VS2019 .

Posting it in case it helps someone else, spent a few days banging my head on this thing...

[vpupkind]

Over? According to the manual it should be helpful at 4 and below...

Quality-wise, it can give you (combined with rd-level=4) quality improvement getting you closer to rd-level=6 performance.

We've seen 3% BD-SSIM improvement from using it.

[Boulder]

Quality-wise, it can give you (combined with rd-level=4) quality improvement getting you closer to rd-level=6 performance.

We've seen 3% BD-SSIM improvement from using it.

According to the manual, it applies only to VBV capped encodes in special situations in the material. I think quite many of us don't use VBV constraints in personal encodes.

[Barough]

x265 v3.2+22-a8a2c4c37267 (http://www.mediafire.com/file/6mb2m4dabqsjpni/x265-3.2%252B22-a8a2c4c37267_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[alexantr]

Did anybody notice enabled b-intra makes more blur artifacts in motion?

[bjoker]

Hi,

I'm basically into CLI stuff. I have no issues running ffmpeg with x265 10-bit using CRF with any x265 parameter value but can't figure out 2-pass encoding which fails in the 2nd pass. Could any one please guide me where I am doing wrong? @Selur please

Microsoft Windows [Version 10.0.18362.535]
(c) 2019 Microsoft Corporation. All rights reserved.

C:\Users\admin\Desktop\REMUX>ffmpeg -y -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -x265-params "pass=1:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 NUL
ffmpeg version git-2019-12-19-99f505d Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9.2.1 (GCC) 20191125
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
libavutil 56. 36.101 / 56. 36.101
libavcodec 58. 65.100 / 58. 65.100
libavformat 58. 35.101 / 58. 35.101
libavdevice 58. 9.101 / 58. 9.101
libavfilter 7. 69.101 / 7. 69.101
libswscale 5. 6.100 / 5. 6.100
libswresample 3. 6.100 / 3. 6.100
libpostproc 55. 6.100 / 55. 6.100
[matroska,webm @ 0000015de81d9d80] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 0000015de81d9d80] Could not find codec parameters for stream 3 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 0000015de81d9d80] Could not find codec parameters for stream 4 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, matroska,webm, from 'Testing-1min.mkv':
Metadata:
title : testing clip
encoder : libebml v1.3.9 + libmatroska v1.5.2
creation_time : 2019-12-18T23:24:19.000000Z
Duration: 00:01:00.02, start: 0.000000, bitrate: 23880 kb/s
Chapter #0:0: start 0.000000, end 12.012208
Metadata:
title : Chapter 09
Chapter #0:1: start 12.012208, end 60.008000
Metadata:
title : Chapter 10
Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc
Metadata:
BPS-eng : 22031553
DURATION-eng : 00:00:59.977000000
NUMBER_OF_FRAMES-eng: 1438
NUMBER_OF_BYTES-eng: 165173310
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:1(por): Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s16p (default)
Metadata:
title : Surround 5.1
BPS-eng : 1787265
DURATION-eng : 00:01:00.011000000
NUMBER_OF_FRAMES-eng: 5626
NUMBER_OF_BYTES-eng: 13406948
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:2(eng): Subtitle: hdmv_pgs_subtitle (default)
Metadata:
BPS-eng : 55145
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 382812
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:3(chi): Subtitle: hdmv_pgs_subtitle
Metadata:
BPS-eng : 40979
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 284474
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:4(chi): Subtitle: hdmv_pgs_subtitle
Metadata:
BPS-eng : 42596
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 295697
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> hevc (libx265))
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool 0 using 32 threads on numa nodes 0
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 5 / 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 : star / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut / bias: 23 / 250 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 25 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 0
x265 [info]: References / ref-limit cu / depth : 4 / on / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 3 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-5000 kbps / 0.60
x265 [info]: tools: rect limit-modes rd=4 psy-rd=2.00 rdoq=2 psy-rdoq=1.00
x265 [info]: tools: rskip signhide tmvp strong-intra-smoothing lslices=4
x265 [info]: tools: deblock stats-write
Output #0, mp4, to 'NUL':
Metadata:
title : testing clip
encoder : Lavf58.35.101
Chapter #0:0: start 0.000000, end 12.012208
Metadata:
title : Chapter 09
Chapter #0:1: start 12.012208, end 60.008000
Metadata:
title : Chapter 10
Stream #0:0(eng): Video: hevc (libx265) (hev1 / 0x31766568), yuv420p10le, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 5000 kb/s, 23.98 fps, 24k tbn, 23.98 tbc
Metadata:
BPS-eng : 22031553
DURATION-eng : 00:00:59.977000000
NUMBER_OF_FRAMES-eng: 1438
NUMBER_OF_BYTES-eng: 165173310
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
encoder : Lavc58.65.100 libx265
Side data:
cpb: bitrate max/min/avg: 0/0/5000000 buffer size: 0 vbv_delay: N/A
frame= 1438 fps=9.9 q=-0.0 Lsize= 38964kB time=00:00:59.85 bitrate=5333.1kbits/s speed=0.412x
video:38945kB audio:0kB subtitle:0kB other streams:0kB global headers:2kB muxing overhead: 0.050550%
x265 [info]: frame I: 12, Avg QP:19.99 kb/s: 27830.30
x265 [info]: frame P: 268, Avg QP:20.89 kb/s: 16318.63
x265 [info]: frame B: 1158, Avg QP:26.00 kb/s: 2539.48
x265 [info]: Weighted P-Frames: Y:0.4% UV:0.4%
x265 [info]: consecutive B-frames: 4.3% 0.7% 2.1% 52.9% 5.0% 6.1% 5.0% 21.8% 2.1%

encoded 1438 frames in 145.06s (9.91 fps), 5318.55 kb/s, Avg QP:25.00

C:\Users\admin\Desktop\REMUX>ffmpeg -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -x265-params "pass=2:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 Testing-1min-2pass.mp4
ffmpeg version git-2019-12-19-99f505d Copyright (c) 2000-2019 the FFmpeg developers
built with gcc 9.2.1 (GCC) 20191125
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libdav1d --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-libxvid --enable-libaom --enable-libmfx --enable-ffnvcodec --enable-cuvid --enable-d3d11va --enable-nvenc --enable-nvdec --enable-dxva2 --enable-avisynth --enable-libopenmpt --enable-amf
libavutil 56. 36.101 / 56. 36.101
libavcodec 58. 65.100 / 58. 65.100
libavformat 58. 35.101 / 58. 35.101
libavdevice 58. 9.101 / 58. 9.101
libavfilter 7. 69.101 / 7. 69.101
libswscale 5. 6.100 / 5. 6.100
libswresample 3. 6.100 / 3. 6.100
libpostproc 55. 6.100 / 55. 6.100
[matroska,webm @ 00000198d82d9cc0] Could not find codec parameters for stream 2 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 00000198d82d9cc0] Could not find codec parameters for stream 3 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[matroska,webm @ 00000198d82d9cc0] Could not find codec parameters for stream 4 (Subtitle: hdmv_pgs_subtitle (pgssub)): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, matroska,webm, from 'Testing-1min.mkv':
Metadata:
title : testing clip
encoder : libebml v1.3.9 + libmatroska v1.5.2
creation_time : 2019-12-18T23:24:19.000000Z
Duration: 00:01:00.02, start: 0.000000, bitrate: 23880 kb/s
Chapter #0:0: start 0.000000, end 12.012208
Metadata:
title : Chapter 09
Chapter #0:1: start 12.012208, end 60.008000
Metadata:
title : Chapter 10
Stream #0:0(eng): Video: h264 (High), yuv420p(progressive), 1920x1080 [SAR 1:1 DAR 16:9], 23.98 fps, 23.98 tbr, 1k tbn, 47.95 tbc
Metadata:
BPS-eng : 22031553
DURATION-eng : 00:00:59.977000000
NUMBER_OF_FRAMES-eng: 1438
NUMBER_OF_BYTES-eng: 165173310
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:1(por): Audio: dts (DTS-HD MA), 48000 Hz, 5.1(side), s16p (default)
Metadata:
title : Surround 5.1
BPS-eng : 1787265
DURATION-eng : 00:01:00.011000000
NUMBER_OF_FRAMES-eng: 5626
NUMBER_OF_BYTES-eng: 13406948
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:2(eng): Subtitle: hdmv_pgs_subtitle (default)
Metadata:
BPS-eng : 55145
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 382812
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:3(chi): Subtitle: hdmv_pgs_subtitle
Metadata:
BPS-eng : 40979
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 284474
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream #0:4(chi): Subtitle: hdmv_pgs_subtitle
Metadata:
BPS-eng : 42596
DURATION-eng : 00:00:55.535000000
NUMBER_OF_FRAMES-eng: 24
NUMBER_OF_BYTES-eng: 295697
_STATISTICS_WRITING_APP-eng: mkvmerge v41.0.0 ('Smarra') 64-bit
_STATISTICS_WRITING_DATE_UTC-eng: 2019-12-18 23:24:19
_STATISTICS_TAGS-eng: BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES
Stream mapping:
Stream #0:0 -> #0:0 (h264 (native) -> hevc (libx265))
Press [q] to stop, [?] for help
x265 [info]: HEVC encoder version 3.2+15-04db2bfee5d6
x265 [info]: build info [Windows][GCC 9.2.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-4 (Main tier)
x265 [info]: Thread pool 0 using 32 threads on numa nodes 0
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [error]: different scenecut setting than first pass (40 vs 40)
[libx265 @ 00000198d8356500] Cannot open libx265 encoder.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!

C:\Users\admin\Desktop\REMUX>

[Selur]

try '-pix_fmt yuv420p10le -strict -1' instead of just '-pix_fmt yuv420p10le'

[bjoker]

try '-pix_fmt yuv420p10le -strict -1' instead of just '-pix_fmt yuv420p10le'

Thank you Selur

Now it throws: (pasted last few lines)

x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [error]: different scenecut setting than first pass (40 vs 40)
[libx265 @ 000001bb8d550300] Cannot open libx265 encoder.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!

I ran 2 commands (for 2 passes separately) like this: (First pass goes fine but 2nd one fails)

ffmpeg -y -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -strict -1 -x265-params "pass=1:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 NUL

ffmpeg -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -strict -1 -x265-params "pass=2:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 Testing-1min-2pass.mp4

[Greenhorn]

Thank you Selur

Now it throws: (pasted last few lines)

x265 [info]: frame threads / pool features : 5 / wpp(17 rows)
x265 [error]: different scenecut setting than first pass (40 vs 40)
[libx265 @ 000001bb8d550300] Cannot open libx265 encoder.
Error initializing output stream 0:0 -- Error while opening encoder for output stream #0:0 - maybe incorrect parameters such as bit_rate, rate, width or height
Conversion failed!

I ran 2 commands (for 2 passes separately) like this: (First pass goes fine but 2nd one fails)

ffmpeg -y -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -strict -1 -x265-params "pass=1:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 NUL

ffmpeg -i "Testing-1min.mkv" -c:v libx265 -b:v 5000k -preset slow -pix_fmt yuv420p10le -strict -1 -x265-params "pass=2:aq-mode=3:bframes=8:sao=0:sar=0:selective-sao=0" -an -f mp4 Testing-1min-2pass.mp4


The "different scenecut" error is caused by a bug in x265 builds 3.2+15 through 3.2+17; selur brought it up here a couple/three weeks ago (https://forum.doom9.org/showthread.php?p=1891654#post1891654), and it should be fixed if you can upgrade to a build (in or out of FFMPEG) that's 3.2+18 or later.

[bjoker]

Thanks.
I tested an older version of ffmpeg/x265 and it worked fine.

Unfortunately the latest ffmpeg build still has x265 3.2+15. I think I will have to use external x265.
How could I pipe ffmpeg to external x265 for 2-pass please?

[Greenhorn]

I don't really know shell syntax, but what I'd normally do for standalone x265 would be convert my input files to decompressed .y4m with ffmpeg (ffmpeg -i example_input.file example_output.y4m), then convert the y4m using x265. (x265 example_output.y4m --my_settings -o example_output.hevc) You'll need enough free disk space for the whole .y4m to be stored, and the output will be a raw HEVC stream that needs to be muxed with ffmpeg again-- although that shouldn't pose any problems, unless you've got two buggy libraries in one ffmpeg at once.

[foxyshadis]

I don't really know shell syntax, but what I'd normally do for standalone x265 would be convert my input files to decompressed .y4m with ffmpeg (ffmpeg -i example_input.file example_output.y4m), then convert the y4m using x265. (x265 example_output.y4m --my_settings -o example_output.hevc) You'll need enough free disk space for the whole .y4m to be stored, and the output will be a raw HEVC stream that needs to be muxed with ffmpeg again-- although that shouldn't pose any problems, unless you've got two buggy libraries in one ffmpeg at once.

No ginormous intermediate file needed: ffmpeg -i example_input.file -f yuv4mpegpipe -strict -2 - | x265 - -o example_output.hevc

That's going to be much faster than writing and reading to disk. The "strict -2" allows y4m to be greater than 8 bits, if necessary.

[nghiabeo20]

Does x265 have tuning for monochrome picture? And is it a good practice to convert a RGB black&white source to actual BW in an encode?

[nghiabeo20]

No ginormous intermediate file needed: ffmpeg -i example_input.file -f yuv4mpegpipe -strict -2 - | x265 - -o example_output.hevc

That's going to be much faster than writing and reading to disk. The "strict -2" allows y4m to be greater than 8 bits, if necessary.

May I explain:

ffmpeg -i example_input.file -f yuv4mpegpipe -strict -2 -

The - makes ffmpeg send output to stdout.

x265 - -o example_output.hevc

The - makes x265 receive input from stdin.

The | (pipe) connects stdout to stdin.

[SaboraPie]

why this last versions are so slow. In v3.0 or earlier versions i was encoding at 1.2fps in veryslow mode, and now it is 0.42fps. Is maybe more efficient but much slower?

[Boulder]

The presets were changed at one point. The old "veryslow" became "slower" etc.

[Atak_Snajpera]

How to correctly signal HLG with x265?
So far I'm using following command line
--colorprim bt2020 --transfer bt2020-10 --colormatrix bt2020nc --atc-sei 18
but according to x265 docs there is also another required switch


--pic-struct <integer>
Set the picture structure and emits it in the picture timing SEI message. Values in the range 0..12. See D.3.3 of the HEVC spec. for a detailed explanation. Required for HLG (Hybrid Log Gamma) signalling. Not signalled by default.


What value has to be set there? Is --pic-struct 0 correct/needed for progressive frame?

[foxyshadis]

Yes, 0 for progressive. Odd that HLG requires it. Wouldn't transfer be arib-std-b67 for HLG?

[Atak_Snajpera]

Yes, 0 for progressive. Odd that HLG requires it. Wouldn't transfer be arib-std-b67 for HLG?

Mediainfo detects both so I'm not sure if arib-std-b67 is required...

--transfer bt2020-10
Transfer characteristics : HLG / BT.2020 (10-bit)

--transfer arib-std-b67
Transfer characteristics : HLG / HLG

[FranceBB]

This is the command line of an HLG encode I've done recently:

--colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18

I've never used --pic-struct, but the file has been recognized as an HLG one anyway.

But... Atak_Snajpera made it popping back up in my mind by asking about it, so... should I include --pic-struct 0 as well?

[excellentswordfight]

This is the command line of an HLG encode I've done recently:

--colorprim bt2020 --transfer arib-std-b67 --colormatrix bt2020nc --atc-sei 18

I've never used --pic-struct, but the file has been recognized as an HLG one anyway.

But... Atak_Snajpera made it popping back up in my mind by asking about it, so... should I include --pic-struct 0 as well?
Mediainfo detects both so I'm not sure if arib-std-b67 is required...

--transfer bt2020-10
Transfer characteristics : HLG / BT.2020 (10-bit)

--transfer arib-std-b67
Transfer characteristics : HLG / HLG
AFIK according to the specc its recommended for HLG that the fallback transfer function should flaged in "--transfer" and the HLG transfer i.e. arib-std-b67 / 18 with the preferred/alternative transfer characteristics flag (--atc-sei).

[hevc_enocder]

hello, may I have question?

What is right scrip for zones I tried this and i alaways get an error

--zones 9277,9328,crf=15.4/9381,9742,crf=15.4/27589,27647,crf=15.4/27885,28012,crf=15.4/28091,28174,crf=15.4/28285,28368,crf=15.4/36778,36848,crf=15.4/71142,71170,crf=15.4/72038,72097,crf=15.4/72401,72422,crf=15.4/157075,157141,crf=15.4/180290,180426,crf=15.4/188329,188459,crf=15.4/199320,199359,crf=15.4/199895,199990,crf=15.4/205184,205327,crf=15.4/221411,221500,crf=15.4/222062,222108,crf=15.4/237130,243727,crf=22

So my final setting is this:
--crf 16 --output-depth 10 --level-idc 5.1 --high-tier --ref 5 --bframes 12 --rd 6 --me 3 --subme 5 --merange 32 --ipratio 1.3 --pbratio 1.2 --weightb --b-intra --hevc-aq --no-rskip --qcomp 0.60 --psy-rd 1.07 --psy-rdoq 1.00 --ctu 64 --rc-lookahead 60 --deblock -3:-3 --cbqpoffs 0 --crqpoffs 0 --qg-size 8 --no-rskip --no-rect --no-amp --no-sao --no-open-gop --no-cutree --range limited --aud --repeat-headers --zones 9277,9328,crf=15.4/9381,9742,crf=15.4/27589,27647,crf=15.4/27885,28012,crf=15.4/28091,28174,crf=15.4/28285,28368,crf=15.4/36778,36848,crf=15.4/71142,71170,crf=15.4/72038,72097,crf=15.4/72401,72422,crf=15.4/157075,157141,crf=15.4/180290,180426,crf=15.4/188329,188459,crf=15.4/199320,199359,crf=15.4/199895,199990,crf=15.4/205184,205327,crf=15.4/221411,221500,crf=15.4/222062,222108,crf=15.4/237130,243727,crf=22

please can you tell me what is wrong about it? Thank you so much.

[Boulder]

I don't think x265 supports setting CRF in zones, you need to define q instead.

[RainyDog]

hello, may I have question?

What is right scrip for zones I tried this and i alaways get an error

So my final setting is this:

please can you tell me what is wrong about it? Thank you so much.

Try replacing all instances of crf=15.4 in your script with b=1.3 (or find your preferred value instead of 1.3).

The 'b' stands for bitrate multiplier so 1.3 will increase the bitrate of the frames designated within zones by a factor of x1.3 (or +30%).

[Magik Mark]

Guys,

When encoding do you use ssim-rdo? Do you see any difference? When is the best time to use this? During 2pass perhaps? or CRF?

It takes longer when this is enabled.

[vpupkind]

I don't think x265 supports setting CRF in zones, you need to define q instead.
You can change crf (as well as some other parameters) per zone using the --zonefile option and a "sidecar file" with frame numbers and zone settings. You can change additional settings beyond crf/bitrate this way.

[vpupkind]

Guys,

When encoding do you use ssim-rdo? Do you see any difference? When is the best time to use this? During 2pass perhaps? or CRF?

It takes longer when this is enabled.
It is heavy but is totally worth it, IMO. We've seen meaningful quality improvements.

[microchip8]

It is heavy but is totally worth it, IMO. We've seen meaningful quality improvements.

From my testing, it produces worse results in dark, mostly clean frames with a little of mosquito noise. Tested on Blade Runner 2049 starting from 6:00 minutes

[Greenhorn]

Oddly, enabling ssim-rd by itself will disable psy-rd, but if you manually specify both they'll both be used.

[benwaggoner]

Oddly, enabling ssim-rd by itself will disable psy-rd, but if you manually specify both they'll both be used.
Have you confirmed they are both operating, or is it possible one overrides the other?

If psy-rd + ssim-rd looks different than just psy-rd OR ssim-rd, than they are doing something together. But it wouldn't be surprising if different rd modes can't operate simultaneously. Although, algorithmically, I could see these being able to function simultaneously.

[Greenhorn]

Have you confirmed they are both operating, or is it possible one overrides the other?

If psy-rd + ssim-rd looks different than just psy-rd OR ssim-rd, than they are doing something together. But it wouldn't be surprising if different rd modes can't operate simultaneously. Although, algorithmically, I could see these being able to function simultaneously.

That was an embarrasing mistake on my part. While the x265 CLI output will imply that both psy-rd and ssim-rd are enabled if you specify psy-rd after ssim-rd, it produces bit-identical output to not having ssim-rd enabled.

Similarly, enabling ssim-rd without doing anything to psy-rd is identical to manually disabling psy-rd. The encoder is clear about this, though, so hopefully I didn't manage to confuse anyone reading about that.

[jlpsvk]

what's better? ssim-rd or psy-rd?

[microchip8]

what's better? ssim-rd or psy-rd?

psy-rd... again, from my own testing ssim-rd produces visual distortions in some samples I tested long ago. ssim-rd is optimized to get the best SSIM metric values. While SSIM is (much) better than PSNR, it isn't perfect. psy-rd biases towards the energy of the source and will give, at higher values, a more subjectively looking better quality

There's also dynamic-rd but it needs vbv-bufsize and vbv-maxrate *and* you need to be hitting those for dynamic-rd to optimally do its thing

[benwaggoner]

There's also dynamic-rd but it needs vbv-bufsize and vbv-maxrate *and* you need to be hitting those for dynamic-rd to optimally do its thing
--dynamic-rd is really a speed/quality tradeoff option, orthogonal to the style of RD actually being applied. dynamic-rd changes the --rd parameter when the VBV buffer is hit, so a faster, lower quality setting can be used for easier sections of the video.

[benwaggoner]

Say, is anyone making Windows binaries with AVX-512 support somewhere? I wanted to do some tests.

[jlpsvk]

Say, is anyone making Windows binaries with AVX-512 support somewhere? I wanted to do some tests.

just use --asm avx512

:)

[Magik Mark]

--dynamic-rd is really a speed/quality tradeoff option, orthogonal to the style of RD actually being applied. dynamic-rd changes the --rd parameter when the VBV buffer is hit, so a faster, lower quality setting can be used for easier sections of the video.



What values would you suggest for vbv buffer when encoding 1080p and 2160p in 2 pass. Maybe a guide or a table. Thanks alot


Sent from my iPhone using Tapatalk

[Blue_MiSfit]

If you're encoding for streaming, I'd start with maxrate = 1.1x - 1.5x bitrate and bufsize = 2x bitrate.

Else set them to the profile maximums

[Magik Mark]

If you're encoding for streaming, I'd start with maxrate = 1.1x - 1.5x bitrate and bufsize = 2x bitrate.

Else set them to the profile maximums



Oh I see. Can you refer me to the table detailing max buffer for every profile? Thanks


Sent from my iPhone using Tapatalk

[l00t]

Say, is anyone making Windows binaries with AVX-512 support somewhere? I wanted to do some tests.

Unfortunately, according to my experiences, it won't do any good, because the CPU's clock speed will be significantly lower and will compensate the speed boost from using AVX512 (or at least this was the case for a Xeon Gold 6152).

[jlpsvk]

Unfortunately, according to my experiences, it won't do any good, because the CPU's clock speed will be significantly lower and will compensate the speed boost from using AVX512 (or at least this was the case for a Xeon Gold 6152).

yeah... avx512 produces much more heat... :( so probably safety issue...

[LazyNcoder]

Hello guys,

Any good, accurate and easy way to convert h265 HDR bt2020 to SDR bt709 using Avisynth/Vapoursynth (maybe via Staxrip)?
Something like what madVR is doing, without all the troubles.

[redbtn]

Hello guys,

Any good, accurate and easy way to convert h265 HDR bt2020 to SDR bt709 using Avisynth/Vapoursynth (maybe via Staxrip)?
Something like what madVR is doing, without all the troubles.Easy, no. You can try HDR to SDR conversion, but you have to adjust settings to every movie.

[LazyNcoder]

Easy, no. You can try HDR to SDR conversion, but you have to adjust settings to every movie.

Eh, thanks?

Any tutorials/tools for doing that?
I can search I know. But you could save a lot of time being wasted for me or other people reading your reply. After all, that's why we are all here. Thank you

[redbtn]

Any tutorials/tools for doing that?
I don't have any tutorials, but some links can help you.

http://forum.doom9.org/showthread.php?p=1847425

http://forum.doom9.org/showthread.php?p=1888974

http://forum.doom9.org/showthread.php?p=1880345

http://forum.doom9.org/showthread.php?p=1800667

[Atak_Snajpera]

Hello guys,

Any good, accurate and easy way to convert h265 HDR bt2020 to SDR bt709 using Avisynth/Vapoursynth (maybe via Staxrip)?
Something like what madVR is doing, without all the troubles.

https://forum.doom9.org/showthread.php?p=1893684#post1893684

[Majorlag]

Oh I see. Can you refer me to the table detailing max buffer for every profile? Thanks


Sent from my iPhone using Tapatalk

For x264 look at https://en.wikipedia.org/wiki/Advanced_Video_Coding under Levels

For x265 look at https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding or for a more detailed deep dive at https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding_tiers_and_levels

For my encodes I use 1080p:--vbv-bufsize 20000 --vbv-maxrate 20000 and for 2160p:--vbv-bufsize 25000 --vbv-maxrate 25000, so that I make sure to meet DXVA requirements for some older finicky set top boxes.

[benwaggoner]

What values would you suggest for vbv buffer when encoding 1080p and 2160p in 2 pass. Maybe a guide or a table. Thanks alot


Sent from my iPhone using TapatalkBy default I'll use the maximum values defined by the Profile, Tier, and Level. Wikipedia's HEVC article has a very nice table.

Sent from my SM-T837V using Tapatalk

[benwaggoner]

Hello guys,

Any good, accurate and easy way to convert h265 HDR bt2020 to SDR bt709 using Avisynth/Vapoursynth (maybe via Staxrip)?
Something like what madVR is doing, without all the troubles.There is no "accurate" way to do this. HDR and SDR masters are actually done as seperate creative passes, emphasizing different visual elements. They get approved seperately by the creatives before release.

If you want 709, best to start with the 709 source. There is almost no HDR content that isn't also available in SDR.

Sent from my SM-T837V using Tapatalk

[benwaggoner]

yeah... avx512 produces much more heat... :( so probably safety issue...This was also true of the initial AVX2 implementation, but the more recent ones get much better. I hope we'll see much more perfomant AVX-512 in the next-gen Xeon.

Still, MCW claims that performance gains can be found with it at slower presets at 4K, and I've got some test 8K samples to check.

Sent from my SM-T837V using Tapatalk

[Atak_Snajpera]

This was also true of the initial AVX2 implementation, but the more recent ones get much better. I hope we'll see much more perfomant AVX-512 in the next-gen Xeon.

Still, MCW claims that performance gains can be found with it at slower presets at 4K, and I've got some test 8K samples to check.

Sent from my SM-T837V using Tapatalk

Avx512 won't help xeons when AMD just Has epyc2/threadriper 3990x with 2x more cores ;)
Personally I prefer 2x more cores supporting avx-256 than 28 cores with avx-512.
Besides Intel Has created a huge mess with that extension.

https://pbs.twimg.com/media/DXSRqJXXUAE0s4J?format=jpg&name=small

[nevcairiel]

Besides Intel Has created a huge mess with that extension.

https://pbs.twimg.com/media/DXSRqJXXUAE0s4J?format=jpg&name=small

That "mess" looks far better if you remove the Knights Landing/Knights Mill stuff, which is only on Xeon Phi and of no relevance to something like x265 anyway - and Cannon Lake is dead, so could also remove that circle.

So what software currently does is develop against the Skylake-X subset (like x265 did), or the Icelake subset if they want to use more advanced features in the future. Two levels to care about, really. Before AVX512, we also had a number of small additional sets to augment SSE and AVX, but those get rarely talked about, since many of them arrived with AVX(2) at the same time. There were FMA3 and FMA4 of course (one for Intel, one for AMD, although AMD switched over in later CPUs), BMI1 and BMI2, XOP, and probably more that are of no direct video relevance that I forgot.

[benwaggoner]

Avx512 won't help xeons when AMD just Has epyc2/threadriper 3990x with 2x more cores ;)
Personally I prefer 2x more cores supporting avx-256 than 28 cores with avx-512.

I'm testing on the hardware I have, which is basically a c5.18xlarge.

[benwaggoner]

I'm testing on the hardware I have, which is basically a c5.18xlarge.
Anyhoo, I encoded 2400 frames of some 8K source with preset slower with and without AVX512.

Just one test run, but I got 1.41 fps with AVX512 and 1.38 without. Also, my office got warm :sly:.

[Blue_MiSfit]

Oh I see. Can you refer me to the table detailing max buffer for every profile? Thanks


Sent from my iPhone using Tapatalk

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

[estir]

While SSIM is (much) better than PSNR, it isn't perfect.

It's not much better. it's not even always better than PSNR.
Anyway PSNRHVS is better than both of them (better even than MS-SSIM), but for some reason no modern codec uses it for RDO.

[filler56789]

x265.exe 3.2+29-c5ff729 has arrived.

http://msystem.waw.pl/x265/

[Barough]

x265 v3.2+31-6b348d5b56d8 (https://www.mediafire.com/file/xqehtwj1ipbhief/x265-3.2+31-6b348d5b56d8_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[l00t]

yeah... avx512 produces much more heat... :( so probably safety issue...

But why? The CPU is at 60oC at 100%, it should allow higher clocks...

[redbtn]

Umm, hdr-opt replaced to hdr10-opt. Is it mean that hdr-opt does nothing in previous releases?

[microchip8]

Umm, hdr-opt replaced to hdr10-opt. Is it mean that hdr-opt does nothing in previous releases?

No, it got replaced to make it more clear that it's meant for HDR10 content

[redbtn]

No, it got replaced to make it more clear that it's meant for HDR10 contentYeah, I mean it does nothing for hrd content. I used it for a year, thinking it doing optimization for HDR.

[microchip8]

Yeah, I mean it does nothing for hrd content. I used it for a year, thinking it doing optimization for HDR.

How do you know?

[iwod]

I am wondering if x265 has any plans for VVC / H.266? We are may be 6 months away from it being finalised.

[redbtn]

How do you know?

This patch deprecates the existing option '--hdr-opt' as the name sounds generic
even though the feature does QP optimizations only for HDR10 content
So i guess for HDR it doesn't nothing.

[nevcairiel]

So i guess for HDR it doesn't nothing.

"HDR" by itself means nothing. Its a marketing name, and does not describe any sort of specific video format for which one could optimize for.

What kind of HDR? HDR10/PQ? HLG? DV?

Thats why the name of the option was changed. HDR by itself is a category of formats, not any specific format one could apply any optimizations for.

[Boulder]

As far as I know, --hdr-opt simply did/does some adjustments to the encoding parameters. You could apply it to SDR content if you like. Not that it would be useful though..

[benwaggoner]

As far as I know, --hdr-opt simply did/does some adjustments to the encoding parameters. You could apply it to SDR content if you like. Not that it would be useful though..
It would be counterproductive in fact. IIRC, hdr10-opt adjusts delta qp for chroma based on luma levels to better match the characteristics of the PQ EOTF. By default x265 is more optimized for gamma. hdr10-opt would thus be bad for 709 or HLG. Dolby Vision, except in profiles that have a backwards compatible PQ base layer, doesn't even use Y'Cb'Cr, and in Profile 5 does some crazy dynamic range adjustments, so not helpful there.

There's probably fruitful research to be done for how to adapt chroma qp relative to luma based on each macroblock's luma levels in a psychovisual model.

[utack]

I am surprised how much difference "slower" makes compared to "slow"
It is probably expected due to all the extra bframes giving a quality gain and much more lookahead making different choices what to prioritize, but was not fully aware of it before testing.

[Barough]

x265 v3.2+34-8e6db24c1517 (https://www.mediafire.com/file/m9c8l1z59z1t2zr/x265-3.2+34-8e6db24c1517_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default

[benwaggoner]

I am surprised how much difference "slower" makes compared to "slow"
It is probably expected due to all the extra bframes giving a quality gain and much more lookahead making different choices what to prioritize, but was not fully aware of it before testing.
I've kinda thought of slower as the first "real" x265 preset, where most of the stuff that makes HEVC better are in play. The quality gap between slower and placebo is smaller than that between slow and slower.

Except for lossless, where placebo has a pretty significant efficiency gain over even veryslow.

[Blue_MiSfit]

I'd say "Slow" is a good compromise, but yeah, "Slower" is really where all the magic happens :)

[Magik Mark]

I have 16 threads CPU. Is there a way to instruct x265 to use only 14?

Need the rest for other apps

[Atak_Snajpera]

I have 16 threads CPU. Is there a way to instruct x265 to use only 14?

Need the rest for other apps

I would just run x265.exe in IDLE priority. You may also use Process Explorer to change affinity to only 14 logical processors.

[vpupkind]

It would be counterproductive in fact. IIRC, hdr10-opt adjusts delta qp for chroma based on luma levels to better match the characteristics of the PQ EOTF. By default x265 is more optimized for gamma. hdr10-opt would thus be bad for 709 or HLG. Dolby Vision, except in profiles that have a backwards compatible PQ base layer, doesn't even use Y'Cb'Cr, and in Profile 5 does some crazy dynamic range adjustments, so not helpful there.

There's probably fruitful research to be done for how to adapt chroma qp relative to luma based on each macroblock's luma levels in a psychovisual model.
ISO/IEC 23008-14 does that. I haven't had too much luck with their recommendations -- they destroyed textures in very bright scenes (think icy mountains).

[benwaggoner]

I have 16 threads CPU. Is there a way to instruct x265 to use only 14?
--pools "14" should exactly limit it to 14 cores.

https://x265.readthedocs.io/en/default/threading.html#thread-pools

[Rousseau]

x265 v3.2+34-8e6db24c1517 (https://www.mediafire.com/file/m9c8l1z59z1t2zr/x265-3.2+34-8e6db24c1517_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265/commits/branch/default


multi-pass-opt-analysis / distortion causes a crash in this build.

[Magik Mark]

--pools "14" should exactly limit it to 14 cores.



https://x265.readthedocs.io/en/default/threading.html#thread-pools



Thanks alot!


Sent from my iPhone using Tapatalk

[jlpsvk]

Is there any way to fully utitlise x265 with single process (without distrubuted encoding) on Ryzen 9 3950X (16c/32t) without quality loss? :)

[benwaggoner]

Is there any way to fully utitlise x265 with single process (without distrubuted encoding) on Ryzen 9 3950X (16c/32t) without quality loss? :)
What resolution are you encoding to?

--preset slower --pmode --pme should saturate most systems. Although it's often faster to leave out --pmode and --pme if the cores/pixels ratio isn't that high. The goal is to maximize fps, not CPU load. PMode is typically a lot more useful than PME, which I've only seen to be helpful at SD resolutions and below.

PMode and PME don't have any negative quality impact, and pmode can actually help a trifle, potentially.

Doing 2160p on an 18/36 system encoding is ~30% faster without pmode than with it, even though CPU load is about 50% versus ~90%.

[Boulder]

--pmode can have a negative impact in CRF mode, so be warned. I just experienced that.. it produced a lower bitrate than without --pmode at the same settings at CRF 18, and I happened to check a scene with a heavily noisy picture. The dancing of the noise was much uglier than in a test encode without --pmode.

[Atak_Snajpera]

Is there any way to fully utitlise x265 with single process (without distrubuted encoding) on Ryzen 9 3950X (16c/32t) without quality loss? :)

--ctu 32

[benwaggoner]

--ctu 32
Right! There are other ways to increase parallelism, at the risk of some hits to compression efficiency. However, with a whole lot of cores, quality @ perf might have a different optimal configuration, like using more frame thread and a higher RD level. Other parameters in the same bucket:

-F >4 (this had quality hits in older versions; not sure of the impact in 3.x)
--lookahead slices >8 (It seems like this shouldn't have a quality hit, but it is 1 in the slowest presets)

Another thing that might help (haven't tested) without impacting quality is --selective-sao 2. SAO itself limits parallelism somewhat per https://x265.readthedocs.io/en/default/threading.html. So turning it off for B-frames could help. Although it's also possible that the latency hit is fixed whenever SAO is on at all, so --no-sao might help, although with efficiency hits, particularly at lower bitrates. Worth testing.

[benwaggoner]

--pmode can have a negative impact in CRF mode, so be warned. I just experienced that.. it produced a lower bitrate than without --pmode at the same settings at CRF 18, and I happened to check a scene with a heavily noisy picture. The dancing of the noise was much uglier than in a test encode without --pmode.
Oh, good tip! That isn't supposed to happen in theory. You should provide a bug report and repro to MultiCoreWare so they can look at this deeper.

[jlpsvk]

What resolution are you encoding to?

--preset slower --pmode --pme should saturate most systems. Although it's often faster to leave out --pmode and --pme if the cores/pixels ratio isn't that high. The goal is to maximize fps, not CPU load. PMode is typically a lot more useful than PME, which I've only seen to be helpful at SD resolutions and below.

PMode and PME don't have any negative quality impact, and pmode can actually help a trifle, potentially.

Doing 2160p on an 18/36 system encoding is ~30% faster without pmode than with it, even though CPU load is about 50% versus ~90%.

I am encoding 2160p, with CRF16.

[Boulder]

--lookahead slices >8 (It seems like this shouldn't have a quality hit, but it is 1 in the slowest presets)

This probably affects frame type decision, at least that's what I observed when using four lookahead slices compared to just one.



--pmode can have a negative impact in CRF mode, so be warned. I just experienced that.. it produced a lower bitrate than without --pmode at the same settings at CRF 18, and I happened to check a scene with a heavily noisy picture. The dancing of the noise was much uglier than in a test encode without --pmode.
Oh, good tip! That isn't supposed to happen in theory. You should provide a bug report and repro to MultiCoreWare so they can look at this deeper.

It's probably due to the encoder doing deeper analysis as some performance related early skips are avoided. Nevertheless, I got a clip of the scene for my testing toolkit and I can definitely create a ticket for the issue. Maybe there is something there to fix.

[jlpsvk]

i tested, and without pme and pmode, it's faster. :D

[microchip8]

Right! There are other ways to increase parallelism, at the risk of some hits to compression efficiency. However, with a whole lot of cores, quality @ perf might have a different optimal configuration, like using more frame thread and a higher RD level. Other parameters in the same bucket:

-F >4 (this had quality hits in older versions; not sure of the impact in 3.x)
--lookahead slices >8 (It seems like this shouldn't have a quality hit, but it is 1 in the slowest presets)

Another thing that might help (haven't tested) without impacting quality is --selective-sao 2. SAO itself limits parallelism somewhat per https://x265.readthedocs.io/en/default/threading.html. So turning it off for B-frames could help. Although it's also possible that the latency hit is fixed whenever SAO is on at all, so --no-sao might help, although with efficiency hits, particularly at lower bitrates. Worth testing.

I have tested a few samples with SAO and selective-sao set to 2. I find the result looking too soft. Without it, there's more detail present. But if others like it, who am I to stop them? :)

[jlpsvk]

I have tested a few samples with SAO and selective-sao set to 2. I find the result looking too soft. Without it, there's more detail present. But if others like it, who am I to stop them? :)

exactly... my 2160p HDR10 preset currently...any suggestions?

--preset slow --profile main10 --level-idc 5.1 --output-depth 10 --crf 16 --ctu 64 --aq-mode 4 --merange 57 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr10 --hdr10-opt --repeat-headers --no-info --no-deblock --no-sao --selective-sao 0 --allow-non-conformance --no-strong-intra-smoothing --high-tier --chromaloc 2
--fades --hme --hme-search umh,umh,star

[microchip8]

exactly... my 2160p HDR10 preset currently...any suggestions?

--preset slow --profile main10 --level-idc 5.1 --output-depth 10 --crf 16 --ctu 64 --aq-mode 4 --merange 57 --amp --no-rskip --qg-size 8 --vbv-bufsize 160000 --vbv-maxrate 160000 --bframes 8
--rc-lookahead 48 --gop-lookahead 30 --hdr10 --hdr10-opt --repeat-headers --no-info --no-deblock --no-sao --selective-sao 0 --allow-non-conformance --no-strong-intra-smoothing --high-tier --chromaloc 2
--fades --hme --hme-search umh,umh,star

I'd set deblock to -1,-1 instead of completely disabling it - deblock has seen a major revision compared to x264.

Also strong-intra-smoothing seems to have a positive effect at keeping noise. Many people are scared by the name but I find it does improve things a bit. It will help reduce banding on very clean scenes too, like skies or other clean textures, by blending a bit instead of keeping the banding

merange has no effect when using HME since the latter has its own range parameters you can adjust with --hme-range

[Boulder]

Ben Waggoner was doing some tests with --aq-mode 4, I don't think he got them finished though. He's probably the only one (apart from the devs) who has some kind of an insight to how it looks with real life examples.

For what it's worth, lately I've found --aq-mode 3 being troublesome. With normal sources originating from film, like the older seasons of X-Files which contain quite a lot of grain and noise, it works well at around ~0.6 for strength. Then there's something like Suits, or The Killing, which look terrible. The sources are terrible in quality -- lots of macroblocking which appears when the encoder starts removing the grain hiding some of that -- and aq-mode 3 produces a substantially lower average bitrate at the same CRF than aq-mode 1. I don't know why the rate control works this way, The Killing does contain quite a lot of dark scenes but I was unable to get a good result without switching to --aq-mode 1 at the default strength. I also raised psy-rd to 3.0 and deblock to 0:0 to try to keep the higher frequencies and avoid banding where the encoder removes too much from the original image.

I really scratched my head at the issue the whole weekend. Yes, I did test x264 at --preset veryslow, but it wasn't any better :)

Sometimes I have used a dirty trick and added a light amount of fake grain with GrainFactory3 before feeding the video to the encoder. I may need to test that too :devil:

[microchip8]

Ben Waggoner was doing some tests with --aq-mode 4, I don't think he got them finished though. He's probably the only one (apart from the devs) who has some kind of an insight to how it looks with real life examples.

For what it's worth, lately I've found --aq-mode 3 being troublesome. With normal sources originating from film, like the older seasons of X-Files which contain quite a lot of grain and noise, it works well at around ~0.6 for strength. Then there's something like Suits, or The Killing, which look terrible. The sources are terrible in quality -- lots of macroblocking which appears when the encoder starts removing the grain hiding some of that -- and aq-mode 3 produces a substantially lower average bitrate at the same CRF than aq-mode 1. I don't know why the rate control works this way, The Killing does contain quite a lot of dark scenes but I was unable to get a good result without switching to --aq-mode 1 at the default strength. I also raised psy-rd to 3.0 and deblock to 0:0 to try to keep the higher frequencies and avoid banding where the encoder removes too much from the original image.

I really scratched my head at the issue the whole weekend. Yes, I did test x264 at --preset veryslow, but it wasn't any better :)

Sometimes I have used a dirty trick and added a light amount of fake grain with GrainFactory3 before feeding the video to the encoder. I may need to test that too :devil:

I did my own testing, both with AQ mode 2 and 3. It did not make things beter here and I was hoping AQ mode 3 would work well on dark scenes, but it didn't. All I saw is increased bitrate for 2 and 3 with no meaningful improvements... so I went back and stick to my good ol' AQ mode 1

As for psy-rd/psy-rdoq, they are meant to keep the original energy of the source as much as possible at higher strength. So if you have a (very) noisy sample, the bitrate will shoot up in order to preserve the noise/grain. These two settings are set to high values when using --tune grain (psy-rd is set to 4 and psy-rdoq is set to 10). I personally now use psy-rd of 3.2 and psy-rdoq of 15. I do not mind the increase of bitrate as I aim to preserver the input as much as possible. These two especially have an effect on dark scenes and look better than using AQ mode 2 or 3. I haven't tested AQ mode 4, though

[benwaggoner]

Ben Waggoner was doing some tests with --aq-mode 4, I don't think he got them finished though. He's probably the only one (apart from the devs) who has some kind of an insight to how it looks with real life examples.
I finished making the content but not my comparisons. Thanks for the reminder to take a look again.

For what it's worth, lately I've found --aq-mode 3 being troublesome. With normal sources originating from film, like the older seasons of X-Files which contain quite a lot of grain and noise, it works well at around ~0.6 for strength. Then there's something like Suits, or The Killing, which look terrible. The sources are terrible in quality -- lots of macroblocking which appears when the encoder starts removing the grain hiding some of that -- and aq-mode 3 produces a substantially lower average bitrate at the same CRF than aq-mode 1. I don't know why the rate control works this way, The Killing does contain quite a lot of dark scenes but I was unable to get a good result without switching to --aq-mode 1 at the default strength. I also raised psy-rd to 3.0 and deblock to 0:0 to try to keep the higher frequencies and avoid banding where the encoder removes too much from the original image.
Maybe throw in some --nr-inter? That tends to reduce grain swirling and lower QPs a bit at the same bitrate.

[benwaggoner]

I did my own testing, both with AQ mode 2 and 3. It did not make things beter here and I was hoping AQ mode 3 would work well on dark scenes, but it didn't. All I saw is increased bitrate for 2 and 3 with no meaningful improvements... so I went back and stick to my good ol' AQ mode 1
The AQ comparisons really need to be made with 2-pass VBR to compare bitrates. Different AQ modes can require different CRF values in practice.

[microchip8]

The AQ comparisons really need to be made with 2-pass VBR to compare bitrates. Different AQ modes can require different CRF values in practice.

I have no need for 2-pass VBR. I only do CRF encoding and that's what matters to me but also tested in 2-pass as you recommended previously in a post a week or so ago. Not much improvement. I find psy-rd/rdoq delivering better results than these AQ modes

[Boulder]

If you want to try things, I uploaded the sample clip I used to test: https://drive.google.com/open?id=1Ar0sKvjc6ygGtmW6DA5cr6UNO1WjfV7- . Take a look at the flat background in the shots with the cop, it's ugly in the source and gets much worse after encoding.

[benwaggoner]

I have no need for 2-pass VBR. I only do CRF encoding and that's what matters to me but also tested in 2-pass as you recommended previously in a post a week or so ago. Not much improvement. I find psy-rd/rdoq delivering better results than these AQ modes


Right. But if you want to figure out the optimum efficiency for a CRF encode, comparing the features in 2-pass VBR shows you how features compare at the same file size. Once you nail down the optimum parameters, then you figure out what CRF is optimal for you with those other parameters.

[microchip8]

Right. But if you want to figure out the optimum efficiency for a CRF encode, comparing the features in 2-pass VBR shows you how features compare at the same file size. Once you nail down the optimum parameters, then you figure out what CRF is optimal for you with those other parameters.

I won't be bothered doing this. At the moment I'm quite happy with my own setting for CRF @ 21. I increased some of them by a small amount to give it a bit more headroom. If I can compress a source of say 22-25 GiB down to 5-6 or 7 GiB (with decent quality according to my eyes), I'm a happy camper

[zerowalker]

Annoying question but might as well ask it.

It was a long time ago since i checked out x265, probably like 2 years ago, and back then x264 was better except for edge cases which was very low bitrate and very high resolutions mostly.
And then it looked crap anyway so even if x265 won it didn't really matter (for me).

How is it nowadays (know it's a vague question)?

If you have like a 1080p video and use crf=16 (which i would say results in high quality for x264 at least) would x265 achieve the "same quality" for less space?
Or is it only in very high resolutions like 4k and beyond that x265 can outdo it cause of how it works?

I know it sounds like i am saying x265 is crap compared to x264, but that's not what i am trying to say, but it's hard to ask the comparison question without making it sound that way.
I am not denying x265 nor the standard h265, it's obviously made for a good reason and the encoder is surely aiming to be as great as possible compared to what currently exists (either for all or some cases),
i just don't know that much about it except that the standard was made with very high resolutions in mind as h264 breaks down quickly there except with very high bitrates (which is the "throw money at the problem" solution usually;P).

Thanks:)

[MeteorRain]

zerowalker, I can't answer your question but I do have a question for you. Were you using 10-bit and were you comparing 10-bit x265 against 8-bit x264?

We / I switched to x265 simply because we wanted to use 10-bit and AVC High10 had some compatibility issues with hardware players.

[benwaggoner]

If you have like a 1080p video and use crf=16 (which i would say results in high quality for x264 at least) would x265 achieve the "same quality" for less space?
Or is it only in very high resolutions like 4k and beyond that x265 can outdo it cause of how it works?

If you're trying to get the best image in a fixed amount of bits, x265 beats x264 in the large majority of scenarios. A big part of this is you can use HEVC at a higher resolution, preserving a lot more detail by preserving more pixels. CRF comparisons are more complex, as it's not a linear relationship. Even just using x264 the same CRF gives different results depending on other parameters.

The biggest problem with x265 years ago was how it handled grain, which is much improved now.

[birdie]

Annoying question but might as well ask it.

It was a long time ago since i checked out x265, probably like 2 years ago, and back then x264 was better except for edge cases which was very low bitrate and very high resolutions mostly.

This is still largely true: x265 is better for resolutions above 1080p and for very low bitrates (which are mostly suitable for streaming anyways).

[LigH]

But the general rule remains: There is no magic. Size reduction requires a loss of quality. It's just a matter how annoying you rate this kind of loss.

[LigH]

The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?

[filler56789]

The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

1) Thanks for the info *THUMBS UP*

2)

downloading with Mercurial = 35.4 MB, very fast;

downloading with git = 290 MB, very slow;

x265_git\.git\objects\pack\pack*.pack = 276 MB — ¿what the devil is that?

[Boulder]

The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?

I think an initial "git clone" followed by "git pull" every time you need to update would do. You may need to set the branch which you want to follow, I don't have any knowledge on that.

[MeteorRain]

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?

If you are not used to Git, I strongly recommend using a GUI to help learning. Personally I love SmartGit the best, but it's a proprietary software (free for non-commercial use).

Pull updates from remote to local is "git fetch".

Pull updates from local to working directory is "git checkout".

Git is much more flexible (and thus harder to use) that's why I always recommend people to use a GUI to get started. There are more concepts in Git than in Hg and it takes time to get used to.

[filler56789]

Just re-checking...

the latest cloned x265/.hg directory = 23.2 MB
Apparently the "conversion" of x265's Hg repository into git included or added some TONS of *garbage*...

[MeteorRain]

I don't understand the point of mentioning the size of the repository.
I use Git not for saving 200MB of space, but for managing the source code.
I'd happily trade a few gigabytes of my "precious?" hard drive space for a tool that works better to me.

To answer your previous question, git object pack is a compressed package of all kinds of objects used by git, including histories, files, deltas, etc.
If network activity is a real concern to you, you can limit the depth of repository to download. You can choose to only download and store the most recent 500 commits, for example, and still work on that as long as you don't need access to history more than 500 commits back.

[qyot27]

The x265 source repo will migrate to Git and move to https://bitbucket.org/multicoreware/x265_git/ (Bitbucket will drop Mercurial support until June 2020).

Previously I used the combo of "hg pull" and "hg update" to keep a local working directory up to date. Which would be the recommended Git commands?
Easy:
git pull (like was mentioned above)

More exact (like when following more than one upstream HEAD):
git fetch <remote>
git merge <remote>/<branch>

which would look like:
git fetch origin
git merge origin/master (to update the master branch to its current remote state)


If you don't care about being able to recover the file or commit history and just want raw download speed:
git clone --depth 1 https://bitbucket.org/multicoreware/x265_git

Git is, as others have noted elsewhere, basically a time-based file system that happens to work great as a DVCS. Mercurial is just a DVCS.

[filler56789]

...
If you don't care about being able to recover the file or commit history and just want raw download speed:
git clone --depth 1 https://bitbucket.org/multicoreware/x265_git

:goodpost: :thanks:

I don't understand the point of mentioning the size of the repository.
I use Git not for saving 200MB of space, but for managing the source code.
I'd happily trade a few gigabytes of my "precious?" hard drive space for a tool that works better to me.


Because the size of the hg repository is much smaller than the git one?
Because I'm old and therefore much more impatient than you?
Because I think that "huge and cheap" storage space is not an excuse for inefficiency?

To answer your previous question, git object pack is a compressed package of all kinds of objects used by git, including histories, files, deltas, etc.

Then it compresses much worse than hg, or at least it seems so...

If network activity is a real concern to you, you can limit the depth of repository to download. You can choose to only download and store the most recent 500 commits, for example, and still work on that as long as you don't need access to history more than 500 commits back.

Yes, my interest in x265's source-code is only to download and compile its most recent stuff, I have no use for a 300 MB """compressed""" archive that is not the code that I intend to compile.

[MeteorRain]

Then do a shallow clone like we posted.
We are developers and functionality is much more important for us than a few hundred megabytes.
No, huge and cheap storage is not an excuse for inefficiency, however this is not inefficiency, this is only "space" inefficiency.
You don't say ffmpeg is garbage because it's a 60MB binary.

BTW, compared to a few seconds of downloading, the actual compiling is much more time consuming.
I'm too impatient but each time I compile my x265 mod it will take a good 2 hours on a Xeon E5 server.

[LigH]

Since the media-autobuild suite switched to the x265 Git repository, I have trouble retrieving the sources. It seems like git receives all the expected data, but then suddenly handles the closing connection as if it was interrupted in an error. Here from an interactive MSYS2/MinGW console:

$ git clone https://bitbucket.org/multicoreware/x265_git.git x265_git-git
Cloning into 'x265_git-git'...
remote: Counting objects: 88154, done.
remote: Compressing objects: 100% (88115/88115), done.
remote: Total 88154 (delta 2853), reused 85263 (delta 0)
error: RPC failed; curl 56 OpenSSL SSL_read: Connection closed abruptly, errno 0 (Fatal because this is a curl debug build)
Receiving objects: 100% (88154/88154), 277.47 MiB | 1.58 MiB/s, done.
Resolving deltas: 100% (2853/2853), done.

Retrieving Git repositories from other sources works without error. So I wonder if Bitbucket may handle little details differently. If so ... I may not be able to report this issue to Bitbucket, as I am not the Atlassian customer responsible for the x265 repo.

[LigH]

I'll see if this Windows 7 hotfix (https://support.microsoft.com/en-us/help/981344/an-application-may-receive-the-10054-error-when-the-application-receiv) has any impact...

Oh, it has been discontinued. I need Windows 10 to solve it. :p

Or it is a different one? It's errno 0, not SysCall 10054.

Cloning x264 and dependent ffmpeg/ffms2/lsmash works without abort.

:eek:

After x264 was retrieved (I deleted build/x264-git), now x265 was retrieved too? ... Strange technology. :o

[Barough]

No issues with the change to x265 git. Just running smooth here.

Sent from my SM-G975F via Tapatalk

[foxyshadis]

I'll see if this Windows 7 hotfix (https://support.microsoft.com/en-us/help/981344/an-application-may-receive-the-10054-error-when-the-application-receiv) has any impact...

Oh, it has been discontinued. I need Windows 10 to solve it. :p

Or it is a different one? It's errno 0, not SysCall 10054.

Cloning x264 and dependent ffmpeg/ffms2/lsmash works without abort.

:eek:

After x264 was retrieved (I deleted build/x264-git), now x265 was retrieved too? ... Strange technology. :o

Git is an abominable piece of trash IMHO, but it's what we're stuck with, since hg is rapidly disappearing. (I'm going to have to convert all of my repos, too.) 99% of all git problems are best solved by just deleting the entire folder and cloning from scratch. Sometimes a hard revert will also do the trick, but not as reliably. If you have changes, just try to pull a patch and reapply after.

[LigH]

Cloning was just the problem. Or handling the HTTPS connection.

[MeteorRain]

Try ssh protocol instead?

[LigH]

Well, it suddenly worked once (when I let it clone x264 before x265). Maybe just something on my PC was out of sync.

[filler56789]

x265.exe 3.3_RC1+2-e386d3a8a713

(64-bits, multilib, GCC 9.2, Win32-threads)

regression: fix analysis-save/load commands

http://www.mediafire.com/file/qnc7l7eiohbiejq/x265_3.3_RC1%252B2-e386d3a8a713.rar/file

[nakTT]

x265.exe 3.3_RC1+2-e386d3a8a713

(64-bits, multilib, GCC 9.2, Win32-threads)

regression: fix analysis-save/load commands

http://www.mediafire.com/file/qnc7l7eiohbiejq/x265_3.3_RC1%252B2-e386d3a8a713.rar/file
Any interesting changes from version 3.2?

[Greenhorn]

Any interesting changes from version 3.2?

Against the last 3.2x nightly builds, or against 3.2 release?

Against the former, just what's mentioned. Against the latter: --hist-scenecut to enable a different method of selecting scenecuts, --scenecut-aware-qp to apply an offset to the qp of keyframes and the frames immediately after them, and a more or less total overhaul of how the analysis-save/load feature works. Probably more that I'm not remembering.

[nakTT]

Against the last 3.2x nightly builds, or against 3.2 release?

Against the former, just what's mentioned. Against the latter: --hist-scenecut to enable a different method of selecting scenecuts, --scenecut-aware-qp to apply an offset to the qp of keyframes and the frames immediately after them, and a more or less total overhaul of how the analysis-save/load feature works. Probably more that I'm not remembering.
Thanks for the reply. My question was against 3.2 release, sorry for not being specific. BTW, was there any changes related to improved compression? Thank you in advance.

[benwaggoner]

Thanks for the reply. My question was against 3.2 release, sorry for not being specific. BTW, was there any changes related to improved compression? Thank you in advance.Yes, the improved scene detection and optimized QP around scene transitions will both improve compression efficiency. The quality of frames around edits will be better at the same bitrate.

Sent from my SM-T837V using Tapatalk

[filler56789]

x265.exe 3.3+3-c2769ac5fa9d

Release notes: https://bitbucket.org/multicoreware/x265/src/057215961bc4b51b6260a584ff3d506e6d65cfd6/doc/reST/releasenotes.rst

download: http://www.mediafire.com/file/op10k0vpygdq3du/x265_3.3%252B3-c2769ac5fa9d.7z/file

[nakTT]

Yes, the improved scene detection and optimized QP around scene transitions will both improve compression efficiency. The quality of frames around edits will be better at the same bitrate.

Sent from my SM-T837V using Tapatalk
Thanks for the reply. Glad to know they are still improving the compression efficiency even after years of develoment.

x265.exe 3.3+3-c2769ac5fa9d

Release notes: https://bitbucket.org/multicoreware/x265/src/057215961bc4b51b6260a584ff3d506e6d65cfd6/doc/reST/releasenotes.rst

download: http://www.mediafire.com/file/op10k0vpygdq3du/x265_3.3%252B3-c2769ac5fa9d.7z/file
Thanks, will give it a try.

[Boulder]

Yes, the improved scene detection and optimized QP around scene transitions will both improve compression efficiency. The quality of frames around edits will be better at the same bitrate.

Have you made any tests concerning the new functionalities? They once again appeared without any use cases etc.

[benwaggoner]

Have you made any tests concerning the new functionalities? They once again appeared without any use cases etc.
Not myself yet. I'm currently at the HPA tech retreat. I should have some physical and CPU time to run some tests next week.

I didn't mention the Adaptive frame duplication feature. This promises some significant efficiency savings and also faster random access for content where there are identical frames. Credits, screen activity, and anime/cel animation seem particularly likely to get improvements.

I wish there was an optional flag that can allow --keyint to limit total encoded frames, so --keyint 240 would mean 240 unique coded frames. Thus, with 24 fps where the animation is at 8 fps (so three duplicate frames in a row), --keyint 240 would yield a GOP covering 30 seconds instead of 10. Not great for adaptive streaming, but could save space for a file without impacting random access.

[benwaggoner]

Thanks for the reply. Glad to know they are still improving the compression efficiency even after years of develoment.
Encoders are never done; we're still seeing improvements to MPEG-2 encoding after all these years. Particularly as long as Moore's Law keeps happening, we'll always find ways to take advantage of more MIPS/pixel.

With a codec as complex as HEVC, I would expect we'll be seeing material year-on-year encoder improvements for at least another five years.

[Boulder]

Not myself yet. I'm currently at the HPA tech retreat. I should have some physical and CPU time to run some tests next week.

I just did a very quick test myself, encoded my Hot Fuzz testclip with --hist-scenecut and it looks like the default settings are way off. 1220 frames of which 251 were I-frames :confused:.. The normal encode would have 12 I-frames (max keyint 480), which looks about the correct amount of true scene changes there.

[LigH]

How do I retrieve version 3.3+3 via git? I only get version 3.3+1 via git pull origin master (in MSYS2) and the TortoiseGit Revision Graph (in Windows) tells me this is the HEAD.

[Greenhorn]

How do I retrieve version 3.3+3 via git? I only get version 3.3+1 via git pull origin master (in MSYS2) and the TortoiseGit Revision Graph (in Windows) tells me this is the HEAD.

All 3 branches appear to be at version 3.3+1 with different commit numbers; the two patches after 3.3+1 consisted solely of merging the Master branch with the Stable and Release_3.3 branches.

(IDK anything about any VCS, so I have no idea if this is as expected or not-- but my point being, the latest files at the moment will be tagged 3.3+1.)

[benwaggoner]

I just did a very quick test myself, encoded my Hot Fuzz testclip with --hist-scenecut and it looks like the default settings are way off. 1220 frames of which 251 were I-frames :confused:.. The normal encode would have 12 I-frames (max keyint 480), which looks about the correct amount of true scene changes there.Have you looked at where the cuts are relative to the IDR frames? Is it sticking IDRs in the middle of shots?

Sent from my SM-T837V using Tapatalk

[LigH]

Let's assume those are the tiny differences between Git and Mercurial, regarding the counting of version numbers and patch increments. Hard to compare "the same build" then ... :rolleyes:
_

PS:

In previous versions I was used to reading only CMake output on the console while x265 is built. Now, suddenly, make clutters the output by reporting verbosely that it is e.g. entering and leaving directories. May that be a new default behaviour of make, of the shell, or of the media-autobuild suite having set an environment variable in a way that it changes the output also in interactive shell mode?


x265 3.3+1-g396395b2b (https://www.mediafire.com/file/gtrc6wzf1gofi9o/x265_3.3+1-g396395b2b.7z/file)

[filler56789]

LigH's latest build of x265.exe says:

version = 3.3+1-g396395b2b

whereas the latest build of x265.exe by http://msystem.waw.pl/x265/ says:

version = 3.3+1-g554c887ac

But according to the page https://bitbucket.org/multicoreware/x265/commits/ ,
those commit numbers don't exist.

:confused:

:mad:

:rolleyes:

[LigH]

You are looking in the Mercurial repository, while I got the sources via Git instead (the hash has a g prefix). Try: https://bitbucket.org/multicoreware/x265_git/commits/ (note the x265_git)

Apparently, merges don't increase the patch count for Git; they did in Mercurial, though.

[filler56789]

Yeah, git is a total mess.

Mercurial apparently is less messy.

x264, for example, doesn't add the prefix "g" to the commit number.

x264 0.159.2991 1771b55

[filler56789]

Actually git is not the culprit to blame, but MulticoreWare. It's MulticoreWare's weird strategy to prefix the hash with "g" in its cmake file (https://bitbucket.org/multicoreware/x265/src/30eb4de83092bddcb4497a47bc9d2211dfb69cfc/source/cmake/version.cmake#lines-92).

:goodpost: :thanks:

[Boulder]

Is it sticking IDRs in the middle of shots?

Yes, that's what it does. It looks like motion and camera movement confuses it a lot. It also doesn't respect the min-keyint setting, which I have at 5 but places I-frames right next to each other.

[benwaggoner]

Yes, that's what it does. It looks like motion and camera movement confuses it a lot. It also doesn't respect the min-keyint setting, which I have at 5 but places I-frames right next to each other.


Sounds like time for a bug report to MCW. Min-keyint NEEDS to be respected. Putting in a non-IDR I-frame is okay more often.

Have you tried raising the threshold value?

[Boulder]

Sounds like time for a bug report to MCW. Min-keyint NEEDS to be respected. Putting in a non-IDR I-frame is okay more often.

Have you tried raising the threshold value?

Actually I don't know which type of I-frames they are as the source filter (ffms2 in Vapoursynth) only reports I, P or B. x265 itself also reports only I-frames as well so no help from there.

I could try and file a report tomorrow and also play with the threshold value. I only made one test with the default values to see what happens.

[vpupkind]

Actually I don't know which type of I-frames they are as the source filter (ffms2 in Vapoursynth) only reports I, P or B. x265 itself also reports only I-frames as well so no help from there.

I could try and file a report tomorrow and also play with the threshold value. I only made one test with the default values to see what happens.
Have a look at the x265 logs

[LigH]

Well, ffmpeg uses the "g" prefix too.

Any idea why make became so verbose?

[filler56789]

Well, ffmpeg uses the "g" prefix too.

Blame cehoyos :D

Any idea why make became so verbose?

Just gave a try to the latest git-download from MCW's x265 and saw the problem doesn't happen to me :confused:

Maybe you'd better ask directly to the maintainers of MSYS2, or perhaps to the MABS people...

the [##%] Building etc message format is "induced" (so to speak) by CMake, ¿maybe they have changed something in their latest release? :confused:
I'm using version 3.15.2, FWIW.

My MSYS2 environment is "old" as well, its release date is
*checks notes*
2016/Oct/25

And I stopped executing the command "pacman -Syuu" ages ago for a good reason.

[LigH]

The cmake messages were all I was used to see. Now I see additional make messages; I guess there are two most possible reasons: a) the current make version is so verbose by default now; b) something in the MSYS2 environment changed, and I am not sure if MABS may have caused that.

Now it looks like this to me:

https://frupic.frubar.net/shots/39086.png

[MeteorRain]

Just so you know that Git and Mercurial are not similar at all. They have HUGE differences and I'd rather think they are completely, totally, different kinds of DVCS. Git has a completely different design, different flexibility, different concepts, etc. than HG. If you apply your knowledge from one tool onto the other you'll likely get lost.

One of the biggest difference is anything you do to the HG repository has side effects. For example, creating a branch and making some commits in HG will permanently leave records, such as affecting commit revision numbers, and leaving a permanent branch that, while hidden, cannot be deleted. In Git, branches and commits can be deleted or changed as you wish. Syncing others' work no longer creates diversity between repositories. Conflicts can be resolved in a nicer way.

The Git command line, however, was pretty hard to use. It's inconsistent in many ways. I always recommend people to stick to a great GUI and only use command lines for occasional batch process. Depending on your role it could be very difficult to work on Git CLI. For example, my mod has 4 branches, all of them being rebased frequently, so `git pull` won't work on any of them, and you have to stick to the low level way of `git fetch` and then rebase what you have onto the branches, or use `git checkout` or `git reset` (dangerous) to update current branch reference. If you are a downstream modder (who takes my patches and integrates into your own mod) you'll likely be transplanting commits across projects and branches. Things get complicated very quick.

I'm kinda surprised to read that many replies talking about Git. Hopefully you'd get used to its concept soon.

[LigH]

I noticed that MABS has a quite elaborate helper routine handling Git. So I shall preferably trust its update results. Thank you for your remark, MeteorRain.

And thanks for this workaround parameter, HolyWu.

[vpupkind]

Yes, that's what it does. It looks like motion and camera movement confuses it a lot. It also doesn't respect the min-keyint setting, which I have at 5 but places I-frames right next to each other.


Have you tried higher threshold values? The algorithm does not look at motion, only on colors and texture. They differ a lot when you have a strong scene cut, but low thresholds can result in it false positives.

[Barough]

x265 v3.3+2-gbe2d82093 (http://www.mediafire.com/file/xb0y5n6ckxu2b0j/x265-3.3%252B2-gbe2d82093_Win_GCC920.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.2.0)
https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[Boulder]

Have you tried higher threshold values? The algorithm does not look at motion, only on colors and texture. They differ a lot when you have a strong scene cut, but low thresholds can result in it false positives.

With the default threshold, lots of false positives. Min-keyint is respected as all were i-frames. The only I-frame was right at the beginning of the file, the same in the encode with the standard scenecut detection. Due to open GOP?

Some tests; Hot Fuzz is an easy clip with clear scene cuts. The correct amount of keyframes in the testclip is 13.

Threshold 0.5, it misses all scene changes
Threshold 0.1, it misses a lot of them
Threshold 0.05, it still misses some quite obvious ones
Threshold 0.025, it begins to place too many (29)
Threshold 0.03, still too many (19)
Threshold 0.035, almost the correct amount (14)

The default encoding missed two very obvious scene cuts which the histogram one was able to find. The histogram one had one false detection in a scene of higher motion. The false one was in the middle of the scene and slightly less blurry, and I suspect that red text on a white shirt skewed the detection routine there even more.

[Boulder]

I uploaded the source clip here: https://drive.google.com/open?id=19cIzFGAocSHYlBNJdZJ08OaQbfBIHUjm

To encode, I cropped off the black borders and downscaled with Spline36 to 1280x544. The histogram sc detection picks up frame 805 incorrectly, others seem good to me.
For some reason, I am unable to tweak the --scenecut and --scenecut-bias parameters to get the standard sc detection to pick up frames 380 and 582 which are perfect cuts between scenes.

[foxyshadis]

I uploaded the source clip here: https://drive.google.com/open?id=19cIzFGAocSHYlBNJdZJ08OaQbfBIHUjm

To encode, I cropped off the black borders and downscaled with Spline36 to 1280x544. The histogram sc detection picks up frame 805 incorrectly, others seem good to me.
For some reason, I am unable to tweak the --scenecut and --scenecut-bias parameters to get the standard sc detection to pick up frames 380 and 582 which are perfect cuts between scenes.

At this point, copy-pasting everything you've discovered into the x265 bug tracker sounds like the way to go.

[Boulder]

At this point, copy-pasting everything you've discovered into the x265 bug tracker sounds like the way to go.

Agreed, I'll do that right away.

[Stereodude]

Are there no more Wolfberry x265 builds (since mid 2019) or another x265 build that can open a .avs directly without the need for piping?

[Forteen88]

I'd appreciate it if devs here, that releases x265-builds, comments on what compiling-setting they use!
My favorite is compiler-setting is "Optimization: Compile for speed", although maybe it doesn't matter that much since x265 is mostly coded in assembler.

[Stereodude]

My build (https://forum.doom9.org/showthread.php?p=1901563#post1901563) is compiled with lavf support.
Thanks for pointing that out. I had missed that detail. I hate having to pipe into x265.

[fauxreaper]

Is it viable to make a --frame-dup mode 2 without generating VFR video? I don't know why x265 spends so many bits on duplicated frames.

Example:

1) Download wallpaper on https://wallpaperscraft.com/download/planet_clouds_light_star_94996/1920x1080
2) Create avs with
ImageSource("planet_clouds_light_star_94996_1920x1080.jpg",start=0,end=199,fps=23.976)
3) Encode avs with x265 x64 10bit, crf 22, preset slow and --csv-log-level 2 --csv
4) Open csv and examine used bits

https://i.imgur.com/vSwL4KQ.png

Why frames with 100% skip 64x64 need to use more than one thousand bits? Why the bits variation on duplicated frames, shouldn't almost all of them have similar size in bits?

x264 has much less variation on bitrate with same video. x64, 10bit, crf22.

I've filed an issue on x265's bugtracker, https://bitbucket.org/multicoreware/x265/issues/537/high-bit-cost-and-bit-cost-variation-on

[jlpsvk]

change from 3.3+1 to 3.3.+2 that haven't been mention anywhere??? command give "unknown parameter" with 3.3+2

--no-rskip --> --rskip 0

[benwaggoner]

Is it viable to make a --frame-dup mode 2 without generating VFR video? I don't know why x265 spends so many bits on duplicated frames.

What is mode 2? The syntax just has --frame-dup as a Boolean.

Frame-dup should be fully compatible with constant frame rate, since it is putting in skip frames, not changing frame durations (which was how WMV9 did it back in the day).

[Greenhorn]

change from 3.3+1 to 3.3.+2 that haven't been mention anywhere??? command give "unknown parameter" with 3.3+2

--no-rskip --> --rskip 0

There's information at (https://x265.readthedocs.io/en/default/cli.html) (just search for "rskip"), or if you run x265 --fullhelp from the CLI.

Basically, --rskip 0 is (old) --no-rskip, (old) --rskip 1 is --rskip, --rskip 2 and --rskip 3 use a different method of analysis to decide when to perform the skip. --rskip-edge-threshold controls how much recursion the encoder skips, if you've set --rskip 2 or 3.

From my limited testing it seems to still need

[jlpsvk]

There's information at (https://x265.readthedocs.io/en/default/cli.html) (just search for "rskip"), or if you run x265 --fullhelp from the CLI.

Basically, --rskip 0 is (old) --no-rskip, (old) --rskip 1 is --rskip, --rskip 2 and --rskip 3 use a different method of analysis to decide when to perform the skip. --rskip-edge-threshold controls how much recursion the encoder skips, if you've set --rskip 2 or 3.

From my limited testing it seems to still need

In the docs, there it is, but nowhere in changelog... :) That's what i am talkong about.. I am using --rskip 0 (--no-rskip till now)...

[stax76]

RD Level Rskip Mode Skip Recursion Heuristic

0 - 4 1 Neighbour costs.
5 - 6 1 Comparison with inter2Nx2N.
0 - 6 2 CU edge denstiy.
0 - 6 3 CU edge denstiy with forceful skip for lower levels of CTU.


Is row 1 column 2 correct?

What is the default? --rskip 0 is the same as no --rskip ?

https://x265.readthedocs.io/en/default/cli.html#cmdoption-rskip

I hope I added it correctly.


New OptionParam With {
.Switch = "--rskip",
.Text = "Recursion Skip",
.Expand = True,
.Options = {
"Disabled",
"0 - RD Level 0-4 Neighbour costs",
"1 - RD Level 5-6 Comparison with inter2Nx2N",
"2 - RD Level 0-6 CU edge denstiy",
"3 - RD Level 0-6 CU edge denstiy with forceful skip for lower levels of CTU"},
.Values = {"", "0", "1", "2", "3"}}

[jlpsvk]

@Stax76

--rskip 0 should be DISABLED (should do the same as --no-rskip) according to docs

[Boulder]

So --rskip 1 is now the same as --rskip previously?
Once again, would be very nice to know which use cases would benefit from the other settings. To me it looks like the changes commited lately have something to do with cartoons and anime, which I never touch myself.

[nevcairiel]

RD Level Rskip Mode Skip Recursion Heuristic

0 - 4 1 Neighbour costs.
5 - 6 1 Comparison with inter2Nx2N.
0 - 6 2 CU edge denstiy.
0 - 6 3 CU edge denstiy with forceful skip for lower levels of CTU.


Is row 1 column 2 correct?

It is correct. "--rskip 1" behavior depends on the RD Level, it differs between RD Level 0-4 and 5-6.

So, your option mapping would not be correct. 0 is disabled. 1 is both those modes, depending on RD.
Default is actually 1, and not disabled, unless --tune grain is used, according to the docs.

[RainyDog]

So --rskip 1 is now the same as --rskip previously?

Appears so, yes. I've not changed my command line since the change and it just defaults to --rskip 1 now.

I'll have a play around with --rskip 2 and 3 shortly but looks like there's also a --rskip-edge-threshold setting to take into account with those too.

I didn't find the speed difference between the old --rskip and --no-skip to be worth the trade off though, so unless the speed drop-off with --rskip 2 and 3 is substantially less then I don't expect them to be of much use.

[stax76]

@nev

I think I got it now, thank you.


New OptionParam With {
.Switch = "--rskip",
.Text = "Recursion Skip",
.Expand = True,
.Options = {
"Undefined",
"0 - Disabled",
"1 - RD Level 0-4 Neighbour costs, RD Level 5-6 Comparison with inter2Nx2N",
"2 - RD Level 0-6 CU edge denstiy",
"3 - RD Level 0-6 CU edge denstiy with forceful skip for lower levels of CTU"},
.Values = {"", "0", "1", "2", "3"}},

[foxyshadis]

In the docs, there it is, but nowhere in changelog... :) That's what i am talkong about.. I am using --rskip 0 (--no-rskip till now)...

If you want to use the bleeding edge builds, you have to be prepared for things to break occasionally, and UIs to catch up later. Otherwise, stick to stable builds or the build provided by the UI.

[MeteorRain]

In the docs, there it is, but nowhere in changelog... :) That's what i am talkong about.. I am using --rskip 0 (--no-rskip till now)...

I just checked the commit log, and found that rskip changes is on future 3.4. You must have used a 3.3+X where X includes the 3.4 changes.

It could be confusing to write 3.3+X in version number indicating a future 3.4 dev version.

[Lucius Snow]

Hi all,

I'm trying to optimize the encoding speed with my Ryzen 3990X (64 cores - SMT disabled) on Windows 10 64 bit.

When encoding UHD @ 23,76 fps file, i only reach 55-58% of CPU charge.

I tried to add "--numa-pools=64" "settings but there's no change.

I currently use 3.2+38-fdbd4e4 build with VS 2019 / AVX2.

Do you have any idea how to speed up encoding?

Thank you.

[Stereodude]

Hi all,

I'm trying to optimize the encoding speed with my Ryzen 3990X (64 cores - SMT disabled) on Windows 10 64 bit.

When encoding UHD @ 23,76 fps file, i only reach 55-58% of CPU charge.

I tried to add "--numa-pools=64" "settings but there's no change.

I currently use 3.2+38-fdbd4e4 build with VS 2019 / AVX2.

Do you have any idea how to speed up encoding?

Thank you.
1) That's not the right switch. You'd want: --pools 64, but it x265 should generate 64 threads automatically if there are 64 logical processors showing to the OS.

2) It depends where the bottleneck is. Your source could be unable to feed frames to the encoder fast enough.

3) Split the encode into pieces on a scene change and run them simultaneously.

[Atak_Snajpera]

Hi all,

I'm trying to optimize the encoding speed with my Ryzen 3990X (64 cores - SMT disabled) on Windows 10 64 bit.

When encoding UHD @ 23,76 fps file, i only reach 55-58% of CPU charge.

I tried to add "--numa-pools=64" "settings but there's no change.

I currently use 3.2+38-fdbd4e4 build with VS 2019 / AVX2.

Do you have any idea how to speed up encoding?

Thank you.

Disabling smt is ultra stupid idea because you lose a lot of performance! Up to 40%. The only good idea is to split video in chunks and encode then simultanously.

[Stereodude]

Disabling smt is ultra stupid idea because you lose a lot of performance! Up to 40%. The only good idea is to split video in chunks and encode then simultanously.
Windows 10 generally doesn't support more than 64 logical cores per NUMA node, so disabling SMT is the best way to get the most performance out of a 3990 under Windows 10 unless he uses Windows 10 Enterprise which can use all 128. Using 64 real cores is better than 64 logical cores across 32 real cores.

[Lucius Snow]

Exactly StereoDude.

I use Windows 10 LTSC so I have better performances with SMT disabled.

[Lucius Snow]

Interesting details:

I have a little better performance on Linux (Centos 8.1) but still far from 100% of CPU charge.

However, I made this X265 benchmark test: http://www.xin.at/x265/index-en.php

I reached 00:40:09:644 on Linux and 01:14:24.446 on Windows.

[Atak_Snajpera]

Windows 10 generally doesn't support more than 64 logical cores per NUMA node, so disabling SMT is the best way to get the most performance out of a 3990 under Windows 10 unless he uses Windows 10 Enterprise which can use all 128. Using 64 real cores is better than 64 logical cores across 32 real cores.

In video encoding 64 logical cpus per CPU group is not a problem. You just have to run additional x265 instances. Problem solved! Disabling smt is a bizarre workaround to low CPU usage by video encoder.

[MeteorRain]

Up to 40%.

Do you have benchmarks to support that? I thought we'd lose at most 20% performance by not using SMT but that's just my wild guess. Would love to see actual numbers showing the difference.

[Stereodude]

What is an exception code of 0xc0000005 in x265?
Faulting application name: x265.exe, version: 3.3.0.1, time stamp: 0x5e4bfd9a
Faulting module name: x265.exe, version: 3.3.0.1, time stamp: 0x5e4bfd9a
Exception code: 0xc0000005
Fault offset: 0x00000000004fb4d2
Faulting process id: 0x23a4
Faulting application start time: 0x01d5f9aa83090eef
Faulting application path: C:\HDTV Tools\x265\x265.exe
Faulting module path: C:\HDTV Tools\x265\x265.exe
Report Id: 921cdb5a-b329-4dac-b876-d60ff8a06c73
I made a few changes to my x265 command line and have gotten the same exception code twice in 10 hours (out of 8 simultaneous encodes on two different encode segments) mid encode after never seeing it ever before of many days of simultaneous encoding on the same system with the same version of x265. Frankly, I've never seen this error before from any version of x265 on any system before with any combination of command line switches.

I changed from this:
START "Enc #6" /NORMAL /NODE 0 /AFFINITY 00000F00 "x265.exe" --pools 4 -F 1 --crf 16.0 -p veryslow --no-sao --aq-mode 1 --aq-strength 1.15 --vbv-maxrate 25000 --vbv-bufsize 25000 --level 5.0 --keyint 120 --open-gop -D 10 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile 6.chp -o "out_6.265" "in_6.avs"
to this:
START "Enc #6" /NORMAL /NODE 0 /AFFINITY 00000F00 "x265.exe" --pools 4 -F 1 --crf 16.0 -p veryslow --aq-strength 1.15 --vbv-maxrate 25000 --vbv-bufsize 25000 --level 5.0 --keyint 120 --open-gop -D 10 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1 --qpfile 6.chp -o "out_6.265" "in_6.avs"

The video has the following properties:
AVSMeter 2.9.8 (x64), 2012-2020, (c) Groucho2004
AviSynth+ 3.4 (r2925, master, x86_64) (3.4.0.0)

Number of frames: 30565
Length (hh:mm:ss.ms): 00:21:14.815
Frame width: 1920
Frame height: 1080
Framerate: 23.976 (24000/1001)
Colorspace: YUV420P10

I restarted the first of the two segment that crashed and it has made it past the prior crash point.

I'm using HolyWu's build (https://forum.doom9.org/showthread.php?p=1901563#post1901563) if that matters.

[Stereodude]

In video encoding 64 logical cpus per CPU group is not a problem. You just have to run additional x265 instances. Problem solved! Disabling smt is a bizarre workaround to low CPU usage by video encoder.
*sigh*
Disabling SMT is how you optimize the performance of an application that will only run on a single NUMA node with a processor like a 3990. The FPS of his single encode with SMT disabled from his single x265 instance is significantly higher than it would be if SMT was enabled. I'd estimate 70-80%.

Is there an alternative workaround for maximizing x265 performance with running multiple simultaneous encodes, yes.

[Lucius Snow]

I can't split the video source file so I don't think running multiple instances would help :\

[Stereodude]

I can't split the video source file so I don't think running multiple instances would help :\
What file format is the video source? You don't have to split the source video file. You only have to split the encoding of the source video file.

By the way, you could just encode two different video source files at the same time.

[LazyNcoder]

Hey guys, any good and free tool to extract hdr10plus meta tags as json and re use it with x265?
I used quietvoid's hdr10plus_parser tool but it gives me error:
Reading parsed dynamic metadata... thread 'main' panicked at 'assertion failed: `(left == right)`
left: `10`,
right: `9`', src/hdr10plus.rs:324:13
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

Tried it on several sources. Any other tool around here?

[quietvoid]

Hey guys, any good and free tool to extract hdr10plus meta tags as json and re use it with x265?
I used quietvoid's hdr10plus_parser tool but it gives me error:


Tried it on several sources. Any other tool around here?

Make sure to update to 0.2.7. If that doesn't work either, I'll need more info.

[LazyNcoder]

Make sure to update to 0.2.7. If that doesn't work either, I'll need more info.

Yes, tried it with 0.2.5 0.2.6 0.2.7 all was the same.
What info do you need? Let me know. I wanted to PM you about it but seems like it's not available.

[quietvoid]

Yes, tried it with 0.2.5 0.2.6 0.2.7 all was the same.
What info do you need? Let me know. I wanted to PM you about it but seems like it's not available.

I just need a sample (or title) of what you're trying to parse, it's hard to test everything. You can open an issue on Github or PM me here.

[LigH]

@Stereodude: I used to believe that the more threads are working on the same video, the smaller the scope of each thread gets, the less efficient the search for redundant areas will be, which will limit quality. Is that no concern for you?

[Stereodude]

@Stereodude: I used to believe that the more threads are working on the same video, the smaller the scope of each thread gets, the less efficient the search for redundant areas will be, which will limit quality. Is that no concern for you?
:confused: Why do you say that?

I've been using --pools 4 -F 1 for my encodes. Mostly because in prior testing I saw a noticeable quality improvement limiting the simultaneous frames to 1. I limit the pools to 4 mostly because when I set frames to 1 it only uses about 4 threads worth of CPU.

I'm going to retest if -F 1 is still necessary with the latest builds since it seems to have considerably image quality improvements that are leading me to rather different conclusions on my preferred settings vs. the last time I tested over a year ago. I find AQ2 w/ SAO left enabled has a very pleasing look now whereas I previously thought it was terrible. Maybe it's just me...

[fauxreaper]

With less frame-threads and no-wpp, the encode has better quality and uses less bitrate. In my tests, disabling wpp is more effective to quality and bitrate than decreasing frame-threads.

[Stereodude]

Where can I get another 64-bit Windows build of 3.3+1-f94b0d32737d? I already have a HolyWu build made with Clang 9.0.0 and want to compare a behavior I see to a different build of the same x265 version.

[Stereodude]

With less frame-threads and no-wpp, the encode has better quality and uses less bitrate. In my tests, disabling wpp is more effective to quality and bitrate than decreasing frame-threads.
I haven't tried no-wpp yet, but going from 4 frame threads to 1 frame thread makes a dramatic quality difference in my testing. I didn't pay much if any attention to the bitrate. I will give --no-wpp a try.

Edit: --no-wpp really reduces CPU usage and used alone increases the number of frame threads. Killing wpp and holding frame threads to 1 is really slow and uses very little CPU. Encodes would be so slow as to be totally impractical.

[Blue_MiSfit]

I found using 1 frame thread to be necessary to avoid macroblocking in certain edge cases (CBR encoding of 4K HDR content, namely)

[Stereodude]

I found using 1 frame thread to be necessary to avoid macroblocking in certain edge cases (CBR encoding of 4K HDR content, namely)
I've been encoding 1080p and 480p and find using 1 frame thread (vs. 4) and found it makes a big difference in the stability of flat areas vs. the source. 1 is nice and stable, 4 is "nervous" with considerably more noise that not in the source. This is using fairly low CRF's (16 for 1080p / 15.5 for 480p).

[LigH]

Where can I get another 64-bit Windows build of 3.3+1-f94b0d32737d? I already have a HolyWu build made with Clang 9.0.0 and want to compare a behavior I see to a different build of the same x265 version.

Using the media-autobuild suite (https://github.com/m-ab-s/media-autobuild_suite) you can compile them yourself, with either clang or GCC.

You may find binaries of the same source state, either with git hash (starting with a g) or with Mercurial hash, but they are equivalent even though hash and increment are not the same (Mercurial counts merges, git doesn't). I switched to git as soon as Multicoreware announced that Bitbucket will drop Mercurial support during this year.

x265 3.3+1-g396395b2b (http://www.mediafire.com/file/gtrc6wzf1gofi9o/x265_3.3%252B1-g396395b2b.7z/file) (GCC 9.2.0)

[Stereodude]

With less frame-threads and no-wpp, the encode has better quality and uses less bitrate. In my tests, disabling wpp is more effective to quality and bitrate than decreasing frame-threads.
So I tried --no-wpp and did not duplicate your finding on my test clip (first 14943 frames of Oblivion). On encodes that ended up at 400MB they were all within 650kB of each other. FWIW, the clip using -F 1 with wpp was the smallest of the permutations I tried.

Here are the common options I used for all 4 encodes:
--crf 16.0 -p veryslow --aq-strength 1.15 --vbv-maxrate 40000 --vbv-bufsize 40000 --level 5.1 --keyint 120 --open-gop -D 10 --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --sar 1:1

On the visual quality I didn't find any improvement from turning wpp off. In contrast it was worse because the frame threads are >1. wpp on with 1 frame thread looked the best of them. wpp off with only 1 frame thread is so excruciatingly slow I would consider it totally unusable. It would have taken days to compress the test sample with those options so I did not run it.

Lastly, after reading up on wpp and how x265 makes the number of wpp rows I don't really see why it would noticeably degrade the image quality. Doesn't it select the number of rows based on the vertical resolution of the video max CU size? So if your CU can be as large as 64 pixels and your video is 1080 pixels tall it will do 17 rows which is basically 1080/64. What's the problem with that method?

[Stereodude]

Using the media-autobuild suite (https://github.com/m-ab-s/media-autobuild_suite) you can compile them yourself, with either clang or GCC.

You may find binaries of the same source state, either with git hash (starting with a g) or with Mercurial hash, but they are equivalent even though hash and increment are not the same (Mercurial counts merges, git doesn't). I switched to git as soon as Multicoreware announced that Bitbucket will drop Mercurial support during this year.

x265 3.3+1-g396395b2b (http://www.mediafire.com/file/gtrc6wzf1gofi9o/x265_3.3%252B1-g396395b2b.7z/file) (GCC 9.2.0)
Thanks. I found a [Windows][MSVC 1916][64 bit] build online of it that I'm testing now. I will try the one you linked next as another data point, but the test can take over 24 hours to run while I wait to see if I get and crashes.

[Boulder]

Does anyone have any sample clips of this big difference between -F 1 and 4? I just tested on a rather noisy clip and visibly they look the same. The average bitrate was almost the same as well, in fact F 2-4 all produced the same size. I think it could be different with clean clips as frame threads should affect references.

[Stereodude]

Does anyone have any sample clips of this big difference between -F 1 and 4? I just tested on a rather noisy clip and visibly they look the same. The average bitrate was almost the same as well, in fact F 2-4 all produced the same size. I think it could be different with clean clips as frame threads should affect references.
You want the source or the output? BTW, I've not found much difference in the resulting file size.

[Blue_MiSfit]

I don't have a sample I can share unfortunately.

I found explosive macroblocking for a few frames a time, and only very rarely (only on specific content and encoding settings).

[Boulder]

You want the source or the output? BTW, I've not found much difference in the resulting file size.

The output would be interesting to see in case I run into similar issues.

EDIT: And of course, it would be best if you could file a bug report for MultiCoreWare as this could also be a bug.

[LigH]

If you need common samples to compare, try Derf's collection at xiph.org (https://media.xiph.org/video/derf/), there is a variety of material (Y4M) with different kinds of codec annoyances.

My favorites: crowd_run / ducks_take_off / in_to_tree / park_joy / parkrun / pedestrian_area / riverbed / sintel_trailer

And if you need a longer playtime: the footage of "Tears of Steel" (https://media.xiph.org/tearsofsteel/)

[Lucius Snow]

What file format is the video source? You don't have to split the source video file. You only have to split the encoding of the source video file.

By the way, you could just encode two different video source files at the same time.
ProRes 4:2:2 HQ or 4:4:4:4 in UHD.

But I don't have two different files to encode at the same time. Only one, fast.

[Stereodude]

ProRes 4:2:2 HQ or 4:4:4:4 in UHD.

But I don't have two different files to encode at the same time. Only one, fast.
Are you using AVIsynth, or how are you getting the file into x265 to be encoded?

[Atak_Snajpera]

ProRes 4:2:2 HQ or 4:4:4:4 in UHD.

But I don't have two different files to encode at the same time. Only one, fast.

How about this?
https://i.postimg.cc/Vk7yzLZN/client.png
Spliting is fully automated. Just fire and forget.

[Lucius Snow]

I use the command line with ffmpeg / x265.

Interesting this RipBot64 thing. Never tried. I'll have a look. Thanks.

EDIT: Well, finally no, just the indexing process at startup takes too much time.

[Andouille]

How about this?
https://i.postimg.cc/Vk7yzLZN/client.png
Spliting is fully automated. Just fire and forget.


Distributed encoding/file spliting should NOT be used for 2pass/filesize target.(your pic seems to be)
Only for quality encoding.

[Blue_MiSfit]

To be fair, distributed multi-pass encoding is a thing.

It's hard to get right and there absolutely are trade-offs, but it can be done.

[Atak_Snajpera]

Distributed encoding/file spliting should NOT be used for 2pass/filesize target.(your pic seems to be)
Only for quality encoding.

I analyze stat file from first pass and then adjust bitrate for each chunk(more complex chunk gets higher bitrate while less complex gets lower). If you use large for example 10 min chunk then you do not have to worry about quality.

[Zebulon84]

Can (or could) RipBot do that automatically ?

[filler56789]

x265.exe 3.3+7-d769bc8e8cde

(x64, multilib, GCC 8.4.0)

Add aarch64 support - Part 1
This patch add some common assembly optimization function for aarch64 platform. These function won't work until the patch Part 2 is merged.

Add aarch64 support - Part 2
This patch adds aarch64 build & compile support. This patch must be merged after the Part 1.

Fix: segmentation fault for hist-scenecut option
fixes plane size calculation for chroma planes using source resolution and not padded resolution.

http://www.mediafire.com/file/2oj8wnp7k4t89dj/x265_3.3%252B7-d769bc8e8cde.rar/file

[Mzvasturbo]

Hi i changed some settings in x265 and for 4k HDR content i came very close to the slow preset quality with 2-3 times faster speed and around 30% smaller file.
here you can check the pictures. https://www.dropbox.com/sh/yabmid1mduiiibm/AAApMWJCziIeyNBMPUI5otsna?dl=0
CRF 17 hdr10-opt was used in both rips.

[filler56789]

x265.exe 3.3+12-00b686782ad0
(GCC 9.3.0, x64, multilib)

Latest changes:

1) Fix: clis in regression txt file.

1. corrects file naming convention.
2. updates deprecated rskip clis options.

2) zone: Enable strict VBV conformance for zone encode as per requirement

3) - Fixes mismatch in BufferRate with dynamic zone reconfiguration when bufferrate varies for each zone
- Logs UnclippedBufferFillFinal into csv when csvloglevel greater than 1

4) Add option to get global maxrate.

This global maxrate can be used for HRD signaling.

5) zone: Remove unnessary conditions on zone reconfig

This commit
- Removes unnessary conditions on zone reconfig
- Fixes crash with dynamic zone reconfig

http://www.mediafire.com/file/nm3997494f2nq9v/x265_3.3%252B12-00b686782ad0.rar/file

[jlpsvk]

Hi i changed some settings in x265 and for 4k HDR content i came very close to the slow preset quality with 2-3 times faster speed and around 30% smaller file.
here you can check the pictures. https://www.dropbox.com/sh/yabmid1mduiiibm/AAApMWJCziIeyNBMPUI5otsna?dl=0
CRF 17 hdr10-opt was used in both rips.
whats your command line???

[Mzvasturbo]

Other settings are from default medium preset this are the changed ones
--crf 17 --level-idc 5.1 --output-depth 10 --rdoq-level 2 --cu-lossless --aq-mode 4 --max-merge 3 --rc-lookahead 25 --lookahead-slices 4 --ref 4 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)" --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --range limited --max-cll "xxx,xxx" --hdr --hdr-opt --repeat-headers --hrd --aud --deblock -1:-1 --no-strong-intra-smoothing

[filler56789]

x265.exe 3.3+19-1d2f556

http://msystem.waw.pl/x265/

Changes after commit 00b6867:

https://bitbucket.org/multicoreware/x265/commits/all

[Barough]

x265 v3.3+17-gdf2ac512d (http://www.mediafire.com/file/q8q29en789g0heh/x265-3.3%252B17-gdf2ac512d_Win_GCC930.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.3.0)
https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[LazyNcoder]

x265.exe 3.3+19-1d2f556

http://msystem.waw.pl/x265/

Changes after commit 00b6867:

https://bitbucket.org/multicoreware/x265/commits/all

Tried the VS 2015/2019 AVX build and it gives me error:

x265 [info]: HEVC encoder version 3.3+19-1d2f556ffb12
x265 [info]: build info [Windows][MSVC 1900][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [error]: internalBitDepth must match compiled bit depth
x265 [error]: x265_encoder_open() failed for Enc,
x265 [error]: Failure generating stream headers 0
Error: fwrite() call failed when writing frame: 1, plane: 0, errno: 32
Output 34 frames in 24.73 seconds (1.37 fps)


x265 v3.3+17-gdf2ac512d (http://www.mediafire.com/file/q8q29en789g0heh/x265-3.3%252B17-gdf2ac512d_Win_GCC930.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.3.0)
https://bitbucket.org/multicoreware/x265_git/commits/branch/master

It's same with this one.
But it's OK with 3.3+10-g08d8

[Forteen88]

LazyNcoder, yeah, I had error in the program "Simple x264 Launcher v2" (set to 10-bit encode) with x265.exe from x265-3.3+19-1d2f556_gcc100-AVX2.7z, but when I instead used x265-10b.exe it worked fine!

With old x265-3.3+10 x265.exe worked in "Simple x264 Launcher v2".

[Patman]

Tried the VS 2015/2019 AVX build and it gives me error:

x265 [info]: HEVC encoder version 3.3+19-1d2f556ffb12
x265 [info]: build info [Windows][MSVC 1900][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [error]: internalBitDepth must match compiled bit depth
x265 [error]: x265_encoder_open() failed for Enc,
x265 [error]: Failure generating stream headers 0
Error: fwrite() call failed when writing frame: 1, plane: 0, errno: 32
Output 34 frames in 24.73 seconds (1.37 fps)



There is an error in the source code. I also compiled x265-3.3+17 and got the same error. I'll report it to the devs.

EDIT:

I compiled a x265-3.3+15 build and that version works. I would like to compile a x265-3.3+16 build and it's not possible. I've opened an issue (https://bitbucket.org/multicoreware/x265/issues/539/error-when-starting-encode ). I use the x265_git as source.

[benwaggoner]

Is there any documentation anywhere on this exciting new feature?

ABR-ladder settings
--abr-ladder <file> File containing config settings required for the generation of ABR-ladder

With scaling also added as a new feature, I presume the file would be a list of resolutions and bitrates at a minimum. But I don't see the syntax documented anywhere yet.

[Blue_MiSfit]

Interesting! They've had this kind of functionality in UHDKit for awhile (commercially productized x265 with lots of neat pro features) so maybe they're bringing some of the features into the open source world :)

Analysis re-use is a huge deal when implemented correctly (especially for UHD). I wonder if that's part of this!

[benwaggoner]

Interesting! They've had this kind of functionality in UHDKit for awhile (commercially productized x265 with lots of neat pro features) so maybe they're bringing some of the features into the open source world :)

Analysis re-use is a huge deal when implemented correctly (especially for UHD). I wonder if that's part of this!
Yeah, 2-3x speedups for a bitrate ladder are quite achievable via shared motion search and other analysis. Definite improvement in quality @ perf (although time to encode the single most complex output stream will be increased, typically).

[benwaggoner]

Silly me, there is help text in the code:

+.. option:: --abr-ladder <filename>
+ File containing the encoder configurations to generate ABR ladder.
+ The format of each line is:
+
+ **<encID:reuse-level:refID> <CLI>**
+
+ where, encID indicates the unique name given to the encode, refID indicates
+ the name of the encode from which analysis info has to be re-used ( set to 'nil'
+ if analysis reuse isn't preferred ), and reuse-level indicates the level ( :option:`--analysis-load-reuse-level`)
+ at which analysis info has to be reused.
+
+ A sample config file is available in `the downloads page <https://bitbucket.org/multicoreware/x265/downloads/Sample_ABR_ladder_config>`_
+
+ Default: Disabled ( Conventional single encode generation ). Experimental feature.
+
+ **CLI ONLY**

[benwaggoner]

And the sample config file.

Seems pretty straightforward. The "base" stream uses nil for the analysis file, and they chain from the previous one on up the ladder. It presumes a ladder of scaled sources.

A lot of cruft comes from using a .yuv file and needing to specify all the color space stuff for each line. Plus calculating PSNR and SSIM and saving those to a log file.

I'm not sure how the --scale-factor parameter is derived, but the rule seems to be 0 if the analysis file is the same resolution, otherwise 2.

Now that there is a scaling algorithm, an obvious extension would be to allow the scaling to take place within x265 so a single source can be used.

Also, it isn't clear at all if these would be encoded in parallel versus serially. I'm guessing serially as it doesn't say otherwise (in contrast to UHDKit, which can already do its own scaling and parallel encoding).

[360p:0:nil] --input 640x360_5994fps_8bit_420p.yuv --input-res 640x360 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 145 --ssim --psnr --csv 0.csv --csv-log-level 2 -o 0.hevc --cutree --scale-factor 0
[432p:1:360p] --input 768x432_5994fps_8bit_420p.yuv --input-res 768x432 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 300 --ssim --psnr --csv 1.csv --csv-log-level 2 -o 1.hevc --cutree --scale-factor 0
[540p1:1:432p] --input 960x540_5994fps_8bit_420p.yuv --input-res 960x540 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 600 --ssim --psnr --csv 2.csv --csv-log-level 2 -o 2.hevc --cutree --scale-factor 0
[540p2:10:540p1] --input 960x540_5994fps_8bit_420p.yuv --input-res 960x540 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 900 --ssim --psnr --csv 3.csv --csv-log-level 2 -o 3.hevc --cutree --scale-factor 0
[540p3:10:540p2] --input 960x540_5994fps_8bit_420p.yuv --input-res 960x540 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 1600 --ssim --psnr --csv 4.csv --csv-log-level 2 -o 4.hevc --cutree --scale-factor 0
[720p1:10:360p] --input 1280x720_5994fps_8bit_420p.yuv --input-res 1280x720 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 2400 --ssim --psnr --csv 5.csv --csv-log-level 2 -o 5.hevc --cutree --scale-factor 2
[720p2:10:720p1] --input 1280x720_5994fps_8bit_420p.yuv --input-res 1280x720 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 3400 --ssim --psnr --csv 6.csv --csv-log-level 2 -o 6.hevc --cutree --scale-factor 0
[1080p1:10:540p3] --input 1920x1080_5994fps_8bit_420p.yuv --input-res 1920x1080 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 4500 --ssim --psnr --csv 7.csv --csv-log-level 2 -o 7.hevc --cutree --scale-factor 2
[1080p2:10:1080p1] --input 1920x1080_5994fps_8bit_420p.yuv --input-res 1920x1080 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 5800 --ssim --psnr --csv 8.csv --csv-log-level 2 -o 8.hevc --cutree --scale-factor 0
[1440p:10:720p2] --input 2560x1440_5994fps_8bit_420p.yuv --input-res 2560x1440 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 8100 --ssim --psnr --csv 9.csv --csv-log-level 2 -o 9.hevc --cutree --scale-factor 2
[2160p1:10:1080p2] --input 3840x2160_5994fps_8bit_420p.yuv --input-res 3840x2160 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 11600 --ssim --psnr --csv 10.csv --csv-log-level 2 -o 10.hevc --cutree --scale-factor 2
[2160p2:10:2160p1] --input 3840x2160_5994fps_8bit_420p.yuv --input-res 3840x2160 --fps 59.94 --input-depth 8 --input-csp i420 --min-keyint 60 --keyint 60 --no-open-gop --bitrate 16800 --ssim --psnr --csv 11.csv --csv-log-level 2 -o 11.hevc --cutree --scale-factor 0

[vpupkind]

And the sample config file.

Seems pretty straightforward. The "base" stream uses nil for the analysis file, and they chain from the previous one on up the ladder. It presumes a ladder of scaled sources.

A lot of cruft comes from using a .yuv file and needing to specify all the color space stuff for each line. Plus calculating PSNR and SSIM and saving those to a log file.

I'm not sure how the --scale-factor parameter is derived, but the rule seems to be 0 if the analysis file is the same resolution, otherwise 2.

Now that there is a scaling algorithm, an obvious extension would be to allow the scaling to take place within x265 so a single source can be used.

Also, it isn't clear at all if these would be encoded in parallel versus serially. I'm guessing serially as it doesn't say otherwise (in contrast to UHDKit, which can already do its own scaling and parallel encoding).
...

The analysis reuse done there depends on whether the analysis-save resolution is a power-of-two multiple of the analysis-load resolution. If the resolutions are same or power-of-two, things like motion vectors and RQT are used as predictors. If not, only frame types are reused in order to maintain IDR alignment in variable duration GOPs.

The older x265 implementation back in 2018 used to be serial (i.e., analysis-save encode had to complete before analysis-load encode starts). This version is closer to parallel -- you only need to finish a number of lower-resolution frames to start encoding at a higher resolution.

The older serial implementation gave us about 2.4x speedup on 4K predicted from 1080p vs "standalone" 4K. I don't have results on the new one yet.

[Blue_MiSfit]

Fascinating stuff! Thanks for sharing

[_kermit]

color primaries

I just re-encoded using this:
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)"

Now I noticed that the original file and the encoded one have different values in the primaries:

Original:
Mastering display color primaries : R: x=0.708000 y=0.292000, G: x=0.170000 y=0.797000, B: x=0.131000 y=0.046000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0001 cd/m2, max: 1000.0000 cd/m2

New:
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.0001 cd/m2, max: 1000.0000 cd/m2

Does that mean anything or is this bad?

-roland

[filler56789]

I've opened an issue (https://bitbucket.org/multicoreware/x265/issues/539/error-when-starting-encode ). I use the x265_git as source.

And the problem hasn't been fixed yet :scared:

Just wondering how and why they (MCW) approve the commits without testing the commits...

[Patman]

And the problem hasn't been fixed yet :scared:

Just wondering how and why they (MCW) approve the commits without testing the commits...

I can't understand the logic ... Compiling till 3.3 + 15 works without problems and the exe-file works, but after adding abr options and encoder this error is present. So far no response to my issue report.

[jlpsvk]

color primaries

I just re-encoded using this:
--master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,1)"

Now I noticed that the original file and the encoded one have different values in the primaries:

Original:
Mastering display color primaries : R: x=0.708000 y=0.292000, G: x=0.170000 y=0.797000, B: x=0.131000 y=0.046000, White point: x=0.312700 y=0.329000
Mastering display luminance : min: 0.0001 cd/m2, max: 1000.0000 cd/m2

New:
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.0001 cd/m2, max: 1000.0000 cd/m2

Does that mean anything or is this bad?

-roland

yes... it is bad... you need to enter correct values to to source... read the x265 documentation...

--master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" are correct values for your source

[_kermit]

yes... it is bad... you need to enter correct values to to source... read the x265 documentation...

--master-display "G(8500,39850)B(6550,2300)R(35400,14600)WP(15635,16450)L(10000000,1)" are correct values for your source

are those values depending on source?
I noticed with other files they are all correct.
It seems that this one was different. Is this common?

[MeteorRain]

Just wondering how and why they (MCW) approve the commits without testing the commits...

I'm guessing because they are still using CVS style committing and branching. If they start using Git style branching bad things would be easier to catch after they commit but before they merge.

[Patman]

I'm guessing because they are still using CVS style committing and branching. If they start using Git style branching bad things would be easier to catch after they commit but before they merge.I used the x265_git and it happened too. Or is it a mirror in preparation for git usage?

[foxyshadis]

And the problem hasn't been fixed yet :scared:

Just wondering how and why they (MCW) approve the commits without testing the commits...

After Steve Borho left, essentially all code review went with him; they just commit every submission and clean up later now. Except assembly; chen still reviews that harshly.

[benwaggoner]

are those values depending on source?
I noticed with other files they are all correct.
It seems that this one was different. Is this common?
The values are specific to the professional grading monitor that was used to master the HDR. The premise is that the content will have no visible-by-creative-intent values outside of what the mastering monitor was capable of.

You need to use the values that are appropriate to the mastering monitor, which isn't something you can know from anything in the source other than this metadata. So, copy it if you have it. Otherwise leave it blank rather than specifying an incorrect value.

[MeteorRain]

I used the x265_git and it happened too. Or is it a mirror in preparation for git usage?

That's not what I mean. Note the word style.

[Patman]

That's not what I mean. Note the word style.

My fault. I only read your entry quickly when I was on the road and read it correctly again this evening :rolleyes: You could be right about that.

[_kermit]

The values are specific to the professional grading monitor that was used to master the HDR. The premise is that the content will have no visible-by-creative-intent values outside of what the mastering monitor was capable of.

You need to use the values that are appropriate to the mastering monitor, which isn't something you can know from anything in the source other than this metadata. So, copy it if you have it. Otherwise leave it blank rather than specifying an incorrect value.

Not defining it in the command line would re-use what's in the source then?

to add: If so, is that also true for --max-cll ?

[Blue_MiSfit]

Not defining it in the command line will simply not set it. x265 has no vision into the source metadata.

Also yes, this is true for --max-cll.

[dREV]

I suppose it's as somebody wrote few posts ago about things breaking when grabbing the latest as I tried the latest build Barough shares x265 v3.3+17-gdf2ac512d https://forum.doom9.org/showthread.php?p=1905930#post1905930 appears both --profile main444-12 --input-csp i444 and --profile main444-10 --input-csp i444 are broken (if somebody else can also confirm) and may include 4:2:0 10 bit equivalent. 8 bit works fine.

Hope Barough will see this post.

----------------------------------------------

I don't know if it's related but as of far as I've tested x265 v3.3+2-gbe2d82093 (https://forum.doom9.org/showthread.php?p=1901894#post1901894) has stopped working telling me Error message for your references: System exception - Access violation when Prefetch(1) is in the end of the script of AviSynth+ 3.5 but runs when (I think its disabled) Prefetch(0) is set. No issues with x265 v3.2+22-a8a2c4c37267 (https://forum.doom9.org/showthread.php?p=1893257#post1893257).

I'm just writing this in case they may be related or not. I really do not know if Prefetch is even worth using since the AviSynth thread is of no help neither the documentation.

----------------------------------------------

Another question in regards to an interest in figuring out if a speed in my encoding with AviSynth+ is possible.

As I recall the settings for slow and veryslow were changed sometime ago and prior my encodes were a bit faster with my settings which have hardly changed since that implementation (likewise with my AviSynth filtering) but I dunno if choosing slower is the same as veryslow as I cannot tell just doing several encode tests at my end.

These are my current settings:
--level 4.1 --crf 16.0 --aq-mode 3 --aq-strength 0.80 --deblock=-1:-1 --me sea --merange 57 --psy-rd 1.00 --rc-lookahead 40 --bframes 16 --ref 6 --subme 7 --qcomp=0.75 --fades --limit-refs=0 --no-limit-modes --rd 6 --psy-rdoq 5 --rdoq-level 1 --tu-intra-depth 4 --tu-inter-depth 4 --ipratio 1.4 --pbratio 1.3 --max-tu-size 32 --ctu 64 --qg-size 64 --limit-tu 0 --max-merge 5 --no-rect --colorprim bt709 --transfer bt709 --colormatrix bt709 --preset veryslow --sar 1:1 --input-depth 16 --profile main444-12 --input-csp i444 --tune animation --no-sao --no-amp --no-strong-intra-smoothing --dither

In 720p if that matters and yeah I am going overboard on some settings. I'm attempting to modify to shorten it some and just found out --ref 8 exists or I wasn't paying much attention to the documentation but doesn't seem to work at this resolution.

Wish the developers would give why the encoder stops to work on some settings instead of just stopping it with no explanation. Well, thanks if anybody gives any suggestions or critique.

[_kermit]

Not defining it in the command line will simply not set it. x265 has no vision into the source metadata.

Also yes, this is true for --max-cll.

now I'm confused, sorry that I keep asking: :o
if used, the correct values must be provided
or
it doesn't matter and they should not be provided?

(for both)

Actually there is more to it:
If I don't provide in particular max-cll, that metadata is missing in the mkv and that data is for example used by the Radiance Pro.
So I think this should be in the new, at least, file since it was in the original?

[MythCreator]

now I'm confused, sorry that I keep asking: :o
if used, the correct values must be provided
or
it doesn't matter and they should not be provided?

(for both)

Actually there is more to it:
If I don't provide in particular max-cll, that metadata is missing in the mkv and that data is for example used by the Radiance Pro.
So I think this should be in the new, at least, file since it was in the original?

It doesn't matter if you provided it or not, because the thing without those preferences is still playable, but if you want to enjoy the "correct" color and light, then you must provide them in command line.

and for the last question, to be honest, I don't know if I need those preferences, why export a new file or something else instead of set them in command line?

[_kermit]

It doesn't matter if you provided it or not, because the thing without those preferences is still playable, but if you want to enjoy the "correct" color and light, then you must provide them in command line.

and for the last question, to be honest, I don't know if I need those preferences, why export a new file or something else instead of set them in command line?

Ok, I stick with providing the parameters then.
If that information isn't there, the Radiance Pro is using default values
(AFAIK), so they are rather important and can not be provided otherwise.
And since I provide max-cll in the command line as parameters, that is fine.
The primaries seem only to have two variants so far:

R: x=0.708000 y=0.292000, G: x=0.170000 y=0.797000, B: x=0.131000 y=0.046000, White point: x=0.312700 y=0.329000

and

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

thank you all!

[onekmilesbehind]

The primaries seem only to have two variants so far:

R: x=0.708000[...]
and
R: x=0.680000[...]

Took me too long to realize those correspond with BT.2020 (https://en.wikipedia.org/wiki/Rec._2020#System_colorimetry) (top) and DCI-P3 (https://en.wikipedia.org/wiki/DCI-P3#System_colorimetry) (bottom), both very common with HDR media.

[_kermit]

Took me too long to realize those correspond with BT.2020 (https://en.wikipedia.org/wiki/Rec._2020#System_colorimetry) (top) and DCI-P3 (https://en.wikipedia.org/wiki/DCI-P3#System_colorimetry) (bottom), both very common with HDR media.

ah, that's good to know :)

thanks.

[Patman]

And the problem hasn't been fixed yet :scared:

Just wondering how and why they (MCW) approve the commits without testing the commits...

They could fix the problem. Look here (https://bitbucket.org/multicoreware/x265/issues/539/error-when-starting-encode#comment-56872276). I think there will be an official fix soon.

[filler56789]

They could fix the problem. Look here (https://bitbucket.org/multicoreware/x265/issues/539/error-when-starting-encode#comment-56872276). I think there will be an official fix soon.

Thanks!

https://bitbucket.org/multicoreware/x265/commits/6bb2d88029c2e13fa13b5b053aa725d4fa84a084

[tuanden0]

Unable to finish encode after using x265 version 3.3+19 and 3.3+21 on http://msystem.waw.pl/x265/

So i have to turn back on version 3.3+10

I got stuck after they encode to last frame
https://i.imgur.com/CvIgQHX.png

[filler56789]

Unable to finish encode after using x265 version 3.3+19 and 3.3+21 on http://msystem.waw.pl/x265/

So i have to turn back on version 3.3+10

I got stuck after they encode to last frame
https://i.imgur.com/CvIgQHX.png

Thanks for the useful information,
I have just reported the latest-and-greatest problem to the x265 devils.

[MythCreator]

My encoding work stuck on 3.3.19 & 3.3.21 too. It won't stuck on 3.3.10 with exact same settings, video and compiler. And it doesn't matter what compiler is, GCC or VS stuck on 3.3.19 and all goes well on 3.3.10. So the problem has to be in those commits between 3.3.19 and 3.3.10.

vspipe 2>NUL "RAW.vpy" - | C:\Encoder\x265_64_10bpp.exe --input-res 1280x720 --fps 29.970 --input-depth 16 --force-flush 0 --ctu 32 --no-strong-intra-smoothing --selective-sao 0 --no-sao --bframes 8 --weightb --no-open-gop --ref 6 --rc-lookahead 48 --aq-strength 1.0 --psy-rd 2.5 --rd 6 --aq-mode 1 --aq-motion --hme --hme-search "2,2,3" --hme-range "24,24,36" --me star --subme 6 --merange 64 --crf 18 --output “RAW.hevc" -

here's the command line that I'm using.

[Patman]

Thanks for the useful information,

I have just reported the latest-and-greatest problem to the x265 devils.I think all the problems are caused by the implantation of the abrEncApp.

EDIT: Here (http://www.mediafire.com/folder/arv5xmdqyiczc/x265_by_Patman) is a link to version 3.3+15 (multilib exe). This version is the last one without implementation of the abrEncApp. Please test if there are any problems with encoding.

[MythCreator]

I think all the problems are caused by the implantation of the abrEncApp.

EDIT: Here (http://www.mediafire.com/folder/arv5xmdqyiczc/x265_by_Patman) is a link to version 3.3+15 (multilib exe). This version is the last one without implementation of the abrEncApp. Please test if there are any problems with encoding.

I tested this version, the encoding ends well.

[Patman]

I tested this version, the encoding ends well.

Thank you very much, this confirms my suspicion that it has to do with the implementation of the abrEncApp.

[tuanden0]

I think all the problems are caused by the implantation of the abrEncApp.

EDIT: Here (http://www.mediafire.com/folder/arv5xmdqyiczc/x265_by_Patman) is a link to version 3.3+15 (multilib exe). This version is the last one without implementation of the abrEncApp. Please test if there are any problems with encoding.

I tested your x265 version and it work! Thank you!
:thanks:

[LigH]

the x265 devils.

:devil:

You slipped.

[dREV]

Is it possible to customize --total-frames to show total-frames=0 ? I'm asking as I've seen some mediainfo's containing such information and wanted to know if there's some other vodoo than typing --total-frames 0 or simply --total-frames as these gets the encoder to stop altogether.

The documentation says almost nothing on this https://x265.readthedocs.io/en/latest/cli.html#cmdoption-uhd-bd (and scroll down a notch or two).

I'm also asking as I heavily use film.trim() so it looks odd seeing only a certain number of frames in mediainfo when the total frames are much larger after appending the files. Thanks if someone answers it unlike my prior post above where it was completely ignored.

[Selur]

are much larger after appending the files
How are you appending the files? Sound like the file headers are not properly adjusted during the appending,...

[dREV]

How are you appending the files? Sound like the file headers are not properly adjusted during the appending,...

I am appending using mkvmerge portable version 45.0 (Heaven's in Pennies) 64 bit under "Add source files" > "Append files". https://www.fosshub.com/MKVToolNix.html After muxing like usual only identifies the first video's cut frames.

I've asked the mkvmerge creator and said this is a non-issue and won't affect video playback several versions ago.

I just wanna know these guys are getting total-frames to read 0. Must be some trick I do not know. Likewise when they somehow cut out encoding settings altogether too but I don't really care about that one. :scared:

Not sure what you mean by headers. I am also using HEVC through MeGUI's one click (and its command line) if that helps.

[Selur]

@dREV: you could try whether appending files with ffmpeg has the same issue
--
Any news about the encoding gets stuck with current x265 versions ?

[Patman]

Any news about the encoding gets stuck with current x265 versions ?

The dev has linked a patch in the issue tracker. I'm now compiling x265.exe with these changes. When the building process is complete, I edit this post and add a link.

EDIT: Here (http://www.mediafire.com/folder/arv5xmdqyiczc/x265_by_Patman) is the link, version x265-3.3+19-..._patched contains with the changes. Pls give me feedback on this version.

[filler56789]

EDIT: Here (https://www.mediafire.com/#arv5xmdqyiczc) is the link, version x265-3.3+19-..._patched contains with the changes. Pls give me feedback on this version.

Wrong link, this is the correct one:

https://www.mediafire.com/folder/arv5xmdqyiczc

I will test the binary A.S.A.P. :thanks:

[Patman]

Wrong link, this is the correct one:

https://www.mediafire.com/folder/arv5xmdqyiczc

I will test the binary A.S.A.P. :thanks:

Ops, now correct. :thanks:

EDIT: I tested this binary and it doesn't work (for me). The encoding process hangs at startup ... :confused: :scared:

[filler56789]

EDIT: I tested this binary and it doesn't work (for me). The encoding process hangs at startup ... :confused: :scared:

I confirm that, the encoding doesn't even start -_-

avs2yuv hc500.avs -o -|z265 --input - --y4m --output C:\hp\test.hevc --crf 22 --no-sao
--subme 3 --no-open-gop --keyint 150 --min-keyint 1 --ctu 32
hc500.avs: 1280x720, YV12, 8-bits, progressive, 30 fps, 4064 frames
y4m [info]: 1280x720 fps 30/1 i420p8 unknown frame count
raw [info]: output file: C:\hp\test.hevc
x265 [info]: HEVC encoder version 3.3+19-gcaf9d4dbe
x265 [info]: build info [Windows][GCC 10.0.1][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
x265 [info]: Main profile, Level-3.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 2 / wpp(23 rows)
x265 [info]: Coding QT: max CU size, min CU size : 32 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 [info]: ME / range / subpel / merge : hex / 57 / 3 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 1 / 150 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-22.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing lslices=4 deblock
^C^C

[Selur]

here too,...

[Patman]

Please test again, an error occurred while implementing the patch. Corrected this now and the binary works for me. I've updated the files.

[filler56789]

Please test again, an error occurred while implementing the patch. Corrected this now and the binary works for me. I've updated the files.

Thanks, now the .EXE works as expected (finally!)

[MythCreator]

Please test again, an error occurred while implementing the patch. Corrected this now and the binary works for me. I've updated the files.

This version works for me too.

[tuanden0]

Please test again, an error occurred while implementing the patch. Corrected this now and the binary works for me. I've updated the files.

This version work for me :D

Edited:
I got some strange output when the encoding almost done
https://i.imgur.com/nrBaf9m.png

[Patman]

Can you post your command line? These are my results...

Avisynth
D:\StaxRip\Apps\Support\avs2pipemod\avs2pipemod64.exe -y4mp "G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new.avs" |
D:\StaxRip\Apps\Encoders\x265\x265.exe --crf 18 --profile main10 --output-depth 10 --frames 4115 --y4m --output "G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new_out.hevc" -

avs2pipemod[info]: writing 4115 frames of 24000/1001 fps, 720x304,
sar 0:0, YUV-420-planar-8bit progressive video.
y4m [info]: 720x304 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new_out.hevc
x265 [info]: HEVC encoder version 3.3+19-gcaf9d4dbe
x265 [info]: build info [Windows][GCC 10.0.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(5 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
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 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao
avs2pipemod[info]: finished, wrote 4115 frames [100%].
avs2pipemod[info]: total elapsed time is 44.602 sec.

x265 [info]: frame I: 153, Avg QP:16.30 kb/s: 4090.80
x265 [info]: frame P: 1226, Avg QP:19.30 kb/s: 1643.85
x265 [info]: frame B: 2736, Avg QP:23.93 kb/s: 545.73
x265 [info]: Weighted P-Frames: Y:2.9% UV:2.3%
x265 [info]: consecutive B-frames: 29.7% 8.7% 16.5% 23.8% 21.3%
encoded 4115 frames in 46.71s (88.09 fps), 1004.71 kb/s, Avg QP:22.27

Vapoursynth
"C:\Program Files\VapourSynth\core\vspipe.exe" "G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new.vpy" - --y4m |
D:\StaxRip\Apps\Encoders\x265\x265.exe --crf 18 --profile main10 --output-depth 10 --frames 4115 --y4m --output "G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new_out.hevc" -

y4m [info]: 720x304 fps 24000/1001 i420p8 unknown frame count
raw [info]: output file: G:\Movie\x264\test\Sonic The Hedgehog Trailer_temp\Sonic The Hedgehog Trailer_new_out.hevc
x265 [info]: HEVC encoder version 3.3+19-gcaf9d4dbe
x265 [info]: build info [Windows][GCC 10.0.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(5 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
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 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 23 / 250 / 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 / off / on
x265 [info]: AQ: mode / str / qg-size / cu-tree : 2 / 1.0 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-18.0 / 0.60
x265 [info]: tools: rd=3 psy-rd=2.00 early-skip rskip mode=1 signhide tmvp
x265 [info]: tools: b-intra strong-intra-smoothing deblock sao
Output 4115 frames in 45.41 seconds (90.61 fps)

x265 [info]: frame I: 154, Avg QP:16.33 kb/s: 4051.93
x265 [info]: frame P: 1218, Avg QP:19.31 kb/s: 1646.53
x265 [info]: frame B: 2743, Avg QP:23.93 kb/s: 547.57
x265 [info]: Weighted P-Frames: Y:3.3% UV:2.5%
x265 [info]: consecutive B-frames: 28.6% 9.4% 16.9% 23.5% 21.6%
encoded 4115 frames in 47.49s (86.66 fps), 1004.00 kb/s, Avg QP:22.28

My logs are clean. I use Avisynth+ 3.5.1 and Vapoursynth R49 + Python 3.8.2.

[tuanden0]

Can you post your command line? These are my results...

My logs are clean. I use Avisynth+ 3.5.1 and Vapoursynth R49 + Python 3.8.2.

I tried to write encode command on my CMD then it OK, maybe my output of my encode script has problem.

Thank you!

[Sagittaire]

There are test in progess for new option like --aq-hevc?

In my historical test sample (harry potter trailer, 720x304x24 at 450 Kbps and 900 kbps), I have new absolute record (all codec tested and AV1 too) with Overall PSNR

For the first time I have similar score for x264 at 900 kbps and x265 at 450 kbps (at max quality for x264 and x265).

Really impressive ... !!!

[MythCreator]

There are test in progess for new option like --aq-hevc?

In my historical test sample (harry potter trailer, 720x304x24 at 450 Kbps and 900 kbps), I have new absolute record (all codec tested and AV1 too) with Overall PSNR

For the first time I have similar score for x264 at 900 kbps and x265 at 450 kbps (at max quality for x264 and x265).

Really impressive ... !!!

hevc aq is saving bitrates, but in some cases (for me, a scene in snowscape), frames were blur like hell and a lot of block on moving tiny things.

[vpupkind]

hevc aq is saving bitrates, but in some cases (for me, a scene in snowscape), frames were blur like hell and a lot of block on moving tiny things.
What were the resolutions and CTU sizes you were using?
Can you please post an example?
Really interested in seeing whether more edge-oriented modes (hevc-aq, aq=4 and aq=5) can outperform aq=2.

[MythCreator]

What were the resolutions and CTU sizes you were using?
Can you please post an example?
Really interested in seeing whether more edge-oriented modes (hevc-aq, aq=4 and aq=5) can outperform aq=2.

Don't bother lol. I cannot reproduce the same problem with newest x265 with same segment:p

[MeteorRain]

Edited:
I got some strange output when the encoding almost done
1.30 seconds (10.21 fps) fp2s1,5 71 8f1r6a.m8e2s kibn/ s 2 1\r

"fps, 1816.82 kb/s \r"
"2157 frames in 211.30 seconds (10.21 fps)"

Sounds correct to me.

[Boulder]

What were the resolutions and CTU sizes you were using?
Can you please post an example?
Really interested in seeing whether more edge-oriented modes (hevc-aq, aq=4 and aq=5) can outperform aq=2.

I did a small test yesterday, comparing the different aq-modes (5 doesn't exist?) looking frame by frame with 2-pass encodes matching the average bitrate of an AQ1 encode. In CGI content (a scene from the first The Hobbit movie), hevc-aq looked quite good. I remember it was a smoothing disaster when it was introduced so something must have happened during this time.

I'll try to create some more test material to watch in motion and preferably on the TV. The swimming noise anomaly in flat areas is something I want to particularly check.

[Sagittaire]

I did a small test yesterday, comparing the different aq-modes (5 doesn't exist?) looking frame by frame with 2-pass encodes matching the average bitrate of an AQ1 encode. In CGI content (a scene from the first The Hobbit movie), hevc-aq looked quite good. I remember it was a smoothing disaster when it was introduced so something must have happened during this time.

I'll try to create some more test material to watch in motion and preferably on the TV. The swimming noise anomaly in flat areas is something I want to particularly check.

yes... I confirm that --aq-hevc produce the highest OPSNR score I have ever see.

With me little sample test, HEVC outperform AV1 with OPSNR too and by far.

[Boulder]

I tested a rather noisy snippet from Star Trek TNG. Lots of noise in the backgrounds, which was already swimming slightly in the source. It's a nice little trap for any encoder to fall in..

The black borders were cropped, very slight denoising applied and the result downscaled to 720p, all based on my normal process. I tried watching the clips on the 65" TV rather close, at 1.5m or so and also on my monitor but I cannot tell which one looks better or worse in motion. All have problems with the background. And while testing, I remembered why hevc-aq looked like crap -- it was simply dropping the bitrate to about half at the same CRF, so you need to compensate quite a bit to make it look normal.

Out of interest, I ran VMAF at model=1 (4K) against a lossless encode.

# 92.079134 -- aq1
# 93.278654 -- aq2
# 92.794155 -- aq3
# 92.670808 -- aq4
# 93.587815 -- hevc-aq
# 93.539299 -- hevc-aq + selective-sao 2

I have some other clips of varying quality collected which I will also run through the same procedure when I have the time.

You can take a look at the results yourself:
AQ-mode 1 : https://drive.google.com/open?id=17LBbaPn_p7lrISFNUSDQlxgWtI7ki48K
AQ-mode 2 : https://drive.google.com/open?id=1DSIFqbljT9j6jcijOU3fcwDSbIgrNuzM
HEVC-AQ : https://drive.google.com/open?id=1aDhKsaX2Jv9RDGbNy4ErqAtUR5wy_VIa

[benwaggoner]

yes... I confirm that --aq-hevc produce the highest OPSNR score I have ever see.

With me little sample test, HEVC outperform AV1 with OPSNR too and by far.
PSNR is known to be pretty useless for estimating subjective quality of adaptive quantization. Lots of techniques are known to improve subjective ratings while reducing PSNR.

I had it in my head that --hevc-aq was a prototype of what became --aq-mode 4. Are they actually orthogonal? That would suggest 9 aq modes: 0, and 1-4 with and without --hevc-aq.

I note that --hevc-aq is also not listed as "experimental" anymore.

[Boulder]

That would suggest 9 aq modes: 0, and 1-4 with and without --hevc-aq.

All other aq-modes are switched off if hevc-aq is enabled, so there's 5 modes to use (or 6 if you count --aq-mode 0 as one).

[almanteka]

this is my problem: an already encoded HEVC video i try to re-encode using x265 always renders a green screen on the re-encoded version. i just re-encode to shrink the file, but i test it out in placebo preset with the same results! any ideas? thanks in advance for any suggestion.

[Boulder]

Ok, I did some more tests. Not visuals yet, I'll probably get to that later today.

Five different clips:
1) Hot Fuzz, 1220 frames. Lots of movement, bright throughout the clip. Amount of grain or noise on scale 1-10, maybe 8. As with the name, a bit fuzzy with noise but quite detailed-looking (fake detail?)
2) The Hobbit (1st movie), 1286 frames. CGI scene with some camera rotation and lots of tiny shapes as there's a big group of orcses (sic!) moving occasionally. Quite bright and grain maybe 4. Sharpish but a little flat in my opinion.
3) Black Sails, 2748 frames. Handheld camera so constant motion (I hate that myself), both bright and darker parts. Grain maybe low 7. Sharp and detailed.
4) Airwolf, 2246 frames. Very dark, quite static scene. Grain 10. Low detail and sharpness.
5) Star Trek TNG, 972 frames. Mostly static, normal TNG scene without CGI with mid indoor brightness. Grain 9. Average details and sharpness.

(In my VMAF calcs, both lossless and encoded result were upscaled to 4K using a neutral bicubic scaler)

Clip 1, VMAF:
# 98.505242 -- aq1
# 98.706121 -- aq2
# 98.613398 -- aq3
# 98.380210 -- aq4
# 98.959994 -- hevc-aq
# 98.960424 -- hevc-aq + selective-sao 2

Clip 2
# 97.728850 -- aq1
# 97.956894 -- aq2
# 97.853706 -- aq3
# 97.565054 -- aq4
# 98.184379 -- hevc-aq
# 98.008400 -- hevc-aq + selective-sao 2

Clip 3
# 95.415750 -- aq1
# 96.473963 -- aq2
# 96.091077 -- aq3
# 95.763069 -- aq4
# 96.882003 -- hevc-aq
# 96.792992 -- hevc-aq + selective-sao 2

Clip 4
# 93.521912 -- aq1
# 95.005253 -- aq2
# 94.472257 -- aq3
# 94.406745 -- aq4
# 95.198142 -- hevc-aq
# 95.142638 -- hevc-aq + selective-sao 2

Clip 5
# 92.079134 -- aq1
# 93.278654 -- aq2
# 92.794155 -- aq3
# 92.670808 -- aq4
# 93.587815 -- hevc-aq
# 93.539299 -- hevc-aq + selective-sao 2

So, VMAF-wise it looks like hevc-aq is a clear winner. What I found very interesting is that I had to reduce CRF quite a lot to reach the same bitrate aq-mode 1 would spend at CRF 18. The VMAF scores are from 2-pass encodes to match AQ1.

Clip 1: CRF 15.1, avg QP 22.87
Clip 2: CRF 16, avg QP 23.39
Clip 3: CRF 15.1, avg QP 21.25
Clip 4: CRF 13.5, avg QP 20.13
Clip 5: CRF 14.4, avg QP 20.60

What these figures tell me is that hevc-aq reduces bitrate in static scenes substantially. I don't know what to make of it -- will it become a problem when watching things on the TV if I don't want to compensate CRF so much that the scenes with more motion then have overallocated bits.

What I'm going to do next is try finding the CRF value which gives me roughly the same VMAF score as AQ1 does, then watch the result on the TV. Maybe I also need to test extracting bigger chunks, like 1000 frames or so over the duration of the whole episode or movie to average things out a bit.

[sneaker_ger]

this is my problem: an already encoded HEVC video i try to re-encode using x265 always renders a green screen on the re-encoded version. i just re-encode to shrink the file, but i test it out in placebo preset with the same results! any ideas? thanks in advance for any suggestion.
This is probably not a problem of the x265 encoder but with decoding the source file. Open a new thread with more details (software you are using, log, sample file) or ask in the appropriate thread (if it has a dedicated thread on doom9).

[Sagittaire]

PSNR is known to be pretty useless for estimating subjective quality of adaptive quantization. Lots of techniques are known to improve subjective ratings while reducing PSNR.

I had it in my head that --hevc-aq was a prototype of what became --aq-mode 4. Are they actually orthogonal? That would suggest 9 aq modes: 0, and 1-4 with and without --hevc-aq.

I note that --hevc-aq is also not listed as "experimental" anymore.

Well, by experience, I think that all metric are more or less dependant. I prefer OPSNR for first test because you have simple and real temporal metric. And if you have 1 dB boost with OPSNR, all the other metric will be certainely better too. IMO have the best possible OPSNR is always good first to have for test new fonctionnality and after you test psy option with that.

With your ToS challenge, I seem have better result for all metric (APSNR, OPSNR, SSIM, MSSIM, PSNR-HVS, PSNR-HVS-M, VMAF). Test in progress ... ;-)

[Sagittaire]

Ok, I did some more tests. Not visuals yet, I'll probably get to that later today.
What these figures tell me is that hevc-aq reduces bitrate in static scenes substantially. I don't know what to make of it -- will it become a problem when watching things on the TV if I don't want to compensate CRF so much that the scenes with more motion then have overallocated bits.

What I'm going to do next is try finding the CRF value which gives me roughly the same VMAF score as AQ1 does, then watch the result on the TV. Maybe I also need to test extracting bigger chunks, like 1000 frames or so over the duration of the whole episode or movie to average things out a bit.

1) Well I have similar result.

For higher bitrate in static scene, you have rate control solution.

- Lower bframe number (3 bframe is generaly good in all case)
- Lower bframe quantizer ratio (1.2 or 1.1 for --pbratio)
- Higher rate control compression (0.5 for --qcomp)

--bframes 3 --b-adapt 2 --pbratio 1.10 --qcomp 0.50

2) I test actualy with that personnaly: --tune ssim --hevc-aq --qp-adaptation-range 1.0

good result in all metric.

You can have more strenght for --hevc-aq with --qp-adaptation-range. 1.0 seem optimized seeting for OPSNR but I don't test qp-adaptation-range with VMAF. If you want try.

[Boulder]

Lowering the amount of b-frames to 3 doesn't do much, also setting both ip- and pb-ratio won't raise the bitrate enough to compensate. I'll need to do the more extensive test to extract several chunks of each case and see how the average turns out.

[benwaggoner]

What these figures tell me is that hevc-aq reduces bitrate in static scenes substantially. I don't know what to make of it -- will it become a problem when watching things on the TV if I don't want to compensate CRF so much that the scenes with more motion then have overallocated bits.
Interesting results! Thanks for running those tests.

And now I must Dadsplain things about VMAF.

With VMAF, something like 3 units is a Just Noticible Difference, where 50% of viewers would score a visible difference. The biggest variance in your examples is more like 2.5, so less than half of viewers would even say there was a quality difference. And particularly in the >90, VMAF's subjective correlation gets even weaker. Without double-blind subjective ratings, I'd not be confident about actual percivable quality differences between the modes. I've certainly seen cases where an encoder of the same content with a VMAF two less than another actually looked better.

Testing at at a higher CRF (and thus lower VMAF) where VMAF is more sensitive is more likely to be useful.

Also VMAF itself was trained of clips up to around 10 seconds, IIRC. Trying to rank overall quality for a 10 second by the mean of individual frame metrics is something. But the longer the clip, the less indicitive the mean is, as there is more time for the content itself to vary. 30 second clips aren't too bad. But you can still find cases where, with two clips of the same VMAF, one looks really bad in some shots and really good in others, while another is consistantly mediocre. Viewers defintely prefer consistant mediocrity than wild quality swings. VMAF-per-GOP is a decent compromise, and then looking at the distribution of scores for individual GOPs.

[Boulder]

Interesting results! Thanks for running those tests.

And now I must Dadsplain things about VMAF.

With VMAF, something like 3 units is a Just Noticible Difference, where 50% of viewers would score a visible difference. The biggest variance in your examples is more like 2.5, so less than half of viewers would even say there was a quality difference. And particularly in the >90, VMAF's subjective correlation gets even weaker. Without double-blind subjective ratings, I'd not be confident about actual percivable quality differences between the modes. I've certainly seen cases where an encoder of the same content with a VMAF two less than another actually looked better.

Testing at at a higher CRF (and thus lower VMAF) where VMAF is more sensitive is more likely to be useful.

Also VMAF itself was trained of clips up to around 10 seconds, IIRC. Trying to rank overall quality for a 10 second by the mean of individual frame metrics is something. But the longer the clip, the less indicitive the mean is, as there is more time for the content itself to vary. 30 second clips aren't too bad. But you can still find cases where, with two clips of the same VMAF, one looks really bad in some shots and really good in others, while another is consistantly mediocre. Viewers defintely prefer consistant mediocrity than wild quality swings. VMAF-per-GOP is a decent compromise, and then looking at the distribution of scores for individual GOPs.

Thank you for a thorough explanation. I don't think I've seen anything really explaining the idea in layman's terms.
VMAF was just an idea that came to my mind as one metric which is based on actual watching instead of blind comparison so it was interesting to see what happened.

My normal viewing distance from the 65" is about 3-3.5 metres, quite a lot, so probably I could not tell much of a difference if there were some serious issues. Dancing noise is easier to see instead of slight ringing or blurring in some parts. When I set an acceptable level for the media player stuff, I try to watch it from 2 metres or so to make sure I can live with the results. And then apply a slight headroom to CRF on top. It's something I probably need to do here with hevc-aq (starting from 18 and going down 0.5 at a time) and see what happens.

[benwaggoner]

Thank you for a thorough explanation. I don't think I've seen anything really explaining the idea in layman's terms.
VMAF was just an idea that came to my mind as one metric which is based on actual watching instead of blind comparison so it was interesting to see what happened.
VMAF is absolutely the least-bad metric we've ever had, and they keep updating the model with new tests and refinements, so today's VMAF scores are more accurate than earlier ones (which also means that when we compare VMAF scores, we need to compare using the same model and some other parameters). But machine learning models are only as good as the tests they were trained on. VMAF originally wasn't good at 4K, but then they revised the model with new 4K tests and it became better. VMAF has never been training on HDR content, so its application to HDR isn't clear. And it hasn't been trained on artifacts from upcoming codecs like VVC and EVC; I'm not sure if the current one has even seen AV1 or HEVC.

My normal viewing distance from the 65" is about 3-3.5 metres, quite a lot, so probably I could not tell much of a difference if there were some serious issues. Dancing noise is easier to see instead of slight ringing or blurring in some parts. When I set an acceptable level for the media player stuff, I try to watch it from 2 metres or so to make sure I can live with the results. And then apply a slight headroom to CRF on top. It's something I probably need to do here with hevc-aq (starting from 18 and going down 0.5 at a time) and see what happens.
To resolve 1080p content on a 65" TV with 20/20 vision, those distances are about as far as they can go, but not too far. For 4K content, you'd want to be within 2 meters; no more than 20% farther away than the diagonal screen size.

For full 8K clarity, you need to sit so close to the screen that you can't see the screen's sides.

[KeVe1983]

Hi all,

need a little bit of help.

I'm using Stax and try to encode a Bluray Movie to x265 8 Bit.
The Movie is called Warrior (2011) and has a lot of grain.

I typically encode CRF 20/Slow no tune

My settings:
--preset slow --aq-mode 1 --aq-strength 0.9 --min-keyint 24 -- --deblock -1:-1 --no-sao

But with these settings the output will be big with more than 10 Gigs.

I also tried to read about command line options for x265 but sorry, i dont get it.

So can you guys help and tell me what parameters i need to switch, to get smaller filesizes for movies with grain and obtain quality?

Or should i give it a go with a 2pass encode?

[Boulder]

Hi all,

need a little bit of help.

I'm using Stax and try to encode a Bluray Movie to x265 8 Bit.
The Movie is called Warrior (2011) and has a lot of grain.

I typically encode CRF 20/Slow no tune

My settings:
--preset slow --aq-mode 1 --aq-strength 0.9 --min-keyint 24 -- --deblock -1:-1 --no-sao

But with these settings the output will be big with more than 10 Gigs.

I also tried to read about command line options for x265 but sorry, i dont get it.

So can you guys help and tell me what parameters i need to switch, to get smaller filesizes for movies with grain and obtain quality?

Or should i give it a go with a 2pass encode?

If it's very grainy, you probably need to denoise and/or downscale to a lower resolution if the final size is a concern. You could try a 2-pass encode but results could be ugly. Noise and grain just requires all those bits.
Is there a reason not to encode to 10bit?

[Sagittaire]

Hi all,

I'm using Stax and try to encode a Bluray Movie to x265 8 Bit.
The Movie is called Warrior (2011) and has a lot of grain.



crf and bitrate are not really correlated: at crf 10 with really low frequency and low motion source, you can have lower bitrate than crf 20 with really high frequency and high motion source.

Use two pass or higher crf will produce the same result at same bitrate.

[KeVe1983]

If it's very grainy, you probably need to denoise and/or downscale to a lower resolution if the final size is a concern. You could try a 2-pass encode but results could be ugly. Noise and grain just requires all those bits.
Is there a reason not to encode to 10bit?

Not sure about 10 Bit... Maybe playback issues?
Or will the most soft and hardware player be able to play 10 Bit content right now?

Is a 10 Bit encode the better option in general?
Will there be any difference in output filesize?

Maybe i'll give it a try

[almanteka]

This is probably not a problem of the x265 encoder but with decoding the source file. Open a new thread with more details (software you are using, log, sample file) or ask in the appropriate thread (if it has a dedicated thread on doom9).

thanks for your reply! i change from avisynth to vapoursynth in staxrip and that fix the green screen! don't know why, i'll ask in the staxrip thread! thanks for your reply and help!

[Boulder]

I did more tests with hevc-aq, and the floating noise issue is something which will prevent me from using it. Mind you, also mode 2 suffers from it which is why I still use mode 1 even if 2 is the default.

You can see the problem in the scene right after the start, above the file cabinet. In mode 1, the background noise is more random-like. In mode 2 and hevc-aq -- particularly in hevc-aq -- the noise starts floating around like a dirty screen or something.
That floating thing is also one reason why I tend to denoise very slightly. If you denoise too heavily, the encoder will start creating those because the complexity is not enough to attract bits.

The encode was done by converting to 16 bit depth, resizing with Lanczos to 1280x720 and feeding the result into x265. Encoded at 10bits, dither enabled. I matched CRF in the hevc-aq encode to approximately match aq1's bitrate.

You can give it a go if you like, here are some links:
Original : https://drive.google.com/open?id=1R67JjV6kH5sMPfvPahuyvXP8sZZcISgF
AQ1 : https://drive.google.com/open?id=1EDz4bAiJos7xOD3qIlyIALZ84C5c91Ep
AQ2 : https://drive.google.com/open?id=1wyqdEH20N8FvKpSvWSHPLJPt5T5mSaVu
HEVC-AQ : https://drive.google.com/open?id=1Txv7_rv8Ml7vEwcQKJMk_Qi15_fazzrW

[Stereodude]

I will readily admit in your clips that AQ1 looks subjectively better than AQ2 or HEVC-AQ, but you're feeding VC-1 compression artifacts into the encoder, not a clean source.

I would MCTD that thing right off the bat.

[Boulder]

It's a tough source (bronze tier in the old Blu-ray PQ ranking list), but I would say pretty much average so many sources look similar. Denoising so that all the artifacts are gone is not my choice in these cases, simply because to denoise enough, you also remove quite a lot of the detail and it's easy to get a plastic look throughout the movie.

I'll do another test with Hot Fuzz, which is quite high quality but has some grain. In my quick basic test, there was one scene where grain acted like it was floating on one character's cheek when aq2 or hevc-aq was used.

[microchip8]

I always use AQ1 because it's the most balanced mode. I've tried all others and they suck up bitrates but actually do not improve (that much) the encode so I settled on AQ1 with high values of psy-rd and psy-rdoq, which helps a lot to preserve noise and details but also increases bitrate somewhat (high psy-rd/psy-rdoq is also used in the grain preset and I agree with that). Regardless, my aim is good quality at an acceptable speed (between 3 and 7 fps on my Ryzen 7) for FHD input

What I'm happy about is that I do not need to do any postprocessing (denoise, etc) the original and still get reasonable file sizes at very decent quality. Compared to x264 where I always had to denoise noisy films just so it doesn't blow up the bitrate and file sizes

[benwaggoner]

...but you're feeding VC-1 compression artifacts into the encoder, not a clean source.

I would MCTD that thing right off the bat.
Or use WMV PowerToy to set the optimal WMV postprocessing mode for the source. 5-6 different levels of deblocking and deringing IIRC.

[benwaggoner]

I believe I've found a bug with multipass encoding with --frame-dup. In a two-pass encode, the second pass fails with a "different number of frames in source" error. Which is presumably due to duplicate frames not being coded and/or read properly in the .stats file.

[vpupkind]

PSNR is known to be pretty useless for estimating subjective quality of adaptive quantization. Lots of techniques are known to improve subjective ratings while reducing PSNR.

I had it in my head that --hevc-aq was a prototype of what became --aq-mode 4. Are they actually orthogonal? That would suggest 9 aq modes: 0, and 1-4 with and without --hevc-aq.

I note that --hevc-aq is also not listed as "experimental" anymore.
They are not orthogonal. They are different ways of accounting for edges and texture sensitivity.
--hevc-aq looks at variances of quartiles
--aq 4 looks at edge pixel variance

[Boulder]

Regarding gq-size, is it generally better to lower it from 32 to 16 when dealing with 720p encodes? If the default was based on 4K, the proportional area covered by qg-size is quite a lot bigger with 720p.

[excellentswordfight]

Regarding gq-size, is it generally better to lower it from 32 to 16 when dealing with 720p encodes? If the default was based on 4K, the proportional area covered by qg-size is quite a lot bigger with 720p.
Default value follows --ctu, so when you lower it qg-size will follow. Or would you like to lower it independant from the CU size? Why?

[microchip8]

I found using a lower qg-size than the CTU one provides worse results. Some visual artifacts are introduced such a mild blocking and smearing. IIRC, qg-size also applies to AQ. YMMY

[Boulder]

Default value follows --ctu, so when you lower it qg-size will follow. Or would you like to lower it independant from the CU size? Why?

There's a long standing misdocumented thing there. The default is always 32 unless CTU is less than that even if the docs say that it's the same as CTU.

And yes, I was thinking if there is any use to lower the size due to the frame size being so much smaller but I'll keep it as it is.

[filler56789]

x265.exe 3.3+24-37916f420742

http://www.mediafire.com/file/olxjiosjggqh0er/x265_3.3%252B24-37916f420742.rar/file

[benwaggoner]

x265.exe 3.3+24-37916f420742

http://www.mediafire.com/file/olxjiosjggqh0er/x265_3.3%252B24-37916f420742.rar/file
Nice! Looks like it fixes the multilib issue seen earlier and adds improved quality for 2-pass CBR encoding.

[Patman]

I've updated x265 too, link is in my sig.

[almanteka]

I've updated x265 too, link is in my sig.

can't find x265.exe 3.3+24-37916f420742 in your signature links! thanks in advance for any help!

[Patman]

can't find x265.exe 3.3+24-37916f420742 in your signature links! thanks in advance for any help!I use the git source (not hg source) and there the build number is a bit different. Download x265-3.3+22-gde09ab80e build, it's the same.

[filler56789]

I use the git source (not hg source) and there the build number is a bit different.

Could you please tell us what is your "trick"?
https://bitbucket.org/multicoreware/x265_git/commits/ does not list de09ab80e :confused:

[Patman]

Could you please tell us what is your "trick"?

https://bitbucket.org/multicoreware/x265_git/commits/ does not list de09ab80e :confused:The mirror on github based on hg source (https://github.com/videolan/x265)

The Synchronisation between https://bitbucket.org/multicoreware/x265 and https://bitbucket.org/multicoreware/x265_git doesn't work properly

[filler56789]

The mirror on github based on hg source (https://github.com/videolan/x265)

Thanks! :thanks:

The Synchronisation between https://bitbucket.org/multicoreware/x265 and https://bitbucket.org/multicoreware/x265_git doesn't work properly

And probably the x265 devs themselves are not very fond of git...

[LoRd_MuldeR]

And probably the x265 devs themselves are not very fond of git...

If the ywant to continue to use Bitbucket, they'll have to migrate to Git tough:
https://hub.packtpub.com/bitbucket-to-no-longer-support-mercurial-users-must-migrate-to-git-by-may-2020/

[almanteka]

I use the git source (not hg source) and there the build number is a bit different. Download x265-3.3+22-gde09ab80e build, it's the same.

thanks!

[stax76]

Sorry to repost, MediaInfo.NET supports a special presentation for x265 parameters, it can be enabled in the settings.

Meanwhile, it was ported to run on .NET Framework 4.8 (so people don't need to install .NET Core) and it has a PowerShell based folder view.

https://github.com/stax76/MediaInfo.NET

https://forum.doom9.org/showthread.php?t=176886

https://i.postimg.cc/0Q3RNTMD/image.png

[Blue_MiSfit]

Hey that's really neat! Thanks for adding this ^ :)

[filler56789]

x265.exe 3.3+26-193db49

http://msystem.waw.pl/x265/

Fix bug in frame-dup + multi pass

Add save-load regression test CLI for Frame Duplication

[Patman]

Updated to version x265-3.3+25-ga6489d2fb (git source). See my sig

[Sagittaire]

x265.exe 3.3+26-193db49

http://msystem.waw.pl/x265/

Fix bug in frame-dup + multi pass

Add save-load regression test CLI for Frame Duplication

Well seem don't change anything. I make test for benwaggoner encoding challenge and I must make 3 pass to have good rate control. 2 pass encoding have too agressive quantizer curve compression at the start of encoding.

[tuanden0]

Updated to version x265-3.3+25-ga6489d2fb (git source). See my sig

Thank for your build :D

[filler56789]

x265.exe 3.3+29-1e3dbf0

--- Cleanup
--- save-load-tests: Fix CLI
--- EQT Updates.

1. Improves documentation in help and x265readthedocs for rskip cli options.
2. Renamed rskip variable in x265_param structure & rectified regression clis.
3. Removed rskip mode 3 which is same as mode 2 with min-cu-size 16.

http://msystem.waw.pl/x265/

[Patman]

Updated (git source):

x265-3.3+4-g6a7df3229-* (marked as 3.4 branch, but the version shows 3.3+4 / maybe stable) [* built with msvc1925 and gcc11.0.0]
x265-3.3+27-g4780a8d99-* (master branch) [* built with msvc1925 and gcc11.0.0]

Downloadlink, see my sig

[RainyDog]

Updated (git source):

x265-3.3+4-g6a7df3229-* (marked as 3.4 branch, but the version shows 3.3+4 / maybe stable) [* built with msvc1925 and gcc11.0.0]
x265-3.3+27-g4780a8d99-* (master branch) [* built with msvc1925 and gcc11.0.0]

Downloadlink, see my sig

Thanks for your builds as always :)

Is there a reason why they no longer support raw .avs (no piping) input?

[Patman]

Thanks for your builds as always :)



Is there a reason why they no longer support raw .avs (no piping) input?You're welcome. My builds have never supported direct avs input. Maybe I will add avs input support in future releases.

[stax76]

Are there builds that support both avs and vpy? libavformat supports both, that's how mpv opens avs and vpy, but does not support portable mode, blocks DLL loading from path env var.

[RainyDog]

You're welcome. My builds have never supported direct avs input. Maybe I will add avs input support in future releases.

Hmm, I was sure there was a point last year when I had the piping tool option set to none in StaxRip across the board. Unless it was just with my x264 set-up...

In any case, be good if you can make your x265 builds work with raw input too. Thanks :)

[Patman]

Hmm, I was sure there was a point last year when I had the piping tool option set to none in StaxRip across the board. Unless it was just with my x264 set-up...



In any case, be good if you can make your x265 builds work with raw input too. Thanks :)Yeah, x264 support that. I do my best and give you a feedback [emoji6]

[RainyDog]

Yeah, x264 support that. I do my best and give you a feedback [emoji6]

Thanks :)

I've now remembered how I was previously using raw input with x265... It was when Stax was using Wolfberry's builds. So seems it is possible to implement at least, unless something's changed with x265 itself since then.

I'll leave it in your capable hands anyway :p

[MeteorRain]

Direct AVS input was there for a while. x265 official denied my attempt to enhance the I/O part, so I have been keeping all patches out of the tree.

No one wrote direct VPY input so far.

[stax76]

If somebody is looking for vpy code:

https://github.com/rigaya/NVEnc/blob/master/NVEncCore/rgy_input_vpy.cpp

https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/vapoursynth.c

[stax76]

Maybe I build a chunk encoding console app as it seems to be relatively simple and nobody else seems to be interested in building it. Are there any special x265 settings needed? x264 has a --stitchable option. How does ripbot264 do it? vspipe and avs2pipemod allow defining start and end frame. Are two chunks enough?

[vpupkind]

Maybe I build a chunk encoding console app as it seems to be relatively simple and nobody else seems to be interested in building it. Are there any special x265 settings needed? x264 has a --stitchable option. How does ripbot264 do it? vspipe and avs2pipemod allow defining start and end frame. Are two chunks enough?

You may want to use their "chunked encoding" mode which will improve performance at the chunk boundaries

[LigH]

x265 3.3+27-g4780a8d99 (https://www.mediafire.com/file/94e52feibz00y7b/x265_3.3+27-g4780a8d99.7z/file) (multilib, GCC 10.1)

[stax76]

You may want to use their "chunked encoding" mode which will improve performance at the chunk boundaries

Thanks, so --chunk-start and --chunk-end, would be helpful if somebody can share experience with it. How many extra frames are needed? I'll use vspipe and avs2pipemod for trimming, modifying the avs/vpy file has too many implications.

[benwaggoner]

Thanks, so --chunk-start and --chunk-end, would be helpful if somebody can share experience with it. How many extra frames are needed? I'll use vspipe and avs2pipemod for trimming, modifying the avs/vpy file has too many implications.
I'd want to use at least as many frames as the greater of keyint and fps*vbv-maxrate/vbv-bufsize. That'll let rate control and IDR placement converge pretty close on what they would be in a full pass encode. If using larger gaps and being kinda paranoid, I'd probably use double the above.

The compute overhead is proportional to chunk duration, so is much less of an issue with 10 minute chunks than 30 second chunks.

[crystalfunky]

I noticed something about the crf value. One step to the next number is around 4000-5000 kbits bitrate.
So for example I have a clip with 27 Mbit/s and I want to lower the bitrate, I need to lower the crf one step. If I want to get the bitrate around 17 Mbit/s, I need to do 2 steps.
Can somebody confirm that?

[Boulder]

I noticed something about the crf value. One step to the next number is around 4000-5000 kbits bitrate.
So for example I have a clip with 27 Mbit/s and I want to lower the bitrate, I need to lower the crf one step. If I want to get the bitrate around 17 Mbit/s, I need to do 2 steps.
Can somebody confirm that?

No, that's not how it works. I'm afraid there is no mathematical way to calculate the "correct" value for CRF. It depends on the source and also the encoder parameters.

[RanmaCanada]

I noticed something about the crf value. One step to the next number is around 4000-5000 kbits bitrate.
So for example I have a clip with 27 Mbit/s and I want to lower the bitrate, I need to lower the crf one step. If I want to get the bitrate around 17 Mbit/s, I need to do 2 steps.
Can somebody confirm that?
If you want to lower the bitrate, then lower the bitrate with a 2 pass. CRF has nothing to do with bitrate.

[Blue_MiSfit]

Well, that's not accurate. If you're generally ok with the quality + bitrate from a given crf with a given preset, and one particular piece of content ends up too big, you can always just increase CRF.

Capped CRF is reasonable too.

[LoRd_MuldeR]

x265 3.3+27-g4780a8d99 (https://www.mediafire.com/file/94e52feibz00y7b/x265_3.3+27-g4780a8d99.7z/file) (multilib, GCC 10.1)

:thanks:

[filler56789]

x265.exe 3.3+31-d5695e2

http://msystem.waw.pl/x265/

[stax76]

Sorry to post here again, I've added this chunk encoding feature to staxrip, available in the last beta. It turned out everything needed was already in place so it could be finished in four hours.

Documented here:

https://staxrip.readthedocs.io/usage.html#parallel-processing

RipBot264 and Media Coder support it too.

[RanmaCanada]

Sorry to post here again, I've added this chunk encoding feature to staxrip, available in the last beta. It turned out everything needed was already in place so it could be finished in four hours.

Documented here:

https://staxrip.readthedocs.io/usage.html#parallel-processing

RipBot264 and Media Coder support it too.

This is fantastic. I haven't used this feature since mediacoder.

thank you.

[filler56789]

x265.exe 3.3+32-516a579

Store histogram of Y, U, V and Y's edge in analysis file.

Enables the library to compute Y Histogram and store
Histogram of Y, U, V Channel and Y's Edge in analysis
file at all reuse levels when --hist-scenecut is enabled.

http://msystem.waw.pl/x265/

[Barough]

x265 v3.3+31-g431a22e82 (http://www.mediafire.com/file/emtac09geqs2tzm/x265-3.3%252B31-g431a22e82_Win_GCC101.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.1.0)
https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[benwaggoner]

No, that's not how it works. I'm afraid there is no mathematical way to calculate the "correct" value for CRF. It depends on the source and also the encoder parameters.
As a heuristic, file size doubles with about 5-6 lowerCRF, and halves with about the same in the other direction. Content dependent, of course.

[Boulder]

Perhaps a silly question, but something I've wondered ever since MakeMKV was able to add Dolby Vision to Matroska files. If at some point mkvmerge can handle the DV layer in a similar way, would it be possible to re-encode the actual video to a lower bitrate and combine the two (provided that mkvmerge supports such action)? Rescaling would definitely be out of question, but some light denoising should not do much, since it's the same with HDR.
The reason I'm asking this is that I have a small 2.5" HDD next to my TV, which I've been using to playback DV on the TV player since Kodi doesn't support DV. The HDD is only 500GB in size so re-encoding could effectively double the amount of movies I could store there.

[quietvoid]

The specs do mention the 1080p enhancement layer always comes with a 2160p base layer.
It is also something I have been wondering, you could easily test it by using yusesope's tool and merging the metadata into a reencoded HEVC file.

[benwaggoner]

The specs do mention the 1080p enhancement layer always comes with a 2160p base layer.
It is also something I have been wondering, you could easily test it by using yusesope's tool and merging the metadata into a reencoded HEVC file.
Yes, the enhancement layer doesn't need to be full rez as it's really spatial metadata. The enhancement layer is unwatchable by itself.

That said, almost all new DoVi content for several years uses a non-backwards compatible (NBC) base layer without an enhancement layer. This provides more efficient encoding and lower complexity decode/tone mapping. x265 can encode the NBC base layer just fine, although I'd use --preset slower at a minimum, and the DoVi-specific encoding tweaks.

[Blue_MiSfit]

3.4 has been tagged for release!

https://bitbucket.org/multicoreware/x265/branch/Release_3.4

Release notes - v3.4
-----------------------------

New features
------------------
• Edge-aware quadtree partitioning to terminate CU depth recursion based on edge information. --rskip 2 enables the feature and --rskip-edge-threshold <0..100> denotes the minimum expected edge-density percentage within the CU, below which the recursion is skipped. Experimental feature.
• Application-level feature --abr-ladder for automating ABR ladder generation. Shows ~65% savings in the over-all turn-around time required for the generation of a typical HLS ladder in Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz over a sequential ABR-ladder generation approach that leverages save-load architecture.
Enhancements to existing features
----------------------------------------------
• Improved 2-pass rate-control algorithm. The savings in the bitrate is ~1.72% with visual improvement in quality in the initial 1-2 secs.
Encoder enhancements
--------------------------------
• Faster ARM64 encodes enabled by ASM contributions from Huawei. The speed-up over no-asm version for 1080p encodes @ medium preset is ~15% in a 16 core H/W.
• Strict VBV conformance in zone encoding.
Bug fixes
------------
• Multi-pass encode failures with --frame-dup.
• Corrupted bitstreams with --hist-scenecut when input depth and internal bit-depth differ.
• Incorrect analysis propagation in multi-level save-load architecture.
• Failure in detecting NUMA packages installed in non-standard directories.

[Patman]

I've updated my x265 builds. x265-3.4+1 is built from the stable branch (stable release) and x265-3.4+6 is built from the master branch. Both builds are 64-bit multilib windows binaries.

[alexantr]

Who try --rskip 2? Did you catch rare glitches like that

[Sagittaire]

3.4 has been tagged for release!

https://bitbucket.org/multicoreware/x265/branch/Release_3.4

Release notes - v3.4
-----------------------------

New features
------------------
• Edge-aware quadtree partitioning to terminate CU depth recursion based on edge information. --rskip 2 enables the feature and --rskip-edge-threshold <0..100> denotes the minimum expected edge-density percentage within the CU, below which the recursion is skipped. Experimental feature.
• Application-level feature --abr-ladder for automating ABR ladder generation. Shows ~65% savings in the over-all turn-around time required for the generation of a typical HLS ladder in Intel(R) Xeon(R) Platinum 8280 CPU @ 2.70GHz over a sequential ABR-ladder generation approach that leverages save-load architecture.
Enhancements to existing features
----------------------------------------------
• Improved 2-pass rate-control algorithm. The savings in the bitrate is ~1.72% with visual improvement in quality in the initial 1-2 secs.
Encoder enhancements
--------------------------------
• Faster ARM64 encodes enabled by ASM contributions from Huawei. The speed-up over no-asm version for 1080p encodes @ medium preset is ~15% in a 16 core H/W.
• Strict VBV conformance in zone encoding.
Bug fixes
------------
• Multi-pass encode failures with --frame-dup.
• Corrupted bitstreams with --hist-scenecut when input depth and internal bit-depth differ.
• Incorrect analysis propagation in multi-level save-load architecture.
• Failure in detecting NUMA packages installed in non-standard directories.

well now Npass encoding seem work like crf mode: It is not a progess. For me the quantizer ratio between pframe and bframe is too high by default.

[burnix]

Patman. Can you build an ffmpeg x64 with it ????

Thanks

[Patman]

Patman. Can you build an ffmpeg x64 with it ????

Thanks

Here (http://www.mediafire.com/file/6920cu884gwplxk/ffmpeg-N-98036-gd538ca5175-gb6d7c4c1d4-gcc10.1.0.7z/file) :D

[burnix]

You're the best.
I'm going to try now, and after i'm going to sell on internet all crappy computer and server to make a real decent computer and work on ffmpeg compil.

Thanks man.

[K.i.N.G]

I have been stuggling for months with ugly distortions (smearing that kinda looks like motion blur with banding) in fast moving scenes and finally found out that x265's CUTree is to blame.
Turning it off solves it, but the bitrate blows up when trying to keep the same overal quality in other scenes.

Is there any way to make CUTree 'less agressive' or set it to 50% for example or some threshold parameter?

[Blue_MiSfit]

try a lower ctu value maybe? What resolution + bitrate are you targeting?

[K.i.N.G]

try a lower ctu value maybe? What resolution + bitrate are you targeting?

4K Bitrate depends on source, but the current footage is decent quality with little grain (which i'd like to keep).
For this footage, lets say arround 15K since its for streaming.

I restarted the encode with --ctu 32 (instead of --ctu 64)

[K.i.N.G]

Lowering the CTU size to 32 (--ctu 32) doesnt really seem to help

[Boulder]

By your description, it looks like the infamous onion artifacts. Have you tried --rd 6 with --rd-refine?

[poisondeathray]

Does increasing qcomp reduce the cutree effect? Similar to how increasing qcomp reduced mbtree effect in x264 ?

[K.i.N.G]

By your description, it looks like the infamous onion artifacts. Have you tried --rd 6 with --rd-refine?

I have not.
I will make sure to try those out next after this encode, which will run for a few days.

Does increasing qcomp reduce the cutree effect? Similar to how increasing qcomp reduced mbtree effect in x264 ?

I can confirm it does.
Normally I raise the qcomp to something like 0.70-0.75 and raise the CRF by ±0.5 which 'fixes' it to more acceptable levels.

Though... I always wondered if there was another (more efficient) way to control CUTree's strength/agressiveness more directly... (if I understand correctly qcomp controls a lot more than just things that are influenced by cutree). Hence my question here.

[Boulder]

I have not.
I will make sure to try those out next after this encode, which will run for a few days.And then it will run even slower :devil:

Though... I always wondered if there was another (more efficient) way to control CUTree's strength/agressiveness more directly... (if I understand correctly qcomp controls a lot more than just things that are influenced by cutree). Hence my question here.
I wouldn't be surprised if aq-mode also played a part here as in my opinion they are related, and the default mode 2 is something I will not use based on my tests. I'm still using mode 1 with strength 0.8-1.0 depending on the source. Higher for cleaner sources.

[benwaggoner]

I wouldn't be surprised if aq-mode also played a part here as in my opinion they are related, and the default mode 2 is something I will not use based on my tests. I'm still using mode 1 with strength 0.8-1.0 depending on the source. Higher for cleaner sources.
I note from the x265 dev list that an --auto-aq mode is in development. Maybe we'll be able to stop sweating aq-mode someday.

> This patch does the following:
> 1. Automatically decides the AQ Mode for each frame, using its scene
> statistics, such as luma intensity and edge density.
> 2. Add option "--auto-aq" to enable auto detection of AQ Mode per frame.

[fauxreaper]

CUTree granularity depends on CU depth recursion. --rskip 0 or 2 reduces onion effect. More early exits from CU recursion = bigger CUs = higher chances of wrong CU propagation and artifacts in motion.

x265 RDO loves to skip blocks, and CUTree artifacts are a consequence of this. Decreasing max-merge also helps, reducing artifacts and skipped blocks. Sometimes even setting bframes=0 decrease artifacts in motion.

[Boulder]

Decreasing max-merge also helps, reducing artifacts and skipped blocks.

I've never understood why max-merge gets increased in the slower and supposedly higher quality profiles. I always have it at '2'.

[Boulder]

CUTree granularity depends on CU depth recursion. --rskip 0 or 2 reduces onion effect. More early exits from CU recursion = bigger CUs = higher chances of wrong CU propagation and artifacts in motion.

x265 RDO loves to skip blocks

I did a little test with a UHD source, downscaled to 1440p. Interesting results, and easy to see that skips and merges are happening more with the default rskip setting compared to mode 2. I didn't do any visual comparions to find any onion artifacts yet.

rskip 1 rskip 2
Intra 64x64 DC 0,00 % 0,00 %
Intra 64x64 Planar 0,00 % 0,00 %
Intra 64x64 Ang 0,00 % 0,00 %
Intra 32x32 DC 2,03 % 1,24 %
Intra 32x32 Planar 1,21 % 0,79 %
Intra 32x32 Ang 9,08 % 3,61 %
Intra 16x16 DC 0,92 % 0,36 %
Intra 16x16 Planar 0,43 % 0,15 %
Intra 16x16 Ang 8,00 % 2,46 %
Intra 8x8 DC 0,25 % 0,14 %
Intra 8x8 Planar 0,06 % 0,04 %
Intra 8x8 Ang 3,75 % 1,61 %
4x4 0,45 % 0,44 %
Inter 64x64 6,50 % 49,71 %
Inter 64x64 (Rect) 0,29 % 15,61 %
Inter 32x32 19,90 % 6,50 %
Inter 32x32 (Rect) 1,05 % 0,91 %
Inter 16x16 16,78 % 4,27 %
Inter 16x16 (Rect) 0,91 % 0,05 %
Inter 8x8 6,65 % 2,21 %
Inter 8x8 (Rect) 0,83 % 0,30 %
Skip 64x64 0,00 % 0,00 %
Skip 32x32 0,81 % 0,24 %
Skip 16x16 3,73 % 1,04 %
Skip 8x8 4,27 % 1,91 %
Merge 64x64 0,27 % 1,63 %
Merge 32x32 2,49 % 0,82 %
Merge 16x16 4,86 % 1,67 %
Merge 8x8 4,47 % 2,27 %

[Greenhorn]

the comparatively enormous number of 64x64 blocks with rskip 2 to me, though-- from a total of 6.79% (normal + rect) to 65.33% (normal + rect)!

Is there any way to get CU-type in a more readable format than setting csv-log-level=1 and viewing the generated file in an Excel/CSV viewer? Would greatly help with some comparison's I've been doing for myself.

[Boulder]

the comparatively enormous number of 64x64 blocks with rskip 2 to me, though-- from a total of 6.79% (normal + rect) to 65.33% (normal + rect)!
That puzzled me as well. Disabling early exits seems to favour bigger CUs in this case. Maybe it's something related to this test clip being HDR, so the image is quite flat compared to the graded result (edit: correctly displayed HDR) on the TV. Plenty of action, but plenty of plain white looking areas when I play the result back on my SDR display.

I checked a couple of frames where I found some onion artifacting -- happened to be next to edges -- and rskip 2 did fix them. So it's definitely helpful.

Is there any way to get CU-type in a more readable format than setting csv-log-level=1 and viewing the generated file in an Excel/CSV viewer? Would greatly help with some comparison's I've been doing for myself.
I'm afraid not. That is something I'd like to see as well, averages like I put there and also information regarding refs. All those you can see with x264 so I don't know why the statistics were not considered for x265. If I was a coder, I would definitely submit a patch for it.

[K.i.N.G]

Thanks for all the suggestions guys!
I will try them out as soon as I can.

I've never understood why max-merge gets increased in the slower and supposedly higher quality profiles. I always have it at '2'.

Funny you should mention this, as i always wondered why I seem to get less of these 'artifacts' when encoding at lower presets. Will have a look at max-merge.

I checked a couple of frames where I found some onion artifacting -- happened to be next to edges -- and rskip 2 did fix them. So it's definitely helpful.

Will try this too.

[vpupkind]

the comparatively enormous number of 64x64 blocks with rskip 2 to me, though-- from a total of 6.79% (normal + rect) to 65.33% (normal + rect)!


Do you see the difference in file size or average quantizer as well?

[benwaggoner]

Do you see the difference in file size or average quantizer as well?
Or visually?

[Greenhorn]

I just meant to say it surprised me, but forgot a word. For most of the stuff I've tried it one (just my personal collection, nothing terribly interesting) rskip 2 produces slightly larger but very similar looking encodes, so realizing that it was making such different files on a basic level was a jolt.

IDK how it behaves when you have studio-grade clean/detailed sources, but for me rskip mode 2 needs an annoying amount of tuning, because with the default edge threshold some clips are a little better than with mode 2, while others just fall apart entirely.

[benwaggoner]

I just meant to say it surprised me, but forgot a word. For most of the stuff I've tried it one (just my personal collection, nothing terribly interesting) rskip 2 produces slightly larger but very similar looking encodes, so realizing that it was making such different files on a basic level was a jolt.

IDK how it behaves when you have studio-grade clean/detailed sources, but for me rskip mode 2 needs an annoying amount of tuning, because with the default edge threshold some clips are a little better than with mode 2, while others just fall apart entirely.
You can try with the source from my encoding challenge: https://forum.doom9.org/showthread.php?t=175776.

It'd be good to try with some files that used to have artifacts with rskip and see if and how they are improved with --rskip 2.

[charliebaby]

Patman Thank you the Build x265 :-)

[stax76]

Do following x265 crf values still make sense?

--crf 10 Super High
--crf 12 Very High
--crf 14 Higher
--crf 16 High
--crf 18 Medium
--crf 20 Low
--crf 22 Lower
--crf 24 Very Low
--crf 26 Super Low

I think the values were established many years ago when 4K was not popular.

There is a request to increase the value by 4:

--crf 14 Super High
--crf 16 Very High
--crf 18 Higher
--crf 20 High
--crf 22 Medium
--crf 24 Low
--crf 26 Lower
--crf 28 Very Low
--crf 30 Super Low

It would be identical to the x264 values then which also start at 14 and end at 30.

Change or not?

[K.i.N.G]

Sorry for the late reply but our remote desktop software crashed and didn't have access to the servers...

After a quick test adding these parameters to the encode improved the quality in parts with motion "--rskip 2 --max-merge 2 --rd-refine" with about the same bitrate.
The artifacts are still there but far less (and much less perceptible when playing the video).
I'll see if i can experiment some more with the settings later, maybe it can be improved even more.

Thanks to everyone for the usefull input and suggestions!

[K.i.N.G]

Do following x265 crf values still make sense?

--crf 10 Super High
--crf 12 Very High
--crf 14 Higher
--crf 16 High
--crf 18 Medium
--crf 20 Low
--crf 22 Lower
--crf 24 Very Low
--crf 26 Super Low

I think the values were established many years ago when 4K was not popular.

There is a request to increase the value by 4:

--crf 14 Super High
--crf 16 Very High
--crf 18 Higher
--crf 20 High
--crf 22 Medium
--crf 24 Low
--crf 26 Lower
--crf 28 Very Low
--crf 30 Super Low

It would be identical to the x264 values then which also start at 14 and end at 30.

Change or not?

I wouldn't change them. Its just going to add more confusion than it will fix when using presets with different versions.
And then there's the fact it also depends on the type of source. HDR needing a lower CRF than SDR etc.

I dont think 'normalizing' the CRF with x264 is that important if it is even possible... since result will always be different depending on the footage imho.

[benwaggoner]

Yeah. CRF fundamentally maps to QP, and while AVC and HEVC have similar QP scales, HEVC can do more with higher QP than AVC can. Any QP delta between x264 and x265 is going to vary based on profile and content. That said, I think the average CRF delta for the same subjective quality would be less than 4. That said, CRF 16 IS generally very high quality with x265. 10-12 are almost always psychovisually indistinguishable from 14 except for some heavy noise edge cases.

[Boulder]

At CRF 10-14, I wouldn't be surprised if the encode sometimes ended up at a higher average bitrate than the source itself :)

[Forteen88]

At CRF 10-14, I wouldn't be surprised if the encode sometimes ended up at a higher average bitrate than the source itself :)I hear that for HDR UHD video, CRF 14 isn't very extreme.

[stax76]

A test encode I did come out like this:


Source:

HEVC, Main 10@L5.1@High, 3840x2160, 23.976 FPS, 57.5 Mbps


Settings:

x265.exe --crf 14 --preset slower --output-depth 10


Result:

HEVC, Main 10@L5@Main, 3840x2160, 23.976 FPS, 32.9 Mbps


It was a sample from the movie Snow White and the Huntsman, had some noise, not particular much.


It would also be possible to add additional items, very, super, extreme, ludicrous...


My sample with the highest bitrate is:

HEVC, Main 10@L5.1@High, 3840x2160, 23.976 FPS, 70.0 Mb/s


Some old boring movie called Crash.

[Boulder]

I hear that for HDR UHD video, CRF 14 isn't very extreme.

True, HDR requires a significantly lower CRF to achieve visual transparency.

[benwaggoner]

True, HDR requires a significantly lower CRF to achieve visual transparency.
Having a perceptually uniform EOTF helps a lot, as QPs don't need to be lowered for dark regions. In SDR it's easy to seams between Y'=16 and Y'=17.

HDR always being 10-bit also helps.

Ballpark, HDR needs ~20% fewer bits than 8-bit SDR to get to a similar subjective quality.

[Blue_MiSfit]

Worth mentioning, x265 does require special tuning for good quality HDR.

The default hdr-opt is pretty good for PQ YCbCr (HDR10), but when encoding for Dolby Vision Profile 5 using PQ IPT (quite similar to ICtCp) masquerading as YCbCr, some additional tuning is needed to mitigate banding artifacts, even at high bitrates. I've seen some proprietary patches to x265 to improve performance here. Hopefully MCW makes something like this in mainline x265 :)

[Boulder]

Having a perceptually uniform EOTF helps a lot, as QPs don't need to be lowered for dark regions. In SDR it's easy to seams between Y'=16 and Y'=17.

HDR always being 10-bit also helps.

Ballpark, HDR needs ~20% fewer bits than 8-bit SDR to get to a similar subjective quality.

But CRF needs to be adjusted quite heavily. With my SDR settings + hdr-opt + HDR metadata, an encode of a HDR source produces a proportionally much smaller file than a similar one in SDR at CRF 18. With HDR sources, I tend to use CRF 14.

[benwaggoner]

Worth mentioning, x265 does require special tuning for good quality HDR.



The default hdr-opt is pretty good for PQ YCbCr (HDR10), but when encoding for Dolby Vision Profile 5 using PQ IPT (quite similar to ICtCp) masquerading as YCbCr, some additional tuning is needed to mitigate banding artifacts, even at high bitrates. I've seen some proprietary patches to x265 to improve performance here. Hopefully MCW makes something like this in mainline x265 :)There's a whole different optimization flag for doing Profile 5, tuned for Y'CtCp instead of Y'CbCr.

Sent from my SM-T837V using Tapatalk

[Blue_MiSfit]

In mainline x265? Do tell. I've been using a patched 3.0 build for quite awhile.

[benwaggoner]

In mainline x265? Do tell. I've been using a patched 3.0 build for quite awhile.
Maybe it was in a private build or something. There was a chroma qp offset in it to leverage Y'CtCp.

There's a lot of other good stuff added between 3.0 and 3.4, though!

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

[theincognito]

Here (http://www.mediafire.com/file/6920cu884gwplxk/ffmpeg-N-98036-gd538ca5175-gb6d7c4c1d4-gcc10.1.0.7z/file) :D

If it's not too much, can you build a test msvc avx2 build, with M support? x265 obviously. :)

[Patman]

If it's not too much, can you build a test msvc avx2 build, with M support? x265 obviously. :)

I did this some time ago, but there is no need to define the instruction set. My versions support all instruction sets and there is no speed increase.

[theincognito]

I did this some time ago, but there is no need to define the instruction set. My versions support all instruction sets and there is no speed increase.

Okay. Thank you. :)

[LigH]

New upload: x265 3.4+7-g38774073d (https://www.mediafire.com/file/musijhlvyke0wq1/x265_3.4+7-g38774073d.7z/file)

Fixed the normalization formula to ouput 0 to 1 and considered max chroma histogram SAD in histogram based scene cut detection

[charliebaby]

Thank you for 3.4+7 LigH :-)

[JoyBell]

x265 3.4+7
--analysis-reuse-level <1..10> Level of analysis reuse indicates amount of info stored/reused in save/load mode, 1:least..10:most. Now deprecated. Default 0

umm. I used these feature exclusively (since I finally got it to work about a year ago) on all my encodes. Is it coming back, is it default for all 2 pass, what is going on?

[charliebaby]

HolyWy Thank you i am test me Threadripper 2990wx 32 core

test 1080p 3min : http://prntscr.com/t7tvjc

[Greenhorn]

umm. I used these feature exclusively (since I finally got it to work about a year ago) on all my encodes. Is it coming back, is it default for all 2 pass, what is going on?

It's been split into 2 different options-- "analysis-save-reuse-level" and "analysis-load-reuse-level".
If you set them to the same values the reuse function should work like before.

[-QfG-]

HolyWy Thank you i am test me Threadripper 2990wx 32 core

test 1080p 3min : http://prntscr.com/t7tvjc

Can u tell me, what switches i must use, for creating 4 thread pools with 8 Threads?

[charliebaby]

Can u tell me, what switches i must use, for creating 4 thread pools with 8 Threads?

hello if you have an amd cpu disabled threads in the bios on the name of SMT to gain power and added ca --pools 4,4,4,4 ;)

[charliebaby]

new FFMPEG 4.3 : https://www.videohelp.com/software/ffmpeg

[quietvoid]

So x265 3.4+9, they "fixed" --hist-threshold to avoid false positives. However it seems to do much worse than before (as well as 3.4+7, where they fixed the false positives).
I'm getting less I frames with --hist-threshold 0.005 (default 0.03) than the default scenecut algorithm..

Maybe my sample clip is not colorful enough..

[LigH]

New upload: x265 3.4+9-g1fb7c7960 (https://www.mediafire.com/file/j6z95t66pzz0t9x/x265_3.4+9-g1fb7c7960.7z/file)

Improvements to hist-based scenecut algorithm.
Add support for RADL pictures at IDR scenecuts

[charliebaby]

New upload: x265 3.4+9-g1fb7c7960 (https://www.mediafire.com/file/j6z95t66pzz0t9x/x265_3.4+9-g1fb7c7960.7z/file)

Improvements to hist-based scenecut algorithm.
Add support for RADL pictures at IDR scenecuts

Thank you

[benwaggoner]

So x265 3.4+9, they "fixed" --hist-threshold to avoid false positives. However it seems to do much worse than before (as well as 3.4+7, where they fixed the false positives).
I'm getting less I frames with --hist-threshold 0.005 (default 0.03) than the default scenecut algorithm..

Maybe my sample clip is not colorful enough..
Do you mean IDR or also non-IDR I-frames?

Fewer I frames isn't problem in itself. The question is if it is not flagging edits and such as IDR. Beyond that, IDR and I should only be used when it improves compression efficiency, or as needed based on --keyint.

[quietvoid]

Do you mean IDR or also non-IDR I-frames?

Fewer I frames isn't problem in itself. The question is if it is not flagging edits and such as IDR. Beyond that, IDR and I should only be used when it improves compression efficiency, or as needed based on --keyint.

I'm not sure, whichever x265 reports as "I frame" in the final log/stats. I do use --no-open-gop, so I assume they are all IDR.
From what I understand, detected scene cuts should start with an I frame, as it is how adaptive keyframe placement works.

[Rousseau]

Does analysis-save always write such huge files at values above 1? I tried a 128MB sample file and it created a multi-gigabyte save file (writing at 60mb/s which significantly slowed down the encode).

Also, it only seems to work with ref=1 in the second pass if you are using --no-slow-firstpass , otherwise I get:

Error reading analysis data. Incompatible option : <ref>


This is with x265 3.3+5-g4a0cef17d+32 and 3.4+9-g1fb7c7960

[charliebaby]

x265 3.4.10 https://www.free-codecs.com/x265_hevc_encoder_download.htm

VS 2015
VS 2019
GCC 10.1

[Barough]

x265 v3.4+10-g7a640a2c1 (https://www.mediafire.com/file/qx7lwbur52u19lp/x265-3.4+10-g7a640a2c1_Win_GCC101.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.1.0)
https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[Barough]

x265 v3.4+11-gee5a266a1 (https://www.mediafire.com/file/pzljihjsierisfp/x265-3.4+11-gee5a266a1_Win_GCC101.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.1.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

https://bitbucket.org/multicoreware/x265_git/commits/ee5a266a1055222faff6c319c7589ddcbef3f9d1

[-QfG-]

Have anyone an idea, how i can change the Info string in the sourcefiles of the Encoder? For Example, it likes so:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 26 min
Bit rate : 7 441 kb/s
Width : 3 840 pixels
Height : 1 608 pixels
Display aspect ratio : 2.40:1
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.050
Stream size : 4.50 GiB (65%)
Writing library : x265 3.2: QfG-Edition
Encoding settings : Encoded-by-QfG / CRF=16.0 / High-Quality
Default : Yes
Forced : No
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.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 712 cd/m2
Maximum Frame-Average Light Level : 355 cd/m2

Thanks the guy, who can tell me this.

[LigH]

Compile your own x265.exe after changing its C/C++ sources accordingly.

[charliebaby]

Have anyone an idea, how i can change the Info string in the sourcefiles of the Encoder? For Example, it likes so:

Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 h 26 min
Bit rate : 7 441 kb/s
Width : 3 840 pixels
Height : 1 608 pixels
Display aspect ratio : 2.40:1
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.050
Stream size : 4.50 GiB (65%)
Writing library : x265 3.2: QfG-Edition
Encoding settings : Encoded-by-QfG / CRF=16.0 / High-Quality
Default : Yes
Forced : No
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.0050 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 712 cd/m2
Maximum Frame-Average Light Level : 355 cd/m2

Thanks the guy, who can tell me this.

don't put a pool and see if it works otherwise you have to try --pool 16 or 8,8

[theincognito]

Compile your own x265.exe after changing its C/C++ sources accordingly.

I use MSVC/ICC builds interchangeably on my intel cpu with avx2 and they seem to be faster for me than GCC builds.

I am planning to buy a Ryzen 7 3rd gen. Which type of build will be the best for it? Any idea? Thanks in advance :)

[theincognito]

And...

One more thing. Anyone here tried aq-mode 4 and got results? Or could explain to me the use case for it? I read the official docs, and to be honest, didn't understand it.

[charliebaby]

I use MSVC/ICC builds interchangeably on my intel cpu with avx2 and they seem to be faster for me than GCC builds.

I am planning to buy a Ryzen 7 3rd gen. Which type of build will be the best for it? Any idea? Thanks in advance :)

I have a 2990wx threadripper and the best for me is the GCC 6.30

here : http://www.mediafire.com/file/p4rf0sayt8wl7by/x265_3.4.0.2_x64.zip/file

:)

[LigH]

Since my last reply, at least two answers posted here seem to have no obvious relation to the questions they quoted... :confused:

[theincognito]

I have a 2990wx threadripper and the best for me is the GCC 6.30

here : http://www.mediafire.com/file/p4rf0sayt8wl7by/x265_3.4.0.2_x64.zip/file

:)

Thanks a lot :)

[theincognito]

Since my last reply, at least two answers posted here seem to have no obvious relation to the questions they quoted... :confused:

Can you help me with the below? :D

And...

One more thing. Anyone here tried aq-mode 4 and got results? Or could explain to me the use case for it? I read the official docs, and to be honest, didn't understand it.

[charliebaby]

Can you help me with the below? :D

AQ-Mode 1 is the Best dont not change :-)

[charliebaby]

x265-3.4+12 VS2019 + GCC 10.1

http://www.mediafire.com/file/iniffp4509rzazt/x265-3.4%252B12-geff9.zip/file

[vpupkind]

And...

One more thing. Anyone here tried aq-mode 4 and got results? Or could explain to me the use case for it? I read the official docs, and to be honest, didn't understand it.

The premise is that the human visual system is less sensitive to edges than flat areas. The approach is known to work, but needs a ton of tuning.

[benwaggoner]

The premise is that the human visual system is less sensitive to edges than flat areas. The approach is known to work, but needs a ton of tuning.
It's actually the other way around: we are much more sensitive to edges (transitions) than to flat areas without any detail. Those are better encoded as frequencies than as spatial pixel values, which is why all lossy still and video codecs use some sort of sine/cosine/wavelet transform.

For adaptive quantization, it's more that the human eye can see errors in frequencies a lot more clearly in smooth areas than textured ones, because that creates edges that weren't there before. Blocking and ringing are a lot easier to see in an area where there shouldn't be detail at all. A bunch of foliage can have slight frequency errors which get masked by all the edges and detail already there.

[Boulder]

I find that all those special edge related AQ modes generally mess any noisy flat areas of the image, causing the floating wall of noise defect I strongly dislike. I don't know if tuning the strength helps but mode 1 still works best for me. Strength 0.8-1.0, lower for noisier material, higher for clean.

[Forteen88]

I find that all those special edge related AQ modes generally mess any noisy flat areas of the image, causing the floating wall of noise defect I strongly dislike. I don't know if tuning the strength helps but mode 1 still works best for me. Strength 0.8-1.0, lower for noisier material, higher for clean.But --tune animation
which is clean (I assume that they mean clean) cartoon, sets (among other things),
--aq-strength 0.4

[Boulder]

If I'm not entirely mistaken, the whole idea of aq-strength is to adjust the amount of bits shifted from more complex blocks (like ones with edges etc.) to simple ones (like a flat background).

From an old x264 thread:

High AQ strength retains more gradients but produces ringing.
Low AQ strength preserves edges but produces banding.

My theory here is that the random noise itself is complex and could actually be harder to compress than something with clear edges and detail. Lowering the strength should not cause excessive banding as the flat areas with noise already attract bits and are not really flat in terms of the encoder. In some tests I did, lowering the strength from 1.0 to 0.8 can cause the bitrate to drop around 10% with other settings remaining the same.

With animation and cartoons, aq-mode 2 could well work because they are very different beasts compared to normal, real-life footage.

[markiemarcus]

With animation and cartoons, aq-mode 2 could well work because they are very different beasts compared to normal, real-life footage.

In my experience, Aq mode 2 is indeed more forgiving in animation and typically results in less ringing. The difference can be very pronounced with SAO disabled. You can get decent results with Aq mode 1, but finding the optimal aq strength is both a massive pain and essential IMO.

Aq mode 4 also works well, but it's also quite a bit slower.

[benwaggoner]

Netflix's Sol Levante is the first creative commons licensed 4K HDR anime-style animation I've seen yet, and makes for some very interesting aq-mode and aq-strength testing.

https://netflixtechblog.com/bringing-4k-and-hdr-to-anime-at-netflix-with-sol-levante-fa68105067cd

And don't forget --hevc-aq, aka --aq-mode 5. I suspect, but have not demonstrated, it could be quite good for line-art style animation.

While lines are blurring a lot in the computer-assisted era, the classic differential attributes of cel animation are:

No motion blur
extremely sharp lines demarcating areas of extremely flat color
Many repeat frames and areas that are identical between many frames


Just look a the --log-level 2 .csv of natural image and cel content and you'll see how different the distribution of block sizes and types is.

[Selur]

Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

I tried with:
"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | "I:\Hybrid\64bit\x265.exe" --input - --output-depth 10 --y4m --profile main10 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --pass 1 --slow-firstpass --bitrate 1500 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --range limited --colormatrix bt470bg --stats "E:\Temp\test_generated.stats" --analysis-save "E:\Temp\test_generated.analysis" --analysis-reuse-level 6 --no-multi-pass-opt-analysis --output "E:\Temp\test.265"
for the 2pass 1st pass, which seems to run fine:
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\test.265
x265 [info]: HEVC encoder version 3.4+7-g38774073d
x265 [info]: build info [Windows][GCC 10.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: analysis-load-reuse-level can be set only when analysis-load is enabled. Resetting analysis-load-reuse-level to 0.
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(6 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
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 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 25 / 250 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
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 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1500 kbps / 0.60
x265 [info]: tools: limit-modes rd=3 ssim-rd psy-rd=2.50 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: rskip mode=1 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-write
x265 [info]: frame I: 3, Avg QP:16.35 kb/s: 3518.73
x265 [info]: frame P: 120, Avg QP:13.21 kb/s: 3109.91
x265 [info]: frame B: 306, Avg QP:17.58 kb/s: 770.49
x265 [info]: Weighted P-Frames: Y:0.8% UV:0.8%
x265 [info]: consecutive B-frames: 3.3% 0.0% 58.5% 21.1% 17.1%
encoded 429 frames in 15.97s (26.86 fps), 1444.09 kb/s, Avg QP:16.35
Not sure about the:
x265 [warning]: analysis-load-reuse-level can be set only when analysis-load is enabled. Resetting analysis-load-reuse-level to 0.

Then I started a 2pass 2nd pass with:
"I:\Hybrid\64bit\ffmpeg.exe" -y -loglevel fatal -noautorotate -nostdin -threads 8 -i "F:\TestClips&Co\files\test.avi" -map 0:0 -an -sn -vf zscale=rangein=tv:range=tv -pix_fmt yuv420p10le -strict -1 -vsync 0 -f yuv4mpegpipe - | "I:\Hybrid\64bit\x265.exe" --input - --output-depth 10 --y4m --profile main10 --limit-modes --no-early-skip --no-open-gop --opt-ref-list-length-pps --pass 2 --bitrate 1500 --opt-qp-pps --cbqpoffs -2 --crqpoffs -2 --limit-refs 0 --ssim-rd --psy-rd 2.50 --rdoq-level 2 --psy-rdoq 10.00 --aq-mode 0 --deblock=-1:-1 --limit-sao --no-repeat-headers --range limited --colormatrix bt470bg --stats "E:\Temp\test_generated.stats" --analysis-load "E:\Temp\test_generated.analysis" --analysis-reuse-level 6 --no-multi-pass-opt-analysis --no-dynamic-refine --refine-ctu-distortion 1 --output "E:\Temp\2020-07-12@16_54_18_4110_03.265"
which starts fine:
y4m [info]: 640x352 fps 25/1 i420p10 sar 1:1 unknown frame count
raw [info]: output file: E:\Temp\2020-07-12@16_54_18_4110_03.265
x265 [info]: HEVC encoder version 3.4+7-g38774073d
x265 [info]: build info [Windows][GCC 10.1.0][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [warning]: analysis-save-reuse-level can be set only when analysis-save is enabled. Resetting analysis-save-reuse-level to 0.
x265 [info]: Main 10 profile, Level-2.1 (Main tier)
x265 [info]: Thread pool created using 16 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 4 / wpp(6 rows)
x265 [warning]: Source height < 720p; disabling lookahead-slices
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 / 3
x265 [info]: Keyframe min / max / scenecut / bias : 25 / 250 / 40 / 5.00
x265 [info]: Cb/Cr QP Offset : -2 / -2
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 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 0.0 / 32 / 1
x265 [info]: Rate Control / qCompress : ABR-1500 kbps / 0.60
x265 [info]: tools: limit-modes rd=3 ssim-rd psy-rd=2.50 rdoq=2 psy-rdoq=10.00
x265 [info]: tools: rskip mode=1 signhide tmvp b-intra strong-intra-smoothing
x265 [info]: tools: deblock(tC=-1:B=-1) sao stats-read

but then nothing happens.
x265 is running, but seemingly not doing anything.

Also tried with HEVC "encoder version 3.4+12-geff904199" same effect.

-> Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

Cu Selur

[theincognito]

Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

....
-> Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

Cu Selur

This is what I use and it works perfectly for me:

pass 1:
--analysis-save "E:\Temp\analysis.dat" --analysis-save-reuse-level 10 --analysis-reuse-file "E:\Temp\analysis.dat"

pass 2:
--analysis-load "E:\Temp\analysis.dat" --analysis-load-reuse-level 10 --analysis-reuse-file "E:\Temp\analysis.dat"

[benwaggoner]

...after some tests with Sol Levante, I've got a couple of observations about anime encoding, at least with this pure digital 4K HDR anime.

--tskip offers a big reduction in bitrate and improvement in quality
--rskip 1 works better than --rskip 2

[microchip8]

...after some tests with Sol Levante, I've got a couple of observations about anime encoding, at least with this pure digital 4K HDR anime.

--tskip offers a big reduction in bitrate and improvement in quality
--rskip 1 works better than --rskip 2


I got the reverse for live action. rskip=2 reduces onion artifacts and is faster. Haven't tested tskip

[theincognito]

...after some tests with Sol Levante, I've got a couple of observations about anime encoding, at least with this pure digital 4K HDR anime.

--tskip offers a big reduction in bitrate and improvement in quality
--rskip 1 works better than --rskip 2


Thats cool :) What about SDR?

[Asmodian]

...after some tests with Sol Levante, I've got a couple of observations about anime encoding, at least with this pure digital 4K HDR anime.

--tskip offers a big reduction in bitrate and improvement in quality
--rskip 1 works better than --rskip 2


I did some testing with a few SDR 1080p anime series (the common lower budget contemporary Japanese style) and --tskip allowed a large reduction in bitrate while also improving quality. It is not just 4K HDR, tskip is huge for 1080p anime too! I was using --rskip 1 and didn't test --rskip 2. I was also using --tu-inter 4, --tu-intra 4, and --limit-tu 4, which might help for 1080p more than 4K?

tskip really is amazing and it makes x265 much better for anime than x264. I care more about transparency than size but tskip seems to improve both. A must enable option for anime, IMO.

:thanks:Thank you!

Edit:
An example command line I used targeting playback on a tablet. It runs really well on my new 3950X. :)
vspipe.exe --y4m "Flying Witch - 05.vpy" - | x265.exe --input - --y4m -o "Flying Witch - 05.265" --crf 22 -p 8 -F 1 --pools 32 --lookahead-slices 0 --gop-lookahead 23 --min-keyint 24 --hme --hist-scenecut --fades --selective-sao 2 --tskip --tu-inter 4 --tu-intra 4 --limit-tu 4 --pmode --rect --amp --rc-lookahead 60 --range limited --colorprim 1 --transfer 1 --colormatrix 1
Edit2: --limit-tu 4 is a speedup with a minor quality hit. Testing with it off does not slow down my 3950X very much with minor quality improvements. I think I will leave it off. :o

[benwaggoner]

Thats cool :) What about SDR?
It's been some years since I tested SDR HD anime, but IIRC, tu-inter/intra 4 and tskip made a huge improvement.

[Sagittaire]

Can someone tell me how to properly use the 2pass options 'analysis-save' and 'analysis-load' ?

You have complete test here
https://forum.doom9.org/showthread.php?t=181362

reuse encoding is not here to obtain better quality refinement in multipass mode but for:
- make reencoding at other bitrate from 2pass with other initial bitrate with really higher speed
- make reencoding at other resolution from 2 pass with other initial resolution with really higher speed

be carefull: you have incompatible option like --rd-refine or --hme with reuse encoding

You have really powefull --abr-ladder option too: you can make simulanous encoding (different bitrate and resolution) with same source at really higher speed than successive encoding.

for make reuse you must make:
- first pass (at high speed if you want)
- second pass with --analysis-save analysis.dat --analysis-save-reuse-level 10
- third pass with --analysis-load analysis.dat --analysis-load-reuse-level 10

you can use --refine-intra 4 --refine-inter 3 --refine-mv 3 for best analyse level in third pass, but really lower speed.

you can try that if you want obtain "crf quality like" with the bitrate that you want for exemple:

x265.exe --input hp.yuv --output HP-450-SSIM.265 --input-res 720x304 --output-depth 10 --fps 25 --crf 19.5 --qcomp 0.60 --pass 1 --stats hp.log --preset veryslow --slow-firstpass --no-limit-modes --rd-refine --tune ssim --hevc-aq --qp-adaptation-range 1.0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim --analysis-save HP_450_R10-abr1_analysis.dat --analysis-save-reuse-level 10 --refine-ctu-distortion 1

second pass at really high speed but little lower quality
x265.exe --input hp.yuv --output HP-450-SSIM.265 --input-res 720x304 --output-depth 10 --fps 25 --bitrate 450 --qcomp 0.60 --pass 3 --stats hp.log --preset veryslow --no-limit-modes --tune ssim --hevc-aq --qp-adaptation-range 1.0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim --analysis-load HP_450_R10-abr1_analysis.dat --analysis-load-reuse-level 10 --refine-ctu-distortion 1

second pass at less high speed but with real "crf like" quality
x265.exe --input hp.yuv --output HP-450-SSIM.265 --input-res 720x304 --output-depth 10 --fps 25 --bitrate 450 --qcomp 0.60 --pass 3 --stats hp.log --preset veryslow --no-limit-modes --tune ssim --hevc-aq --qp-adaptation-range 1.0 --bframes 3 --b-adapt 2 --min-keyint 1 --psnr --ssim --analysis-load HP_450_R10-abr1_analysis.dat --analysis-load-reuse-level 10 --refine-ctu-distortion 1 --refine-intra 4 --refine-inter 3 --refine-mv 3

[theincognito]

I did some testing with a few SDR 1080p anime series (the common lower budget contemporary Japanese style) and --tskip allowed a large reduction in bitrate while also improving quality. It is not just 4K HDR, tskip is huge for 1080p anime too! I was using --rskip 1 and didn't test --rskip 2. I was also using --tu-inter 4, --tu-intra 4, and --limit-tu 4, which might help for 1080p more than 4K?

tskip really is amazing and it makes x265 much better for anime than x264. I care more about transparency than size but tskip seems to improve both. A must enable option for anime, IMO.

:thanks:Thank you!

Edit:
An example command line I used targeting playback on a tablet. It runs really well on my new 3950X. :)
vspipe.exe --y4m "Flying Witch - 05.vpy" - | x265.exe --input - --y4m -o "Flying Witch - 05.265" --crf 22 -p 8 -F 1 --pools 32 --lookahead-slices 0 --gop-lookahead 23 --min-keyint 24 --hme --hist-scenecut --fades --selective-sao 2 --tskip --tu-inter 4 --tu-intra 4 --limit-tu 4 --pmode --rect --amp --rc-lookahead 60 --range limited --colorprim 1 --transfer 1 --colormatrix 1
Edit2: --limit-tu 4 is a speedup with a minor quality hit. Testing with it off does not slow down my 3950X very much with minor quality improvements. I think I will leave it off. :o

It's been some years since I tested SDR HD anime, but IIRC, tu-inter/intra 4 and tskip made a huge improvement.


Thank you :)

[Selur]

@Sagittaire: Thanks for the link and the explanation. :)

[benwaggoner]

I did some testing with a few SDR 1080p anime series (the common lower budget contemporary Japanese style) and --tskip allowed a large reduction in bitrate while also improving quality. It is not just 4K HDR, tskip is huge for 1080p anime too! I was using --rskip 1 and didn't test --rskip 2. I was also using --tu-inter 4, --tu-intra 4, and --limit-tu 4, which might help for 1080p more than 4K?
I'm running a test encode right now to compare a tu of 3 with tskip and tu of 4 without tskip. My intuition is that anime can benefit from tskip at any resolution, because the sharpness of the lines is pretty consistant, and sharp lines on smooth backgrounds is exactly why we want to get very fine blocks (min 4x4 with amp and rect) so we can isolate the sharp lines from the rest of the image and selectively apply tskip. Tskip on a 32x32 block that isn't something weird and regular like a checkerboard is probably going to be worse than a normal block. But a 4x4 with amp gets down to pixel-level alignment.

tskip really is amazing and it makes x265 much better for anime than x264. I care more about transparency than size but tskip seems to improve both. A must enable option for anime, IMO.
Yep. It's big help with motion graphics too. Probably for anything the screen coding extensions would help.

I'd guess videogame footage would probably be better with it too, especially with HUD and games with aliasing.

Edit2: --limit-tu 4 is a speedup with a minor quality hit. Testing with it off does not slow down my 3950X very much with minor quality improvements. I think I will leave it off. :o
Yeah, I only had about a 1% perf change using --limit-tu 4 with the anime test clip. That might be because there just aren't many potential tskip blocks that trigger the early exit in this kind of content. I think the speed gains with --tskip-fast were a lot higher with regular content.

I thought there was somewhere in --log-level 2 that showed how many tskip and cu-lossless blocks were used, but I can't find it now. Am I misremembering?

[jlpsvk]

when encoding 1917 with HDR10+ metadata, encode gets only 171168 frames instead of 171176. when encoding without HDR10+ metadata json, everything is OK. using latest LigH's build (3.4+9).

EDIT: used the same JSON with NVENC and all good... so probably x265 problem???

[fauxreaper]

I was reading x265 source code and I found an interesting comment about merge mode in x265_git/source/encoder/analysis.cpp...

/* Todo: Fix the satd cost estimates. Why is merge being chosen in high motion areas: estimated distortion is too low? */

I think that this can explain why restricting merge usage (lowering max-merge and/or using rskip 2) generates a video with less artifacts.

[Greenhorn]

I was reading x265 source code and I found an interesting comment about merge mode in x265_git/source/encoder/analysis.cpp...

/* Todo: Fix the satd cost estimates. Why is merge being chosen in high motion areas: estimated distortion is too low? */

I think that this can explain why restricting merge usage (lowering max-merge and/or using rskip 2) generates a video with less artifacts.

Do you have a link to where you were browsing this? I'm looking at (https://bitbucket.org/multicoreware/x265_git/src/master/source/encoder/analysis.cpp) right now and not seeing this comment. (Wrong file?)

[fauxreaper]

Do you have a link to where you were browsing this? I'm looking at (https://bitbucket.org/multicoreware/x265_git/src/master/source/encoder/analysis.cpp) right now and not seeing this comment. (Wrong file?)

I think that I saw an old file.

https://bitbucket.org/multicoreware/x265_git/src/8ee74a78e5ef71643047b22078a20e9e450e252c/source/encoder/analysis.cpp

[LeXXuz]

I note from the x265 dev list that an --auto-aq mode is in development. Maybe we'll be able to stop sweating aq-mode someday.

> This patch does the following:
> 1. Automatically decides the AQ Mode for each frame, using its scene
> statistics, such as luma intensity and edge density.
> 2. Add option "--auto-aq" to enable auto detection of AQ Mode per frame.

Any news on this? I use mode 3 for very clean sources and mode 2 for everything else.

Btw are there any new switches that should be added and are not part of the standard presets?

Right now I use preset slower with output-depth 10, aq-mode 3 and a qpfile for more acurate and faster chapter jumps. I usually use CRF16/18 for 1080p SDR.

The very slow preset is way to slow for my needs, even on a Ryzen 9 system.

[Boulder]

I'd also set --rskip 2 and possibly lower the corresponding threshold a bit. --no-sao as you don't do low bitrate encodes.

[106062316]

x265 [info]: HEVC encoder version 3.4+12-geff904199
x265 [info]: build info [Windows][GCC 11.0.0][64 bit] 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.48.100)
x265 [info]: (libavcodec 58.96.100)
x265 [info]: (libavutil 56.55.100)

https://1drv.ms/u/s!Arxq3mixC4xAg0xX9G7_VubNYJhm?e=gJJxt8

[jlpsvk]

really nobody will look into this????

when encoding 1917 with HDR10+ metadata, encode gets only 171168 frames instead of 171176. when encoding without HDR10+ metadata json, everything is OK. using latest LigH's build (3.4+9). tested the same encode with nvencc64 and frames number is correct. this prevents me to use hdr10+ encode for muxing with Dolby Vision EL+RPU...

[LigH]

Possibly best to report this in the x265 developer mailing list. I'll do so.

Please try to provide a small sample with only few frames (I'd suggest ~500 to have more than one GOP) if you can reproduce the issue in this case.

[Boulder]

I just noticed that --limit-tu 0 seems to be a potentially dangerous setting coupled with --rskip 2. I've encoded episodes of 'Chernobyl' and saw that the average bitrate is quite low for 1080p material. I found one scene where the encode looked really ugly and with some testing, I checked that changing from --limit-tu 4 to --limit-tu 0 made it happen. --ctu 32 also fixed the issue.

[microchip8]

I just noticed that --limit-tu 0 seems to be a potentially dangerous setting coupled with --rskip 2. I've encoded episodes of 'Chernobyl' and saw that the average bitrate is quite low for 1080p material. I found one scene where the encode looked really ugly and with some testing, I checked that changing from --limit-tu 4 to --limit-tu 0 made it happen. --ctu 32 also fixed the issue.

I've encoded quite a few flicks since then with limit-tu 0 and rskip 2 and have yet to see some noticable (major) distortions. Maybe your issue is sample specific

[Boulder]

I made some tests to show the issue. The basic x265 settings were "--preset slower --no-sao --aq-mode 1 --aq-strength 1.0 --qcomp 0.7 --crf 20". The source was unaltered, I only cropped the black borders off in the script.

--ctu 64 --limit-tu 4 --rskip 1 : 4730.32 kbps
--ctu 64 --limit-tu 0 --rskip 1 : 4477.60 kbps
--ctu 32 --limit-tu 4 --rskip 1 : 4735.29 kbps
--ctu 32 --limit-tu 0 --rskip 1 : 4733.48 kbps

--ctu 64 --limit-tu 4 --rskip 2 : 4863.81 kbps
--ctu 64 --limit-tu 0 --rskip 2 : 2877.67 kbps
--ctu 32 --limit-tu 4 --rskip 2 : 5090.29 kbps
--ctu 32 --limit-tu 0 --rskip 2 : 5142.87 kbps

I put the original source clip here:

https://drive.google.com/file/d/1nEa9H70d7Ekeue2omnwLDToVK7LaxZ_t/view?usp=sharing

The problem is very visible around the middle of the clip in the scene where the woman on the phone is in the distant background. The noise turns into very ugly shapes there.

I don't know if I should use --ctu 32 also with 1080p sources with --rskip 2 just to be safe. I need to test 1440p as well.

[Boulder]

A similar test with 1440p (2560x1048):

--limit-tu 4 : 6963.05 kbps
--limit-tu 0 : 6825.00 kbps
--limit-tu 4 --ctu 32 : 6905.23 kbps
--limit-tu 0 --ctu 32 : 6906.79 kbps
--limit-tu 4 --rskip 2 : 7563.58 kbps
--limit-tu 0 --rskip 2 : 5934.17 kbps
--limit-tu 4 --ctu 32 --rskip 2 : 7045.77 kbps
--limit-tu 0 --ctu 32 --rskip 2 : 7099.02 kbps

The large difference can also be seen there. I didn't check how the encode looked but probably there would be scenes which would look ugly. This means it's either --limit-tu 4 or --limit-tu 0 --ctu 32 to avoid the issue. I'm just not sure which one is the better choice quality-wise.

[LigH]

New upload: x265 3.4+14-gd419c7152 (https://www.mediafire.com/file/e5nsrl1bue9eld9/x265_3.4+14-gd419c7152.7z/file)

abr-ladder: fix memleak in copyInfo()
Fix cost estimation error for hist-based scenecut
Fix libvmaf integration issues

[Boulder]

I tested the histogram based scenecut detection yesterday quite a lot. I still couldn't get it to detect proper scenecuts -- it would either miss too many, at least one very obvious one, and lowering the threshold would cause it to find scenecuts in quite strange places. My Hot Fuzz testclip triggered scenecuts in scenes where there is some motion blur and then single frames which are just slightly less blurry. Probably the sudden sharp edged text on shirts etc. are enough to tell that it's a scenecut.

If you lower the threshold enough, it will start reducing the number of keyframes which was really strange. In the csv log, you can see that a scenecut is detected but they are often coded as B/b-frames.

[jlpsvk]

New upload: x265 3.4+14-gd419c7152 (https://www.mediafire.com/file/e5nsrl1bue9eld9/x265_3.4+14-gd419c7152.7z/file)

abr-ladder: fix memleak in copyInfo()
Fix cost estimation error for hist-based scenecut
Fix libvmaf integration issues

testing to encode 1917 HDR10+ again (testing with every new build)...

[quietvoid]

I tested the histogram based scenecut detection yesterday quite a lot. I still couldn't get it to detect proper scenecuts -- it would either miss too many, at least one very obvious one, and lowering the threshold would cause it to find scenecuts in quite strange places. My Hot Fuzz testclip triggered scenecuts in scenes where there is some motion blur and then single frames which are just slightly less blurry. Probably the sudden sharp edged text on shirts etc. are enough to tell that it's a scenecut.

If you lower the threshold enough, it will start reducing the number of keyframes which was really strange. In the csv log, you can see that a scenecut is detected but they are often coded as B/b-frames.

I've posted about this before:
So x265 3.4+9, they "fixed" --hist-threshold to avoid false positives. However it seems to do much worse than before (as well as 3.4+7, where they fixed the false positives).
I'm getting less I frames with --hist-threshold 0.005 (default 0.03) than the default scenecut algorithm..

Maybe my sample clip is not colorful enough..
Since then I've just given up on hist-scenecut. As well as scenecut-aware-qp, because they introduced QP changes before scene cuts...

[Boulder]

I've posted about this before

Actually that's why I tested it now, since there was that one patch related to the feature.

Too bad they don't seem to care for the original method anymore, my bug report (https://bitbucket.org/multicoreware/x265/issues/535/scenechange-detection-misses-two-clear) has not had any activity.

[vpupkind]

I've posted about this before:

Since then I've just given up on hist-scenecut. As well as scenecut-aware-qp, because they introduced QP changes before scene cuts...

Have you tried scenecut-aware-qp? Unless you pause at this frame, a human observer is typically unable to notice quality degradation within ~100ms from a strong scene cut.

[Boulder]

Have you tried scenecut-aware-qp? Unless you pause at this frame, a human observer is typically unable to notice quality degradation within ~100ms from a strong scene cut.

Why does that option only work with a multipass encode? You would expect that the lookahead could take care of the work also in CRF mode.

[quietvoid]

Have you tried scenecut-aware-qp? Unless you pause at this frame, a human observer is typically unable to notice quality degradation within ~100ms from a strong scene cut.

I have tried it, it was fine before they changed it.
The quality change AFTER a scene cut is not visible, but the idea of lowering the quality BEFORE (which is what they did) does not sound good to me.
It makes no sense.

Why does that option only work with a multipass encode? You would expect that the lookahead could take care of the work also in CRF mode.

This is another good point, I don't know how these patches get through quality checks.
It used to work just fine for CRF, and they added a condition that makes it multipass exclusive.

[foxyshadis]

This is another good point, I don't know how these patches get through quality checks.
It used to work just fine for CRF, and they added a condition that makes it multipass exclusive.

Since Steve Borho and chen moved on, the main quality check is "does it compile". Almost every submitted patch is immediately committed without discussion now, and reverted later if need be.

[LeXXuz]

Quick question: should SMT/Hyperthreading be enabled on a Ryzen 9 machine or not? With 2x logical cpus I had about 66% average cpu usage and lower fps than with logical cpus = cpus @ 95-100%. Same settings of course.

[Boulder]

HT on works fine. If the CPU usage tends to stay low, it could a parallelization issue like CTU 64 with less than FullHD resolution source.

[Atak_Snajpera]

Quick question: should SMT/Hyperthreading be enabled on a Ryzen 9 machine or not? With 2x logical cpus I had about 66% average cpu usage and lower fps than with logical cpus = cpus @ 95-100%. Same settings of course.

Always on.

[LigH]

HEVC has more dependencies than AVC. More parts of the calculation in x265 need to wait for intermediate results of previous calculations. Not approaching 100% CPU usage is not concerning. You may be able to run two separate encoding jobs (provided you have enough RAM and the cooling can handle the heat).

[LeXXuz]

Thanks for the replies guys.

Yes, I've noticed a temperature drop of about ten degrees with SMT off. But that is of no concern anyway since the cpus are watercooled.

I always use --ctu 32 for 1080p resolutions and below. Frame threads is set to auto. x.265 picks 4 threads on 3900x (12C/24T) and 5 threads on 3950x (16C/32T).

I did an encode with frame threads set to 1 but the file size was just negligible smaller than with the auto setting.

So SMT on it is. Maybe I just do 2 parallel jobs instead. :)

[microchip8]

Thanks for the replies guys.

Yes, I've noticed a temperature drop of about ten degrees with SMT off. But that is of no concern anyway since the cpus are watercooled.

I always use --ctu 32 for 1080p resolutions and below. Frame threads is set to auto. x.265 picks 4 threads on 3900x (12C/24T) and 5 threads on 3950x (16C/32T).

I did an encode with frame threads set to 1 but the file size was just negligible smaller than with the auto setting.

So SMT on it is. Maybe I just do 2 parallel jobs instead. :)

Try with --pmode

[Boulder]

I run my 3900X with two framethreads (-F 2). I don't know if it will increase quality (in theory it should) but the CPU usage difference to -F 4 is around 10% so I consider it more like headroom for doing all the other stuff at the same time. The encoder uses a 24-thread pool, I also assign 24 threads to Avisynth processing. The Avisynth part takes about 20-30% of total CPU time when encoding.

[LeXXuz]

I also assign 24 threads to Avisynth processing. The Avisynth part takes about 20-30% of total CPU time when encoding.

Wait. You mean you set prefetch() to 24 in Avisynth? :eek:
Or are we talking about different things here?

[Boulder]

Wait. You mean you set prefetch() to 24 in Avisynth? :eek:
Or are we talking about different things here?

Yes. Prefetch(24, 24) works best for me as I have a 12c/24t CPU.

[LeXXuz]

Hm. My encodes never gained any speed increase beyond prefetch(4). On the contrary, I had much more ram and cpu utilisization (naturally) but no fps increase. That's why I stayed with just 4.

[Boulder]

Did you increase the maximum cache size? When I switched back to Avisynth+, I noticed that I had to increase it to over 10GB for UHD things, otherwise everything would just stall. I think I now have it at 16GB just in case. Also the new caching method in Avs+ 3.6.1 helped me.

[K.i.N.G]

After a quick test adding these parameters to the encode improved the quality in parts with motion "--rskip 2 --max-merge 2 --rd-refine" with about the same bitrate.
The artifacts are still there but far less (and much less perceptible when playing the video).
I'll see if i can experiment some more with the settings later, maybe it can be improved even more.

Thanks to everyone for the usefull input and suggestions!

Just a quick update:
So, after some more testing I've found that setting --rskip 2 causes a lot of flickering macro blocks.. setting this to 1 (the default) fixed it.
I'm not sure if this reintroduces the original problem i was having of 'smeared' fast motion. I will need to (re)test some more later to see.

[Boulder]

Just a quick update:
So, after some more testing I've found that setting --rskip 2 causes a lot of flickering macro blocks.. setting this to 1 fixed it.
I'm not sure if this reintroduces the original problem i was having of 'smeared' fast motion. I will need to test some more to see.

Could you post the rest of your settings? I've not noticed that issue with --ctu 32 and --limit-tu 0. With --limit-tu 0 --rskip 2, --ctu 32 is a must. The encoder favours merges much more with --rskip 2 which tend to destroy quality if you are not careful.

I have to note that I am not at all confident that the developers always know what they are doing. As mentioned earlier, the true QA people have left the building and unfortunately it shows. I'm also quite disappointed that clear bug reports are not responded at all even if the issues being corrected would benefit also commercial clients.

[K.i.N.G]

Well, it looks like I jumped to conclusions a bit too fast...
appearantly its not completely gone with rskip 1... just a lot less.
So I'll try rskip 0 now...

Could you post the rest of your settings? I've not noticed that issue with --ctu 32 and --limit-tu 0. With --limit-tu 0 --rskip 2, --ctu 32 is a must. The encoder favours merges much more with --rskip 2 which tend to destroy quality if you are not careful.

I have to note that I am not at all confident that the developers always know what they are doing. As mentioned earlier, the true QA people have left the building and unfortunately it shows. I'm also quite disappointed that clear bug reports are not responded at all even if the issues being corrected would benefit also commercial clients.

settings:
x265.exe --crf 18 --preset veryslow --profile main10 --level-idc 4 --output-depth 10 --limit-refs 0 --psy-rdoq 1.5 --rskip-edge-threshold 4 --cu-lossless --subme 6 --merange 64 --max-merge 2 --keyint 480 --no-hdr10 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --deblock -2:-2 --selective-sao 0 --no-sao --high-tier --no-strong-intra-smoothing --rd-refine

Just standard HD (no HDR).

Will try CTU 32 and limit-tu 0 aswell.
*edit: as I'm using the very slow preset as a base limit-tu was already set at 0

[stax76]

Do lavf builds allow passing options to ffmpeg for instance to enable vpy reading, hw decoding or other useful ffmpeg functionality?

[K.i.N.G]

I've not noticed that issue with --ctu 32 and --limit-tu 0. With --limit-tu 0 --rskip 2, --ctu 32 is a must. The encoder favours merges much more with --rskip 2 which tend to destroy quality if you are not careful.

I have to note that I am not at all confident that the developers always know what they are doing. As mentioned earlier, the true QA people have left the building and unfortunately it shows. I'm also quite disappointed that clear bug reports are not responded at all even if the issues being corrected would benefit also commercial clients.

Setting --rskip 2 with --ctu 32 it still caused flickering macroblocks.
Setting --rskip 1 with --ctu 32 seems to have fixed it. I'll have to try with some other problematic sources later to be sure.

setting --rskip 2 wit a low --rskip-edge-threshold also seemed to give better results but I got tired of testing so I just went with rskip 1.


Yes, its very frustrating how easily things just break apart with x265. Quite a lot of issues which I dont seem to remember having encountered with older versions of x265?!


*edit: Nope, nevermind, still not fixed by adding --rskip 1 with --ctu 32, its still there in darker parts... Turning off rskip now...


.

[Boulder]

*edit:[/U][/B] Nope, nevermind, still not fixed by adding --rskip 1 with --ctu 32, its still there in darker parts... Turning off rskip now...
.
rskip off is probably worse. I think that --rskip 2 causes less recursion skips than --rskip 1 so in that sense, totally disabling skips would cause more issues.

You are probably using the default aq-mode (2), which is worse in my opinion. It sometimes caused the ugly floating macroblocks in flat areas, and I cannot stand those so I'd test also --aq-mode 1 to make sure it's not the issue there.

I also suggest removing --no-strong-intra-smoothing, there were some tests showing that the details are retained better that way.

[alex1399]

Does I miss something, the x265 last commit stopped at 73ca1d7 which is on 2020/05/30.

[LigH]

https://bitbucket.org/multicoreware/x265/commits/ = abandoned Mercurial repository. Obsolete.

https://bitbucket.org/multicoreware/x265_git/commits/ = current git repository. Use only now.

[nakTT]

https://bitbucket.org/multicoreware/x265/commits/ = abandoned Mercurial repository. Obsolete.

https://bitbucket.org/multicoreware/x265_git/commits/ = current git repository. Use only now.
Why did they abandoned it?

Btw, thanks for the info. No wonder there was no updates since 30th of May.

[filler56789]

Why did they abandoned it?

Because BitBucket decided to drop Mercurial -_-

[LigH]

It was announced half a year ago (https://forum.doom9.org/showthread.php?p=1898474#post1898474) so we all could adapt in time.

[K.i.N.G]

rskip off is probably worse. I think that --rskip 2 causes less recursion skips than --rskip 1 so in that sense, totally disabling skips would cause more issues.

You are probably using the default aq-mode (2), which is worse in my opinion. It sometimes caused the ugly floating macroblocks in flat areas, and I cannot stand those so I'd test also --aq-mode 1 to make sure it's not the issue there.

I also suggest removing --no-strong-intra-smoothing, there were some tests showing that the details are retained better that way.

Lower rskip values actually improved the results (at least with this issue/artifact).

Setting --aq-mode 1 also helps quite a bit!

So now I'm testing with aq-mode 1, rskip 2 with rskip-edge-threshold 0.03 and re-enabled strong-intra-smoothing.

So far its looking promessing... Thank you for these suggestions!
I have several problematic sources to re-encode and that's going to take a few weeks(!). So, it will take quite some time before I can tell for sure that it fixed the issue, but its looking good so far.

[nakTT]

Because BitBucket decided to drop Mercurial -_-

It was announced half a year ago (https://forum.doom9.org/showthread.php?p=1898474#post1898474) so we all could adapt in time.
I see. Thank for the clarification.

[fauxreaper]

https://bitbucket.org/multicoreware/x265/issues is gone and https://bitbucket.org/multicoreware/x265_git don't have an issue tracker.

[jlpsvk]

even latest x265 still encodes few frames less with hdr10+ metadata.. :(

[onekmilesbehind]

@jlpsvk have you tried using patman's 3.4+6 build from 5/30? HDR10+ was still working for me with that using the JSON sidecar file. At least if it works there, that gives you an idea of where things may have broken.

[Barough]

x265 v3.4+15-g45f1d01f8 (http://www.mediafire.com/file/y24vk81lrfdu8tm/x265-3.4+15-g45f1d01f8_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)


https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[BobbyBoberton]

Lower rskip values actually improved the results (at least with this issue/artifact).

Setting --aq-mode 1 also helps quite a bit!

So now I'm testing with aq-mode 1, rskip 2 with rskip-edge-threshold 0.03 and re-enabled strong-intra-smoothing.

So far its looking promessing... Thank you for these suggestions!
I have several problematic sources to re-encode and that's going to take a few weeks(!). So, it will take quite some time before I can tell for sure that it fixed the issue, but its looking good so far.

I find rskip 2 with hevc-aq mode enabled and rskip-edge-skip-threshold 5 to give very good results for me for both SDR and HDR content.

Just my experience

[LigH]

https://bitbucket.org/multicoreware/x265/issues is gone and https://bitbucket.org/multicoreware/x265_git don't have an issue tracker.

All that remains seems to be the mailing list: x265-devel@videolan.org (https://mailman.videolan.org/listinfo/x265-devel)

[Boulder]

All that remains seems to be the mailing list: x265-devel@videolan.org (https://mailman.videolan.org/listinfo/x265-devel)

Easy to get rid of the silly users reporting errors by not using an issue tracker :D

[jlpsvk]

@jlpsvk have you tried using patman's 3.4+6 build from 5/30? HDR10+ was still working for me with that using the JSON sidecar file. At least if it works there, that gives you an idea of where things may have broken.

will give it a try. :) but it's not a problem, that hdr10+ encoding is not working... it just does not throw out the same number of frames, as source.. :(

[LeXXuz]

Following a recent discussion I had with someone:

Is it still recommended to crop/resize videos to a mod-16 resolution?

I remember this was always recommended long time ago with MPEG2/MPEG4-ASP encoders.
I know 1080p isn't mod-16 either but after cropping I still either over- or undercrop to get a mod-16 resolution. Someone told me that wouldn't be necessary with x.265 and even x.264 anymore as long as it is mod-2 at least. :confused:

[LigH]

Vintage graphic cards used to suffer some performance loss when the output of the video player did not match some memory address boundaries. This era should be over.

Regarding encoding, it doesn't matter so much anymore. A modulo 2 may be necessary due to Chroma Subsampling 4:2:0. A modulo 4 is possibly a recommendable target regarding performance (related to partitions). But modern encoders and video formats allow encoding to dimensions not fitting macroblock (or coding unit) boundaries by encoding the video at the next larger boundary, repeating or mirroring some content, and carrying a crop rectangle telling the decoder to omit the rest. This may typically happen for 1080 encodes being stored with a height of 1088 and being cropped back to 1080 during playback, automatically.

PS: ITU standard = theory documents in upper case with dot (H.264), encoder implementation = practical software in lower case without dot (x264).

[LeXXuz]

Thanks for that explanation LigH :thanks:

So all left to worry about may be some of my Avisynth filters.

[Magik Mark]

Did you increase the maximum cache size? When I switched back to Avisynth+, I noticed that I had to increase it to over 10GB for UHD things, otherwise everything would just stall. I think I now have it at 16GB just in case. Also the new caching method in Avs+ 3.6.1 helped me.

Hi!

How do you increase the cache size?
Is there a table or formula in order to determine the optimum size? I do 1080p and 2160p

Thanks

[Boulder]

I use these lines to setup the cache:
SetMemoryMax(20480)
SetCacheMode(1)

To avoid having to put them in every script, I have them saved in the plugins folder as an .avsi file so it's autoloaded whenever Avs+ is used.
I don't think there is a special formula, the required amount depends on your script and the resolution. 20GB should be more than enough, it's just a safe maximum value which will never be exceeded in my use.

[Magik Mark]

I use these lines to setup the cache:
SetMemoryMax(20480)
SetCacheMode(1)

To avoid having to put them in every script, I have them saved in the plugins folder as an .avsi file so it's autoloaded whenever Avs+ is used.
I don't think there is a special formula, the required amount depends on your script and the resolution. 20GB should be more than enough, it's just a safe maximum value which will never be exceeded in my use.

I use StaxRIP. Do you happen to know how this is implemented?

[Boulder]

It's probably using the Avisynth+ default values. If the program uses a standard Avs+ installation, you can save the avsi file to its plugins folder and it's autoloaded from there. The path is usually C:\Program Files\Avisynth+\plugins64.

[Magik Mark]

It's probably using the Avisynth+ default values. If the program uses a standard Avs+ installation, you can save the avsi file to its plugins folder and it's autoloaded from there. The path is usually C:\Program Files\Avisynth+\plugins64.Alright then will give it a try.

What file name shall I use?

Sent from my SM-G988B using Tapatalk

[LigH]

Doesn't matter much. AviSynth+ will try to load all DLL and AVSI files from there. So, how about: defaults.avsi or similar...

[Magik Mark]

Thanks a lot!

Will experiment soon

Sent from my SM-G988B using Tapatalk

[Magik Mark]

Whats the difference between hevc-aq and aq-mode? Do I have to turn off one of them when encoding?

Which one is better to use?

[jlpsvk]

@jlpsvk have you tried using patman's 3.4+6 build from 5/30? HDR10+ was still working for me with that using the JSON sidecar file. At least if it works there, that gives you an idea of where things may have broken.

no go... the result still the same... :(

source has 171176 frames, encode has 171171 frames...

without HDR10+ metadata, encode has 171176 frames...

[Greenhorn]

Whats the difference between hevc-aq and aq-mode? Do I have to turn off one of them when encoding?

Which one is better to use?

hevc-aq, confusingly, is just another mode of AQ (adaptive quantization) that gets its own option instead of being added to the same list as the others. There's a even third option, aq-motion, which also gets its own option.

General consensus seems to be that hevc-aq and aq-motion are both sort of experimental features. I know there's at least one user here who really like hevc-aq, though. I'd just note that in CRF mode, hevc-aq will lower bitrates really drastically-- enough to affect visual quality in my experience. It's possible still more efficient than the other aq-modes if you lower your CRF to compensate, but just don't set blindly, is what I guess I'm saying.

[charliebaby]

X265 3.4+15-g45f1
VS 2019 GCC 10.2
http://www.mediafire.com/file/ho3b7exg7w9n6qd/x265-3.4+15.rar/file

[benwaggoner]

hevc-aq, confusingly, is just another mode of AQ (adaptive quantization) that gets its own option instead of being added to the same list as the others. There's a even third option, aq-motion, which also gets its own option.
AQ needs some refactoring, for sure!
aq-mode 3=2 with low luma bias. hevc-aq is really aq-mode 5, and should map to that.

I'd suggest some ala:

--aq-method for 0, 1, 2, 4, and hevc-aq mapping to 0-4.
A seperate --aq-dark so we could apply the low luma offset to any method.
And ideally an --aq-dark-strength to control that offset.


General consensus seems to be that hevc-aq and aq-motion are both sort of experimental features.
Aq-motion is a lot more experimental than hevc-aq, and I've not heard anyone suggest it'd be appropriate to have on by default. HEVC-AQ is a lot more mature at this point, althogh newer.

The concept of having motion impact AQ is quite straightforward and of obvious benefit, but getting an actual psycho-visually tuned algorithm implemented is...complex. Especially since other things in x265 are also responding to motion and need to be considered.

I know there's at least one user here who really like hevc-aq, though. I'd just note that in CRF mode, hevc-aq will lower bitrates really drastically-- enough to affect visual quality in my experience. It's possible still more efficient than the other aq-modes if you lower your CRF to compensate, but just don't set blindly, is what I guess I'm saying.
Given aq's influence on ABR, testing aq parameters at a given CRF isn't efficient. I strongly recommend testing with 2-pass VBR so we can really see bang for the bit. Once the most efficient aq parameters are figured out for the given scenario, then the right CRF can be determined.

[LeXXuz]

I could use some advice to reduce banding on my x265 encodes.

I've noticed on many newer movies (with little to no noise) banding appears on my x265 encodes in difference to the source H.264 video from Blu-ray.

I expected encodes with --crf 16 --aq-mode 3 --no-sao --output-depth 10 on the "slower" preset to be more transparent regarding the source video.

However, banding occurs especially in dark backgrounds like underwater scenes, night skies and such.

My intend is to do this without any additional AVS filters to leave the source video as 'untouched' as possible.

From your experience are there any tweaks I can use to force x265 to (obviously) spend more bits into these scenes?

[microchip8]

I could use some advice to reduce banding on my x265 encodes.

I've noticed on many newer movies (with little to no noise) banding appears on my x265 encodes in difference to the source H.264 video from Blu-ray.

I expected encodes with --crf 16 --aq-mode 3 --no-sao --output-depth 10 on the "slower" preset to be more transparent regarding the source video.

However, banding occurs especially in dark backgrounds like underwater scenes, night skies and such.

My intend is to do this without any additional AVS filters to leave the source video as 'untouched' as possible.

From your experience are there any tweaks I can use to force x265 to (obviously) spend more bits into these scenes?

Try increasing psy-rd and psy-rdoq. Something like 3 for psy-rd and 15 for psy-rdoq. Also, aq-mode 1 seems better than the other aq modes

[excellentswordfight]

I could use some advice to reduce banding on my x265 encodes.

I've noticed on many newer movies (with little to no noise) banding appears on my x265 encodes in difference to the source H.264 video from Blu-ray.

I expected encodes with --crf 16 --aq-mode 3 --no-sao --output-depth 10 on the "slower" preset to be more transparent regarding the source video.

However, banding occurs especially in dark backgrounds like underwater scenes, night skies and such.

My intend is to do this without any additional AVS filters to leave the source video as 'untouched' as possible.

From your experience are there any tweaks I can use to force x265 to (obviously) spend more bits into these scenes?
I would recommend the same thing as froggy1, try aq-mode 1.

Generally I use aq-mode 1, 2 & 3 for low, medium & high compression targets. Aq-mode 1 seems to work best for visually lossless goals while 3 is better for highly compressed encodes.

[Barough]

x265 v3.4+18-g8718641e5 (http://www.mediafire.com/file/qn5am9a43uyiw7r/x265-3.4+18-g8718641e5_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[LeXXuz]

I would recommend the same thing as froggy1, try aq-mode 1.


That confuses me a little. Isn't aq-mode 3 supposed to work better on dark scenes? :confused:

[microchip8]

That confuses me a little. Isn't aq-mode 3 supposed to work better on dark scenes? :confused:

In theory. In practice, not really. It sucks up bitrate and can make the image worse

[LeXXuz]

Try increasing psy-rd and psy-rdoq. Something like 3 for psy-rd and 15 for psy-rdoq. Also, aq-mode 1 seems better than the other aq modes

I would recommend the same thing as froggy1, try aq-mode 1.

Generally I use aq-mode 1, 2 & 3 for low, medium & high compression targets. Aq-mode 1 seems to work best for visually lossless goals while 3 is better for highly compressed encodes.


Thank you guys. I will try out those settings. :)

[LigH]

NASM 2.15.03 (MSYS2/MinGW) throws a huge amount of macro warnings.

Just a list of warnings for one file (there were so many, it left my console window's line buffer):

[ 18%] Building ASM_NASM object common/CMakeFiles/common.dir/x86/loopfilter.asm.obj
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1243: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1243: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1243: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1364: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1364: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1364: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1494: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1494: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1494: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1614: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1614: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1614: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1869: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1869: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1869: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1955: warning: improperly calling multi-line macro `SETUP_STACK_POINTER' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:629: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1955: warning: improperly calling multi-line macro `ALLOC_STACK' with 0 parameters [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:632: ... from macro `PROLOGUE' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:1955: warning: dropping trailing empty parameter in call to multi-line macro `DEFINE_ARGS_INTERNAL' [-w+macro-params-legacy]
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:722: ... from macro `cglobal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:755: ... from macro `cglobal_internal' defined here
E:/MABS/build/x265_git-git/source/common/x86/loopfilter.asm:634: ... from macro `PROLOGUE' defined here

[LigH]

Will this be another case of "warnings to be silenced by legacy parameter", or is it a hint to a more serious issue?

[MasterNobody]

Will this be another case of "warnings to be silenced by legacy parameter", or is it a hint to a more serious issue?

It is hint that they should update x264asm (x86inc.asm):
x86inc: Fix warnings when using nasm 2.15 (https://code.videolan.org/videolan/x264/-/commit/22fcbe12046b7d6ed7af5d7a47258f1f2ebd56c1)
Fix compilation with nasm 2.15 (https://code.videolan.org/videolan/x264/-/commit/d78c1e83a1a9d34857eb53294282b3fbca3aba18)

[LigH]

:thanks:

No reply to the mailing list, though...

[Rousseau]

Is it possible to do a partial crf encode using an analysis-save/load file ? Is there a way to specify the proper start frame in the analysis.dat file? The seek function doesn't appear to work.

[charliebaby]

x265-3.4+20-g06c5

VS 2019 GCC 10.2 = http://www.mediafire.com/file/dbdh0lvpxghd63w/x265-3.4+20-g06c5.rar/file

[benwaggoner]

Is it possible to do a partial crf encode using an analysis-save/load file ? Is there a way to specify the proper start frame in the analysis.dat file? The seek function doesn't appear to work.
I'm not sure what a "partial CRF" file would be. But you can run a CRF encode using analysis-load.

[Rousseau]

I'm not sure what a "partial CRF" file would be. But you can run a CRF encode using analysis-load.

What I mean is, if I did a partial encode but was interrupted by a crash, could I resume the encode where I left off in a new file (to merge later) so I wouldn't have to re-encode the whole thing. I've done this with crf encodes before but with the analysis file it's like a 2-pass encode. I tried ignoring the analysis file but then my bitrate seems to be cut in half. :confused: I thought --seek might work but it seems to have no effect.

[benwaggoner]

What I mean is, if I did a partial encode but was interrupted by a crash, could I resume the encode where I left off in a new file (to merge later) so I wouldn't have to re-encode the whole thing. I've done this with crf encodes before but with the analysis file it's like a 2-pass encode. I tried ignoring the analysis file but then my bitrate seems to be cut in half. :confused: I thought --seek might work but it seems to have no effect.
I think it should work in theory, but there could be a bug. But --seek and --frames do work; that's how doing chunked encode works. Best to use --chunk-start as well to get VBV tracking more accurately at the start.

[Barough]

x265 v3.4+22-ga988fbbac (http://www.mediafire.com/file/u515zgaovxwo5s9/x265-3.4+22-ga988fbbac_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[ghostshadow]

Hello, i have HEVC encoder version 3.4+10-g7a640a2c1
build info [Windows][MSVC 1926][64 bit] 10bit,
but I wanted to install one of the latest version (34+12, 34+20)and with these versions I have this error "x265-10b: unrecognized option `--max-qp-delta' "
Here are the parameters used : --ref 4 --scenecut-aware-qp --scenecut-window 500 --max-qp-delta 10 --no-cu-lossless

I am in 2 pass encoding.
Please Help me

[Greenhorn]

Hello, i have HEVC encoder version 3.4+10-g7a640a2c1
build info [Windows][MSVC 1926][64 bit] 10bit,
but I wanted to install one of the latest version (34+12, 34+20)and with these versions I have this error "x265-10b: unrecognized option `--max-qp-delta' "
Here are the parameters used : --ref 4 --scenecut-aware-qp --scenecut-window 500 --max-qp-delta 10 --no-cu-lossless

I am in 2 pass encoding.
Please Help me

It appears to have been split into two options: --qp-delta-ref and --qp-delta-nonref. The first is for REFERENCED p/b frames and defaults to 5.0, while the second is for NON-REFERENCED p/b frames and defaults to 6.5.

This is present in the CLI encoder's documentation, but not on x265.readthedocs.io; 3.4+20 (and all versions after 3.4+4) are development builds, rather than release. (Even if the difference between the two is usually kinda small.)

[ghostshadow]

It appears to have been split into two options: --qp-delta-ref and --qp-delta-nonref. The first is for REFERENCED p/b frames and defaults to 5.0, while the second is for NON-REFERENCED p/b frames and defaults to 6.5.

This is present in the CLI encoder's documentation, but not on x265.readthedocs.io; 3.4+20 (and all versions after 3.4+4) are development builds, rather than release. (Even if the difference between the two is usually kinda small.)

Thank you very much

[jlpsvk]

ok.. seriously there's a problem with x265 and HDR10+ encoding...

tried another HDR10+ encode... source has 195593 frames, encode has 195585. Without HDR10+ (only HDR10) encode has 195593. It's clearly problem of x265, as with nVidia and Intel's encoders, using the same HDR10+ metadata file, output has right number of frames.

[benwaggoner]

It appears to have been split into two options: --qp-delta-ref and --qp-delta-nonref. The first is for REFERENCED p/b frames and defaults to 5.0, while the second is for NON-REFERENCED p/b frames and defaults to 6.5.

This is present in the CLI encoder's documentation, but not on x265.readthedocs.io; 3.4+20 (and all versions after 3.4+4) are development builds, rather than release. (Even if the difference between the two is usually kinda small.)
This seems like a good feature to have. Spending fewer bits on non-reference frames in order to spend more on reference frames so they provide better predictors for the frames they reference is a key feature of good rate control.

We already have that in the ip and pb ratios. But with HEVC you can have non-referenced blocks in all frame types.

Getting it tuned so there isn't any thresholding (visible seams when a contiguous area has some reference and some non-reference blocks) is the tricky part with such things.

[birdie]

They've migrated to a new repo and pretty much all the old open issues have been lost in transition. Sigh.

[benwaggoner]

They've migrated to a new repo and pretty much all the old open issues have been lost in transition. Sigh.
Well, we should go back and add new repros for bugs that still exist. I hope some of the older ones have gotten fixed in the backgroud.

[Majorlag]

ok.. seriously there's a problem with x265 and HDR10+ encoding...

tried another HDR10+ encode... source has 195593 frames, encode has 195585. Without HDR10+ (only HDR10) encode has 195593. It's clearly problem of x265, as with nVidia and Intel's encoders, using the same HDR10+ metadata file, output has right number of frames.

How are you feeding x265, hopefully with a frame accurate frame server?

What frame server are you using AviSynth+ or VaporSynth? Also which indexer are you using? I tend to get better consistent results with FFMSIndex. To many failed encodes with L-SMASH Works indexer.

Have you tried removing all x265 custom parameters and just use defaults with just hdr10+ options to eliminate any conflicting parameters?

[Barough]

x265 v3.4+24-g6ed1c24a2 (http://www.mediafire.com/file/x813hgzm896xpz7/x265-3.4+24-g6ed1c24a2_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[jlpsvk]

How are you feeding x265, hopefully with a frame accurate frame server?

What frame server are you using AviSynth+ or VaporSynth? Also which indexer are you using? I tend to get better consistent results with FFMSIndex. To many failed encodes with L-SMASH Works indexer.

Have you tried removing all x265 custom parameters and just use defaults with just hdr10+ options to eliminate any conflicting parameters?

no matter what i try. :) still the same result, staxrip, ripbot264, command line.... still the same... with the same setting but just without dhdr, encoded frame number is identical to source

as soon as i use GPU encoder (intel or nvidia), encode is fine.

[benwaggoner]

no matter what i try. :) still the same result, staxrip, ripbot264, command line.... still the same... with the same setting but just without dhdr, encoded frame number is identical to source

as soon as i use GPU encoder (intel or nvidia), encode is fine.
Check your JSON file, and see if it has a different number of frames than your source or something. Or if the final frames that are cut off have all have the same metadata. My wild guess is that x265 is cutting off frames that it doesn't have metadata for, or unique metadata for. Which would be a bug.

[jlpsvk]

Check your JSON file, and see if it has a different number of frames than your source or something. Or if the final frames that are cut off have all have the same metadata. My wild guess is that x265 is cutting off frames that it doesn't have metadata for, or unique metadata for. Which would be a bug.

when using JSON for encode with intel or nvidia, everything is OK.... :( so i excluded wrong JSON.. i also tried with different movies and the results are the same.

[Barough]

x265 v3.4+26-ga82c6c7a7 (http://www.mediafire.com/file/errun2hhaj9u0mw/x265-3.4+26-ga82c6c7a7_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master

[filler56789]

OK, I was bored, so I compiled x265.exe 3.4+30-g6722fce.

GIT command-line:
git clone --single-branch --branch Release_3.5 --depth 128 https://bitbucket.org/multicoreware/x265_git.git

Changes since commit ga82c6c7a7:
https://bitbucket.org/multicoreware/x265_git/commits/all

Download:
http://www.mediafire.com/file/8n5bnny3rc4915x/x265_3.4%252B30-g6722fce.7z/file

[benwaggoner]

And wow, this thread went three weeks without a post.

I see from the git that we're getting x265 3.5 features checked in.

[markiemarcus]

AQ needs some refactoring, for sure!
aq-mode 3=2 with low luma bias. hevc-aq is really aq-mode 5, and should map to that.

Aq-motion is a lot more experimental than hevc-aq, and I've not heard anyone suggest it'd be appropriate to have on by default. HEVC-AQ is a lot more mature at this point, althogh newer.



Yes the mapping is a little confusing! Also that Aq strength has no impact on hevc-aq could probably be better clarified.

I must say though, HEVC-AQ is by far my preferred method of encoding animation in instances with selective sao 0-2. The other aq modes typically produce more noise around dark lines. Even with 2 pass encodes and checking aq-strength in steps of 0.05, I haven't been able to replicate hevc-aq's results in this area with any of the other aq modes. There's also something about having RD greater than 4 and b-intra enabled that really seems to helps with this too. Slow though, but you can make compromises in other areas. Rect for instance seems to achieve nothing or very little. Tskip works well.

How have you found aq mode 4? With grainier or more detailed content, I'm finding the results extremely encouraging. Seems to fare well on flat areas with grain, especially in high motion.

[vpupkind]

hevc-aq and aq mode 4 are different: hevc-aq is based on quartile variance, while aq mode 4 is based on variance of edges

[markiemarcus]

hevc-aq and aq mode 4 are different: hevc-aq is based on quartile variance, while aq mode 4 is based on variance of edges

Very obviously so based on the results alone. Aq mode 4 is actually a fair bit slower too.

They both seem quite mature to me; but it's definitely very much source dependent. HEVC-AQ for instance I've had less than ideal results with live action, but it's rather good and my preferred mode with animation.

[vpupkind]

Aq mode 4 is actually a fair bit slower too.


AQ4, histogram-based scenecut, and rskip 2 all depend on an edge detection pre-pass.

[markiemarcus]

AQ4, histogram-based scenecut, and rskip 2 all depend on an edge detection pre-pass.

Ah that explains a lot.

[quietvoid]

I've created a new issue for the previously mentioned x265 HDR10+ crashes: https://bitbucket.org/multicoreware/x265_git/issues/574/x265-segmentation-fault-when-using-hdr10
If someone knows a bit around the code, it might be simple to fix.
Otherwise I hope it reaches someone over at MCW.

[jlpsvk]

I've created a new issue for the previously mentioned x265 HDR10+ crashes: https://bitbucket.org/multicoreware/x265_git/issues/574/x265-segmentation-fault-when-using-hdr10
If someone knows a bit around the code, it might be simple to fix.
Otherwise I hope it reaches someone over at MCW.

Hail to quietvoid!!! :)

[LigH]

I'm getting buried under NASM warnings for over a month now... patching them out like in x264 is not good enough for x265. They seem to need experienced contributors.

[filler56789]

https://bitbucket.org/multicoreware/x265_git/issues/559/warnings-when-assembling-with-nasm-215

so the problem is 3 months old already -_-

I keep using nasm 2.14, but I know the users of MABS have to use what MABS gives them :-/

[LeXXuz]

So many updates in the last couple of weeks/month. May I ask what version is recommended for daily use?

[Selur]

Can someone clear up why '--tune psnr' disables '--hevc-aq' ?

For detail how I come to this conclusion read:
https://forum.doom9.org/showpost.php?p=1925877
https://forum.doom9.org/showpost.php?p=1925878

Cu Selur

Ps.: also created an entry in the issue tracker (https://bitbucket.org/multicoreware/x265_git/issues/575/can-someone-clear-up-why-tune-psnr)

[vpupkind]

I think this is the expected behavior for tune=psnr.
If I am not mistaken, it always disabled adaptive quantization and psy-rd.

[Asmodian]

Can someone clear up why '--tune psnr' disables '--hevc-aq' ?

Because psnr is worse with --hevc-aq enabled?

[LigH]

Yes. Psycho-visual enhancements in general shall appear more convenient to a human, but will probably cause a bigger objective difference to the original.

[Selur]

If I am not mistaken, it always disabled adaptive quantization and psy-rd.
But shouldn't "--tune psnr --hevc-aq" and "--aq-mode 0 --no-psy-rd --psy-rdoq 0 --hevc-aq" then not have the same effect?

Because psnr is worse with --hevc-aq enabled?
but there shouldn't it be documented somewhere that "--tune psnr" disables "-hevc-aq" and "--aq-mode 0 --no-psy-rd --psy-rdoq 0" does not which according to https://bitbucket.org/multicoreware/x265_git/src/master/source/common/param.cpp (line 566-571) is what psnr does?

Cu Selur

[benwaggoner]

But shouldn't "--tune psnr --hevc-aq" and "--aq-mode 0 --no-psy-rd --psy-rdoq 0 --hevc-aq" then not have the same effect?

but there shouldn't it be documented somewhere that "--tune psnr" disables "-hevc-aq" and "--aq-mode 0 --no-psy-rd --psy-rdoq 0" does not which according to https://bitbucket.org/multicoreware/x265_git/src/master/source/common/param.cpp (line 566-571) is what psnr does?
Neither SSIM or PSNR are the "native" internal metric used by x265. Thus turning off all psychovisual tuning doesn't push encoding into PNSR.

And a really aggressive PSNR optimization has lots of unfortunate side effects. For example, optimizing for mean PSNR would mean subjective quality would be higher at the start of a GOP and lower at the end, as getting really good references early improves the whole GOP, while encoding a lot of intra on the last B-frame doesn't.

Pretty much any metric winds up being increasingly pathological subjectively the more closely its objective values are optimized for. There are plenty of tricks that can be played with VMAF even.

[Selur]

This wasn't really about metrics, but about that shortening the command line using options '--tune psnr' should cover has unexpected effects,..

Cu Selur

[LigH]

x264 --fullhelp
--tune <string> Tune the settings for a particular type of source
or situation
Overridden by user settings.
Multiple tunings are separated by commas.
Only one psy tuning can be used at a time.
...
- psnr (psy tuning):
--aq-mode 0 --no-psy
...

x265 --fullhelp is not as verbose. More information only online (https://x265.readthedocs.io/en/master/presets.html#tunings) (see blue Note).

Would you like some kind of x265 [info|warning]: PSNR tuning may result in subjectively lower quality console output?

[Selur]

According to the x265 source code:

if (!strcmp(tune, "psnr"))
{
param->rc.aqStrength = 0.0;
param->psyRd = 0.0;
param->psyRdoq = 0.0;
}
source: https://bitbucket.org/multicoreware/x265_git/src/master/source/common/param.cpp
"--tune psr" should be the same as using "--aq-strength 0 --no-psy-rd --psy-rdoq 0"
"--aq-strength 0" is the same as "--aq-mode 0" and "--psy-rdoq" shouldn't be used when "--no-psy-rd" is used
so:
1. --aq-mode 0 --psy-rdoq 0 --hevc-aq
should have the same effect as:
2. --psnr --hevc-aq
which is has not.
When using 1. --hevc-aq is used, but with 2. it is not;

[poisondeathray]

so:
1. --aq-mode 0 --psy-rdoq 0 --hevc-aq
should have the same effect as:
2. --psnr --hevc-aq
which is has not.
When using 1. --hevc-aq is used, but with 2. it is not;

typo?

--tune psnr is not the same thing as --psnr

--psnr just calculates metrics

[LigH]

Surely Selur meant --tune psnr

[Selur]

yes I meant '--tune psnr'

[Asmodian]

I agree, --hevc-aq is a new option that is and should be turned off by --tune psnr. The documentation simply needs updating to let the user know --tune psnr will turn it off like the other AQ options.

[benwaggoner]

I agree, --hevc-aq is a new option that is and should be turned off by --tune psnr. The documentation simply needs updating to let the user know --tune psnr will turn it off like the other AQ options.
--hevc-aq is a terrible parameter, as it introduces a lot of unneeded interdependency with other parameters. If it was just --aq-mode 5 everything would just work.

[Selur]

If it was just --aq-mode 5 everything would just work.
agree :)

[Boulder]

Has anyone made any comprehensive tests regarding the various rskip modes? I was just thinking if CPU time is not a factor, would --rskip 0 always produce the highest quality output, no matter if it's a high or low bitrate encode. Rskip mode 2 clearly produces less onion artifacts compared to mode 1 but I'm not sure if allowing full recursion would bring any improvement.

This question arises because I'm always having a hard time trying to understand what the x265 development is targeting. It often seems to be trying to do more things at very low bitrates, which usually means losing detail etc. while my needs are quite the opposite.

[-QfG-]

Has anyone an idea how i can make a single layer DV Encode? I mean, if i have both layers, HDR10 and DV - how can i encode one single Layer DV file, in case how makeMKV does this? I have seen an single Layer DV x265 Encode, so i think there is a functionality.

Many Thanks for response.

[LigH]

What does "DV" mean in this context?

[Majorlag]

Has anyone an idea how i can make a single layer DV Encode? I mean, if i have both layers, HDR10 and DV - how can i encode one single Layer DV file, in case how makeMKV does this? I have seen an single Layer DV x265 Encode, so i think there is a functionality.

Many Thanks for response.

I am going to guess your talking about DolbyVision. As per makeMKV forum, you would use mp4 muxer, instructions at https://makemkv.com/forum/viewtopic.php?t=18602

mp4muxer --dv-profile 7 --input-file (baselayername.hevc1) --input-file (dvlayername.hevc2) --input-file (audio.ac3) --media-lang eng --output-file (nameofmovie).mp4

[-QfG-]

dv profile 7 is Dual Layer. I need Profile 8.1 Single Layer DV + HDR Support. The newest makeMKV can create this Video Stream from a DV Dual Layer UHD, so i have one Single DV + HDR Videostream.
I search a Tool, that can convert 2 Streams (Video Layer and Dolby Vision Layer) in a Single Layer DV Profile 8.1.

[jlpsvk]

dv profile 7 is Dual Layer. I need Profile 8.1 Single Layer DV + HDR Support. The newest makeMKV can create this Video Stream from a DV Dual Layer UHD, so i have one Single DV + HDR Videostream.
I search a Tool, that can convert 2 Streams (Video Layer and Dolby Vision Layer) in a Single Layer DV Profile 8.1.

you want this...

https://www.makemkv.com/forum/viewtopic.php?f=12&t=18602&p=96282#p96282

[agressiv]

dv profile 7 is Dual Layer. I need Profile 8.1 Single Layer DV + HDR Support. The newest makeMKV can create this Video Stream from a DV Dual Layer UHD, so i have one Single DV + HDR Videostream.
I search a Tool, that can convert 2 Streams (Video Layer and Dolby Vision Layer) in a Single Layer DV Profile 8.1.

MakeMKV is doing their own thing by adding the Profile 7 EL on top of a the BL in a "piggyback" fashion, but this is now "officially" supported in Matroska. MKVToolnix is currently unaware of Dolby Vision, but the latest MediaInfo will see it.

If you truly want Profile 8.1, you'll need the RPU extracted as an elementary stream and can use x265.exe to encode it with this guide:

http://x265.org/x265-delivers-dolby-vision-streams/

The MakeMKV guide linked above is good if you just want to remux, but depending on your player - TV's tend to like dual-layer DV and players like NVidia Shield want single layer DV.

Muxing the video - well, let's just say that Dolby's mp4muxer doesn't like to mux encoded x265 Dolby Vision Profile 8.1 streams - it tends to just hang. I would advise using TSMuxeR until MKVToolnix has native support, assuming they handle other DV profiles when support is added. If you can get mp4muxer to work on encoded DV content, I'm all ears on how you got it to work.

[jlpsvk]

MakeMKV is doing their own thing by adding the Profile 7 EL on top of a the BL in a "piggyback" fashion, but this is now "officially" supported in Matroska. MKVToolnix is currently unaware of Dolby Vision, but the latest MediaInfo will see it.

If you truly want Profile 8.1, you'll need the RPU extracted as an elementary stream and can use x265.exe to encode it with this guide:

http://x265.org/x265-delivers-dolby-vision-streams/

The MakeMKV guide linked above is good if you just want to remux, but depending on your player - TV's tend to like dual-layer DV and players like NVidia Shield want single layer DV.

Muxing the video - well, let's just say that Dolby's mp4muxer doesn't like to mux encoded x265 Dolby Vision Profile 8.1 streams - it tends to just hang. I would advise using TSMuxeR until MKVToolnix has native support, assuming they handle other DV profiles when support is added. If you can get mp4muxer to work on encoded DV content, I'm all ears on how you got it to work.

MKVtoolnix 51 is aware of DoVi and preserves metadata...

With the guide o posted, you can encode pure HDR without cropping, the use encoded hevc to combine with EL+RPU to combine into PROFILE 8.1

[LigH]

New upload: x265 3.4+27-g5163c32d7 (https://www.mediafire.com/file/xzi9yyztn0wk5gi/x265_3.4+27-g5163c32d7.7z/file)

CLI changes since x265 3.4+14-gd419c7152:


Defaults changed from undef to unknown for:
--overscan
--colorprim
--colormatrix
New options:
--min-vbv-fullness <double> Minimum VBV fullness percentage to be maintained. Default 50.00
--max-vbv-fullness <double> Maximum VBV fullness percentage to be maintained. Default 80.00

--[no-]vbv-live-multi-pass Enable realtime VBV in rate control 2 pass.Default disabled


Apparently there is a new commit based on an older branch (+27) which only updates the documentation but skips the latest additions with the "ABR Ladder" (+30)...

[ghostshadow]

hello, on version 3.0 you have introduced the parameters:
–dolby-vision-profile <integer|float>
and
–dolby-vision-rpu’ File containing Dolby Vision RPU metadata.
Excluding as for:
--dhdr10-info
You do not provide anything to exploit them. Indeed how to extract the Dolby Vision RPU? So these parameters are not usable.
For HDR10 + (--dhdr10-info) a coder had to face a python script to extract the metadata to use the: --dhdr10-info.
So what do we do to exploit the: –dolby-vision-rpu
thank

[LigH]

New upload: x265 3.4+30-g6722fce1f (https://www.mediafire.com/file/sk7nni880d16eo8/x265_3.4+30-g6722fce1f.7z/file)

[benwaggoner]

hello, on version 3.0 you have introduced the parameters:
–dolby-vision-profile <integer|float>
and
–dolby-vision-rpu’ File containing Dolby Vision RPU metadata.
Excluding as for:
--dhdr10-info
You do not provide anything to exploit them. Indeed how to extract the Dolby Vision RPU? So these parameters are not usable.
For HDR10 + (--dhdr10-info) a coder had to face a python script to extract the metadata to use the: --dhdr10-info.
So what do we do to exploit the: –dolby-vision-rpu
thank
Normally one uses software that generates the RPU file, like Dolby's SDK or ColorFront Transkoder. Unless Profile 8.x is targeted, that's coupled with software that creates the non-backwards compatible base layer, and the RPU data is relative to that.

Dolby hasn't really invested in making Dolby Vision a hobbyist-friendly format. Although the support in the iPhone 12 Pro might change that some. But even that uses a new profile that's not widely supported by TVs (HLG + metadata), and doesn't have RPU data compatible with typical DoVi content. Making a DoVi Blu-ray from an iPhone DoVi file requires changing every pixel in the video and generating new dynamic metadata.

[Blue_MiSfit]

Yeah, how would one even do that? Convert the HLG into PQ and do a new analysis pass in Resolve or something, then encode UHD BD compliant Profile 5 or 7 from that?

[FranceBB]

Dolby hasn't really invested in making Dolby Vision a hobbyist-friendly format. Although the support in the iPhone 12 Pro might change that some. But even that uses a new profile that's not widely supported by TVs (HLG + metadata), and doesn't have RPU data compatible with typical DoVi content. Making a DoVi Blu-ray from an iPhone DoVi file requires changing every pixel in the video and generating new dynamic metadata.

Our of curiosity, how are the new iPhones recording?
I saw the "Dolby Vision" announcement days ago, but it was rather vague. Is it H.265 10bit UHD HDR HLG 60p with metadata? Does it have the FULL HD 10bit additional layer with info to make the 12bit final result? Or perhaps it's still one layer in 8bit? And most importantly, given that most mobile phones have a ridiculously tiny sensor whose stops are low, does all this even make sense? I mean, I read that it can achieve up to 12 stops, but I think that it's not gonna get even close. SDR in BT709 100 nits is 6 stops, if they manage to get 9 stops out of that it would already be a miracle...

[Stacey Spears]

Yeah, how would one even do that? Convert the HLG into PQ and do a new analysis pass in Resolve or something, then encode UHD BD compliant Profile 5 or 7 from that?

UHD BD only supports Profile 7.

[Stacey Spears]

Our of curiosity, how are the new iPhones recording?
I saw the "Dolby Vision" announcement days ago, but it was rather vague. Is it H.265 10bit UHD HDR HLG 60p with metadata? Does it have the FULL HD 10bit additional layer with info to make the 12bit final result? Or perhaps it's still one layer in 8bit? And most importantly, given that most mobile phones have a ridiculously tiny sensor whose stops are low, does all this even make sense? I mean, I read that it can achieve up to 12 stops, but I think that it's not gonna get even close. SDR in BT709 100 nits is 6 stops, if they manage to get 9 stops out of that it would already be a miracle...

They use Profile 8.3, which is HLG + Dolby's dynamic metadata. If you have an LG C9 or CX, it will play in Dolby Vision. If you have an older LG, then it plays as HLG.

Profile 5 and 8 are single layer 10-bit profiles. Profile 7 has the additional full enhancement layer for addition bit-depth. Profile 5 uses ICtCp while Profile 7 and 8 use YCbCr.

The reason the iPhone went with Profile 8.3 was so they would not have to tone map for the SDR version.

[nakTT]

New upload: x265 3.4+30-g6722fce1f (https://www.mediafire.com/file/sk7nni880d16eo8/x265_3.4+30-g6722fce1f.7z/file)

Thanks for the upload.

[Blue_MiSfit]

The reason the iPhone went with Profile 8.3 was so they would not have to tone map for the SDR version.

That makes sense, but FWIU HLG is only actually "backwards compatible" in terms of dynamic range, not color gamut (since rec2020 / p3d65 / WCG -> rec709 is hard to do well automatically).

So, from a backwards compatibility standpoint, you can either use WCG (and thus only be really backwards compatible with SDR WCG displays of which there aren't too many AFAIK) or use standard 709 gamut and thus be only HDR and not WCG which won't take advantage of modern HDR displays that are all WCG.

Do I have that wrong?

[benwaggoner]

That makes sense, but FWIU HLG is only actually "backwards compatible" in terms of dynamic range, not color gamut (since rec2020 / p3d65 / WCG -> rec709 is hard to do well automatically).

So, from a backwards compatibility standpoint, you can either use WCG (and thus only be really backwards compatible with SDR WCG displays of which there aren't too many AFAIK) or use standard 709 gamut and thus be only HDR and not WCG which won't take advantage of modern HDR displays that are all WCG.

Do I have that wrong?
That was certainly how HLG was originally intended to work by the BBC. But the de facto HLG has drifted somewhat; after all, essentially no devices shipped with Rec 2020 and NOT PQ. It must be using 709 primaries or else it wouldn't be backwards compatible.

My take on HLG has been "it may work in practice, but it definitely doesn't work in theory!"

[benwaggoner]

Yeah, how would one even do that? Convert the HLG into PQ and do a new analysis pass in Resolve or something, then encode UHD BD compliant Profile 5 or 7 from that?
Yes, pretty much. Of course, while in Resolve, additional color work could be done to get to >1000 nits, use more saturated colors, etcetera.

Profile 8.3 isn't great, but it makes for a substantially better HDR source than anything 709 would be. The 12 Pro Max with its improved optics will probably lead to some interesting student and experimental HDR (and HFR) titles. Biggest question is how clean the HEVC encoding will be. I need to finally order mine.

[FranceBB]

That was certainly how HLG was originally intended to work by the BBC. But the de facto HLG has drifted somewhat; after all, essentially no devices shipped with Rec 2020 and NOT PQ. It must be using 709 primaries or else it wouldn't be backwards compatible.

Wait, so you're saying that it's using Rec709 primaries with an HLG color curve applied? That would be a pretty poor choice...
Also, if it's not and they're just displaying BT2020 on non BT2020 compatible displays that's a poor choice as well...


My take on HLG has been "it may work in practice, but it definitely doesn't work in theory!"


lol
My take is: most users are too "inexpert" to notice...
(and with the term "inexpert" I've been very kind)

[benwaggoner]

Wait, so you're saying that it's using Rec709 primaries with an HLG color curve applied? That would be a pretty poor choice...
Also, if it's not and they're just displaying BT2020 on non BT2020 compatible displays that's a poor choice as well...
HLG's whole premise is the same set of code values will encode two different creative intents on two very different EOTFs, without metadata. So it's fundamentally pretty nuts. I don't know that they're using 709, but I can't imagine what else it would be. Viewing 2020 as 709 looks weird and brown.

My take is: most users are too "inexpert" to notice...
(and with the term "inexpert" I've been very kind)
HLG is mainly being boosted for live broadcast scenarios, where there aren't colorists anyway. Premium content (movies and scripted TV) creatives and technologists aren't fans.

[FranceBB]

I don't know that they're using 709, but I can't imagine what else it would be. Viewing 2020 as 709 looks weird and brown.

I guess we're gonna have to wait 'till someone will upload a sample, then...

[benwaggoner]

I guess we're gonna have to wait 'till someone will upload a sample, then...
Yeah, I need to actually go and buy mine!

[excellentswordfight]

Wait, so you're saying that it's using Rec709 primaries with an HLG color curve applied? That would be a pretty poor choice...
Also, if it's not and they're just displaying BT2020 on non BT2020 compatible displays that's a poor choice as well...
HLG is mainly being boosted for live broadcast scenarios, where there aren't colorists anyway. Premium content (movies and scripted TV) creatives and technologists aren't fans.
I did some experiments with this so called SDR backwards compatible component of HLG a few years ago, and all parties found it not really to work. This was for an UHD broadcast using the 2020 primaries, and using the bt2020-10 transfer curve, with HLG as the altarnative transfer curve. The issues was, that the live production couldn't produce an image that looked good on both an HLG-ready tv-set and the ones without it.

Today, we just convert everything to 709... Cause i guess since BBC thought it was needed to create the conversion kit for hlg/hdr (https://downloads.bbc.co.uk/rd/pubs/papers/HDR/BBC_HDRTV_HLG_LUT_Implementation_Guide.pdf) I guess that this backwards compatible goal with HLG was something that never worked.

[FranceBB]

I did some experiments with this so called SDR backwards compatible component of HLG a few years ago, and all parties found it not really to work. This was for an UHD broadcast using the 2020 primaries, and using the bt2020-10 transfer curve, with HLG as the altarnative transfer curve. The issues was, that the live production couldn't produce an image that looked good on both an HLG-ready tv-set and the ones without it.

Today, we just convert everything to 709... Cause i guess since BBC thought it was needed to create the conversion kit for hlg/hdr (https://downloads.bbc.co.uk/rd/pubs/papers/HDR/BBC_HDRTV_HLG_LUT_Implementation_Guide.pdf) I guess that this backwards compatible goal with HLG was something that never worked.

I know exactly what you mean as I use HLG all the times at work to air in BT2020nc + color curve. The compromise is simple: the closer you get to HDR, the worse it looks on SDR BT2020 compatible monitors, the closer you get to SDR BT2020, the less dynamic range you have on those with an HDR compatible TV.
Since HLG is not a purely logarithmic curve its lower part resembles the one of an SDR curve like the Linear BT2020nc SDR 100 nits, but as it gets to the higher values (whites) it resembles more and more a logarithmic curve and therefore introduces dynamic range, hence it doesn't offer many details in the blacks, but it does offer them in the mid-white and therefore it avoids the sky to be clipped out etc. As I said, the problem is that the TVs that don't understand any color curve, but do understand BT2020 are not gonna interpret those things, hence displaying the lower values correctly but not the highlights. Of course, this is intended and it's what the BBC made it for, in fact we've been airing like this for years now.

Here's a comparison of an HDR HLG BT2020nc 600 nits shot.

On a TV which interprets both the color matrix (BT2020nc) and the color curve (HLG) and displays it as intended:
https://i.imgur.com/T7I2bRK.png

On an SDR TV 100 nits which does interpret the color matrix (BT2020nc) but totally ignores the color curve (the "not so bad" fallback as intended by the BBC specs):
https://i.imgur.com/W9TViA6.png

On an SDR TV 100 nits which has no clue about both the color matrix and the color curve and ignores them both (totally wrong display, not acceptable, never should happen):
https://i.imgur.com/sXNb8CI.png


The first image is what we see in our monitors and it's how the whole content is graded and how it should be visualized by people at home. It's HDR, it has a dynamic range of 600 nits.
The second image is what people at home who have an old 4K TV which doesn't support HDR are gonna see. Ignoring the color curve and just interpreting the matrix isn't so bad and it's what the BBC guys were thinking about. The fact that the color curve is ignored makes the image look ok in the lower values/blacks ('cause the HLG is essentially like the Linear BT2020 SDR on the lower part) and "dull"/greyish in the higher values/whites ('cause as it goes up it embraces its logarithmic part).
Lastly, we have something that should never happen and that it's not part of the specs as not only it ignores the color curve, but it wrongly translates the values of the BT2020 so it's totally wrong. This is what happens if you try to watch a BT2020nc HLG stream on a BT709 aware only monitor (so don't do it).


My remarks:
as I said countless times in other topics here on Doom9 before, overall, the result of HLG on BT2020nc only aware monitors is not so bad and HLG makes its fair share to keep things not so unwatchable compared to PQ. In fact, while HLG can be watched on SDR BT2020 monitors, PQ can't and if you attempt to recreate a similar experiment you would get this on an HDR PQ BT2100 aware display:

https://i.imgur.com/pUAUNkb.png

and this crap on an SDR BT2020nc only aware display:

https://i.imgur.com/FVHOeYz.png

This is because PQ is a truly logarithmic curve, so blacks start very high and the "trick" doesn't work...
Of course there are caveats in HLG as not only is limited to 1000 nits maximum, but there's no added benefit for the blacks compared to a BT2020 SDR stream, while the PQ not only can achieve up to 10'000 nits but it does offer a wide range in the blacks as well (although it breaks BT2020 SDR compatibility). On top of this, the example above is done with a 600 nit file, but as we go up, the SDR picture will look more and more grey as we will be essentially pushing mid-tones up and up, so it will look worse (this is what I said at the very beginning "the closer we get to HDR, the worse it will look on BT2020 SDR monitors").
I discussed these things several times both in "General" and in "Development" with Derek and the others and I can say that I'm not too disappointed with HLG as it just works and it allows broadcasters like us to save a lot of bandwidth, especially on our beloved overcrowded Hot Bird where it's pricey.

[nakTT]

Wonder why there's no activity since a little over a month ago. Anyone here know the reason why, or did I missed something. Thank you in advance.

https://bitbucket.org/multicoreware/x265_git/commits/

[LigH]

That happens from time to time. The mailing list is a little more active with discussions about details before commits are agreed to.

[benwaggoner]

I did some experiments with this so called SDR backwards compatible component of HLG a few years ago, and all parties found it not really to work. This was for an UHD broadcast using the 2020 primaries, and using the bt2020-10 transfer curve, with HLG as the altarnative transfer curve. The issues was, that the live production couldn't produce an image that looked good on both an HLG-ready tv-set and the ones without it.

Today, we just convert everything to 709... Cause i guess since BBC thought it was needed to create the conversion kit for hlg/hdr (https://downloads.bbc.co.uk/rd/pubs/papers/HDR/BBC_HDRTV_HLG_LUT_Implementation_Guide.pdf) I guess that this backwards compatible goal with HLG was something that never worked.
Yeah, HLG seems to give you one of decent SDR OR decent HDR. If you want both, you get mediocre SDR and mediocre HDR.

HLG + dynamic metadata could help that a LOT. One of the key goals/limitations of HLG was that it not require any metadata, because preserving metadata in broadcast is a massive PITA.

[nakTT]

That happens from time to time. The mailing list is a little more active with discussions about details before commits are agreed to.
Seems like the last commit was way back in the late october. Wonder why there is a fairly large gap since last commit, unlike anything before.

[Boulder]

Seems like the last commit was way back in the late october. Wonder why there is a fairly large gap since last commit, unlike anything before.

Based on the mailing list, there's nothing amazing in the pipeline. I think it's safe to say that the application is in a stable status with not much active development going on. The active developers and QA people from the early days have moved on a long time ago.

[LigH]

Well, then maybe someone could have time to clean up "small but annoying things" like tons of NASM warnings... :o

[Boulder]

Well, then maybe someone could have time to clean up "small but annoying things" like tons of NASM warnings... :o

I'm not sure they possess the proper knowledge, based on what I've seen and tested myself :devil:

[FranceBB]

HLG + dynamic metadata could help that a LOT.

Ahhh!! Dynamic Metadata!! *screams out in pain*

https://media4.giphy.com/media/3o7budXjKD1lTHx7m8/source.gif


Just joking, but yes, it would be hard to broadcast dynamically changing metadata on live feeds, especially with commercial breaks and other stuff...

[Boulder]

Just joking, but yes, it would be hard to broadcast dynamically changing metadata on live feeds, especially with commercial breaks and other stuff...

Oh come on, you can always do the same as with the audio. Come the commercial break, turn the knob to 11 :p

[benwaggoner]

Oh come on, you can always do the same as with the audio. Come the commercial break, turn the knob to 11 :p
Oh, all that loudness boost stuff gets applied to the ad's audio source. Then CALM act loudness limitation gets applied to the whole audio channel. It's a weird tech arms race. CALM helped a lot at first, but once the algorithm was codified, working around it became a valuable feature.

[quietvoid]

Finally a patch to be able to have more control with --scenecut-aware-qp: https://mailman.videolan.org/pipermail/x265-devel/2020-December/013191.html
Now "Forward masking" would be like the first implementation.

Too bad it's still restricted to 2 pass for no reason.
There should be an option to have it forward-only with single pass/CRF, only backwards would require a stat file I think.

And it's merged! https://bitbucket.org/multicoreware/x265_git/commits/cdb9477e8aa63a763694487f62ff4f5f6e617a30

[vpupkind]

Finally a patch to be able to have more control with --scenecut-aware-qp: https://mailman.videolan.org/pipermail/x265-devel/2020-December/013191.html
Now "Forward masking" would be like the first implementation.

Too bad it's still restricted to 2 pass for no reason.
There should be an option to have it forward-only with single pass/CRF, only backwards would require a stat file I think.

And it's merged! https://bitbucket.org/multicoreware/x265_git/commits/cdb9477e8aa63a763694487f62ff4f5f6e617a30

The reason for two-pass is that it messes up with VBV rate control in single pass.

[LigH]

New uploads: x265 32-g57e0b0382 (https://www.mediafire.com/file/tyrhk9miefp978e/x265_3.4+32-g57e0b0382.7z/file)

CLI changes since x265 3.4+30-g6722fce1f:

--scenecut-aware-qp <0..3> Enable increasing QP for frames inside the scenecut window around scenecut. Default disabled
0 - Disabled
1 - Forward masking
2 - Backward masking
3 - Bidirectional masking
--masking-strength <string> Comma separated values which specifies the duration and offset for the QP increment for inter-frames
replaces
--[no-]scenecut-aware-qp Enable increasing QP for frames inside the scenecut window after scenecut. Default disabled
--scenecut-window <0..1000> QP incremental duration(in milliseconds) when scenecut-aware-qp is enabled. Default 500
--qp-delta-ref <0..10> QP offset to increment with base QP for inter-frames. Default 5.000000
--qp-delta-nonref <0..10> QP offset to increment with base QP for non-referenced inter-frames. Default 6.500000

[quietvoid]

The reason for two-pass is that it messes up with VBV rate control in single pass.

Hm, well this is only an issue for use cases that need strict VBV conformance.
I guess we are stuck with it then. :)

[benwaggoner]

Hm, well this is only an issue for use cases that need strict VBV conformance.
I guess we are stuck with it then. :)
Isn't this exactly the sort of thing that --rc-lookahead is for? Plus --gop-lookahead, --lookahead-slices, and --lookahead-threads are all doing "so, what's happening with upcoming frames" stuff.

Seems like an oversight or an upcoming feature. No hard 2-pass requirement for this approach.

[Stereodude]

Any recent x265 builds with lavf support (to use a .AVS as the source and avoid piping)?

[stax76]

Any recent x265 builds with lavf support (to use a .AVS as the source and avoid piping)?

Would be great but vpy support should be enabled too, vpy is supported by lavf but it's disabled by default. As far as I know it cannot be enabled at runtime, I've asked before but there wasn't any C++ programmer with an answer.

[LigH]

Best chance: ffmpeg. Although it may not pass all x265 params.

[qyot27]

Best chance: ffmpeg. Although it may not pass all x265 params.
CLI params, up in the air. API params, it can access all of them using the -x265_params option.

FFmpeg has the advantage that the bit depth you put in is the bit depth you get out. Unlike x265 CLI sampling everything down to 8-bit unless you use --output-depth.

Any recent x265 builds with lavf support (to use a .AVS as the source and avoid piping)?
There's a standalone AviSynth+ input now, which takes precedence over LAVF (https://github.com/msg7086/x265-Yuuki-Asuna/commit/0bbb886cbbcf5264c78c93cb96aab72c6873fe0f).

But anyway, here's a build of from November 1st (which means it's just missing the three latest commits from MCW/x265_git) with most* of the x265-Yuuki patches applied onto it:
https://www.mediafire.com/file/2f0k0k0rhrzzo69/x265_3.4%252B53-ge4afbd100.7z/file

*I remember I had to skip some of them because it was complicating the rebase process, or needed updating, or something. But the AviSynth demuxer is there, as is 8+10+12 on both.

[Stereodude]

There's a standalone AviSynth+ input now, which takes precedence over LAVF (https://github.com/msg7086/x265-Yuuki-Asuna/commit/0bbb886cbbcf5264c78c93cb96aab72c6873fe0f).

But anyway, here's a build of from November 1st (which means it's just missing the three latest commits from MCW/x265_git) with most* of the x265-Yuuki patches applied onto it:
https://www.mediafire.com/file/2f0k0k0rhrzzo69/x265_3.4%252B53-ge4afbd100.7z/file

*I remember I had to skip some of them because it was complicating the rebase process, or needed updating, or something. But the AviSynth demuxer is there, as is 8+10+12 on both.
Okay, I'm using AVS+. But that still requires special builds, not something that's in the mainline x265 right?

[qyot27]

LAVF support isn't in mainline x265 either.

[stax76]

Is there a default value for --qp-delta-nonref (https://x265.readthedocs.io/en/master/cli.html#cmdoption-qp-delta-nonref)?

[quietvoid]

The offset is computed from --qp-delta-ref when it is not explicitly specified.
So probably 5 as well.
Edit: It's actually the ref offset * 0.3 apparently.

[Stereodude]

LAVF support isn't in mainline x265 either.
I know, I was just confirming whether I would find the new AVS+ input capability in the mainline or not. Thanks for the build! :thanks:

[vpupkind]

Hm, well this is only an issue for use cases that need strict VBV conformance.
I guess we are stuck with it then. :)
If you increase the QP (i.e., consume less bits), the single-pass VBV RC would lower the QP's onwards because it still has some bits to spare.

[quietvoid]

That sounds like sane behavior to me, what point are you getting at?
I did notice improvements in frames after the scenecut higher QP ones, where there's a benefit in using --scenecut-aware-qp compared to not.
Usually that meant saving around 500 kbps using --detla-ref-qp 2 and the quality was sometimes much better after the scenecut window.

Also this is for 1 pass CRF, not 1 pass CBR.
I still see no reason the feature should be restricted to multi pass.

[Kurtnoise]

Would be great but vpy support should be enabled too, vpy is supported by lavf but it's disabled by default. As far as I know it cannot be enabled at runtime, I've asked before but there wasn't any C++ programmer with an answer.
https://github.com/DJATOM/x265-aMod

[Boulder]

That sounds like sane behavior to me, what point are you getting at?
I did notice improvements in frames after the scenecut higher QP ones, where there's a benefit in using --scenecut-aware-qp compared to not.
Usually that meant saving around 500 kbps using --detla-ref-qp 2 and the quality was sometimes much better after the scenecut window.

Also this is for 1 pass CRF, not 1 pass CBR.
I still see no reason the feature should be restricted to multi pass.

There is absolutely no reason for the restriction. In case of a CRF encode without any VBV settings, there is nothing requiring a second pass.

I wonder if the feature could be enabled just by removing some basic check from the code, or is there more inside the various functions?

[quietvoid]

I'm going to try making a patch that enables single pass to work with Forward masking, there were some changes that made it rely on using scenecuts from the stats file though.

[Boulder]

I'm going to try making a patch that enables single pass to work with Forward masking, there were some changes that made it rely on using scenecuts from the stats file though.

Quite strange that rc-lookahead is not used with the feature, IMO it would be a perfect match for this.

[stax76]

https://github.com/DJATOM/x265-aMod

Didn't know it, thanks.

[quietvoid]

Quite strange that rc-lookahead is not used with the feature, IMO it would be a perfect match for this.

For scenecut-aware-qp, I'm pretty sure it uses lookahead either way since the info seems to be coming from frames in the lookahead queue.

Here's the patch if anyone wants to test, I'll post my results back later: https://gist.github.com/quietvoid/49d9dbca87ad373ad51516e306d5fa0d
Applies on top of Release_3.5 branch, for some reason they didn't push the new masking stuff into master.

Edit: The patch seems to work just fine.
I don't really understand the concept of the non-ref inter frames, because it's increasing the QP on the same frames, except enabling non-ref strength makes it even higher QP (in my test it goes from +4 to +8 when both are set to 10).
Unfortunately, the QP increase seems to be different from the first implementation (apparently it was wrong), setting --masking-strength 500,1,0 is increasing QP by 6, according to the csv log while 10 increases by 8..

Anyways, I fixed it by allowing the offset to be set to 0 (was defaulting to 6.5..). Patch updated.
Seems to be varying the offset depending on the distance from the scenecut frame, where the closest inter frames have higher QP than the ones at the end of the window (allowing negative offset at the end).

Using --masking-strength 500,2,0 makes the offset vary between -1 to +3.5 while 500,2,2 varies between +1.1 to +4.2.
So without using non-ref offset, quality can be increased near the end of the scene cut window while still lowering bitrate a little (in my test this is a 400 kb/s difference). :)

The original x265 patch was pretty incomplete, so anyone feel free to send this upstream. Who knows if it's acceptable.

On top of it all, the last commit "Fix version information reporting for x265 git archival" breaks CMake's version detection. Always returns unknown.
Now this is an actual issue. Someone might want to let them know.

[Boulder]

For scenecut-aware-qp, I'm pretty sure it uses lookahead either way since the info seems to be coming from frames in the lookahead queue.

Here's the patch if anyone wants to test, I'll post my results back later: https://gist.github.com/quietvoid/49d9dbca87ad373ad51516e306d5fa0d
Applies on top of Release_3.5 branch, for some reason they didn't push the new masking stuff into master.

Edit: The patch seems to work just fine.
I don't really understand the concept of the non-ref inter frames, because it's increasing the QP on the same frames, except enabling non-ref strength makes it even higher QP (in my test it goes from +4 to +8 when both are set to 10).
Unfortunately, the QP increase seems to be different from the first implementation (apparently it was wrong), setting --masking-strength 500,1,0 is increasing QP by 6, according to the csv log while 10 increases by 8..

Anyways, I fixed it by allowing the offset to be set to 0 (was defaulting to 6.5..). Patch updated.
Seems to be varying the offset depending on the distance from the scenecut frame, where the closest inter frames have higher QP than the ones at the end of the window (allowing negative offset at the end).

Using --masking-strength 500,2,0 makes the offset vary between -1 to +3.5 while 500,2,2 varies between +1.1 to +4.2.
So without using non-ref offset, quality can be increased near the end of the scene cut window while still lowering bitrate a little (in my test this is a 400 kb/s difference). :)

The original x265 patch was pretty incomplete, so anyone feel free to send this upstream. Who knows if it's acceptable.

On top of it all, the last commit "Fix version information reporting for x265 git archival" breaks CMake's version detection. Always returns unknown.
Now this is an actual issue. Someone might want to let them know.
Thank you for the patch, I'll try find the time to test it during the Christmas period. Do you feel that the default window of 500 ms is suitable considering subjective quality in motion?

[quietvoid]

Probably, I've used 550 in the past to save a bit more. It's better now that the offset isn't fixed for the whole window.
I can't really notice a difference after ~300 ms (before that the offset is pretty high, but the quality change shouldn't be noticeable) when comparing still shots.

Also the new code avoids selecting scenecuts that are still within a previous window, so in motion it wouldn't be constantly resetting to high QP.

[Barough]

x265 v3.4+33-606265ac7 (https://www.mediafire.com/file/ulla7o5ezjmm43v/x265-3.4%252B33-606265ac7_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5

[vpupkind]

For scenecut-aware-qp, I'm pretty sure it uses lookahead either way since the info seems to be coming from frames in the lookahead queue.

Here's the patch if anyone wants to test, I'll post my results back later: https://gist.github.com/quietvoid/49d9dbca87ad373ad51516e306d5fa0d
Applies on top of Release_3.5 branch, for some reason they didn't push the new masking stuff into master.


Are you going to submit it?

[quietvoid]

I don't even know how mailing lists work :)

[Boulder]

I don't even know how mailing lists work :)

I think you can just send your patch in an email to x265-devel@videolan.org. I recall that you have to "sign" some sort of a document but they'll probably tell you where it is located if so.

https://bitbucket.org/multicoreware/x265_git/wiki/Contribute

[quietvoid]

Yea, I'm not doing any of that.

[LigH]

The media-autobuild suite supports custom patches (https://github.com/m-ab-s/media-autobuild_suite#custom-patches); unfortunately, I am not experienced enough to create them from differences between forks. But if anyone here could help making them available from Yuuki-Asuna and DJATOM mods, it might be possible to build fresh modified builds conveniently.

[Patman]

Hello everybody,

I'm having a problem creating the binary with the correct version tag. When I ask the version on the command line, it always says "unknown". What could be the reason? The source files have not been changed and HG / Git is installed. I am using GCC to compile.

[quietvoid]

Hello everybody,

I'm having a problem creating the binary with the correct version tag. When I ask the version on the command line, it always says "unknown". What could be the reason? The source files have not been changed and HG / Git is installed. I am using GCC to compile.

Revert commit d926c02/606265a, "Fix version information reporting for x265 git archival"
There might be a fix getting pushed sooner or later.

[Patman]

Revert commit d926c02/606265a, "Fix version information reporting for x265 git archival"
There might be a fix getting pushed sooner or later.

Barough compiled with the latest commit. Maybe the version.txt was pimped up by him :D

[Barough]

Barough compiled with the latest commit. Maybe the version.txt was pimped up by him :D

Nah, i haven't done anything.

[GrampaD]

x265-3.2.1+1 (https://www.mediafire.com/file/osjbu48x7t5d3fk/x265-3.2.1+1.7z/file)
x265-3.2.1+1 (UPX packed) (https://www.mediafire.com/file/c7lknofh4g6h43y/x265-3.2.1+1_%28UPX_packed%29.7z/file)


x265 [info]: HEVC encoder version 3.2.1+1-b5c86a64bbbe
x265 [info]: build info [Windows][Clang 9.0.0][64 bit] 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.29.100)
x265 [info]: (libavcodec 58.54.100)
x265 [info]: (libavutil 56.31.100)


I have the same version of the codec, my source is MacPorts:


~> which x265

/opt/local/bin/x265


...But it's not showing 10-bit support:

~> x265 -V
x265 [info]: HEVC encoder version 3.2.1+1-b5c86a64bbbe
x265 [info]: build info [Mac OS X][clang 11.0.0][64 bit] 8bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2


...Is it because my hardware won't support 10-bit color? Will MacBook Pros EVER support 10-bit color?

Thanx in advance for answering :)

[sneaker_ger]

It's not about your hardware. "Your" x265 binary simply wasn't compiled with 10 bit support. You have to download a different binary or compile one yourself.

[qyot27]

Related:
https://trac.macports.org/ticket/59860

[LigH]

The media-autobuild suite supports custom patches (https://github.com/m-ab-s/media-autobuild_suite#custom-patches); unfortunately, I am not experienced enough to create them from differences between forks. But if anyone here could help making them available from Yuuki-Asuna and DJATOM mods, it might be possible to build fresh modified builds conveniently.

Can anyone help me creating diff patches out of their current repos?

[quietvoid]

Can anyone help me creating diff patches out of their current repos?

As in on top of both master branches?
You can just add a remote to your x265_git repo and do a diff on the branches:
git clone https://bitbucket.org/multicoreware/x265_git.git
cd x265_git
git remote add x265-Yuuki-Asuna https://github.com/msg7086/x265-Yuuki-Asuna.git
git remote update

# For example if you want to use the Yuuki branch
git diff origin/master x265-Yuuki-Asuna/Yuuki > x265_git-master-Yuuki-diff.patch


And you have a patch (that may be outdated in this case).
The same workflow should work for DJATOM's repo.

You'd have the origin remote (which has x265_git's branches) and whichever other remote repos you add.

[stax76]

@Barough

Do you also have a MediaFire folder for your builds?

I've created a wiki page (https://github.com/staxrip/staxrip/wiki/x265) showing which builds and mods exist.

[Barough]

@Barough

Do you also have a MediaFire folder for your builds?

I've created a wiki page (https://github.com/staxrip/staxrip/wiki/x265) showing which builds and mods exist.

@stax76

I'll PM you.

[stax76]

@stax76

I'll PM you.

I've private messages disabled.

But my mail address is on my GitHub profile (https://github.com/stax76).

[Barough]

I've private messages disabled.

But my mail address is on my GitHub profile (https://github.com/stax76).I'll have a look there when i get bk home

[EDIT]
Sent you a email

[Kurogane]

I'm trying to figure out why pmode give me this warning

x265 [warning]: Limit reference options 2 and 3 are not supported with pmode. Disabling limit reference

I'm using this basic config

--preset slow --crf 18.0 --profile main10 --output-depth 10 --pmode

When i use another preset than slow not give me this warning.

I'm using 3.4+9-g1fb7c7960

[benwaggoner]

I'm trying to figure out why pmode give me this warning

x265 [warning]: Limit reference options 2 and 3 are not supported with pmode. Disabling limit reference

I'm using this basic config

--preset slow --crf 18.0 --profile main10 --output-depth 10 --pmode

When i use another preset than slow not give me this warning.

You can see here that Limit Refs 3 is used in presets 2-6 only:

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

[Barough]

x265 v3.4+35-772bb4c84 (https://www.mediafire.com/file/s0igugnx3ydilw3/x265-3.4%252B35-772bb4c84_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5

[Kurogane]

You can see here that Limit Refs 3 is used in presets 2-6 only:

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

I tested in all profiles and only the one give me this error is "slow".

[Greenhorn]

The table is out-of-date/wrong. Limit-refs 1 is only used on "Slow" these days. Everything else uses 3 (slower, medium and lower) or none (veryslow/placebo.)

@kurogane: it's just saying that a setting used by the preset is incompatible with pmode. It should probably be setting it to "1" instead of disabling it entirely, but you can use both features and the slow preset all together just by setting --preset slow --limit-refs 1 --pmode.

[Boulder]

The table is out-of-date/wrong. Limit-refs 3 is only used on "Slow" these days. Everything else uses 3 (slower, medium and lower) or none (veryslow/placebo.)

@kurogane: it's just saying that a setting used by the preset is incompatible with pmode. It should probably be setting it to "1" instead of disabling it entirely, but you can use both features and the slow preset all together just by setting --preset slow --limit-refs 1 --pmode.

--preset slower applies --limit-refs 1. I'm using it right now in my encodes and I don't have any separate --limit-refs call. The info section shows this:

x265 [info]: References / ref-limit cu / depth : 4 / off / on

[Greenhorn]

--preset slower applies --limit-refs 1. I'm using it right now in my encodes and I don't have any separate --limit-refs call. The info section shows this:

x265 [info]: References / ref-limit cu / depth : 4 / off / on

Typo in my post. Woops.

[FranceBB]

For those of you that use AVID Media Composer, from version 2020.12 it's possible to link and edit H.265 files. Considering that H.265 was released more than 8 years ago, it's about time, AVID! They should have done this long time ago!! What took them so long...?! -.- Still, habemus H.265 import support at last...

[Barough]

x265 v3.4+36-5239276dd (https://www.mediafire.com/file/645v8gzgslzv1gv/x265-3.4%252B36-5239276dd_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5

[FranceBB]

I guess we're gonna have to wait 'till someone will upload a sample, then...

In case anyone is still interested in files produced by Iphone 12, here it is:

https://i.imgur.com/wfA1scT.png

They're indeed in Dolby Vision with the HLG profile, so BT2020nc HLG HDR 4:2:0 10bit planar in H.265.
Too bad for the VFR stuff which mobiles seem to love and everyone else in the world hates... (especially us, working in broadcast!)
I'm not in the edit room in which I have an HDR monitor and scope, so I can't tell you exactly how many nits there actually are, but Apple claims to reach 699 nits...
I think they're way too many for such a tiny sensor. From a very quick analysis, it looks like it's more or less 300 nits, which, for a mobile phone, looks quite alright.


For the records: this is from a colleague of mine who bought it, I actually went for a Google Pixel 5 in early November.

[quietvoid]

Updated my scenecut-aware-qp patch, now applies directly on Release 3.5 @ 5239276

[LigH]

Because the Yuuki mod appears to be well maintained, I tried to download and build this one alternatively in an interactive shell in MABS. Unfortunately, in contrast to the original x265 git, this modified fork apparently needs Ruby. A compatible version was found in the MSYS2 installation of MABS (2.7.0; minimum required is 1.8.0); but several include directories were missing, so cmake halted. I guess I could make it work if I knew where to include which shell variable exports?

[MeteorRain]

>tree /f D:\dev\x265-Yuuki-Asuna\include
D:\DEV\X265-YUUKI-ASUNA\INCLUDE
│ lsmash.h
│
├─avisynth
│ │ avisynth.h
│ │ avisynth_c.h
│ │
│ └─avs
│ alignment.h
│ capi.h
│ config.h
│ cpuid.h
│ minmax.h
│ posix.h
│ types.h
│ win.h
│
└─vapoursynth
VapourSynth.h
VSHelper.h
VSScript.h

You'll need those to support avs/vpy/lsmash. ffmpeg input on msvc wasn't tested.

For msvc multi lib build you need to

-DLSMASH_SOURCE_DIR=../../x265-Yuuki-Asuna/include -DEXTRA_LINK_FLAGS="/LIBPATH:../../../x265-Yuuki-Asuna/lib-msvc /LIBPATH:.."

something like that.

For gcc you just compile and make install dependencies into system directories. That includes ffmpeg, avisynth (header only), vapoursynth(header only), lsmash.

Ruby script was to compose version number, so it's not absolute necessary and can be replaced by you own code to produce your own version number. I use Ruby because I'm a Ruby developer.

It may not be easy to use yuuki mod in mabs due to extra libraries being linked.

[LigH]

One hurdle after another ... the first one looked rather low to me, as a layman:

-- Could NOT find Ruby (missing: Ruby_INCLUDE_DIR Ruby_LIBRARY Ruby_CONFIG_INCLUDE_DIR) (found suitable version "2.7.2", minimum required is "1.8.0")

If that is all cmake complains about, I guess it can be solved. Then we will see further from there.

[MeteorRain]

Says found suitable version, so I guess it's just fine? I have the mingw-w64-x86_64-ruby package installed from pacman, and it works.

[LigH]

Well, the Ruby package as such is installed, but it misses configured environment variables. Therefore cmake halts.

[MeteorRain]

That's weird. I'm getting a similar error but cmake did generate all the project files without any problem.
-- Found Nasm 2.15.05 to build assembly primitives
-- Could NOT find Ruby (missing: Ruby_LIBRARY) (found suitable version "2.7.1", minimum required is "1.8.0")
-- x265 version 3.4+13-g729a838d3+38

[LigH]

So maybe the reason is somewhere else, like the cmake command line may need more explicit parameters than the vanilla x265 multilib configuration.

...
-- Found nasm: E:/MABS/msys64/mingw64/bin/nasm.exe (found version "2.15.05")
-- Found Nasm 2.15.05 to build assembly primitives
CMake Deprecation Warning at dynamicHDR10/CMakeLists.txt:13 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions.


-- Found Git: E:/MABS/msys64/usr/bin/git.exe (found version "2.30.0")
-- Could NOT find Ruby (missing: Ruby_INCLUDE_DIR Ruby_LIBRARY Ruby_CONFIG_INCLUDE_DIR) (found suitable version "2.7.2", minimum required is "1.8.0")
-- x265 Release Version
-- The ASM_NASM compiler identification is NASM
-- Found assembler: E:/MABS/msys64/mingw64/bin/nasm.exe
-- Looking for strtok_r
-- Looking for strtok_r - found
CMake Error at CMakeLists.txt:637 (list):
list GET given empty list


CMake Error at CMakeLists.txt:638 (list):
list GET given empty list


-- Configuring incomplete, errors occurred!
See also "E:/MABS/x265-Yuuki-Asuna-Yuuki/build/msys64_hdr10_ml/12bit/CMakeFiles/CMakeOutput.log".
See also "E:/MABS/x265-Yuuki-Asuna-Yuuki/build/msys64_hdr10_ml/12bit/CMakeFiles/CMakeError.log".
make: *** No targets specified and no makefile found. Stop.
cp: cannot stat 'libx265.a': No such file or directory
make: *** No rule to make target 'clean-generated'. Stop.

Shall we discuss this elsewhere? A new thread here? An issue in your github repo?

[MeteorRain]

Please open an issue ticket.

EDIT:

Actually, I think you are on the wrong branch. Please switch to Asuna branch to test. Yuuki branch is not ready yet because 3.5 is not ready yet. As soon as 3.5 is tagged I'm going to revise the version generation code, which should solve the issue you are seeing.

[LigH]

:thanks:

The Asuna branch passed.

PS: OK, adding a few parameters of the modification may break the attempt, e.g. L-SMASH headers need to be found if I want to enable MP4 output...

Seems I could create a build with AVS and VPY input and MKV output, yet without LAVF input and without MP4 output. And with unknown version. To be tested...

Works with AviSynth input and MKV output.

[MeteorRain]

FYI: MKV output is not supported and is provided as best effort because one of my friends actively uses it. I was thinking maybe I should add a warning message saying it's unsupported.

If possible, please try to integrate l-smash using the flags above (post #7944).

[LigH]

Your repo does not provide an include directory, so I tried to configure the cmake flags to use the liblsmash git directory which is retrieved by MABS when building all its projects, up to ffmpeg:

-DENABLE_LSMASH=ON -DLSMASH_SOURCE_DIR=/build/liblsmash-git/

Configuring finished, make started ... all these NASM warnings are a PITA ... hmm, no. Obviously I have no clue how to point to the lsmash.h file so that it is found:

In file included from F:/MABS/x265-Yuuki-Asuna-Asuna/source/output/output.cpp:44:
F:/MABS/x265-Yuuki-Asuna-Asuna/source/output/mp4.h:8:10: fatal error: lsmash.h: No such file or directory
8 | #include <lsmash.h>
| ^~~~~~~~~~
compilation terminated.

Maybe due to:

CMake Warning:
Manually-specified variables were not used by the project:

LSMASH_SOURCE_DIR

Trying again with additional -DSPECIFY_LSMASH_SOURCE_DIR=ON

Next hurdle: I guess MABS used liblsmash somewhere but did not make and install it separately, so it is not a registered package.

F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -llsmash

Ran make install-lib and trying again without explicitly specifying lsmash directory...

Meh. Did not help. Without explicit source dir it doesn't find the header, with it it can't link the library. "It's complicated"...

[MeteorRain]

Ooooh you are using GCC.

>make install-lib
install -d /mingw64/include
install -m 644 ./lsmash.h /mingw64/include
install -d /mingw64/lib/pkgconfig
install -m 644 liblsmash.pc /mingw64/lib/pkgconfig
install -m 644 liblsmash.a /mingw64/lib

You should be able to find those 3 files in the corresponding directories, and GCC should automatically find them. Can you confirm they are there?

Try this and see if pkg-config gets you the command line.

pkg-config --libs liblsmash

[LigH]

Yes, the media-autobuild suite is based on MSYS2, MinGW, and usually GCC (could use clang if configured). And I even run the interactive shell instead of patching the automated build scripts. So I mostly profit from MABS keeping MSYS2/MinGW and GCC and all projects linked into ffmpeg up-to-date, before sometimes also experimenting interactively.

Using ./configure without extra parameters, it gets installed into /usr/local ... I guess I should add a parameter to change the prefix, because MABS uses /local64 (or /local32) as target directories.

OK, MABS requires e.g. ./configure --prefix="/local64" to install the header and library where the packages are expected. Compilation seems to be successful.

[LigH]

Last missing puzzle piece: Linking issues with libav libraries ... but ffmpeg had been built before and has been found by the compiler. So the reason must be in a different magnitude.

[ 96%] Linking CXX executable x265.exe
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x11): undefined reference to `avcodec_free_context'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x1a): undefined reference to `avformat_close_input'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x19d): undefined reference to `av_init_packet'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x1c0): undefined reference to `avcodec_receive_frame'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x1d8): undefined reference to `av_read_frame'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x1f4): undefined reference to `av_packet_unref'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x204): undefined reference to `av_init_packet'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x226): undefined reference to `avcodec_send_packet'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x23d): undefined reference to `avcodec_receive_frame'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x2a4): undefined reference to `av_packet_unref'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x2b8): undefined reference to `av_packet_unref'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x4aa): undefined reference to `avcodec_find_decoder'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x4ba): undefined reference to `avcodec_alloc_context3'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x4d3): undefined reference to `avcodec_parameters_to_context'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x4e7): undefined reference to `avcodec_open2'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x5ad): undefined reference to `av_packet_unref'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x60c): undefined reference to `av_frame_alloc'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x62e): undefined reference to `avformat_open_input'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x64b): undefined reference to `avformat_find_stream_info'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x6c9): undefined reference to `avcodec_find_decoder'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x6d8): undefined reference to `avcodec_alloc_context3'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x6f4): undefined reference to `avcodec_parameters_to_context'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x707): undefined reference to `avcodec_open2'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x72c): undefined reference to `av_dict_set'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x73f): undefined reference to `avcodec_open2'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x761): undefined reference to `av_dict_free'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x82b): undefined reference to `av_pix_fmt_desc_get'
F:/MABS/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/cli.dir/objects.a(lavf.cpp.obj):lavf.cpp:(.text+0x2c): undefined reference to `av_frame_free'
collect2.exe: error: ld returned 1 exit status

[MeteorRain]

I have no idea about that. Maybe check if the lib files are correctly found by gcc.
The error message looks like it didn't find the lib and thus missed the reference to its functions.

[DJATOM]

Undefined reference usually means that symbol is not reachable. For example, there is no library with such names supplied to the linker. Check generated build files if all needed ffmpeg libs are actually provided for linking.

[LigH]

Which are these "build files"?

[LoRd_MuldeR]

Which are these "build files"?

If a C/C++ application depends on library 'XYZ', the you will need to do two things:
At compile-time, you need to ensure that the required header files (usually .h or .hpp) for library XYZ are present in one of the directories that the compiler scans for header files.
Additional search directories for header files can be specified by adding the -I option to the CFLAGS.

At link-time, you need to ensure that library XYZ is actually linked to your binary. This is done by adding the -l option your LDFLAGS.
Note that -l automatically adds the "lib..." prefix as well as the file extension. So, in order to link against libXYZ.a, you just need to write -lXYZ.

Furthermore, you have to make sure that the library file (usually .a) is present in one of the directories that the linker scans for library files.
Additional search directories for library files can be specified by adding the -L option to the LDLAGS.

Of course you will need to build library 'XYZ' before you build your "main" application, because otherwise the required library file libXYZ.a (the "build file") has not been created yet :)

Undefined reference usually means that symbol is not reachable. For example, there is no library with such names supplied to the linker.

Yes, "undefined reference" could mean that a required library was not linked at all. Could also mean that you are linking a "wrong" version of the library which doesn't match to the header files that were used.

(If you try to link against a library, but the linker couldn't find the requested library file, it would be a different error message)

Another "fun" thing needs to be considered: Libraries can be compiled as either a "static" library (.a) or a "shared" library (.dll). Specifically on Windows, the actual symbol names differ between the "static" and "shared" libraries! Usually the header files support both variants, via #ifdef's, but default often is the "shared" variant. So, a special #define needs to be set, at compile-time, if you intend to link against the "static" library. Could also be the other way around tough :D

[DJATOM]

Which are these "build files"?

If you're using mingw (as I am), they are in the generated build folder. For example, CMakeFiles\cli.dir\linklibs.rsp. If you generated msvc project, it's somewhere in the linker options.

[LigH]

The only *.rsp files I see are objects1.rsp in 8bit/CMakeFiles/x265-shared.dir (I'm trying to make a multi-lib static build). It contains only obj files created by the basic x265 compilation.

With -DENABLE_AVISYNTH=ON in the cmake configuration, the x265.exe contains avs_ symbols; AviSynth+ headers are present in local includes.
With -DENABLE_VPYSYNTH=ON in the cmake configuration, the x265.exe contains vsscript_ symbols; libvapoursynth.a + vapoursynth[-script].pc are present in local libs[/pkgconfig].
With -DENABLE_LSMASH=ON in the cmake configuration, the x265.exe contains LSMASH_ symbols and even a version number (printed in the version console output); liblsmash{a|pc} are present in local libs[/pkgconfig].
With -DENABLE_ZIMG=ON in the cmake configuration, the x265.exe contains zimg5graph12_ symbols; libzimg.a + zimg.pc are present in local libs[/pkgconfig].

All that works without any other *.rsp files.

{libavcodec|libavdevice|libavfilter|libavformat|libavif|libavutil}.{a|pc} are present in local libs[/pkgconfig]. Apparently, with -DENABLE_LAVF=ON in the cmake configuration, cmake detects them (or would error out otherwise), so I assume ld can find them like all the other libraries (especially like lsmash and zlib). Headers and libraries should match because MABS compiled a whole ffmpeg the other day, before I tried to build x265_Asuna afterwards. Therefore I agree with:
(If you try to link against a library, but the linker couldn't find the requested library file, it would be a different error message)

The only doubt I have left: a "light" version of ffmpeg is also a part of other tools, like x264 and cyanrip; but I would like to trust in MABS not to install these system-wide and use them only in the related projects. But even if, it should only limit the selection of codecs, not make basic APIs (like e.g. avformat_close_input) completely unavailable... I guess. :o

PS: x265cli.cpp.obj and objects.a contain libav* version string format templates; lavf.cpp.obj and objects.a contain avformat_close_input. Does the command line need more extra parameters that ff libs can be linked correctly?

[qyot27]

https://github.com/msg7086/x265-Yuuki-Asuna/blob/Yuuki/source/CMakeLists.txt#L770
and
https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html, if necessary

[LigH]

@qyot27:

ENABLE_STATIC_LAVF should be enabled by default (if LAVF and CLI are enabled), if I read that first location correctly; I already found this option, still tried to enable it explicitly in the cmake command line parameters (-DENABLE_STATIC_LAVF=ON), but it did not help as such...

VapourSynth, LSMASH and ZIMG packages are found without CMAKE_PREFIX_PATH, and I believe libav libraries (via the "FF" package) are found too; just linking them fails for a different reason. As if they are found but not used, maybe...

[PoeBear]

What CLI option(s) should I be tweaking to help stop chroma bleed? It seems that no matter how low I go with CRF, my reds will still bleed out into neighboring areas

My options are roughly a mix of veryslow and placebo, with some other options thrown in. Here's one from a recent 1080p/HDR test:
avs2yuv.exe "Test.avs" - | "x265.exe" -D 10 --crf 14 --profile main10 --level-idc 5.1 --high-tier --preset placebo --input-depth 16 --cu-lossless --pmode --bframes 16 --qg-size 32 --frame-threads 4 --ref 6 --limit-refs 1 --merange 57 --no-amp --tskip --tskip-fast --limit-modes --no-open-gop --hrd --cbqpoffs -0 --crqpoffs -1 --no-cutree --deblock -2:-2 --psy-rd 2.50 --psy-rdoq 1.00 --qcomp .6 --aq-mode 2 --aq-strength 1.0 --ipratio 1.3 --pbratio 1.2 --vbv-bufsize 160000 --vbv-maxrate 160000 --aud --hdr10 --hdr10-opt --range limited --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --master-display G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(40000000,50) --max-cll 602,187 --chromaloc 2 --repeat-headers --output "C:\Temp\Test.hevc" --frames 5000 --y4m -

I've tried a few numerous tweaks: amp, no-amp, pmode, no-pmode, pme, no-pme, hme instead of merange, dropping cbqpoffs/crqpoffs a bit further. All which really only affect very minor detail retention, likely due to such low CRF, but I still get color bleeds

I know my settings are a bit absurd, I'm getting around 1.2FPS on a 3900X with around 60% load, but my goal is transparency mostly, with a tiny hint of keeping speeds above 1FPS

Side question: Is there anyway to increase load usage with command line x265 without affecting PQ? Ie without using something like RipBot's distributed encoding

[FranceBB]

Chroma bleeding is actually really weird, it shouldn't really happen and I think I know why it's happening to you!
Your input is an AVS Script from what I see, which handles 4:2:0 Type 1 but not 4:2:0 Type2!
So, the chroma location is wrong, hence the "bleeding".

Can you try with:

ffmpeg.exe -i "AVS Script.avs" -vf scale=out_color_matrix=bt2020nc:out_h_chr_pos=0:out_v_chr_pos=0 -pix_fmt yuv420p16le -strict -1 -an -f yuv4mpegpipe - | x265.exe --y4m - --dither

followed by the rest of your x265 command line? This should solve the chroma bleeding problem. ;)

[LigH]

Success! With the great support of Christopher Degawa, main supporter of the media-autobuild suite, I was able to tweak my workflow until I could build an x265 binary with Yuuki-Asuna mod (Asuna branch = based on v3.4-stable). It required some pkgconfig tuning and I found a way to use the "video decoders only" light ffmpeg build as already used by m-ab-s in its x264 binary (option 6); so it should contain support for AVS input, VPY input, LAVF input, MP4 output (L-SMASH), MKV output (Haali, obsolete), and ZIMG scaling.

x265 3.4-Asuna+54 (https://www.mediafire.com/file/jwfrq44310wd6o5/x265_3.4-Asuna%252B54.7z/file)

x265 [info]: HEVC encoder version 3.4+-+54
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] Asuna 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.65.101)
x265 [info]: (libavcodec 58.117.101)
x265 [info]: (libavutil 56.63.101)

[benwaggoner]

Chroma bleeding is actually really weird, it shouldn't really happen and I think I know why it's happening to you!
Your input is an AVS Script from what I see, which handles 4:2:0 Type 1 but not 4:2:0 Type2!
So, the chroma location is wrong, hence the "bleeding".

Chromaloc seems like a big misfire to me at this point, since so many encoders and decoders don't actually encode/decode differently based on the parameter. Other than for HDR Blu-Ray, which requires chromaloc 2, I recommend leaving it at the default for broader compatibility.

At 4K resolutions, getting it wrong is pretty hard to see, but the lower the frame size, the more screen area an error will take up.

[LigH]

Update with correct version numbering

x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/ababni9k8qvt44t/x265_3.4+13-g729a838d3+41_Asuna.7z/file)

x265 [info]: HEVC encoder version 3.4+13-g729a838d3+41
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] Asuna 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.65.101)
x265 [info]: (libavcodec 58.117.101)
x265 [info]: (libavutil 56.63.101)

[Barough]

x265 v3.4+37-dd1101b6d (https://www.mediafire.com/file/uzfgv7k6rhp9trp/x265-3.4%252B37-dd1101b6d_Win_GCC102.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.2.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/Release_3.5

[FranceBB]

Chromaloc seems like a big misfire to me at this point, since so many encoders and decoders don't actually encode/decode differently based on the parameter. Other than for HDR Blu-Ray, which requires chromaloc 2, I recommend leaving it at the default for broader compatibility.

At 4K resolutions, getting it wrong is pretty hard to see, but the lower the frame size, the more screen area an error will take up.

True, but the thing is that he was using chromaloc 2 in x265 but his input (the AVS Script output) wasn't, so it was just wrong. Either he specifies the normal 4:2:0 or he converts it to type2 and specifies chromaloc 2. That's what I meant ;)

[outhud]

Success! With the great support of Christopher Degawa, main supporter of the media-autobuild suite, I was able to tweak my workflow until I could build an x265 binary with Yuuki-Asuna mod (Asuna branch = based on v3.4-stable). It required some pkgconfig tuning and I found a way to use the "video decoders only" light ffmpeg build as already used by m-ab-s in its x264 binary (option 6); so it should contain support for AVS input, VPY input, LAVF input, MP4 output (L-SMASH), MKV output (Haali, obsolete), and ZIMG scaling.

Very nice! Thank you.

[K.i.N.G]

Has anyone done any re-tests recently to see if SAO has improved?
It's been a while since I've tested it and concluded not to use it (removed too much detail)

[microchip8]

Has anyone done any re-tests recently to see if SAO has improved?
It's been a while since I've tested it and concluded not to use it (removed too much detail)

there hasn't been any work on SAO for a long time. So doubtful

[benwaggoner]

there hasn't been any work on SAO for a long time. So doubtful
There was --limit-sao, which provided a pretty nice performance boost without material quality loss when SAO was limited to only I and P frames.

SAO can definitely be helpful at moderate-low bitrates. But the x265 implementation has fixed parameters for SAO. Adjusting them some based on bitrate or QP or content analysis could make it a more reliable net benefit even at high bitrates and high detail.

[LoRd_MuldeR]

Update with correct version numbering

x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/ababni9k8qvt44t/x265_3.4+13-g729a838d3+41_Asuna.7z/file)

x265 [info]: HEVC encoder version 3.4+13-g729a838d3+41
x265 [info]: build info [Windows][GCC 10.2.0][64 bit] Asuna 8bit+10bit+12bit
x265 [info]: (lsmash 2.16.1)
x265 [info]: (libavformat 58.65.101)
x265 [info]: (libavcodec 58.117.101)
x265 [info]: (libavutil 56.63.101)

Thanks! Any chance you can include 32-Bit binary as well, as you used to do?

[benwaggoner]

Thanks! Any chance you can include 32-Bit binary as well, as you used to do?
What's your use case for a 32-bit version?

[LoRd_MuldeR]

What's your use case for a 32-bit version?

I usually include 32-Bit and 64-Bit binaries with my GUI, so we can pick the "best" one for the specific machine at runtime.

Of course, you could ask whether it still makes sense to support 32-Bit systems these days. But the code for supporting multiple architectures is already there in the GUI, so I don't see much reason to drop this feature.

...unless it becomes too cumbersome to obtain 32-Bit encoder binaries ;)

(Another possible use case is Avisynth input: If you want to use "official" AviSynth 2.6, you'll be locked to 32-Bit. And yes, I know there is Avisynth+ as well as VapurSynth now)

[benwaggoner]

I usually include 32-Bit and 64-Bit binaries with my GUI, so we can pick the "best" one for the specific machine at runtime.

Of course, you could ask whether it still makes sense to support 32-Bit systems these days. But the code for supporting multiple architectures is already there in the GUI, so I don't see much reason to drop this feature.
At higher resolutions and presets, x265 can use more than 2 GB; some of my 8K tests used >>4GB of RAM. And 64-bit is just faster overall. The only use case where I can imagine 32-bit being "best" is running a 32-bit OS. If you are still supporting 32-bit OSes, you'd need a 32-bit build.

(Another possible use case is Avisynth input: If you want to use "official" AviSynth 2.6, you'll be locked to 32-Bit. And yes, I know there is Avisynth+ as well as VapurSynth now)
And just piping from 32-bit AVS to a 64-bit encoding process is trivial. I've been doing that for more than a decade. The piping overhead is generally a lot smaller than the 64-bit encoding performance boost.

Not that I have any skin in the game or anything, just an aversion to 32-bit for anything performance-critical ;).

[LoRd_MuldeR]

The only use case where I can imagine 32-bit being "best" is running a 32-bit OS. If you are still supporting 32-bit OSes, you'd need a 32-bit build.

That's exactly the point. The GUI program is 32-Bit, so can run on 32-Bit as well as 64-Bit platforms. At the same time, the encoder binary will be selected, at runtime, based on the actual CPU architecture.

So "best" means we select the 64-Bit binary, if we detect that we are running on 64-Bit system; otherwise 32-Bit binary will be selected.

As said before: You can argue that support for 32-Bit OS is mostly irrelevant these days. But since support for multiple CPU architectures has already been implemented in the GUI, supporting 32-Bit OS pretty much comes for free.

(provided 32-Bit encoder binaries are easily available ;))

And just piping from 32-bit AVS to a 64-bit encoding process is trivial.

Yeah, sure. But I was referring to LigH's "Asuna" x265 build, which features built-in Avisynth support. And if you want to use built-in Avisynth input, your Avisynth DLL has to match the "bitness" of the x265 binary.

(If you pipe from Avs2YUV or similar tool, then we don't need Avisynth support in x265 to begin with)

[aegisofrime]

@Ligh, thanks very much for your build! I gotta ask, did you notice any memory leak issues? I did an overnight encode, only to wake up and find that x265.exe has ate most of my RAM. Did a bit of googling and found that DJATOM might have fixed the memory leak, not sure the same bit of code is in your code base?

https://github.com/staxrip/staxrip/issues/445

[DJATOM]

Yuuki Asuna mod merged my early VS reader works. After some testing from StaxRip users and devs it was found that vspipe's strategy of requesting new frames doesn't work well, I tried different approach to the problem and now it seems no leaks spotted. You can get my build on github and try it. If leak still occurs, describe in details how to reproduce it.

[LigH]

I will try to build it again as soon as I get a fix for rust / cargo failing.

[tormento]

Yuuki Asuna mod
Quoted just to hail you. :)

Can you please explain me the meaning of the files inside your x265 build on GitHub? The ones with the processor suffix are self explanatory, I need clarifications about:

x265-x64-v3.4+65-aMod-gcc10.2.1.exe
x265-x64-v3.4+65-aMod-gcc10.2.1-opt-znver1.exe
x265-x64-v3.4+65-aMod-gcc10.2.1-opt-znver2.exe

Moreover, can you explain me how your builds are different from the LigH one? AVS support, etc?

Thanks.

[DJATOM]

CPU-specific builds made with (for example, zen2 = -march=znver2) compiler flag which should optimize program for specific CPU microarchitecture. Non-opt build is just generic build without such flag.
As for differences, I tried to make commits descriptive. But yeaр, it contains 2 frameserver readers (Avisynth+/Vapoursynth) and y4m reader understand vspipe's XLENGTH header, which "says" how much frames x265 should expect from it.
LigH just uses another mod for his builds. I'm not saying that my build/mod is superior, it just contains certain feature set that I'm using for my needs. That's it.

[tormento]

But yeaр, it contains 2 frameserver readers (Avisynth+/Vapoursynth) and y4m reader understand vspipe's XLENGTH header, which "says" how much frames x265 should expect from it.
Thank you for your answer.

[benwaggoner]

Just curious - has anyone done any perf benchmarking of x265 on ARM processors? With the Apple M1 and workstation successors coming, and the AWS Graviton EC2 instances, it seems we're on the verge of high-performance ARM w/ SIMD compute becoming available. Obviously x265 has a HUGE amount of x64 assembly optimizations, but has some ARM as well. Anyone do any testing or have any data?

I don't imagine that peak ARM perf is anywhere near the latest Ryzen, but perhaps fps/watt is interesting?

[DJATOM]

My friend recently bought a new mac mini with m1 chip, here some numbers on the same source
M1 with 8 gb ram (lpddr4x 4266 mhz) : 5.27 fps
3700x with 32 gb ram (3666 mhz ram oc): 7.73 fps
It was 1080p 8 bit bdmv, encoded in 10 bit mode.

[Ritsuka]

x265 had almost no arm64 assembly. Apple contributed a patch to HandBrake with some neon intrinsics. Unfortunately there seems no one interesting in getting it merged upstream.

[DJATOM]

He used that patch: https://imgur.com/a/ArgJEEe

[Stereodude]

CPU-specific builds made with (for example, zen2 = -march=znver2) compiler flag which should optimize program for specific CPU microarchitecture. Non-opt build is just generic build without such flag.
As for differences, I tried to make commits descriptive. But yeaр, it contains 2 frameserver readers (Avisynth+/Vapoursynth) and y4m reader understand vspipe's XLENGTH header, which "says" how much frames x265 should expect from it.
LigH just uses another mod for his builds. I'm not saying that my build/mod is superior, it just contains certain feature set that I'm using for my needs. That's it.
But are they actually any faster? If so, by what amount?

[DJATOM]

I didn't compared since I only have Zen2 based PC and sandy bridge based notebook... Apparenly Zen2 optimized build operates slightly faster on my machine. Did you measure some data with your CPU?

[Boulder]

At least the Zen2 GCC builds have been faster on my Zen2 system than Visual Studio builds. I don't recall any exact figures, but it was large enough to be noticable, maybe 3-5% with my use.

[LigH]

Building Asuna mod for Win32 target failed...

[ 76%] Building CXX object CMakeFiles/cli.dir/input/input.cpp.obj
In file included from F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/avs.h:5,
from F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/input.cpp:28:
F:/MABS/local32/include/avisynth/avisynth_c.h:786:39: warning: missing initializer for member 'AVS_Value::array_size' [-Wmissing-field-initializers]
786 | static const AVS_Value avs_void = {'v'};
| ^
F:/MABS/local32/include/avisynth/avisynth_c.h:786:39: warning: missing initializer for member 'AVS_Value::d' [-Wmissing-field-initializers]
[ 77%] Building CXX object CMakeFiles/cli.dir/input/y4m.cpp.obj
[ 78%] Building CXX object CMakeFiles/cli.dir/input/yuv.cpp.obj
[ 79%] Building CXX object CMakeFiles/cli.dir/input/lavf.cpp.obj
[ 80%] Building CXX object CMakeFiles/cli.dir/input/avs.cpp.obj
In file included from F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/avs.h:5,
from F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/avs.cpp:23:
F:/MABS/local32/include/avisynth/avisynth_c.h:786:39: warning: missing initializer for member 'AVS_Value::array_size' [-Wmissing-field-initializers]
786 | static const AVS_Value avs_void = {'v'};
| ^
F:/MABS/local32/include/avisynth/avisynth_c.h:786:39: warning: missing initializer for member 'AVS_Value::d' [-Wmissing-field-initializers]
[ 81%] Building CXX object CMakeFiles/cli.dir/input/vpy.cpp.obj
F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/vpy.cpp: In function 'void frameDoneCallback(void*, const VSFrameRef*, int, VSNodeRef*, const char*)':
F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/vpy.cpp:49:91: error: invalid conversion from 'void (*)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)' to 'VSFrameDoneCallback' {aka 'void (__attribute__((stdcall)) *)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)'} [-fpermissive]
49 | vpyCallbackData->vsapi->getFrameAsync(vpyCallbackData->requestedFrames, node, frameDoneCallback, vpyCallbackData);
| ^~~~~~~~~~~~~~~~~
| |
| void (*)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)
F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/vpy.cpp: In member function 'virtual void x265::VPYInput::startReader()':
F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/vpy.cpp:268:39: error: invalid conversion from 'void (*)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)' to 'VSFrameDoneCallback' {aka 'void (__attribute__((stdcall)) *)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)'} [-fpermissive]
268 | vsapi->getFrameAsync(n, node, frameDoneCallback, &vpyCallbackData);
| ^~~~~~~~~~~~~~~~~
| |
| void (*)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)

[DJATOM]

Configure project with -fpermissive cxx flag or edit conflicting signature manually.

[LigH]

Thanks @DJATOM.

@LoRd_MuldeR: x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/coaqv9vaawxm3fb/x265_3.4+13-g729a838d3+41_Asuna.7z/file) — no guarantees, check thoroughly!

[tormento]

If I feed x265 with a 16 bit stream from a SMDegrain source with n16=true, is it necessary to use --input-depth 16 or x265 can "understand" automatically the bit depth?

[cap5lock]

Thanks @DJATOM.

@LoRd_MuldeR: x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/coaqv9vaawxm3fb/x265_3.4+13-g729a838d3+41_Asuna.7z/file) — no guarantees, check thoroughly!

What are tune lists for asuna mod ?
I know --tune lp only

[benwaggoner]

If I feed x265 with a 16 bit stream from a SMDegrain source with n16=true, is it necessary to use --input-depth 16 or x265 can "understand" automatically the bit depth?
If you're using a yuv4mpegpipe, then the depth should be signaled by the pipe. But if a yuv pipe, you'll need to set all the parameters manually.

For doing 8-bit encoding from a higher depth source inside x265, it helps to use the --dither command to get better dithering. But there are better external dithering options than that as well. It probably would help a bit with 10-bit encoding, particularly if it is in HDR.

[LigH]

What are tune lists for asuna mod ?
I know --tune lp only

Run x265 --fullhelp and you will be told:
-t/--tune <string> Tune the settings for a particular type of source or situation:
(mid bitrate anime) littlepox/lp, (slower) littlepox++/lp++,
(high bitrate anime BD / film) vcb-s/vcbs, (slower) vcb-s++/vcbs++,
psnr, ssim, grain, zerolatency, fastdecode


The details (https://github.com/msg7086/x265-Yuuki-Asuna/blob/f9c3b2805f98ae6492528ef69e0cb745c3b9a684/source/common/param.cpp#L622) are a bit complex...

[Boulder]

If you're using a yuv4mpegpipe, then the depth should be signaled by the pipe. But if a yuv pipe, you'll need to set all the parameters manually.

For doing 8-bit encoding from a higher depth source inside x265, it helps to use the --dither command to get better dithering. But there are better external dithering options than that as well. It probably would help a bit with 10-bit encoding, particularly if it is in HDR.

If you process in 10 or 16 bits, it's much better to feed it as such to x265 and use --dither. x264 works internally in 16-bit land so x265 probably does as well.

[benwaggoner]

If you process in 10 or 16 bits, it's much better to feed it as such to x265 and use --dither. x264 works internally in 16-bit land so x265 probably does as well.
x265 always goes down to the native color depth before the frequency transform, so the net effect is identical with internal and external ditherers of the same algorithm.

[foxyshadis]

Run x265 --fullhelp and you will be told:
-t/--tune <string> Tune the settings for a particular type of source or situation:
(mid bitrate anime) littlepox/lp, (slower) littlepox++/lp++,
(high bitrate anime BD / film) vcb-s/vcbs, (slower) vcb-s++/vcbs++,
psnr, ssim, grain, zerolatency, fastdecode


The details (https://github.com/msg7086/x265-Yuuki-Asuna/blob/f9c3b2805f98ae6492528ef69e0cb745c3b9a684/source/common/param.cpp#L622) are a bit complex...

Half of these seem like options that should be based on the preset instead of the tune, but I guess if you're happy with them (basic tune being roughly medium-to-slow and ++ being roughly veryslow) then I guess that works. I would much rather see pure speed options be scaled based on the preset rather than flat overridden in the tune, though.

Adaptive SAO & strong intra smoothing would be such a dream, so they didn't have to be flat out disabled, but the companies with the resources to contribute aren't looking for that kind of absolute sharpness.

[benwaggoner]

Half of these seem like options that should be based on the preset instead of the tune, but I guess if you're happy with them (basic tune being roughly medium-to-slow and ++ being roughly veryslow) then I guess that works. I would much rather see pure speed options be scaled based on the preset rather than flat overridden in the tune, though.
Yeah, it should really be a 2D matrix of preset and tune for parameters, as the tradeoffs can be different at different speed points.

Adaptive SAO & strong intra smoothing would be such a dream, so they didn't have to be flat out disabled, but the companies with the resources to contribute aren't looking for that kind of absolute sharpness.
Also, the companies with the resource to contribute are likely to set exact parameters instead of relying on stock --preset and --tune.

[LoRd_MuldeR]

Thanks @DJATOM.

@LoRd_MuldeR: x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/coaqv9vaawxm3fb/x265_3.4+13-g729a838d3+41_Asuna.7z/file) — no guarantees, check thoroughly!

Thank you! However, your latest binary has dependencies to some shared libraries (DLL files) that are not included in the ZIP package:

https://i.imgur.com/OAOEXOH.png

Of course, it would be much preferable if you could link those statically. Also, the included "libx265.dll" is not actually needed, as far as I can tell.

[DJATOM]

Probably he should remove zlib files from msys and compile from sources, that way it will be linked statically. I've spent a night figuring that out when tried to compile ffms2 libs for x264 :'D

[LigH]

Of course, it would be much preferable if you could link those statically.

I am sorry, I have no clue how, I am no C/C++ developer. If anyone can tell me how to tweak the build scripts, I will do so, but I am not able to discover that on my own.

But it confuses me why it worked on my PC. Maybe I have other applications installed which have them in my PATH. Like GIMP. -- No, I tested only the x64 build, see below.

As I am bound to the environment m-ab-s uses, I can't install or uninstall libraries as I wish.

Also, the included "libx265.dll" is not actually needed, as far as I can tell.

True, they are not, input/output libraries linked are only a matter of the CLI executable.
_

PS:

These dependencies are only valid for the Win32 executables, not for the Win64?!... Just checked with "Dependency Walker".

I am not sure where it comes from. The x264 with the same ffmpeg-light libraries does not need them. Maybe I can discover if m-ab-s excludes them explicitly when building x264.

[LoRd_MuldeR]

I am sorry, I have no clue how, I am no C/C++ developer. If anyone can tell me how to tweak the build scripts, I will do so, but I am not able to discover that on my own.

Well, I think you first would have to figure out whether the libraries in question (libbz2-1 and liblzma-5) were built as part of your build process, or whether they shipped as "pre-built" libraries with your MinGW/GCC/MSYS.

As far as pre-built libraries are concerned, you will often find that two files, called "libfoo.a" (static library) and "libfoo.dll.a" (shared library), are provided. Alternatively, the naming convention "libfoo_static.a" (static library) and "libfoo.a" (shared library) may be used. Other naming convention exist. You'll have to look. Anyway, you will have to make sure that the "static" version of the pre-compiled library is linked into your binary, not the "shared" version.

(A rather "crude" method would be to just delete the "shared" library file from your LIB path and hope that the build script will then pick up the "static" one ;))

If, however, the pre-compiled library is provided only as a shared library, then the only solution would be to build that library yourself from now on - as a static library - instead of using the pre-compiled (shared) version.

But it confuses me why it worked on my PC. Maybe I have other applications installed which have them in my PATH. Like GIMP. -- No, I tested only the x64 build, see below.

There are quite a number of directories that Windows will search for DLL files at runtime. The directories that are listed in your PATH environment variable actually are the last ones to be searched:
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications

Anyways, if you use a "proper" task manager, such as Process Explorer or Process Hacker, you can see all DLLs a process has loaded, with full path. So it would be trivial to figure out where the DLLs in question are located on your system.

[LigH]

I cloned the Asuna branch again, staying at commit 0b7a00d, applied the local fixes anew, compiled ... and the Win32 builds don't seem to need those libraries anymore. Miracles happen...

x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/kvyl9m9s17t7qze/x265_3.4+13-g729a838d3+41_Asuna.7z/file) – 3rd attempt: Win32, Win32XP, Win64 only EXE

[LoRd_MuldeR]

I cloned the Asuna branch again, staying at commit 0b7a00d, applied the local fixes anew, compiled ... and the Win32 builds don't seem to need those libraries anymore. Miracles happen...

x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/kvyl9m9s17t7qze/x265_3.4+13-g729a838d3+41_Asuna.7z/file) – 3rd attempt: Win32, Win32XP, Win64 only EXE

:thanks:

[stax76]

Does it support --reader-options library from aMod?

[LigH]

I don't find that string in the EXE. But DJATOM works together with msg7086, they will know that much better than me...

[MeteorRain]

No. We are developing (kinda) individually. Although some patches were transplanted, they are not identical. Only some patches are copied to the other side.
Please do not expect it to support everything in aMod, and vice versa.

[stax76]

DJATOM has been very responsive to the staxrip community. Maybe create a GitHub organization encoder-mod and work together, otherwise staxrip will support different code paths based on the version name looking for the keywords aMod and Asuna.

[DJATOM]

I think it's better to leave things as is.
Just detect user-supplied binary's mod/version and use different feature set for it. Or discard if binary lacks functionality...

[DJATOM]

Also you can ask Pat to make StaxRip edition, merging and unifying from both worlds :)