Codec Multimedia Blog
codecs.multimedia.cx · Personal blog · on HN since 2015
Kostya, a longtime FFmpeg contributor, writes about video codecs, FFmpeg history, and his views on Rust, C and other programming languages.
What HN saysCommenters point to it for FFmpeg history and his Rust-based NihAV project, though one finds the blog hard to follow.
20HN people shared it
9linked it in comments
23stories submitted
693story points
10 months agolast shared
2015people per year2026
Most-shared posts
- 1Ffhistory: Fabrice Bellard3 people · 4 points · first shared 2022 · discussion on HN
- 2Why I am sceptical about AV13 people · 4 points · first shared 2018 · discussion on HN
- 3A History of the FFmpeg Project2 people · 2 points · first shared 2023 · discussion on HN
- 4Post 3392 people · first shared 2015
- 5Homepage2 people · first shared 2020
- 6Rust: Not So Great For Codec Implementing1 people · 215 points · first shared 2017 · 278 comments on HN
- 7Looking at Zig Programming Language1 people · 181 points · first shared 2022 · 74 comments on HN
- 8I still like C and strongly dislike C++1 people · 164 points · first shared 2021 · 165 comments on HN
- 9My Rust experience after eight years1 people · 57 points · first shared 2025 · 50 comments on HN
- 10Why Rust is not a mature programming language1 people · 40 points · first shared 2020 · 70 comments on HN
- 11Why I’m not excited about RISC-V1 people · 6 points · first shared 2022 · 4 comments on HN
- 12Visiting Multimedia Grave1 people · 3 points · first shared 2022 · 1 comments on HN
- 13Winamp recent code release includes VP5 and VP6 codecs source code1 people · 3 points · first shared 2024 · discussion on HN
- 14H.264 Specification Sucks1 people · 2 points · first shared 2020 · discussion on HN
- 15The sorry state of open source multimedia1 people · 2 points · first shared 2024 · discussion on HN
What HN people wrote when they linked it
mappu · 2020-06-19
Kostya (long time ffmpeg contributor from e.g. RV40 reverse engineering) moved on to writing a greenfield ffmpeg alternative purely in Rust, with all new codecs, named NihAV.
Follow the blog: https://codecs.multimedia.cx/ but there's no source code release yet AFAIK.
lsofzz · 2020-06-19
> Follow the blog: https://codecs.multimedia.cx/ but there's no source code release yet AFAIK.
Nice; though the documentation/blog is quite hard to follow :)
jordigh · 2016-02-15
> This is mostly a political issue.
Let us not forget the reasons for libav. The ffmpeg development process was having a lot of problems due to very controversial decisions that its lead dev was taking. The libav fork has resulted in a restructuring of the ffmpeg development workflow. In this regard, libav is about as important as egcs was to gcc.
Further reading:
http://codecs.multimedia.cx/?p=339
ftomassetti · 2015-08-01
Just to add context: this is a post from a person involved in the project since 2004. It is a bit bitter but I found it interesting to read ("What happened to FFmpeg" by Kostya)
http://codecs.multimedia.cx/?p=339
averne_ · 2025-12-24
Not really. https://codecs.multimedia.cx/2022/12/ffhistory-fabrice-bellard/
>Fabrice won International Obfuscated C Code Contest three times and you need a certain mindset to create code like that—which creeps into your other work. So despite his implementation of FFmpeg was fast-working, it was not very nice to debug or refactor, especially if you’re not Fabrice
hitekker · 2025-11-03
Kostya fanned the flames https://codecs.multimedia.cx/2011/10/why-ffmpeg-is-better-than-libav-b… As for "his" ownership, I think LibAV was a failure each team member should own and comes to terms with.
That's my point and also why I won't dig more. The author hasn't come to terms with his bad experience with ffmpeg, in LibAV or otherwise. Whatever the baggage is, it feels quite messy and heavy. It weighs down the article, with too much bitterness and resentment. That could work for self-therapy, less so for a credible account. As he confesses at the end:
> I wrote this post with an ulterior motive—I don’t want to feel shame when remembering that I took part in that project. So far though the more I hear about it the more disgusted I become.
luispauloml · 2023-04-16
You can this series of blog posts by one of key people involved in FFmepg: https://codecs.multimedia.cx/category/cempeg/ffhistory/
This was discussed here too: https://news.ycombinator.com/item?id=34555465
ksec · 2020-03-14
>Hardware support from vendors has been a key consideration from the inception of the AV1 project.
If that was the case AV1 spec version 1.0 would not have been postponed multiple times simply because the spec did not had any hardware decoder cost / performance in mind. And then there was the errata to version 1.0 which makes it incompatible to AV1 1.0. [1] Those vendors being a member of AOM means literally just a member only. They may or may not share any common interest.
[1] https://codecs.multimedia.cx/2018/12/why-i-am-sceptical-about-av1/
motbob · 2019-06-10
>Company, which has every reason to exaggerate, claims it can improve encoding speed by 32.2% against x265 veryslow
"It’ll be interesting to see if we find out more info and are able to test this encoder in the coming months."
>BBC, which has no skin in the game, claims AV1 is less efficient than HEVC
"I would call this test flawed as AV1 has consistently shown to perform better than HEVC."
Every article on AV1 that I have read is like this, except for https://codecs.multimedia.cx/2018/12/why-i-am-sceptical-about-av1/ -- they are always blatantly cheerleading new advancements, like only being 5x slower to decode than VP9 or 10x slower to encode than x265 or whatever. But the advancements are not phrased like that, of course--you are never reminded that the competition continues to clobber AV1 in every aspect but filesize/quality efficiency.