x265 HEVC Encoder

[benwaggoner]

Originally Posted by Blue_MiSfit

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/defau...easenotes.html

[theincognito]

Originally Posted by Patman

Here

If it's not too much, can you build a test msvc avx2 build, with M support? x265 obviously.

[Patman]

Originally Posted by theincognito

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]

Originally Posted by Patman

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

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]

Originally Posted by JoyBell

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-]

Originally Posted by charliebaby

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]

Originally Posted by -QfG-

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

Improvements to hist-based scenecut algorithm.
Add support for RADL pictures at IDR scenecuts

[charliebaby]

Originally Posted by LigH

New upload: x265 3.4+9-g1fb7c7960

Improvements to hist-based scenecut algorithm.
Add support for RADL pictures at IDR scenecuts

Thank you

[benwaggoner]

Originally Posted by 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..

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]

Originally Posted by benwaggoner

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_hev...r_download.htm

VS 2015
VS 2019
GCC 10.1

[Barough]

x265 v3.4+10-g7a640a2c1 (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 10.1.0)

https://bitbucket.org/multicoreware/x265_git/commits/branch/master