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.
It's nice to have a reference implementation, but it's not like that's the only way it can be done.
That's a good point --- you can write an H.264 encoder that doesn't compress at all, and as expected, the amount of code to do so is quite small:
However, minih264 may currently be the smallest encoder that does compress.
The only grip I have is the 13k lines of C + intrinsics.
How are you supposed to get acceptable performance without intrinsics?
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.
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?
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?
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.
There is also this rather amusing "4k remake":