Kostya, a longtime FFmpeg contributor, writes about video codecs, FFmpeg history, and his views on Rust, C and other programming languages.
Commenters point to it for FFmpeg history and his Rust-based NihAV project, though one finds the blog hard to follow.
>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.
Kostya fanned the flames https://codecs.multimedia.cx/2011/10/why-ffmpeg-is-better-than-libav-by-numbers-but-not-in-reality/ 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.
>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/
> 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
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
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.