x265 HEVC Encoder

[StvG]

Hey StvG,

in fact I already do. I'm using the VS2019 versions from there.
Hey. A week ago or so I tested VS2019 builds and I had no problems when using zones. GCC builds were crashing when using zones.

[birdie]

No they're not if you look at the output in your post. I still think the biggest difference comes from aq-mode changing from 1 to 2. The other changes should cause a much smaller change in the bitrate.

EDIT: as mentioned earlier, the presets have been changed. Veryslow in v2.4 is different from v3.0.

I thought CRF actually meant something. Not really a given bitrate but something close to it.

[mini-moose]

I thought CRF actually meant something. Not really a given bitrate but something close to it.

the lower the CRF value, the higher the bitrate. slowdown is due to preset changes, bitrate differences are due to AQ mode changing from AQ1 default to AQ2 default.

I found that AQ1 was giving a higher bitrate than AQ2, but I suppose it depends on source. I think AQ1 is constant while AQ2 is variable.

[LigH]

CRF means: Constant Rate Factor. It keeps an internal distortion metric in the encoding workflow (called "rate factor") below a threshold. But many details are part of the RF calculation, and not all represent your personal subjective quality impression perfectly. Yet, it is a much better one than PSNR and allows an easy adjustment of the quantization with some respect to the encoding complexity. But a few seemingly paradox results may happen. Heavier efforts do not always result in more efficient video stream code or visually more convenient pictures, exceptions from a general rule aren't impossible.

[jlpsvk]

welcome back LigH. Missing new builds from you. :) Haven't seen you for a longer time here active.

[katzenjoghurt]

Hey. A week ago or so I tested VS2019 builds and I had no problems when using zones. GCC builds were crashing when using zones.

Oh man. You put my hopes so high... :D
Tried out RC1+3 (built with VS2019) but... no luck - it still crashes for me.



Video encoding [...] failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: Ein Heap wurde beschädigt.

[...]
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
[...]

*sigh*

[benwaggoner]

So, I am trying to do a lossless HDR encoding test.

x265.exe - --y4m --colorprim bt2020 --transfer smpte2084 --colormatrix bt2020nc --hdr --hdr-opt -o 4K_LOSSLESS.hevc

And I get this error, which sounds like hdr-opt is getting deactivated because it is confused about the metadata?

Output #0, yuv4mpegpipe, to 'pipe:':
Metadata:
encoder : Lavf58.27.103
Stream #0:0: Video: wrapped_avframe, yuv420p10le, 3840x2160, q=2-31, 200 kb/s, 24 fps, 24 tbn, 24 tbc
Metadata:
encoder : Lavc58.53.100 wrapped_avframe
y4m [info]: 3840x2160 fps 24/1 i420p10 unknown frame count
raw [info]: output file: D:\Octarine\foo_4k_HDR.hevc
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
x265 [info]: build info [Windows][MSVC 1921][64 bit] 8bit+10bit+12bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 [error]: Recommended Settings for HDR: colour primaries should be BT.2020,
transfer characteristics should be SMPTE ST.2084,
matrix coeffs should be BT.2020,
the input video should be 10 bit 4:2:0
Disabling offset tuning for HDR videos
x265 [warning]: Turning on repeat-headers for HDR compatibility

Everything seems set up just fine. Any thoughts about what might be going on here?

[LigH]

welcome back LigH. Missing new builds from you.

Ah, well ... had some issues with other projects compiled in MABS, and more work thus less spare time. And there are so many competitors now. But a "merge with stable" is a reason to publish another one.

[Blue_MiSfit]

@benwaggoner I'd suggest patching out the feature that disables hdr-opt in certain conditions. You certainly know what you're doing and it's a one-line fix ;)

[benwaggoner]

@benwaggoner I'd suggest patching out the feature that disables hdr-opt in certain conditions. You certainly know what you're doing and it's a one-line fix ;)
First off, I want to know what the conditions are. I don't dismiss the possibility that I don't know what I'm doing in some aspect :sly:.

[Barough]

x265 v3.1+2-b36c03e4e771 (https://www.mediafire.com/file/h2t7taqxxikptfr/x265-3.1+2-b36c03e4e771_Win_GCC910.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)


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

[Blue_MiSfit]

@benwaggoner

https://bitbucket.org/multicoreware/x265/src/b36c03e4e7719da0c708218192357a17f0a3d42b/source/encoder/encoder.cpp#lines-3316


if (p->internalCsp != X265_CSP_I420 || p->internalBitDepth != 10 || p->vui.colorPrimaries != 9 ||
p->vui.transferCharacteristics != 16 || p->vui.matrixCoeffs != 9)


So, if any of the following are NOT true x265 will disable hdr-opt

4:2:0
10 bit
color primaries = 9 (bt2020)
transfer characteristics = 16 (smpte2084)
matrix coefficients = 9 (bt2020nc)

It does look like you're set up correctly, so no idea why this is happening.

I've found hdr-opt to be helpful for Dolby Vision Profile 5 encoding, which is incompatible with the required VUI to enable it, so I just patched out the above code block :devil:

[StvG]

Oh man. You put my hopes so high... :D
Tried out RC1+3 (built with VS2019) but... no luck - it still crashes for me.



Video encoding [...] failed with exit code: -1073740940 (0xC0000374)

The exit code might be a system error code: Ein Heap wurde beschädigt.

[...]
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
[...]

*sigh*

gcc:
avs2yuv_x64 -depth 10 1.avs -o - | x265-10b.exe --y4m - --level-idc 5.1 --high-tier --ref 6 --bframes 12 --rd 4 --me 3 --subme 5 --merange 57 --ipratio 1.2 --pbratio 1.1 --aq-mode 3 --aq-strength 0.95 --qcomp 0.70 --psy-rd 1.35 --psy-rdoq 1.20 --ctu 32 --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-early-skip --no-cutree --tu-intra-depth 4 --tu-inter-depth 4 --range limited --aud --repeat-headers --hrd --hdr-opt --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,20)" --max-cll=0,0 --input-depth 10 --chromaloc 2 --preset slower -o gcc.mkv --asm avx512 --zones 2100,3000,b=1.22/9000,10500,b=1.3/13000,13500,b=1.1/22000,22320,b=1.11/25000,25300,b=1.15 --crf 17 > gcc.txt 2>&1y4m [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw [info]: output file: gcc.mkv
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
...
30194 frames: 5.47 fps, 20856.40 kb/s
30198 frames: 5.47 fps, 20855.46 kb/s
30201 frames: 5.47 fps, 20854.86 kb/s
30206 frames: 5.47 fps, 20853.95 kb/s
30210 frames: 5.47 fps, 20852.97 kb/s
vs2019:
avs2yuv_x64 -depth 10 1.avs -o - | x265-10bvs.exe --y4m - --level-idc 5.1 --high-tier --ref 6 --bframes 12 --rd 4 --me 3 --subme 5 --merange 57 --ipratio 1.2 --pbratio 1.1 --aq-mode 3 --aq-strength 0.95 --qcomp 0.70 --psy-rd 1.35 --psy-rdoq 1.20 --ctu 32 --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-early-skip --no-cutree --tu-intra-depth 4 --tu-inter-depth 4 --range limited --aud --repeat-headers --hrd --hdr-opt --colorprim bt2020 --colormatrix bt2020nc --transfer smpte2084 --master-display "G(13250,34500)B(7500,3000)R(34000,16000)WP(15635,16450)L(10000000,20)" --max-cll=0,0 --input-depth 10 --chromaloc 2 --preset slower -o vs.mkv --asm avx512 --zones 2100,3000,b=1.22/9000,10500,b=1.3/13000,13500,b=1.1/22000,22320,b=1.11/25000,25300,b=1.15 --crf 17 > vs.txt 2>&1y4m [info]: 1920x1080 fps 24000/1001 i420p10 unknown frame count
raw [info]: output file: vs.mkv
x265 [info]: HEVC encoder version 3.1_RC1+3-3bdf06e3c628
x265 [info]: build info [Windows][MSVC 1921][64 bit] 10bit
...
30194 frames: 5.32 fps, 20856.40 kb/s
30197 frames: 5.32 fps, 20855.68 kb/s
30199 frames: 5.32 fps, 20855.23 kb/s
30201 frames: 5.32 fps, 20854.86 kb/s
30205 frames: 5.32 fps, 20854.18 kb/s
30207 frames: 5.33 fps, 20853.70 kb/s
30210 frames: 5.33 fps, 20852.97 kb/s

x265 [info]: frame I: 204, Avg QP:14.97 kb/s: 33917.45
x265 [info]: frame P: 3896, Avg QP:16.17 kb/s: 26657.95
x265 [info]: frame B: 26112, Avg QP:17.10 kb/s: 20900.09
x265 [info]: Weighted P-Frames: Y:2.8% UV:0.6%
x265 [info]: Weighted B-Frames: Y:5.6% UV:0.2%
x265 [info]: consecutive B-frames: 13.6% 1.0% 2.4% 9.0% 3.2% 7.3% 3.9% 24.4% 5.8% 4.8% 4.0% 14.9% 5.6%

encoded 30212 frames in 5669.34s (5.33 fps), 21730.49 kb/s, Avg QP:16.97
GCC build didn't output the last lines with the statistics but the last encoded frame is identical to the vs last frame. Also GCC as always is a bit faster than VS at least for me.

Edit: GCC MediaInfo (https://pastebin.com/M2wC2YTB) and VS MediaInfo (https://pastebin.com/aDp3fkjX). Both has zone-count=5

[MeteorRain]

Had anyone actually done any benchmark on x265 on GCC 8.3 and 9.1?
From past records 9preview was slower than 8 but how about now?

[StvG]

Couple days ago I tested x265 compiled with gcc-7/8/9-branch and all three builds gave me the same fps (<=1%).

[benwaggoner]

First off, I want to know what the conditions are. I don't dismiss the possibility that I don't know what I'm doing in some aspect :sly:.
It appears that the --lossless flag blocks --hdr-opt. Which makes total sense in retrospect, as lossless is QP 4.

So, right behavior, wrong error message.

[katzenjoghurt]

Oh my.
Am I the only one having such a hard time encoding scenes with red light / red backgrounds?

[...]

Oh man. I THINK I finally found a solution for my neverending problem with red areas getting blurred and/or blocky.

People already gave me a hint to use 10bit encoding or playing around with the crqpoffs parameter. Both didn't really help.

This changed drastically now after I converted the source to YV24 colorspace and encoded it with Main 444 10.

Suddenly the crqpoffs parameter started to work wonders and setting it to -1 already brought back most of the details.


How to do it in StaxRip 1.7.0.6:
1) Click on the "AVS Filter" label. Click "Profiles".
2) Find the [Misc] section and add this line to the bottom: ConvertToYV24 = ConvertToYV24()
3) Add the Filter now via right-click -> Misc -> ConvertToYV24
4) Go into the x265 encoder settings
5) In "Basic" chose the Main 444 10 profile.
6) In "Rate Control 1" set CR QB Offset to -1.

Meh.

And now I reallize that with Main 10 444...
a) ... the contrast is too high in VLC
b) ... the video won't play at all in Windows Media Player
c) ... while it works well in Kodi and Zoom Player.

:(

[LigH]

x265 3.1+2-b36c03e4e771 (https://www.mediafire.com/file/12qr86ocy2eox6d/x265_3.1+2-b36c03e4e771.7z/file) (MSYS2, GCC 9.1.0)

New options / changes:

--[no-]field Enable or disable field coding. Default disabled
--[no-]early-skip Enable early SKIP detection. Default enabled
--max-merge <1..5> Maximum number of merge candidates. Default 3
--limit-refs <0|1|2|3> Limit references per depth (1) or CU (2) or both (3). Default 1
--[no-]b-intra Enable intra in B frames in veryslow presets. Default enabled
--[no-]fades Enable detection and handling of fade-in regions. Default disabled
--max-cll <string> Specify content light level info SEI as "cll,fall" (HDR).
--[no-]cll Emit content light level info SEI. Default enabled

[Natty]

Had anyone actually done any benchmark on x265 on GCC 8.3 and 9.1?
From past records 9preview was slower than 8 but how about now?

it looks like the bug of hidden encoding settings is still there in x265-Yuuki-3.1_RC1+4-gf48f4d038+23.7z build :helpful:

[MeteorRain]

Well I observed some performance regression so I'm keeping my GCC 8.3 for now. 1-3% slower with GCC 9.1 than 8.3 on my workstation.
It could be measurement error though.

@Natty Yea 3.1 RC1+4 was not properly compiled. Will remove it soon. I've properly revised the mod branch and that should be fixed in 3.1 GA.

[katzenjoghurt]

[...]

I updated to the GCC build LigH posted a bit above (thx!) and it seems zones now aren't crashing for me as well any more. Hooray!!!!! :)

Can't explain why it worked for you but not for me before that.

[poisondeathray]

New options / changes:

--[no-]fades Enable detection and handling of fade-in regions. Default disabled


Thanks for the build;

Any more info or discussion on this somewhere?

Is it sort of like the --fade-compensate patch from x264 ?

Is there anyway to modulate the strength ?


1) The setting is not currently reflected in the encoder settings (as read by mediainfo)

2) on a quick test, it seems to correctly detect and increase the bitrate in the fade area... But there seems to be a slight abrupt transition as it exits out of the fade, almost like "keyframe popping", when compared to without --fades . There is an I frame placed on the --fades encode, where it was a B on the without .

Just one observation, one test, so I'll take do some other tests before before making any preliminary conclusions...

[LigH]

I updated to the GCC build LigH posted a bit above (thx!) and it seems zones now aren't crashing for me as well any more. Hooray!!!!! :)

Can't explain why it worked for you but not for me before that.

Probably depending on details, due to the nature of the problem (https://bitbucket.org/multicoreware/x265/commits/b4e38ce16d7c4b37a6482dc7ae61fd31071b6ff1):

Fix double free in zones

[benwaggoner]

2) on a quick test, it seems to correctly detect and increase the bitrate in the fade area... But there seems to be a slight abrupt transition as it exits out of the fade, almost like "keyframe popping", when compared to without --fades . There is an I frame placed on the --fades encode, where it was a B on the without .

Just one observation, one test, so I'll take do some other tests before before making any preliminary conclusions...
What preset were you using? I'd expect that with weighted B and P prediction, a fade itself shouldn't require an increase in bitrate. And with Open GOP I'd hope the keyframe pop wouldn't be quite so harsh.

[poisondeathray]

What preset were you using? I'd expect that with weighted B and P prediction, a fade itself shouldn't require an increase in bitrate. And with Open GOP I'd hope the keyframe pop wouldn't be quite so harsh.


Slower , plus a few other changes . 10bit, CRF rate control

As you probably are aware, x264 and x265 have had issues with fades for a long time (probably why this option was introduced) . So I'm guessing the point of --fades was to increase the bitrate and fix the fade region (it's desired) . Without it - the banding and fade looks worse (as expected), With it, the fade looks better, bitrate increased - except for the popping

I haven't had a chance to examine in more detail or run more tests, but it's a pretty clear "pop" because of the quality change. The I frame is lower in quality. The test sequence was Lighthouses of the Pacific at the beginning . You only need to encode about 50 frames or so, it occurs 46-47 .

[filler56789]

As you probably are aware, x264 and x265 have had issues with fades for a long time (probably why this option was introduced) . So I'm guessing the point of --fades was to increase the bitrate and fix the fade region (it's desired) . Without it - the banding and fade looks worse (as expected), With it, the fade looks better, bitrate increased - except for the popping.

IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/

[SeeMoreDigital]

IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/I could have done with something like that a few years ago when I had to generate an encode that began with a black to full colour transition over the first 125 frames (5 seconds).

In order to get rid of the horrendous blocks at the beginning of the encode, I ended up having encode the first 125 frames separately (using I and P frames).

[TomV]

IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/

That is an extremely inefficient strategy for encoding dissolve transitions.

[benwaggoner]

IMHO x264, x265, and Xvid as well, should have gone the way of DivX and WMV3/WVC1, regarding ~scene detection~. In both DivX and WMV, the fades generate a sequence of I-frames, and this is a non-problem when the playback device of the user doesn't care about "excessive" bitrates. Sadly it seems the FOSS developers think «the less options for the end-user, the better» :-/
Actually, the VC-1 encoder (and I believe the stock WMV9) would turn a transition into a sequence of P frames. It didn't have weighted prediction for B-frames so that was a lot more efficient.

Since HEVC has b-frame weighted prediction as well, that shouldn't be necessary. But rate control and motion estimation for a cross-dissolve is irreducibly tricky. Ideally the "before" and "after" frames would be defined and then forward/back proprogated via some mbtree extension.

[filler56789]

That is an extremely inefficient strategy for encoding dissolve transitions.

I know that. But it seems you don't know that it WORKS :sly:

[benwaggoner]

I know that. But it seems you don't know that it WORKS :sly:
Up to a point. Maybe. But a second long cross dissolve would need either a really big VBV or really high QP. And weighted prediction is EXACTLY for this kind of use case.

[Barough]

x265 v3.1+4-4f6dde51a5db (https://www.mediafire.com/file/lct1u36fy1kpy1x/x265-3.1+4-4f6dde51a5db_Win_GCC910.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)


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

[birdie]

x265 3.1.1 is out.

https://bitbucket.org/multicoreware/x265/downloads/x265_3.1.1.tar.gz

[MeteorRain]

From 9612a000cb26748e62833dcd9e47d890af0e3dec Mon Sep 17 00:00:00 2001
From: Xinyue Lu <i@7086.in>
Date: Tue, 9 Jul 2019 21:30:15 -0400
Subject: [PATCH] icc: fix compiling and linking issue under ICC

---
source/common/x86/asm-primitives.cpp | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/source/common/x86/asm-primitives.cpp b/source/common/x86/asm-primitives.cpp
index 3948c4b97..abd3665f8 100644
--- a/source/common/x86/asm-primitives.cpp
+++ b/source/common/x86/asm-primitives.cpp
@@ -5429,7 +5429,7 @@ void setupAssemblyPrimitives(EncoderPrimitives &p, int cpuMask) // Main
} // namespace X265_NS

extern "C" {
-#ifdef __INTEL_COMPILER
+#if defined(__INTEL_COMPILER) && EXPORT_C_API

/* Agner's patch to Intel's CPU dispatcher from pages 131-132 of
* http://agner.org/optimize/optimizing_cpp.pdf (2011-01-30)
@@ -5440,7 +5440,7 @@ int __intel_cpu_indicator = 0;
// CPU dispatcher function
void PFX(intel_cpu_indicator_init)(void)
{
- uint32_t cpu = x265::cpu_detect(false);
+ uint32_t cpu = X265_NS::cpu_detect(false);

if (cpu & X265_CPU_AVX)
__intel_cpu_indicator = 0x20000;
@@ -5467,7 +5467,7 @@ void PFX(intel_cpu_indicator_init)(void)
* that backs up all the registers. */
void __intel_cpu_indicator_init(void)
{
- x265_safe_intel_cpu_indicator_init();
+ PFX(intel_cpu_indicator_init)();
}

#else // ifdef __INTEL_COMPILER
--
2.19.1.windows.1


Fixes #487 and #488. For those who'd like to use ICC. Anyone is free to submit this patch to the official with any amount of modification.

[chenm001]

From 9612a000cb26748e62833dcd9e47d890af0e3dec Mon Sep 17 00:00:00 2001
From: Xinyue Lu <i@7086.in>
Date: Tue, 9 Jul 2019 21:30:15 -0400
Subject: [PATCH] icc: fix compiling and linking issue under ICC


Fixes #487 and #488. For those who'd like to use ICC. Anyone is free to submit this patch to the official with any amount of modification.

Thank you point out this bug, I have been forward message to project manager.

[Stereodude]

What happened to x265 from 2.9 to 3.x? The bitrate dropped (and the QP increased) and the visual output quality has suffered at the same crf with the same command line. I read the release notes here: https://x265.readthedocs.io/en/default/releasenotes.html but they don't shed a ton of light. I know they made the old veryslow = new slower and effectively made a new preset between placebo and the old veryslow, but I've been using placebo so that doesn't explain it.

My typical 1080p command line switches for 8 bit 4:2:0 input.
--crf 16.0 -p placebo --no-sao --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

[LigH]

:eek: Preset "placebo" as your "typical" 1080p parameter ... seriously?! I hope you use solar power to operate your PC. :o

The meaning of the placebo preset didn't change in the last years. So it must be a change in the general default behaviour.

I can hardly imagine anyone actually seeing an obvious loss of quality in a CRF 16 result played at normal speed. I hope you don't compare single frames with a magnifier to produce this claim. Are you able to provide clips to compare?

[Wolfberry]

The default AQ mode has been changed to auto-variance (aq-mode 2) in version 3.0.

Try setting --aq-mode 1 (the old default) in your command line.

[Stereodude]

I can hardly imagine anyone actually seeing an obvious loss of quality in a CRF 16 result played at normal speed. I hope you don't compare single frames with a magnifier to produce this claim. Are you able to provide clips to compare?
It's quite easy to see in motion without magnification. Watch how fine grain dances and changes over time compared to the source (or doesn't dance and change like it should). With 2.9 the presets faster than placebo did not give satisfactory results even with significantly more bitrate.
The default AQ mode has been changed to auto-variance (aq-mode 2) in version 3.0.

Try setting --aq-mode 1 (the old default) in your command line.
Okay, thanks I will try this.

[Barough]

x265 v3.1+7-147fb92c5ed5 (https://www.mediafire.com/file/1a9q2qjfusbvi9p/x265-3.1+7-147fb92c5ed5_Win_GCC910.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)


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

[Stereodude]

Why hasn't direct AVIsynth input been added to the windows builds of x265 like x264 has? I'm rather sick of having to pipe video into it.

[Natty]

x265-3.1.1+1-04b37fd-win64-static-multilib (https://drive.google.com/open?id=1iCOs9fD5i6tWh62-OOIH_6AGJhpSWv66)


x265 v3.1+7-147fb92c5ed5 (https://www.mediafire.com/file/1a9q2qjfusbvi9p/x265-3.1+7-147fb92c5ed5_Win_GCC910.7z/file) (32 & 64-bit 8/10/12bit Multilib Windows Binaries) (GCC 9.1.0)


which one is latest ?:thanks:

[Barough]

V3.1+7 is from the Default channel and includes what the v3.1.1 have and some more

Skickat från min SM-G975F via Tapatalk

[qyot27]

Why hasn't direct AVIsynth input been added to the windows builds of x265 like x264 has? I'm rather sick of having to pipe video into it.
Use x265-Yuuki or ffmpeg.

[stax76]

Use x265-Yuuki or ffmpeg.

Or Wolfberry

[Stereodude]

Use x265-Yuuki or ffmpeg.
Is there some trick to making x265-Yuuki work with avisynth+?

C:\HDTV Tools\x265_Yuuki>x265-gcc-multilib-full.exe -f 1500 --crf 16.0 -p placebo --no-sao --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 -o HZLIP_p_1.15_16.0_nosao_D10_dith_p1_t_10in.265
"E:\TempBD\HZLIP\HZLIP_comb_1.avs"
[avs2 @ 00000000037d8300] Format avs2 detected only with low score of 1, misdetection possible!
[avs2 @ 00000000037d8300] Could not find codec parameters for stream 0 (Video: avs2, none): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
[NULL @ 0000000004e14700] No codec provided to avcodec_open2()
[NULL @ 0000000004e14700] No codec provided to avcodec_open2()
lavf [error]: could not find decoder for video stream
x265 [error]: unable to open input file <E:\TempBD\HZLIP\HZLIP_comb_1.avs>
Edit: Wolfberry works with the same command line (changing only the name of the executable). :confused:

[qyot27]

Yuuki is the patchset/branch (https://github.com/msg7086/x265-Yuuki-Asuna/commits/Yuuki) (the patch itself is just generic LAVF input); whether the particular build was linked against a libavformat that itself was built with --enable-avisynth is up to the one building it. 'avs2' is not AviSynth (it's the Chinese AVS2 format), and the only reason libavformat would jump to that when given an AviSynth script is that FFmpeg hadn't been built with --enable-avisynth.

[Stereodude]

So why doesn't the Wolfberry build of x265 honor affinity restrictions? Using START "Enc #1" /NORMAL /NODE 0 /AFFINITY 00FF in front of the x265 command line still results in the same number of threads being spawned as no affinity restrictions or /AFFINITY 000F. It always sees the full processor which is the same problem I have with piping.

[Stereodude]

--seek doesn't work correctly with the Wolfberry build with an avisynth+ input either.

x265.exe" --pools 4 -F 1 --crf 16.0 -p veryslow --no-sao --aq-mode 1 --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 --seek 16609
--frames 16678 -o out_2.265 "source.avs"

I get this output in the console: (which says all the right things)
lavf [info]:
Format : avisynth
Codec : rawvideo ( raw video )
PixFmt : yuv420p10le
Framerate : 24/1
Timebase : 1/24
Duration : 2:18:31
lavf [info]: 1920x1080 fps 24/1 i420p10 sar 1:1 frames 16609 - 33286 of 199487
raw [info]: output file: out_2.265
x265 [info]: HEVC encoder version 3.1.1+1-04b37fdfd2dc
x265 [info]: build info [Windows][GCC 9.1.1][64 bit] 10bit
x265 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.2 AVX
x265 [info]: Main 10 profile, Level-5.1 (Main tier)
x265 [info]: Thread pool created using 4 threads
x265 [info]: Slices : 1
x265 [info]: frame threads / pool features : 1 / wpp(17 rows)
x265 [info]: Coding QT: max CU size, min CU size : 64 / 8
x265 [info]: Residual QT: max TU size, max depth : 32 / 3 inter / 3 intra
x265 [info]: ME / range / subpel / merge : star / 57 / 4 / 5
x265 [info]: Keyframe min / max / scenecut / bias: 12 / 120 / 40 / 5.00
x265 [info]: Lookahead / bframes / badapt : 40 / 8 / 2
x265 [info]: b-pyramid / weightp / weightb : 1 / 1 / 1
x265 [info]: References / ref-limit cu / depth : 5 / off / off
x265 [info]: AQ: mode / str / qg-size / cu-tree : 1 / 1.1 / 32 / 1
x265 [info]: Rate Control / qCompress : CRF-16.0 / 0.60
x265 [info]: VBV/HRD buffer / max-rate / init : 40000 / 40000 / 0.900
x265 [info]: tools: rect amp rd=6 psy-rd=2.00 rdoq=2 psy-rdoq=1.00 rskip
x265 [info]: tools: signhide tmvp b-intra strong-intra-smoothing deblock
[0.3%] 54/16678 frames, 0.16 fps, 6617.67 kb/s, 1.77 MB, eta 29:46:47, est.size 548.21 MB
But the actual out_2.265 output file starts from frame 0 in the source, not frame 16609.

[MeteorRain]

AviSynth support came from LAVF input filter.
LAVF input filter was ported from x264.
x264 didn't support seeking.

So this input filter never had seeking feature.

As a side note, LAVF was never designed to take AVS script (and that's exactly the reason I did not include AVS support in my build).

I'd hope one day someone can add a proper AVS native input. But on the other hand my scripts are on 32-bit so I have no choice but to use piper anyway.