Support for dynamic AVX2 dispatch to avoid SIGILL on non-AVX2 CPUs

[Laky-64]

Hi,

I'd like to ask whether there is any plan or known way to support dynamic dispatch of AVX2 code paths in OpenH264.

Currently, when OpenH264 is built with "HAVE_AVX2", it seems that AVX2 instructions are embedded directly into the binary. As a result, attempting to load or use the library on CPUs that do not support AVX2 results in an illegal instruction crash (SIGILL), even if the code that uses AVX2 is not explicitly executed.

I’ve noticed that OpenH264 already includes runtime CPU feature detection via WelsCPUFeatureDetect, which correctly detects AVX2 availability. However, this doesn’t prevent issues when AVX2 instructions are present in the binary and accidentally executed (e.g., via function pointer assignment, or even indirectly).

Would it be possible to refactor the AVX2-accelerated paths into separate functions and use a runtime dispatch mechanism, similar to how some libraries (e.g., x264, libjpeg-turbo, or libvpx) manage this?

This would allow:

Building one universal .so (or .dll) with all SIMD variants included.

Avoiding SIGILL crashes on older CPUs.

Keeping high performance where supported.

Logs

0x00007fffe4b0b3b9 in WelsLog(TagLogContext*, int, char const*, ...) () from /home/laky64/CLionProjects/ntgcalls/tests/venv/lib64/python3.13/site-packages/ntgcalls.cpython-313-x86_64-linux-gnu.so
(gdb) bt
#0  0x00007fffe4b0b3b9 in WelsLog(TagLogContext*, int, char const*, ...) () from /home/laky64/CLionProjects/ntgcalls/tests/venv/lib64/python3.13/site-packages/ntgcalls.cpython-313-x86_64-linux-gnu.so
#1  0x00007fffe4b08d54 in WelsEnc::CWelsH264SVCEncoder::InitializeExt(TagEncParamExt const*) () from /home/laky64/CLionProjects/ntgcalls/tests/venv/lib64/python3.13/site-packages/ntgcalls.cpython-313-x86_64-linux-gnu.so