x265 HEVC Encoder

[Boulder]

Originally Posted by jpsdr

Seriously...! A new version just right now after all my strugles...
They made it on purpose, just after i put my build i spend all this time on...
Have to wait a little time unfortunately for a new build.

The latest commits don't concern the regular Windows binary at all I think.

[jpsdr]

Except maybe just one on the asm file, not being sure, i've made new builds, you can get them on my github.

[Barough]

x265 v3.5+94
Built on February 20, 2023, GCC 12.2.0

DL :
https://www.mediafire.com/file/c38imiluf5gyabb

[jpsdr]

Noooooooooooooooooooooooooooooooooooooooooooooooooooooo !!!!!!!!!!!!!!!!!!!!!!!!

[john33]

x265 v3.5+94
Built on February 20, 2023, VS2019 (AVX2 compiler optimisation)

DL: https://www.rarewares.org/files/x265...4-20230220.zip

[Morku]

Originally Posted by jpsdr

Noooooooooooooooooooooooooooooooooooooooooooooooooooooo !!!!!!!!!!!!!!!!!!!!!!!!

xD Love your build.

[filler56789]

Originally Posted by john33

x265 v3.5+94
Built on February 20, 2023, VS2019 (AVX2 compiler optimisation)

DL: https://www.rarewares.org/files/x265...4-20230220.zip

Does your build also encode audio, like some ancient mods of x264?

[LeXXuz]

Originally Posted by jpsdr

Noooooooooooooooooooooooooooooooooooooooooooooooooooooo !!!!!!!!!!!!!!!!!!!!!!!!

LOL. Someone over there must know when you just finished your work.
SCNR!

Really appreciate your builds. Still using +87 and I'm very happy with it. See no reason to update any time soon.

[john33]

Originally Posted by filler56789

Does your build also encode audio, like some ancient mods of x264?

Just a current git build.

[jpsdr]

Made a new build, check my github.

[john33]

Since (and including) r3.50.0.87.1, the " // solve "fatal error C1061: compiler limit : blocks nested too deeply"" error has returned with attempted MSVC compiles of the "Patman" version. (source\common\param.cpp) GCC doesn't exhibit this issue. The standard git version does not have this problem so it is obviously to do with the "Patman" mods. And, @jpsdr, you'll be happy to know there is another update!

[filler56789]

Originally Posted by john33

And, @jpsdr, you'll be happy to know there is another update!

That's why I'll keep using version 3.3+10 forever😇

[john33]

x265 v3.5+95
Built on February 22, 2023, VS2019 (AVX2 compiler optimisation)


DL:https://www.rarewares.org/files/x265...5-20230222.zip

[Barough]

x265 v3.5+96
Built on February 22, 2023, GCC 12.2.0

DL :
https://www.mediafire.com/file/lvwa18uv48f4aq9

[jpsdr]

It's not even funny anymore...

Edit:
After looking the commits, not offect on PC, so no build necessary...
Yes !!!

[jpsdr]

Originally Posted by john33

The standard git version does not have this problem so it is obviously to do with the "Patman" mods.

It's not the Patman mods, it's the commands i've added.
This make me adds parameters description, and with the standard version it's very close to the limits.
If the standard version adds 3 or 4 others commands, it will hit also the limit.

[john33]

Originally Posted by jpsdr

It's not the Patman mods, it's the commands i've added.
This make me adds parameters description, and with the standard version it's very close to the limits.
If the standard version adds 3 or 4 others commands, it will hit also the limit.

So I guess we're already there.

[~ VEGETA ~]

hello,

in my setup i encode lossless 1080p first, then use it to encode final 1080p, 720p, etc.. this is usually in x264, qp 0 ultrafast for lossless which gives me fast enough results.

can I use that output as input to x265?

my lossless is .mkv but i can easily make it .yuv or .y4m if needed. I tried inputting that to x265 but it didn't take all frames even when specified, then outputted garbage video (full of colors and no actual content).

I prefer a direct usage of x265 rather than piping from vspipe or so.

for your kind input please.

[LigH]

New upload: x265 3.5+94-74a312564

[Windows][GCC 12.2.0][32/32XP/64 bit] 8bit+10bit+12bit

[jlpsvk]

it's better to use --aq-mode 2 or --aq-auto 6 for 4K HDR? both giving me almost same bitrate at CRF16 with preset slower (with some manual settings)