16 ms·

Minih264 – Minimalistic, single-header library for encoding H264/SVC

131 points by lieff 8y ago

mratsim 8y ago
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.
- danmg 8y ago
  That's most DSP code. Take a look at FFTW or SOKit.
- lieff 8y ago
  I've add screenshot of first intra frame and x264.264 to compare in players.
- vardump 8y ago
  > The only grip I have is the 13k lines of C + intrinsics. How are you supposed to get acceptable performance without intrinsics?
  - userbinator 8y ago
    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.
    - lieff 8y ago
      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.
deleted 8y ago
[deleted]
microcolonel 8y ago
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).
userbinator 8y ago
Wow. The MP3 decoder that just appeared on HN ( https://news.ycombinator.com/item?id=18046114 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.
- 01100011 8y ago
  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.
  - userbinator 8y ago
    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/ https://cardinalpeak.com/blog/worlds-smallest-h-264-encoder/ However, minih264 may currently be the smallest encoder that does compress.
bloopernova 8y ago
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?
- lieff 8y ago
  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.
  - bloopernova 8y ago
    Cool, thank you for replying, I appreciate that.
apocalypses 8y ago
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?
- lieff 8y ago
  https://github.com/cisco/openh264 https://github.com/cisco/openh264 can do both encode/decode.
  - Game_Ender 8y ago
    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.
    - stepik777 8y ago
      Isn't ffmpeg's libavcodec a good decoding library?
- stepik777 8y ago
  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.
rjeli 8y ago
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.
disqard 8y ago
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!
- userbinator 8y ago
  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 http://forum.doom9.org/showthread.php?t=171375 There is also this rather amusing "4k remake": https://www.youtube.com/watch?v=pjA-YW71ZOg https://www.youtube.com/watch?v=pjA-YW71ZOg
  - disqard 8y ago
    Thanks for taking the time to reply, and I got a good chuckle out of the 4k "remake" :)

131 points by lieff 8y ago

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.

danmg 8y ago
That's most DSP code. Take a look at FFTW or SOKit.
lieff 8y ago
I've add screenshot of first intra frame and x264.264 to compare in players.
vardump 8y ago
> The only grip I have is the 13k lines of C + intrinsics. How are you supposed to get acceptable performance without intrinsics?
- userbinator 8y ago
  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.
  - lieff 8y ago
    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.

deleted 8y ago

[deleted]

microcolonel 8y ago

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).

userbinator 8y ago

Wow. The MP3 decoder that just appeared on HN ( https://news.ycombinator.com/item?id=18046114 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.

01100011 8y ago
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.
- userbinator 8y ago
  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/ https://cardinalpeak.com/blog/worlds-smallest-h-264-encoder/ However, minih264 may currently be the smallest encoder that does compress.

bloopernova 8y ago

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?

lieff 8y ago
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.
- bloopernova 8y ago
  Cool, thank you for replying, I appreciate that.

apocalypses 8y ago

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?

lieff 8y ago
https://github.com/cisco/openh264 https://github.com/cisco/openh264 can do both encode/decode.
- Game_Ender 8y ago
  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.
  - stepik777 8y ago
    Isn't ffmpeg's libavcodec a good decoding library?
stepik777 8y ago
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.

rjeli 8y ago

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.

disqard 8y ago

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!

userbinator 8y ago
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 http://forum.doom9.org/showthread.php?t=171375 There is also this rather amusing "4k remake": https://www.youtube.com/watch?v=pjA-YW71ZOg https://www.youtube.com/watch?v=pjA-YW71ZOg
- disqard 8y ago
  Thanks for taking the time to reply, and I got a good chuckle out of the 4k "remake" :)