buddy_alloc VS rav1e

If you need a sub-allocator with predictable performance feel free to give it a try. The code is here and it is licensed under the 0BSD license, making it as lax and as close to public domain as possible. Comments, issues and PRs are always welcomed and appreciated. Thanks!

I maintain a project that's not technically MISRA compliant (due to being a memory allocator and MISRA disallowing the very idea) and I keep it at 100% test coverage with support for multiple compilers and operating systems. Over time I had a few users reporting back - since it's working for them I count that as success. Is it wildly popular ? Of course not, but it doesn't have to be.

You are right about the tests - they are written with 64-bit in mind. I ought to rework them to switch sizes based on arch but that will take a weekend. I've filed https://github.com/spaskalev/buddy_alloc/issues/19 to track this.

I also maintain a application-based malloc (that doesn't do obtaining and releasing memory through the OS, just managing sub-diving a larger memory block into smaller requests) at https://github.com/spaskalev/buddy_alloc - feel free to ping me with any questions about it.

I'm the author of https://github.com/spaskalev/buddy_alloc - a custom memory allocator for C (modern C11, works with C++ as well) designed for predictable and repeatable performance. It is suitable for use in embedded, games and any other system with soft or hard real-time demands. It has 100% line and branch test coverage and uses a fixed amount of space on the call stack when called. Recently the project had its first external contribution as well. Cheers!

I made a memory allocator that turned out rather neat - https://github.com/spaskalev/buddy_alloc

Sure. You'll see it very often in codec implementations. From rav1e, a fast AV1 encoder mostly written in Rust: https://github.com/xiph/rav1e/tree/master/src/x86

Large portions of the algorithm have been translated into assembly for ARM and x86. Shaving even a couple percent off something like motion compensation search will add up to meaningful gains.

Or the current reference implementation of JPEG: https://github.com/libjpeg-turbo/libjpeg-turbo/tree/main/sim...

Again, if anything AOM would be the one restricting licenses to AV1 (if they chose to) except AOM has stated and also published AV1 in a way to allow license free access to development (which allows people to make forks of the official build like it's open source) and usage. (1)(2) I don't see why they would suddenly change this.

You can speed up the sampling process with --vmaf n_subsample=5, which in my experience works more accurately than either 2 or 4, possibly due to this bug/feature present in multiple encoders. You might also need to manually set the number of threads used for VMAF calculation with --vmaf n_threads=16, but YMMV.

That remember me of https://github.com/xiph/rav1e which is an AV1 encoder

I put in the request for ffmpeg passthrough mastering-display data a few years ago and haven't heard of any support yet.

It's getting there.. Initial steps for FFmepg: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8444 rav1e: https://github.com/xiph/rav1e/pull/3000

It's entirely possible to re-use bits of other HW encoders for the first pass (motion estimation, etc).