3.5+
### If you are building x265 yourself (vanilla or any mods) do not use clang (probably other llvm based too), clang compiled x265 produces gliches in certain conditions, although it may be a rare situation but better to start without this risk, am I right. (INTERNAL(TM) PM ME FOR DETAIL LOL (Private Nachrichten werden nicht für Fremde geöffnet)
About the scratched content above: https://forum.doom9.org/showpost.php?p=2006435&postcount=9491
Added PGO profile data in case you want to reproduce the build?
The pack is significantly bigger than 3.6's because I as a retard used RAR recovery 100% or something. (OMG I forgot to use 1000%)
This release note has been updated several times, how to read this shit:
- Sextions separated by
---
are newer to older from top to bottom - Builds inside each section are newer to older from bottom to top
Win x64 EXE
GCC 13.2.0:
8+10+12, AVS, VPY, MP4 and MKV:
3.5+2-pgo-4: profiling data re-generated due to compiler version upgrade, using preset slowxx tune vq (should be vq3 after splitting). all bitdepths are optimized plus extensive profiling for 10bits makes the speed benefit increase to around 3-5% (only 10bits is measured this time), and lto makes about 0.6%-0.8% increase on top of that. it's also worth to mention that with hme enabled the encoded results from different optimization are not bit-exact (they are bit-exact if hme is disabled, at least that's the only one I encountered so far), but yeah, well, that's just one of the compiler related weird things... (and there're many) (it's actually hme's nature (currently, at least) hme with some lookahead slices value (seemingly) to not be bit-exact, fuck) (the "safe values" of lslices varys between different input resolutions, it's easier to just disable it😶)
3.5+106-lol: merge official commits and split tune vq
3.5+2-pgo-5: split tune vq
3.5+110-lol: merge official commits and adjust tune vq3
3.5+2-pgo-6: adjust tune vq3
Windows executable
Bitdepth 8+10+12
No additional filter support
AVS and VPY input support
MP4 & MKV muxing support:
With GCC 13.1.0:
(The way recommended to do encoding is still Y4M input and HEVC bitstream output)
(Why not just use FFmpeg instead, LOL) (although FFmpeg's vpy input really sucks but anything else, okay? anything else)
(There's a branch named vanilla-lol which I only add my preset and tunes on top of official codes for ease of linking it to FFmpeg, if you are interested in those parameter combinations)
(But promise me you only use FFmpeg for encoding, dont tell me you do some denoise deband whatever in FFmpeg while you have vapoursynth already I'll be dead)
3.5+104-lol: keep up with official git and new tune: vq
3.5+104-lol-2: built with l-smash latest code (version 2.16.1 compared to 2.14.5 which is the latest release which is what mingw provide) l-smash/l-smash@18a9ed2
3.5+2-pgo-3: guess what, tune vq and mp4 mkv muxing
Windows executable
With GCC 13.1.0:
Bitdepth 8+10+12
No additional io support (mp4/mkv)
No additional filter support
With GCC 13.1.0:
3.5+101-lol: catch up some commits
3.5+2-4: re-built with gcc13
3.5+2-pgo: pgo with preset slowxx tune none speeds up encoding by 3-4% on ryzen 7950x for all bits
3.5+103-lol: catch up and new tunes
3.5+2-pgo-2: new tunes, reused profiling data, roughly the same improvement for preset slowxx tune eee
Windows executable
Built with GCC 12.2.0
Bitdepth 8+10+12
No additional io support (mp4/mkv)
No additional filter support
3.5+2: pretty much just like the original one
3.5+2-2: with avs/vs support and new params
3.5+2-3: vs input api4
And there are some "updated" builds.
Two pass problem fixed (seemingly). And I somehow turned on vs input support.
3.5+97: updated with official bitbucket git, removed redundant tunes
3.5+97-lol: for fun but, param recommendations, yeah
3.5+97-lol-2: built with avs input as well since I turned on vs input at some point
3.5+97-lol-3: more f
3.5+97-lol-4: vs input api4
Known issue with three versions below: two pass didn't work. Not present in Coresi7's fork, must be my recklessness when dealt with merge confilts. not going to look into it for now. deal with it.
3.5+96: updated with official bitbucket git, thanks @Coresi7 for fixing compile error (after my failed attempt I found it by conincidece)
3.5+97-z: slightly experimental, same as above plus https://bitbucket.org/multicoreware/x265_git/pull-requests/14 (that's me) (last distance in x265 -V is different, that's just because some trial and error in +96 branch which are just some versioning things so doesn't really matter)
3.5+96-foo: foo branch ofc