x265 HEVC Encoder

[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 (https://www.mediafire.com/file/jwfrq44310wd6o5/x265_3.4-Asuna%252B54.7z/file)

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]

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) (https://www.mediafire.com/file/ababni9k8qvt44t/x265_3.4+13-g729a838d3+41_Asuna.7z/file)

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 (https://www.mediafire.com/file/uzfgv7k6rhp9trp/x265-3.4%252B37-dd1101b6d_Win_GCC102.7z/file) (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]

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]

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]

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]

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]

Update with correct version numbering

x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/ababni9k8qvt44t/x265_3.4+13-g729a838d3+41_Asuna.7z/file)

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]

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]

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]

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]

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 ;))

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)

[aegisofrime]

@Ligh, thanks very much for your build! I gotta ask, did you notice any memory leak issues? I did an overnight encode, only to wake up and find that x265.exe has ate most of my RAM. Did a bit of googling and found that DJATOM might have fixed the memory leak, not sure the same bit of code is in your code base?

https://github.com/staxrip/staxrip/issues/445

[DJATOM]

Yuuki Asuna mod merged my early VS reader works. After some testing from StaxRip users and devs it was found that vspipe's strategy of requesting new frames doesn't work well, I tried different approach to the problem and now it seems no leaks spotted. You can get my build on github and try it. If leak still occurs, describe in details how to reproduce it.

[LigH]

I will try to build it again as soon as I get a fix for rust / cargo failing.

[tormento]

Yuuki Asuna mod
Quoted just to hail you. :)

Can you please explain me the meaning of the files inside your x265 build on GitHub? The ones with the processor suffix are self explanatory, I need clarifications about:

x265-x64-v3.4+65-aMod-gcc10.2.1.exe
x265-x64-v3.4+65-aMod-gcc10.2.1-opt-znver1.exe
x265-x64-v3.4+65-aMod-gcc10.2.1-opt-znver2.exe

Moreover, can you explain me how your builds are different from the LigH one? AVS support, etc?

Thanks.

[DJATOM]

CPU-specific builds made with (for example, zen2 = -march=znver2) compiler flag which should optimize program for specific CPU microarchitecture. Non-opt build is just generic build without such flag.
As for differences, I tried to make commits descriptive. But yeaр, it contains 2 frameserver readers (Avisynth+/Vapoursynth) and y4m reader understand vspipe's XLENGTH header, which "says" how much frames x265 should expect from it.
LigH just uses another mod for his builds. I'm not saying that my build/mod is superior, it just contains certain feature set that I'm using for my needs. That's it.

[tormento]

But yeaр, it contains 2 frameserver readers (Avisynth+/Vapoursynth) and y4m reader understand vspipe's XLENGTH header, which "says" how much frames x265 should expect from it.
Thank you for your answer.

[benwaggoner]

Just curious - has anyone done any perf benchmarking of x265 on ARM processors? With the Apple M1 and workstation successors coming, and the AWS Graviton EC2 instances, it seems we're on the verge of high-performance ARM w/ SIMD compute becoming available. Obviously x265 has a HUGE amount of x64 assembly optimizations, but has some ARM as well. Anyone do any testing or have any data?

I don't imagine that peak ARM perf is anywhere near the latest Ryzen, but perhaps fps/watt is interesting?

[DJATOM]

My friend recently bought a new mac mini with m1 chip, here some numbers on the same source
M1 with 8 gb ram (lpddr4x 4266 mhz) : 5.27 fps
3700x with 32 gb ram (3666 mhz ram oc): 7.73 fps
It was 1080p 8 bit bdmv, encoded in 10 bit mode.

[Ritsuka]

x265 had almost no arm64 assembly. Apple contributed a patch to HandBrake with some neon intrinsics. Unfortunately there seems no one interesting in getting it merged upstream.

[DJATOM]

He used that patch: https://imgur.com/a/ArgJEEe

[Stereodude]

CPU-specific builds made with (for example, zen2 = -march=znver2) compiler flag which should optimize program for specific CPU microarchitecture. Non-opt build is just generic build without such flag.
As for differences, I tried to make commits descriptive. But yeaр, it contains 2 frameserver readers (Avisynth+/Vapoursynth) and y4m reader understand vspipe's XLENGTH header, which "says" how much frames x265 should expect from it.
LigH just uses another mod for his builds. I'm not saying that my build/mod is superior, it just contains certain feature set that I'm using for my needs. That's it.
But are they actually any faster? If so, by what amount?

[DJATOM]

I didn't compared since I only have Zen2 based PC and sandy bridge based notebook... Apparenly Zen2 optimized build operates slightly faster on my machine. Did you measure some data with your CPU?

[Boulder]

At least the Zen2 GCC builds have been faster on my Zen2 system than Visual Studio builds. I don't recall any exact figures, but it was large enough to be noticable, maybe 3-5% with my use.

[LigH]

Building Asuna mod for Win32 target failed...

[ 76%] Building CXX object CMakeFiles/cli.dir/input/input.cpp.obj
In file included from F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/avs.h:5,
from F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/input.cpp:28:
F:/MABS/local32/include/avisynth/avisynth_c.h:786:39: warning: missing initializer for member 'AVS_Value::array_size' [-Wmissing-field-initializers]
786 | static const AVS_Value avs_void = {'v'};
| ^
F:/MABS/local32/include/avisynth/avisynth_c.h:786:39: warning: missing initializer for member 'AVS_Value::d' [-Wmissing-field-initializers]
[ 77%] Building CXX object CMakeFiles/cli.dir/input/y4m.cpp.obj
[ 78%] Building CXX object CMakeFiles/cli.dir/input/yuv.cpp.obj
[ 79%] Building CXX object CMakeFiles/cli.dir/input/lavf.cpp.obj
[ 80%] Building CXX object CMakeFiles/cli.dir/input/avs.cpp.obj
In file included from F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/avs.h:5,
from F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/avs.cpp:23:
F:/MABS/local32/include/avisynth/avisynth_c.h:786:39: warning: missing initializer for member 'AVS_Value::array_size' [-Wmissing-field-initializers]
786 | static const AVS_Value avs_void = {'v'};
| ^
F:/MABS/local32/include/avisynth/avisynth_c.h:786:39: warning: missing initializer for member 'AVS_Value::d' [-Wmissing-field-initializers]
[ 81%] Building CXX object CMakeFiles/cli.dir/input/vpy.cpp.obj
F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/vpy.cpp: In function 'void frameDoneCallback(void*, const VSFrameRef*, int, VSNodeRef*, const char*)':
F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/vpy.cpp:49:91: error: invalid conversion from 'void (*)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)' to 'VSFrameDoneCallback' {aka 'void (__attribute__((stdcall)) *)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)'} [-fpermissive]
49 | vpyCallbackData->vsapi->getFrameAsync(vpyCallbackData->requestedFrames, node, frameDoneCallback, vpyCallbackData);
| ^~~~~~~~~~~~~~~~~
| |
| void (*)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)
F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/vpy.cpp: In member function 'virtual void x265::VPYInput::startReader()':
F:/MABS/x265-Yuuki-Asuna-Asuna/source/input/vpy.cpp:268:39: error: invalid conversion from 'void (*)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)' to 'VSFrameDoneCallback' {aka 'void (__attribute__((stdcall)) *)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)'} [-fpermissive]
268 | vsapi->getFrameAsync(n, node, frameDoneCallback, &vpyCallbackData);
| ^~~~~~~~~~~~~~~~~
| |
| void (*)(void*, const VSFrameRef*, int, VSNodeRef*, const char*)

[DJATOM]

Configure project with -fpermissive cxx flag or edit conflicting signature manually.

[LigH]

Thanks @DJATOM.

@LoRd_MuldeR: x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/coaqv9vaawxm3fb/x265_3.4+13-g729a838d3+41_Asuna.7z/file) — no guarantees, check thoroughly!

[tormento]

If I feed x265 with a 16 bit stream from a SMDegrain source with n16=true, is it necessary to use --input-depth 16 or x265 can "understand" automatically the bit depth?

[cap5lock]

Thanks @DJATOM.

@LoRd_MuldeR: x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/coaqv9vaawxm3fb/x265_3.4+13-g729a838d3+41_Asuna.7z/file) — no guarantees, check thoroughly!

What are tune lists for asuna mod ?
I know --tune lp only

[benwaggoner]

If I feed x265 with a 16 bit stream from a SMDegrain source with n16=true, is it necessary to use --input-depth 16 or x265 can "understand" automatically the bit depth?
If you're using a yuv4mpegpipe, then the depth should be signaled by the pipe. But if a yuv pipe, you'll need to set all the parameters manually.

For doing 8-bit encoding from a higher depth source inside x265, it helps to use the --dither command to get better dithering. But there are better external dithering options than that as well. It probably would help a bit with 10-bit encoding, particularly if it is in HDR.

[LigH]

What are tune lists for asuna mod ?
I know --tune lp only

Run x265 --fullhelp and you will be told:
-t/--tune <string> Tune the settings for a particular type of source or situation:
(mid bitrate anime) littlepox/lp, (slower) littlepox++/lp++,
(high bitrate anime BD / film) vcb-s/vcbs, (slower) vcb-s++/vcbs++,
psnr, ssim, grain, zerolatency, fastdecode


The details (https://github.com/msg7086/x265-Yuuki-Asuna/blob/f9c3b2805f98ae6492528ef69e0cb745c3b9a684/source/common/param.cpp#L622) are a bit complex...

[Boulder]

If you're using a yuv4mpegpipe, then the depth should be signaled by the pipe. But if a yuv pipe, you'll need to set all the parameters manually.

For doing 8-bit encoding from a higher depth source inside x265, it helps to use the --dither command to get better dithering. But there are better external dithering options than that as well. It probably would help a bit with 10-bit encoding, particularly if it is in HDR.

If you process in 10 or 16 bits, it's much better to feed it as such to x265 and use --dither. x264 works internally in 16-bit land so x265 probably does as well.

[benwaggoner]

If you process in 10 or 16 bits, it's much better to feed it as such to x265 and use --dither. x264 works internally in 16-bit land so x265 probably does as well.
x265 always goes down to the native color depth before the frequency transform, so the net effect is identical with internal and external ditherers of the same algorithm.

[foxyshadis]

Run x265 --fullhelp and you will be told:
-t/--tune <string> Tune the settings for a particular type of source or situation:
(mid bitrate anime) littlepox/lp, (slower) littlepox++/lp++,
(high bitrate anime BD / film) vcb-s/vcbs, (slower) vcb-s++/vcbs++,
psnr, ssim, grain, zerolatency, fastdecode


The details (https://github.com/msg7086/x265-Yuuki-Asuna/blob/f9c3b2805f98ae6492528ef69e0cb745c3b9a684/source/common/param.cpp#L622) are a bit complex...

Half of these seem like options that should be based on the preset instead of the tune, but I guess if you're happy with them (basic tune being roughly medium-to-slow and ++ being roughly veryslow) then I guess that works. I would much rather see pure speed options be scaled based on the preset rather than flat overridden in the tune, though.

Adaptive SAO & strong intra smoothing would be such a dream, so they didn't have to be flat out disabled, but the companies with the resources to contribute aren't looking for that kind of absolute sharpness.

[benwaggoner]

Half of these seem like options that should be based on the preset instead of the tune, but I guess if you're happy with them (basic tune being roughly medium-to-slow and ++ being roughly veryslow) then I guess that works. I would much rather see pure speed options be scaled based on the preset rather than flat overridden in the tune, though.
Yeah, it should really be a 2D matrix of preset and tune for parameters, as the tradeoffs can be different at different speed points.

Adaptive SAO & strong intra smoothing would be such a dream, so they didn't have to be flat out disabled, but the companies with the resources to contribute aren't looking for that kind of absolute sharpness.
Also, the companies with the resource to contribute are likely to set exact parameters instead of relying on stock --preset and --tune.

[LoRd_MuldeR]

Thanks @DJATOM.

@LoRd_MuldeR: x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/coaqv9vaawxm3fb/x265_3.4+13-g729a838d3+41_Asuna.7z/file) — no guarantees, check thoroughly!

Thank you! However, your latest binary has dependencies to some shared libraries (DLL files) that are not included in the ZIP package:

https://i.imgur.com/OAOEXOH.png

Of course, it would be much preferable if you could link those statically. Also, the included "libx265.dll" is not actually needed, as far as I can tell.

[DJATOM]

Probably he should remove zlib files from msys and compile from sources, that way it will be linked statically. I've spent a night figuring that out when tried to compile ffms2 libs for x264 :'D

[LigH]

Of course, it would be much preferable if you could link those statically.

I am sorry, I have no clue how, I am no C/C++ developer. If anyone can tell me how to tweak the build scripts, I will do so, but I am not able to discover that on my own.

But it confuses me why it worked on my PC. Maybe I have other applications installed which have them in my PATH. Like GIMP. -- No, I tested only the x64 build, see below.

As I am bound to the environment m-ab-s uses, I can't install or uninstall libraries as I wish.

Also, the included "libx265.dll" is not actually needed, as far as I can tell.

True, they are not, input/output libraries linked are only a matter of the CLI executable.
_

PS:

These dependencies are only valid for the Win32 executables, not for the Win64?!... Just checked with "Dependency Walker".

I am not sure where it comes from. The x264 with the same ffmpeg-light libraries does not need them. Maybe I can discover if m-ab-s excludes them explicitly when building x264.

[LoRd_MuldeR]

I am sorry, I have no clue how, I am no C/C++ developer. If anyone can tell me how to tweak the build scripts, I will do so, but I am not able to discover that on my own.

Well, I think you first would have to figure out whether the libraries in question (libbz2-1 and liblzma-5) were built as part of your build process, or whether they shipped as "pre-built" libraries with your MinGW/GCC/MSYS.

As far as pre-built libraries are concerned, you will often find that two files, called "libfoo.a" (static library) and "libfoo.dll.a" (shared library), are provided. Alternatively, the naming convention "libfoo_static.a" (static library) and "libfoo.a" (shared library) may be used. Other naming convention exist. You'll have to look. Anyway, you will have to make sure that the "static" version of the pre-compiled library is linked into your binary, not the "shared" version.

(A rather "crude" method would be to just delete the "shared" library file from your LIB path and hope that the build script will then pick up the "static" one ;))

If, however, the pre-compiled library is provided only as a shared library, then the only solution would be to build that library yourself from now on - as a static library - instead of using the pre-compiled (shared) version.

But it confuses me why it worked on my PC. Maybe I have other applications installed which have them in my PATH. Like GIMP. -- No, I tested only the x64 build, see below.

There are quite a number of directories that Windows will search for DLL files at runtime. The directories that are listed in your PATH environment variable actually are the last ones to be searched:
https://docs.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications

Anyways, if you use a "proper" task manager, such as Process Explorer or Process Hacker, you can see all DLLs a process has loaded, with full path. So it would be trivial to figure out where the DLLs in question are located on your system.

[LigH]

I cloned the Asuna branch again, staying at commit 0b7a00d, applied the local fixes anew, compiled ... and the Win32 builds don't seem to need those libraries anymore. Miracles happen...

x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/kvyl9m9s17t7qze/x265_3.4+13-g729a838d3+41_Asuna.7z/file) – 3rd attempt: Win32, Win32XP, Win64 only EXE

[LoRd_MuldeR]

I cloned the Asuna branch again, staying at commit 0b7a00d, applied the local fixes anew, compiled ... and the Win32 builds don't seem to need those libraries anymore. Miracles happen...

x265 3.4+13-g729a838d3+41 (Asuna) (https://www.mediafire.com/file/kvyl9m9s17t7qze/x265_3.4+13-g729a838d3+41_Asuna.7z/file) – 3rd attempt: Win32, Win32XP, Win64 only EXE

:thanks:

[stax76]

Does it support --reader-options library from aMod?

[LigH]

I don't find that string in the EXE. But DJATOM works together with msg7086, they will know that much better than me...

[MeteorRain]

No. We are developing (kinda) individually. Although some patches were transplanted, they are not identical. Only some patches are copied to the other side.
Please do not expect it to support everything in aMod, and vice versa.

[stax76]

DJATOM has been very responsive to the staxrip community. Maybe create a GitHub organization encoder-mod and work together, otherwise staxrip will support different code paths based on the version name looking for the keywords aMod and Asuna.

[DJATOM]

I think it's better to leave things as is.
Just detect user-supplied binary's mod/version and use different feature set for it. Or discard if binary lacks functionality...

[DJATOM]

Also you can ask Pat to make StaxRip edition, merging and unifying from both worlds :)