
FFmpeg's future and resigning as leader - ux
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/176489.html
======
brokentone
I don't know the extent of the drama, but I have used FFMpeg a decent amount
and it's been a lifesaver. I know that OSS leaders are extremely under
appreciated, and I'd like to thank Michael for all of his efforts doing so.

~~~
jbk
> I don't know the extent of the drama

As a heavy user of FFmpeg/libav, for VLC (I'm the VideoLAN president), the
drama has been huge, and more aggressive than most forks we've seen in the
open source community.

Most of the information you find online is biased, wrong or down-right lying,
including the usual blogposts that are quoted from one side or the other one.
(like the pkh.me pasted or the Debian wiki one)

Whose fault is it? Well, it's a bit complex to answer, and there has been very
dick moves from both sides. Especially since the beginning of the story
started in private and was not reported publicly.

Who is doing more work between the forks? That's also very hard to answer,
because most of the libavcodec and libavformat work has been done in libav,
but most of the libavfilter, ffmpeg and tools work has been done in FFmpeg.

What you should know is that the current codebase of FFmpeg is messier
compared to libav, but has quite a few more features, notably filters and more
formats supported.

Choosing one or the other gives you different set of features, but mostly
different set of bugs and level of support of codecs. It's a big mess...

~~~
emcrazyone
" FFmpeg is a huge mess compared to libav"

I assume this is an unbiased opinion as much as it can be but could you
elaborate on what about FFmpeg is a "mess."

I've used both these libraries in building MythTV from strictly a user
perspective. Both code bases are open source. I'm wondering if there is so
much turmoil here, why doesn't someone (like VLC) take the best features from
both projects and create their own library?

I never understood the OSS communities. It just seems simple to me. If you
don't like it, fork it and do your own.

<shrug>

~~~
jbk
> I assume this is an unbiased opinion as much as it can be but could you
> elaborate on what about FFmpeg is a "mess."

Examples: 2 prores decoders, 2 prores encoders (or 3), 2 different resampling
libraries, libstagefright integration that does not work, more global context
structures compared to libav, etc... They also refused to remove some very
outdated (non-working) code like xvmc.

> why doesn't someone (like VLC) take the best features from both projects and
> create their own library?

Because it's a lot of work. An enormous work.

~~~
anon4
For what it's worth, a lot of production code looks this way. It's not right,
it really should be nice and neat and so on. However, I don't see it as a
grave sin against the project. Messy code can diverge where needed more
easily.

Three different copies of the same code? Yeah, ok. That's ok. One day, when
you can, merge them together. You can't merge them together? It's ok. Maybe
they shouldn't be merged together.

Is it a barrier to entry for new developers? I feel that any developer who has
worked on messy legacy code won't bat an eye. This sounds more like a problem
experienced by a young coder fresh out of university.

You definitely can write clean code. Cleanliness can be a priority. There are
some surprisingly clean and well-written large codebases out there. However, a
lot of people just don't care. They are very smart, capable people who just
bang out code that works and don't care to integrate in the proper clean way
with the old code.

If you want clean code, an old, large, working C/C++ codebase is not what you
want. We often can't spend time cleaning up old code, since there's always
more features to implement, bugs to fix, etc. Learn to deal pragmatically with
code like that. It's not like that out of malice, or some misguided attempt at
writing the largest IOCCC winner. You can work with it. It's just a bit
trickier.

~~~
prewett
I've worked on some of those "old, large, working C/C++ codebases" and the
ones that are not clean are the ones where you are terrified of making a small
change to fix a bug, especially close to release, because you have absolutely
no idea what might break. Two copies of the same code? Great, which one do I
fix? Both? How do I test that it worked, I can't even figure out where #2 is
activated in the UI?! Is there something a little different about them that I
need to watch out for? And test cases for said codebase? Hahahahaha!

------
snorrah
Interestingly, a recent LWM article on ffmpeg coming back to Debian touched on
the possible implications of Michael stopping work on the project:
[https://lwn.net/Articles/650816/](https://lwn.net/Articles/650816/)

"Reinhard asked whether FFmpeg is a one-developer project that would find
itself in trouble should Michael stop working on it. "To me, this constitutes
a serious bus-factor: Without Michael, (probably) nobody is able to replace
him." He went on to suggest, though, that Michael's departure could do a lot
to bring an end to the fork."

------
supertruth
Before Yahoo! went public David Filo contacted Larry Wall and gave him the
option to buy a good portion of pre-IPO stock at a low price.

The reason? Yahoo! could not have existed without Perl.

FFmpeg has been used in so many profitable ventures (hint[1] hint[2] Netflix).
I sincerely hope there is a business leader with the same level of
consciousness and grace that will do the same for Michael. He's one of the
heroes of the past decade. Internet video streaming would certainly not exist
as soon as it did without him.

[1]
[https://twitter.com/nicolasweil/status/466248052454727680](https://twitter.com/nicolasweil/status/466248052454727680)

[2] [http://www.streamingmedia.com/Articles/Editorial/Featured-
Ar...](http://www.streamingmedia.com/Articles/Editorial/Featured-
Articles/Streaming-Media-East-Netflix-Making-the-Move-to-HEVC-but-Efficiency-
Gains-Lag-96981.aspx)

~~~
alecco
Kudos to Yahoo! What a different time, thankful tech companies. But this is no
more, only after public shaming did the Googles/Facebooks chip in money for
OpenSSL and GnuPG when those projects almost collapsed. And they gave
rounding-error level of their multibillion cash piles.

This is why the community is broken and sadly some of us feel cornered to do
Affero or just not open source. I used to be hardcore BSD, but times changed
and had to adapt.

These the majority of the community is selfish, doesn't contribute back,
doesn't even give credit to most of the tools behind their UIs. See:

[http://zedshaw.com/archive/why-i-algpl/](http://zedshaw.com/archive/why-i-
algpl/)

~~~
astrange
Being LGPLv2 was enough to get FFmpeg some income streams, because almost any
shareware video converter you could find shipped it without credit or source
distribution, and the SFLC would go after them for copyright violation.

Not sure if there was much contribution or acknowledgement for the longest
time from any company (Google, FB, Vimeo, Netflix, Zencoder, etc) using it,
and I remember the best they'd do for bug reports was say "yeah it crashes
sometimes" and refuse to send sample files.

Eventually Google did have some people contributing full-time, of course. They
paid me 1x GSoC (one week's engineer salary) for more than a year of work
once. Um, it seemed like a good idea at the time.

------
jacquesm
Wow, that's a pretty classy move. Now lets how this will help heal the wounds
with the libav community and they will in fact move to the other side.

I think he should have left out the bit about 'will I ever return', that might
actually cause libav contributors to hold off from making the switch.

Still, it's great to see the recognition that in the end this is all about the
product and its users.

~~~
Afforess
I disagree. FFmpeg is/was heavily dependent on Michael for active development
and bug fixes. In the last few years, more than half of the commits are from
him. Without his contribution to development, nor a clear leader and
succession plan, FFmpeg may stagnate again.

I don't blame Michael for any of this situation, but this is not a win for the
community, product, or users. Development is going to slow way down, bugs are
going to go unfixed, and the overall quality will decline in the short to
medium term. It is unfortunate that vitriol over the fork led to this
situation, where neither libav nor FFmpeg win, and everyone loses.

~~~
jacquesm
What else should/could he have done that would be better?

~~~
av500
he could have stepped back much earlier

~~~
phpnode
or someone else could have stepped up much earlier?

~~~
thresh
Well people actually have tried that 4 years ago:
[http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/123868](http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/123868)

and somehow leadership was still a thing for Michael at that time, which
really contradicts with something he says now.

~~~
phpnode
That looks very much like a hostile takeover, it's unsurprising that it
failed.

~~~
makomk
It was very much a hostile takeover. If I remember correctly, the people who
controlled the infrastructure like the website and mailing list booted out not
only Michael but also a bunch of the existing maintainers of ffmpeg code and
it got really ugly.

~~~
lu_zero_
You might check your facts before spouting this kind of sentences.

Sadly the people on the Libav side never spoke up and nobody really checked or
asked since they are "EVIL".

------
tacos
Sigh. This is one of those situations where the world has received so much
benefit and they didn't realize it until that person finally got fed up.
FFmpeg is sort of an ongoing disaster, but it reflects the nature of media on
the web, and it works. I'd love to say that my hunch is things will get better
but I don't think that will be the case short or long term.

libsndfile -- another key component everyone takes for granted -- is in a
similar position. Full of known problems, super-smart but slightly neurotic
leader, and GPL issues that people are pretending not to notice in hopes he
finally does a release after 5 years.

I've done major community work and man, is it ever exhausting. It's a shame we
haven't found a way to get people the assistance they need. Some of which is
psychological.

~~~
pm215
The approach I'm trying to take with the community I'm involved in is to keep
the effort required spread out -- so for instance I manage mainline releases
but somebody else deals with stable branches and point releases, and a third
person does the "pick up otherwise orphaned patches from the mailing list and
get them applied" work. If I was trying to do all those jobs at once I'd never
find time to do any of the things I actually find interesting!

~~~
ethbro
This is probably one of the issues with being a the aforementioned super-smart
/ super-productive leader: they _can_ take all of that load if needed.

Should they? God no. No one can run that workload as a volunteer for a
decade+.

But I can see how the default reality probably bends towards "Well, someone
left and we need this job filled" -> "I'll just temporarily add that job to my
workload" -> "It'd be more effort to move that job's responsibility to someone
else, so I'll just keep doing it."

------
hartator
Thanks Michael for all the awesome work. Sad you are leaving for these
reasons, hopefully in the futur, libav contributors will come back to FFmpeg
and be less agressive with the leadership, but it might not happen.

------
srj
A huge thank you to Michael. It's easy to forget how difficult playback was
just 5-10 years ago. FFmpeg has been invaluable.

------
billjings
> Especially as somehow "leader" is being interpreted by everyone as "the guy
> who does all work noone else does, and takes all responsibility noone else
> wants to take"

Hmm.

~~~
nailer
> Especially as somehow "leader" is being interpreted by everyone as "the guy
> who does all work noone else does, and takes all responsibility noone else
> wants to take"

That's what leadership is.

~~~
Twirrim
There's likely otherwise stuff to it, e.g. Does all the boring housekeeping
commits, patches security vulnerabilities etc, leaving others to work on the
'sexy' stuff like new features.

------
nickpsecurity
As a VLC user, I'm sorry to hear things in the FFmpeg community got so bad.
However, I thank all involved (including VideoLAN) for the work they did to
make something that plays about anything on the major systems. Good news is,
since it's open-source & mature, it has a chance of rebounding back into good
shape either in current or new hands.

------
ftomassetti
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](http://codecs.multimedia.cx/?p=339)

------
Zarkonnen
Can someone give us a backgrounder on what the split in the ffmpeg community
is about?

~~~
DanBC
[http://blog.pkh.me/p/13-the-ffmpeg-libav-
situation.html](http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html)

There's probably some great popcorn in mailing lists.

Edit: libav have a big "personal conflict resolution" section here which is
another hint:

[http://libav.org/about/](http://libav.org/about/)

------
mark4o
The message on the FFmpeg site
[http://ffmpeg.org/index.html#message](http://ffmpeg.org/index.html#message)
sounds hopeful for a reconciliation of the forks.

------
72deluxe
This is all news to me but the FFMpeg / libav split and apparent attempted
coup d'etat of FFMPEG the other year all looks very sad. This reminds me of
the XFree86 / x.org splits, the EGCS/GCC splits etc.

All very sad but makes for interesting OSS history! I find FFMpeg very useful,
but then again I find VLC and libav useful. In fact, it is all useful. I hope
it all works out.

~~~
jkot
Why sad? XFree86 and GCC had HORRIBLE code, first thing done in forks was to
delete 70% of code.

~~~
frozenport
As a Gentoo user we're gonna have terrible dependency problems for the next
few years. Specifically VLC and Qt.

Somebody at Redmond is laughing at the OSS community for failing to provide
functionality that comes out of the box on the latest Windows systems.

~~~
__david__
Nothing that Microsoft has comes close to the functionality of ffmpeg. Apple,
either, for that matter. Last time I checked neither OS even supported reading
Matroska containers natively, and containers are pretty simple compared to
codecs.

    
    
        $ ffmpeg -codecs 2> /dev/null | wc -l
             396
    

ffmpeg and libav are simply the most comprehensive collections of video codec
software in existence.

~~~
jfb
That doesn't make either one good.

~~~
astrange
I can promise nearly every implementation in ffmpeg is better than the
competitors. No commercial product has the motivation to keep making
improvements to their code that already works "well enough", and they don't
have as good a set of working optimizations to apply to new codecs.

They can get new features out the door, though. One reason for the original
fork in ffmpeg was that the very strict code review culture made it difficult
to get anything in that was experimental or depended on personal taste.

~~~
jfb
There is a lot of very useful functionality in ffmpeg/libav. That doesn't make
using it pleasurable.

~~~
astrange
Were you trying to use it from the API or the command line?

Either way, yes. Elenril and others were doing good work cleaning up the API
when I last paid attention years ago, but there's a lot of surprise technical
issues esp. in libavformat that it has to cover up. (Like, PTS/DTS in avi.
Like operations that are instant in some file types might be real-time minutes
in others.)

As for the command line, major customers tended to not ever give feedback on
it, and it was maintained by Michael who tended to use the same code-review
standards on the UI code as on the inside of a video encoder. This made it
quite difficult to ever get anywhere. That's one of the reasons there was a
fork back then.

Of course, there's deep technical problems there too - you can tell it to do
all kinds of things that are actually really hard, and it will kind of half-
heartedly do them then fail. Try converting a Matroska file to MP4 without re-
encoding it; you'll get a weird error. That one weird error would take more
than a year of developer time to fix.

~~~
jfb
Yeah, both. In fairness, the last time I tried using the API was before the
libav split, and I have no doubt that the situation has improved; the command
line, while almost ludicrously powerful, retains a lot of terrible habits --
silent defaults, mutually contradictory options, &c.

I have somewhere a much more prescriptive python library that sits on top of
the command line API, but I think it'd be really great if there were a
"strict" mode for the CLI -- no more implicits, no more silent rejiggering of
options. If you don't totally account for your input and output, it's an
error. Then, there could be a much more forgiving and intelligent front end to
the front end that allowed for things like "-i foo.avi ./foo.mp4", making best
guesses at each stage of the pipeline.

------
AdmiralAsshat
So who is likely to take the reins on the FFmpeg end?

------
aidenn0
For those who were around for it, I'd be interested in a comparison with the
ffmpeg/libav issue and the GNU Emacs/XEmacs times.

------
shmerl
I didn't follow the background of that fork. Will ffmpeg and libav be able to
merge now? Was it a leader conflict or something else?

------
wedesoft
To whoever contributed to it: the swscale library (colorspace conversions) was
really helpful during my PhD work.

------
josteink
Sad to see the hostile fork "win".

I know if I were ever in the position to contribute to general OSS video,
libavcodec would be on the list of projects i would never be willing to
support.

Hopefully these projects can reconcile and libavcodec and its shamed name can
be put down and development can continue under the projects true name to
honour its true roots.

~~~
JoshTriplett
> Sad to see the hostile fork "win".

I wouldn't put it that way, considering that the last distros still shipping
libav are abandoning it in favor of ffmpeg.

------
ytdht
Thank you for all the work that you have done so far Michael Niedermayer

------
ratsmack
Every project needs a strong leader. I seems that projects seem to fall apart
when decision making become driven purely by consensus. If Linus was not a
strong leader in giving Linux definitive direction, this same thing may have
happened for Linux by now.

------
av500
not that he was likely to go without making a ton of derogatory remarks about
the livav split.

and if he never liked the leadership role as he claims, he was given ample
opportunities to get rid of it.

~~~
Intermernet
He states:

"I had hoped for a long time that the fork situation would resolve and both
sides somehow merging back into one team. All the Libav developers joining
FFmpeg again. But even now as the last distributions are preparing to remove
Libav, still theres no hint of that happening. Maybe even the opposite."

and

"Do friendly merges, and if you like do hostile merges. Its all up to you
now!"

That isn't "a ton of derogatory remarks".

libav is working to the same goal as ffmpeg. The split is due to idealism and
politics, not due to the goal of the project. I'm not going to pick a side in
this, as interpersonal relationships are impossible to accurately gauge from
an external viewpoint.

I'm not sure if you have a personal stake in this argument, and I apologize,
and sympathize if you do.

Best of luck in the future Mr Niedermayer. Thanks for all the work over the
years.

~~~
av500
"...and its very difficult to be the leader when one is on one side of this
split and the other tries everything to push me out..."

that the gist of it, it's always the _other_ side wanting him harm. he never
ever acknowleged any wrongdoing on his side.

~~~
makomk
The libav side have consistently refused to merge code from the ffmpeg side of
the split, including security fixes, have written their own incompatible
versions of any APIs the ffmpeg developers come up with, and been generally
hostile, and he's the one that's had to deal with the mess for the past
several years.

~~~
lu_zero_
"Refused" ? In Libav any patch has to go through review, anything that had
been put in review had been managed as any other patches by any other sources.

Libav is about rules and not leaders.

~~~
sirbribri
After seeing a few of the comments from libav developers here and on IRC, you
can see the bitterness is still alive. :-(

~~~
av500
if everything that somebody from the libav side says here is automatically
labelled bitterness and downvoted, maybe you can understand why some are
indeed bitter.

~~~
iopq
I've never heard of this split up until today, why are you still salty? You
won, you can take over the world now.

------
mahouse
Not going to comment on his skills to lead such a community, which more than
obviously are very very good, but for a project manager of 14 years he really
writes like a newcomer.

~~~
jjbiotech
I was thinking the same thing. Looks like the writing of someone posting to a
drug forum blacked out on benzodiazepines.

~~~
Pinatubo
That's oddly specific.

~~~
ytdht
maybe speaking from personal experience...

