FFmpeg纪传体通史（2）：Michael Niedermayer

谷谷小师妹

FFmpeg纪传体通史（2）：Michael Niedermayer
作者：Kostya Shishkov本系列文章征得作者同意后翻译。
译者注：作者对Michael Niedermayer意见很大，请酌情阅读


And now is finally the time when we should discuss the man who made FFmpeg into what it is today: large, successful and toxic mess. The man who was the project leader for a long time and definitely-not-project-leader since. Of course I’m talking about Michael Niedermayer.

终于，是时候讨论那个人了，他把FFmpeg变成今天这样子：大型的，成功的，也是混乱不堪的项目。很长一段时间，他担任项目的领导者，如今早已卸任。那个人就是Michael Niedermayer。

From what I can gather, he started as yet another MPlayer developer adding crucial bits to it, namely the library for video output postprocessing (deblocking, deinterlacing and such) and the infamous libswscale for image format conversion and rescaling that grew out of it. There he got interested in FFmpeg, started to contribute various fixed and optimisations to it and eventually Fabrice left the project to him.

据我所知，他起初是MPlayer的开发者之一，为其添加了一些关键的部分，即视频输出后处理的库（去块效应，反交错等），以及由此产生的臭名昭著的图像格式转换和缩放的libswscale。在那里，他对FFmpeg产生了兴趣，开始为其贡献各种修复和优化，最终Fabrice把项目交给了他。译者注：社区正着手清理libswscale。

Unlike the rest of people, he dedicated all of himself to the work. Few people met him in person as he never goes to any conferences, at least back in the day he lived at the minimum income in order not to waste time on other work.

与其他人不同，他全身心地投入到工作中。他从不参加任何会议，所以很少有人亲自见过他，至少在过去，他以最低的收入生活，以免浪费时间在其他工作上。

How do I know that bit? I was involved in libswscale relicensing to LGPL and splitting the reward for doing that afterwards with several other people; boy, was it a mess for Diego (who handled the official financial part).

我是怎么知道这一点的？我参与了将libswscale重新授权为LGPL协议，并与其他几个人分享了对应的奖励；对于处理官方财务部分的Diego来说，这真是一团糟。

So what has he done to the project in all this years:

这些年来，他对项目的贡献包括：

• improving the speed of decoding and encoding by introducing countless new x86-specific optimisations and overall tweaking of C code;
• 通过引入无数新的针对x86的优化和对C代码的整体调整，提高了解码和编码的速度；
• extending the amount of H.263 (or MPEG-4 part 2) based codecs supported, both for decoding and encoding;
• 扩展了对基于H.263（或MPEG-4 part 2）的编解码器的支持，包括解码和编码；
• implementing support for other formats (especially H.264);
• 实现了对其他格式（尤其是H.264）的支持；
• inventing new formats himself (like FFV1 or Snow);
• 自己发明了新的格式（如FFV1或Snow）；
• adding crucial components (like replacing rather rudimentary imgconvert with libswscale and allowing it to be re-licensed under LGPL later);
• 添加了关键的组件（如用libswscale替换了相当初级的imgconvert，并允许它后来在LGPL下重新授权）；
• a lot of testing, bugfixing and mitigating security issues;
• 大量的测试，修复bug和缓解安全问题；
• and overall leadership of course.
• 当然还有领导整个项目。
  

What’s there not to like? Let’s see:
有什么不讨人喜欢的呢？让我们看看：

• tweaking C code for optimal performance is fine only until the next version of compiler decides it’s an undefined behaviour now (I remember this being an issue with pointer aliasing but there were more);
• 为了最佳性能调整C代码，结果引入了未定义行为出现在新版本编译器中（我记得这是指针别名的问题，但还有更多）；
• having a lot of codecs if definitely good but trying to fit almost all video codecs into the same framework designed only for the H.263 likes is not. Mentioning MpegEncContext still makes some people shudder;
• 拥有大量的编解码器肯定是好的，但试图将几乎所有的视频编解码器都塞进只为H.263等设计的同一框架则不是。提到MpegEncContext仍会让一些人感到不安；
• pushing your own toys into a widely-used library is a dubious move. FFV1 proved out to be an excellent lossless video codec but Snow is a failed experiment that was competitive in DivX times but went irrelevant when x264 appeared;
• 将你自己的玩具项目塞进广泛使用的库是一个值得怀疑的举动。FFV1被证明是一个优秀的无损视频编解码器，但Snow是一个失败的实验，在DivX时代具有竞争力，但在x264出现后就变得无关紧要了；
• coding style (more about it below);
• 编码风格（下面会有更多介绍）；
• and overall project decisions that led to the project split among other things (more about it below as well).
• 以及导致项目分裂等问题的整体项目决策（下面也会有更多介绍）。
  

A small rant about coding style. I can’t claim that Niedermayer wrote outright bad code but I can’t say he wrote code that was easy to maintain.

关于编码风格的一点小抱怨。我不能说Niedermayer写的是彻头彻尾的糟糕代码，但我也不能说他写的代码易于维护。

As in MpegEncContext mentioned above—initially it was the context for both decoding and encoding all those “8×8 DCT in 16×16 macroblock” formats but Michael kept using it for the codecs where it made less sense (like H.264) and all different codec flavours were handled inside the single file using extremely complex conditions and obscure context variables.

就像上面提到的MpegEncContext——最初它是解码和编码所有那些“8×8 DCT in 16×16 macroblock”格式的上下文，但Michael一直用它实现那些不太适用的编解码格式（如H.264），以及所有不同的编解码器都在单个文件中使用极其复杂的条件和晦涩的上下文变量进行处理。

And of course all of those variables were stored in one extremely large context (no points for guessing the name). It took years of refactoring to make it somewhat saner and understandable. If you argue that the code was perfect as is, I should point out that it had to be modified later in order to handle various standard extensions like YUV422 or 10-bit video and it was not a trivial thing to do.

当然，所有这些变量都存储在一个极大的上下文中（猜对名字没有奖励）。经过多年的重构，才使其变得稍微合理可读。如果你认为代码本身就是完美的，我应该指出，为了处理各种标准扩展，如YUV422或10-bit视频，必须进行修改，这并不是一件容易做到的事情。

And while we’re speaking about his technical decisions, beside creating impenetrable code monoliths he is also responsible for introducing various “fixes” for the very specific cases nobody has encountered (I understand the desire to support all more or less valid streams but you should draw a line somewhere instead of adding a hack for each sample somebody asked you to support in private).

在我们谈论他的技术决策时，除了创建无法剖析的代码单体外，他还负责引入各种针对没有人遇到过的非常特殊情况的“修复”（我理解支持所有或多或少有效的流的愿望，但你应该在某个地方划一条线，而不是为每个人私下要求你支持的媒体文件添加一个hack）。译者注：要兼容，但也要有个底线。我与Michael 讨论过这一问题，无底线兼容导致维护困难。例如，因为他强行纠正某些错误文件信息（mp4中的创作时间），导致正常的文件信息解析出错。

And the thing directly related to this: automagic guesstimation. The best example of it the infamous compute_pkt_fields() which tried to fill timestamps and duration properties of a packet. For the sane streams it was not needed at all and for the broken ones it functioned on GIGO principle, so not surprisingly there were complaints about it all the time.

与此直接相关的事情是：（处理媒体流时）自行推断。最好的例子是臭名昭著的compute_pkt_fields()，它试图填充数据包的时间戳和持续时间属性。对于正常的流，它根本不需要，对于损坏的流，它遵循GIGO（输入垃圾，输出垃圾）原则，所以毫不奇怪，总是有人对此抱怨。

And now finally a rant about leadership. Sometimes I wonder if it’s because he comes from a country with a **** and a **** on its coat of arms but his management way reminds me of a typical s**** country: selective application of rules, extreme conservatism and voting used to evade responsibility while ensuring the desired outcome.

现在，最后来抱怨一下领导力。有时我想知道，是不是因为他来自一个国徽上有**和**的国家，他的管理方式让我想起了典型的****国家：选择性地应用规则，极端的保守主义，以及用投票来逃避责任，同时确保期望的结果。

What do I mean by selective application of rules? Just doing what would make other people get their commit rights suspended (I think Måns actually did that once after his post-commit reviews had no effect on Michael). I suspect that “Michael Niedermayer (and Carl Eugen Hoyos to some extent) can do whatever he wants” is still an unwritten but accepted rule in jbmpeg let alone previous iterations of the project.

我说的选择性应用规则是什么意思？就是（Michael自己违反规则）做那些会让其他人被暂停提交权的事情（我想Måns实际上做过一次（暂停了Michael的代码提交权限），当他发现Michael忽视他的post-commit patch review意见）。我怀疑即使在现在这个时期，“Michael Niedermayer（以及在某种程度上的Carl Eugen Hoyos）可以做他想做的任何事”仍是一条不成文的规定，更别说担任项目领导人的时期。译者注：夸张了，Michael 也不能为所欲为。

What do I mean by extreme conservatism? Mostly feature hoarding: you may add a new feature, extend an already existing one but never to remove any.

我所说的极端保守主义是什么意思呢？主要是特性囤积：你可以添加一个新的特性，扩展一个已经存在的特性，但永远不要移除任何特性。

The extreme example of it would be libpostproc: this library had never been used by FFmpeg itself but when finally Derek tried to move it into stand-alone repository Michael added a special filter just to keep it inside.

最极端的例子就是libpostproc：这个库从未被FFmpeg本身使用过，但当Derek最终试图将它移动到独立的仓库时，Michael添加了一个特殊的过滤器，只是为了将它保留在内部。

There’s Sonic—a lossless audio codec based on Bonk that has never been working good (or used by anybody). libswscale replacement never happening because the alternatives do not have the most important feature—runtime-generated MMX scaler.

还有Sonic——一个基于Bonk的无损音频编解码器，它从未工作良好（或被任何人使用过）。libswscale的替代品从未出现，因为替代品没有最重要的特性——运行时生成的MMX scaler。

The few things that were removed after all (like ffserver) were done as the result of fierce battles against Michael.

最后被移除的少数几个东西（比如ffserver）是与Michael激烈斗争的结果。

Or as a lighter example, he was always against moving to Git so it happened only after the third attempt and right before the split (fun fact: IIRC during the second attempt some guy called Linus Torvalds sent a mail in support of the move).

或者举一个轻松的例子，他一直反对转移到Git，所以这只在第三次尝试和分裂前夕才发生（有趣的事实：我记得在第二次尝试时，有个叫Linus Torvalds的家伙发了一封支持转移（到git）的邮件）。

And what did he usually do when some concrete decision was needed? He usually resorted to “let everybody with SVN commit access to mplayerhq.hu vote” which meant some people who were not contributing to FFmpeg had a say while people who sent patches but were not granted commit rights were excluded.

当需要做出一些具体的决定时，他通常会做什么呢？他通常会采取“让所有有SVN提交权限到mplayerhq.hu的人投票”的方式，这意味着一些没有为FFmpeg做出贡献的人有发言权，而那些提交了补丁但没有被授予提交权限的人则被排除在外。

Of course there were people disagreeing with such behaviour and they tried to reform the project—resulting in the infamous split. And what do you know, during the initial talks between two groups of the developers Michael invited MPlayer-only developers again.

当然，有人不同意这种行为，他们试图改革这个项目——结果导致了臭名昭著的分裂。你知道吗，在两组开发者的初次谈话中，Michael再次邀请了只有MPlayer开发者。

During the CEmpeg war against libav his behaviour was far from perfect. I can find badmouthing and changing project name in the files “because it existed before libav” a bit childish yet inoffensive but not the other things.

在与libav的CEmpeg战争中，他的行为远非完美。我发现他在文件中诋毁和更改项目名称“因为它在libav之前就存在”有点幼稚但无害，但其他事情就不是这样了。

For instance, poaching. I conducted an experiment once: took Derek’s name, translated it into German and committed some Indeo-related patches using this pseudonym to libav mailing list. Even before they were reviewed there I got a message from Michael that he committed them to FFmpeg and I should send them there instead.

例如，挖人。我曾经做过一个实验：取Derek的名字，将其翻译成德语，并使用这个假名提交了一些与Indeo相关的补丁到libav的邮件列表。甚至在那里被review之前，我就收到了Michael的消息，他说他已经将它们提交给了FFmpeg，我应该将它们发送到那里。

And there was a case with sound conversion library. Apparently he and Justin Ruggles worked jointly on the design (so it could be used by the both projects) but then for some reason Michael released his version under libswresample name instead (I heard claims that a certain corporation asked him to do that). Unrelated sad thing: the same happened to ProRes decoder but it was Maxim Poliakovski and Baptiste Coudurier involved there.

还有一个与声音转换库相关的案例。显然，他和Justin Ruggles共同设计了这个库（所以它可以被两个项目使用），但出于某种原因，Michael却以libswresample的名字发布了他的版本（我听说有人声称是某个公司要求他这么做的）。一个无关的悲伤的事情：ProRes解码器也发生了同样的事情，但涉及到的是Maxim Poliakovski和Baptiste Coudurier。

Overall, I believe Michael Niedermayer was an extremely useful man for the project until probably 2010 when his flaws and shifting norms in project development made him rather a detriment.

总的来说，我认为Michael Niedermayer在2010年之前对项目非常有用，但当他的缺点和项目开发中的多重标准使他变得相当有害时，他的价值就大打折扣了。

The harsh split in 2011 made him rethink some of his former decisions and embrace things he previously denied (like releases). Yet it made him shift from a developer who works on great stuff to somebody who mostly does janitorial work (namely fixing various issues reported by the fuzzer).

2011年的激烈分裂使他重新思考了一些以前的决定，并接受了他以前否认的事情（比如发布）。然而，这使他从一个致力于伟大事业的开发者变成了一个主要做杂务工作的人（即修复fuzzer报告的各种问题）。

I’d say his last greatest work was H.264 decoder and his last substantial piece of work was libswresample and I don’t expect anything neither from him nor from jbmpeg in general.

我会说他最后的伟大作品是H.264解码器，他最后的实质性工作是libswresample，我不期待他或者jbmpeg总体上会有什么新的贡献。

P.S. Now with the two prominent figures described it’s time to talk about all the lesser-known people who actually made FFmpeg a great project, from Alex Beregszaszi to Vladimir Voroshilov, from Luca Abeni to Zdenek Kabelac, from Diego Biurrun to Benjamin Zores. Not all of them will be described in great details but I hope to give at least a passing mention.

附言：现在，已经描述了两位杰出的人物，是时候谈谈那些实际上使FFmpeg成为一个伟大项目的鲜为人知的人们，从Alex Beregszaszi到Vladimir Voroshilov，从Luca Abeni到Zdenek Kabelac，从Diego Biurrun到Benjamin Zores。他们中的不是所有人都会被详细描述，但我希望至少能提及一下。

原文：https://codecs.multimedia.cx/202 ... ichael-niedermayer/