- 107comments
- 103comments
- 83comments
- 64comments
- 435comments
- 72comments
- 17comments
- 49comments
- 285comments
- 18comments
- 338comments
- 39comments
- 81comments
- 15comments
- 32comments
- 92comments
- 6comments
- 2comments
- 106comments
- 267comments
- 4comments
- 1comments
- 89comments
- 73comments
- —discuss
- 54comments
- 1comments
- 13comments
- 72comments
- 100comments
Very impressive, kudos. I'd like screenshots rather than PSNR and SSIM because those don't translate into human perception of a good encode.
The only grip I have is the 13k lines of C + intrinsics.
That's most DSP code. Take a look at FFTW or SOKit.
I've add screenshot of first intra frame and x264.264 to compare in players.
How are you supposed to get acceptable performance without intrinsics?
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.
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.
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).
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.
Encoding can work however you like. The important thing is that the output complies with the standard.
It's nice to have a reference implementation, but it's not like that's the only way it can be done.
The important thing is that the output complies with the standard.
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:
https://cardinalpeak.com/blog/worlds-smallest-h-264-encoder/
However, minih264 may currently be the smallest encoder that does compress.
Nice job!
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.
Cool, thank you for replying, I appreciate that.
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?
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?
Unless you cannot use GPL, I suggest to use x264 for encoding. It is simply the best there is. There is nothing similar to it.
Very impressive. Nice work!
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!
Good question. It's certainly not as famous as Lena. Unfortunately I don't have an answer, but found others looking for one: http://forum.doom9.org/showthread.php?t=171375
There is also this rather amusing "4k remake":
https://www.youtube.com/watch?v=pjA-YW71ZOg
Thanks for taking the time to reply, and I got a good chuckle out of the 4k "remake" :)