x265 HEVC Encoder

[DJATOM]

Originally Posted by LigH

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:

Originally Posted by LoRd_MuldeR

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

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-Yuuk...Lists.txt#L770
and
https://cmake.org/cmake/help/latest/...EFIX_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

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]

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

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)

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

Originally Posted by benwaggoner

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]

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

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]

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

there hasn't been any work on SAO for a long time. So doubtful

[benwaggoner]

Originally Posted by microchip8

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]

Originally Posted by LigH

Update with correct version numbering

x265 3.4+13-g729a838d3+41 (Asuna)

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]

Originally Posted by LoRd_MuldeR

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]

Originally Posted by benwaggoner

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]

Originally Posted by LoRd_MuldeR

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]

Originally Posted by benwaggoner

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 )

Originally Posted by benwaggoner

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)