You absolutely correct, it's indeed inspired by Keyj`s minimp3. Float-point used because it's hard do with 4-byte fixed-point type and achieve ISO conformance. We must to use different dynamic ranges for different parts of decoder (i.e. emulate own floating point) or more than 4-byte fixed-point type. Only float-point support is needed, SSE/NEON intrinsics is not required and can be fully disabled by MINIMP3_NO_SIMD.

Encoders usually harder, because, for example, you can't verify it using reference vectors (there no exact reference to compare with). Also encoders like h264 contains big part of decoder as well, because it must reconstruct encoded frame internally for motion compensation.

It's also single core comparison. Multi-threaded encoding is supported too: with 4 threads I get 0,190s for minih264 and 0,135s for x264.

https://github.com/cisco/openh264 can do both encode/decode.

It has very limited support for H264 advanced profiles that are usually used, which is a down side. I was honestly surprised about the lack of a good decode library.

Isn't ffmpeg's libavcodec a good decoding library?

There already defines to include\exclude features: H264E_MAX_THREADS=n, H264E_SVC_API=1, MINIH264_ONLY_SIMD. Complete documentation still in progress and subject to change. For now only comments in minih264e.h and minih264e_test.c can tell how to use it.

Cool, thank you for replying, I appreciate that.

Yes, It's already been used on STM32F407 and ESP32.

I've add screenshot of first intra frame and x264.264 to compare in players.