Releases: Mr-Z-2697/x265-Yuuki-Asuna
4.1+x
Win x64 EXE
GCC 14.2.0:
8+10+12, AVS, VPY, MP4 and MKV:
lol-4.1-pgo: new release.
4.1+"54"-lol: "fixed" the inconsistency with different compile target flags, previously described in 3.6+1-lol-3-2 release, or other places like Patman86/x265-Mod-by-Patman#21 https://bitbucket.org/multicoreware/x265_git/issues/957/different-metrics-with-avx-versions thanks for narrowing it down to cutree otherwise I was planning on just live with it 😆 more details can be found in commit message or Doom9's forum x265 thread https://forum.doom9.org/showthread.php?t=168814&page=484 but I don't think I'll build a so called "AVX2" or what version because the difference that the compiler target specific optimizations make is like, uhm, extremely close to zero, if any. but it (this mod) should still improve accuracy a little bit when not comparing different ISA builds. also a cool lossless tweak which doesn't sound cool actually. PGO build "on its way". I only build this after 12 hrs after commit what do you expect. oh man this release note is hard to read isn't it.
lol-4.1-pgo-2: see above.
4.1+79-lol: new git code I don't understand error why add override hell yeah
4.0+n
update: mandatory --input is fixed in 4.0+6
Using--inputto pass a input string is now mandatory due to some change for the new features,
Multiview (although I'm almost sure I'll never have a chance to use MV, LOL), SCC and Alpha are enabled 'cause why not.
Win x64 EXE
GCC 14.2.0:
8+10+12, AVS, VPY, MP4 and MKV:
4.0+3-lol: 🧐
lol-4.0-pgo: 😶
4.0+3-lol-2: "revisited" some code, for example somehow the aq-bias-strength was not actually parsed? WTF I did back then?
4.0+19-lol: upstream update
4.0+61-lol: upstream update, hope I didn't break something
4.0+76-lol: upstream update. actually this should be 4.1+x but maybe the cmake versioning code is "broken" because the release branch is created too early and they confused(?) and pushed new commits to release branch, then pushed those commits to master branch, then pushed new commits to release and master branch simultaneously. or because they haven't merge the release / stable branch back to master like they used to yet.
3.6+
Added PGO profile data in case you want to reproduce the build?
Although I have enabled extra I/O support (that's the collective name I made up for them), it doesn't mean that I encourage you to use them.
The best practice is still y4m/yuv pipe with raw bitstream output.
Actually the GOP output is very interesting and potentially very useful, but unfortunately I'm yet to meet a situation that really makes it shine.
If you even go as far as want to use LAVF (i.e. FFmpeg library) reader, my crazy* friend, there's a program, called FFmpeg.exe that can read and write any format that 99.9%** of any other tool can provide you, including libx265, you're welcome my friend.
https://github.com/Mr-Z-2697/x265-Yuuki-Asuna/releases#:~:text=(The%20way%20recommended,I%27ll%20be%20dead)
With all the respect to the authors of these extra I/O supports. They are awesome.
*: Nyabe me are the one that were actually crayzy
**: This value may be a bit exaggerated
Win x64 EXE
GCC 14.2.0:
8+10+12, AVS, VPY, MP4 and MKV:
3.6+64-lol: yeah. don't use mp4 or mkv output for new features, I suppose. SHOULD all three new features be enabled together? I don't know, looks ok to me.
3.6+64-lol-2: 3d72ad6
3.6+84-lol: follow up. there are newer commits that I'm not interested becaused they are aarch64 related, they are in pending for next "irregularly manually pull"
lol-3.6-pgo-7: d9a2d4c . re-run profiling.
3.6+116-lol: manually pulled. forgot to enable new features, sry
3.6+116-lol-2: (re-)enabled new features.
lol-3.6-pgo-8: updated preset slowxx removing -2 chrome offsets. setting the chroma offsets will interfere with the auto offset YUV444 input, and a negative offset is not strictly speaking always harmless (although should be 99% of the times harmless). also replaced pow() in the hdr10-opt mod with bitwise shift, should be faster but how much does it improve overall speed is unclear.
3.6+116-lol-3: same change, different branch.
3.6+129-lol: updated.
3.6+162-lol: looks like they are gonna release this as version 4.0, wtf two releases in less than half a year compared to 3.5 release cycle. looks like they are not busy developing x266 which was originally "teased" for yesteryear or so lol.
Win x64 EXE
GCC 14.1.0:
8+10+12, AVS, VPY, MP4 and MKV:
(It looks like the mp4 output is broken and I don't know why, I never use it and have no skill (and interest, if that matters) to fix it.)
Note: for some reason the non-pgo build just decided to output different encoding results compared to previous build while pgo build is unaffected. Fascinating. (It's not bad or corrupted file)
3.6+1-lol-3: some tweaking in the bitstream SEI info and CLI progress info. the updates in the official BB repo are just some document related thing, I just ignore them for now.
lol-3.6-pgo-2: abovementioned tweaks and new profiling with gcc14.
3.6+1-lol-3-2: screwed up naming scheme. the abovementioned "encoding results difference" is caused by setting march=x86-64-v3. this build removes it. so probably default to x86-64(-v1?) I didn't bother to check the docs. here's what interesting/confusing: non-pgo-non-x86-64-v3 = pgo-x86-64-v3 = pgo-non-x86-64-v3, encoding results wise. so setting march will affect encoding result of non-pgo builds (at least x86-64-v3 does) but won't affect pgo builds. not very crucial but definitely something to keep an eye on. (perhaps the PGO just override what -march is set to optimize?)
lol-3.6-pgo-3: some fix. GOP based segmented output modification. breaks compatibility with the specifically designed tool but it was already broken in this branch until the aforementinoed fix so yeah. the code is changed to a certain degree that it's better to re-run the profiling, and I tried something different, instead of using long clips (2182 frames), I ran it with short clips (241 frames) but with a range of param conbinations, and the result is mostly similar if not better. (-pslowxx -tf*1~f*8 -tvq1~3 --asm avx512 on&off) oh and I turned off x86-64-v3 thing because I don't think it makes any tangible difference.
my understanding is that the output files should be able to be binarily concatenated to become one bitstream, but no-annexb and the "lenx", pts and dts extra data breaks that.
maybe there're some reason to do so (apart from the requirement for the specifically designed tool and the process of mp4 muxing), and there's a specifically designed tool to mux it into mp4, but I prefer this way.
just concat them, and output is exactly the same as "raw" bitstream.
as of why not to force no-repeat-headers, well, it's not necessary, I presume.
lol-3.6-pgo-4: AQ1: *joins the orgy* don't hesitate to send me ✨ cute little private messages ✨ if you think use 13 instead of 2523 is better.
lol-3.6-pgo-5: aq-mode 2524, 2525 and 5. profile is run on (in? at? with? by? for? of? my english is bad) aq-mode 2524 only
lol-3.6-pgo-6: pure magic and improved(?) hdr10-opt I gave up running half of the profiling with --asm avx512 because I think it does not have meaningful result for making measureable difference. (it's not hdr10 anymore if it's not following the spec strictly, is it? well don't think too much of it)
3.6+34-lol: have you figured out by now? no? I might need a better naming
3.6+35-lol: merge latest official commit (this one is kinda interesting, I knew that lowpass-dct was broken when I tested it, now I can test it properly)
Win x64 EXE
GCC 13.2.0:
8+10+12, AVS, VPY, MP4 and MKV:
(I might have forgotten to enable some extra I/O support (e.g. l-smash (i.e. mp4 support)) in the way)
3.6+1-lol: catch up with official release.
3.6+1-lol-2: applied videolan/x265 pull request 6. But I'm not planning to use tskip anyway, virtually.
lol-3.6-pgo: lol-Yuuki branched off after release 3.6 (essentially the same code, for now). PGO and LTO enabled like before. AVX2 (march=x86-64-v3) is required, I don't know if this will make any significant performance difference given that the encoder is heavily asm optimised, even PGO and LTO brought a measureable speedup is a surprise (which is about the same 3-5% as before).
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
