Wow. The MP3 decoder that just appeared on HN ( https://news.ycombinator.com/item?id=18046114 ) is impressive enough, this is even more amazing --- especially given the fact that the standard doesn't detail how encoding works, only decoding.
The fact that a single person can write a working H.264 encoder is very inspirational, in the same way as tiny C compilers and the like --- writing software which is commonly thought of as being impossible for a single person to accomplish in a reasonable amount of time really gives a better idea of the actual minimal complexity to those studying such software.
Especially if it's meant to be an educational and in any case non-realtime encoder, intrinsics are not really necessary and make the code less portable.
I also wonder how much the compiler can do autovectorisation on code like this --- it's pretty much exactly the type of code that autovectorisation is intended for.
Edit: I noticed in the benchmark that it compressed the 10s foreman.cif (demo video) in half a second, so it's already 20x faster than realtime on that small resolution.
I found this very interesting, particular the comparison to x264 (which I had never heard of).
Looking into it I found x264 looked really easy to use with a nice C api but was encode only - does anyone know of a library very similar to x264 which is 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.
Please forgive my poor understanding of C, but is it possible to add the missing features as extra options/files/headers so you can pick and choose which features you want to enable and/or include?
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.
I’ve been learning a lot about h264 and h265 recently, and I’ve read that hevc is somewhat more straightforward to decode. Is that true? I might try writing a decoder for it.
Apologies for the OT question, but does anybody know why the foreman video clip is used as a standard test sequence for video encoding? Thanks in advance!
These types of encoders are very useful, and I hope to see something in this style emerge for AV1 (an encoder which produces reasonable quality in real time on commodity CPUs, using the appropriate subset of bitstream tools for that job).
The fact that a single person can write a working H.264 encoder is very inspirational, in the same way as tiny C compilers and the like --- writing software which is commonly thought of as being impossible for a single person to accomplish in a reasonable amount of time really gives a better idea of the actual minimal complexity to those studying such software.