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.
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...
I'd be surprised if you had actually read the blog post I wrote (pkh.me) :)
> most of the libavcodec and libavformat work has been done in libav
Well, I believe this is a bit more complex. While it might be true for API changes and cleanups, FFmpeg has dozens of additionnal codecs and formats, as well as way more assembly/optimization code.
> What you should know is that the current codebase of FFmpeg is a huge mess compared to libav
Honestly, this is pure FUD and it's very surprising to read that from you. You seem to have no idea about the cleanups of FFmpeg because we do not advertise them (they are not relevant for the users). What is so much a huge mess? This is very insulting for the work done by FFmpeg developers these last years. Hey, even libmpcodecs (the MPlayer filter wrapper) is no more. A lot of work was also done on the documentation. Seriously, please stop doing FUD like this.
> Choosing one or the other gives you different set of features
> I'd be surprised if you had actually read the blog post I wrote (pkh.me) :)
I did, and many times. And I already said so.
> Well, I believe this is a bit more complex.
Unfortunately, it's more complex, yes, but it's not that much. Elenril, Koda and Martin are the one spending the more times and commits on libavcodec and libavformat.
> Honestly, this is pure FUD and it's very surprising to read that from you.
It's not. Unfortunately. Who has multiple implementations of the same codecs (2 prores decoders, at least 2 prores encoders) or libraries (2 resampling libraries) ?
Who is spending hours removing the famous MPEG12EncContext from everywhere? And I don't even speak about the refusal to removing the non-working xvmc support for MPEG2.
And sorry, but you are one side, that joined after the fork. Attacking me is not really objective.
> Not exactly true.
Of course it is. Every time I do package VLC I need to choose one fork over the other and every time that means a different bug. This is documented over and over on our wiki and our bugtracker...
EDIT: I'm sorry you (and other) took that as an attack on FFmpeg. We use FFmpeg over libav in the current VLC windows and Mac version.
In the decades I'm developing software, I've learned that there is no developer out there liking somebody else's code. There's always something. You can think you're objective and unbiased, but you're not, no-one is. FFMpeg's code might be a mess due to a large chunk of legacy / backwards compatibility code, but very likely the other side's code base is a mess in other people's eyes.
Except I'm on no side in this fight: we use both, have friends in both side, and we host FFmpeg's git. I may be not 100% objective, but I'm more objective than a developer from one of the side.
The fork is hurting us a lot. It means a lot of work.
Given what I've read from the stories, and taking into account the rhetoric employed by one side versus the other, I have to say that, at least in tone, FFMpeg struck me as being more mature about the whole affair.
> I have to say that, at least in tone, FFMpeg struck me as being more mature about the whole affair.
same here. And regardless of what their codebase smells like, their stuff works and does what it says on the tin, letting people play whatever format there is out there on a massive amount of different systems. I'm the first to admit the dialogs they're using to configure the codecs is one which is a yearly 'Ugliest UI' award winner, but luckily others have made front ends which make you avoid all that mess in the first place.
It might hurt you but it looks like it doesn't hurt you enough that you decide 'pick a side and stick with it'. What I don't understand is why you don't simply pick ffmpeg and be done with it? E.g. it's good enough for playing whatever format on windows using WMP, so why isn't it enough for you to play whatever is out there using VLC?
distro packagers typically undo vendoring for lots of reasons (among others: smaller packages, fixes propagate automatically, which is particularly important with security issue)
Given how similar libav and ffmpeg still are in places, they might even consider replacing the vendored ffmpeg with the packaged libav (or vice versa, if done the other way).
But the fallout would be for VLC to deal with ("VLC breaks on my Debian, it must be crap").
The whole situation is really representative of the whole philosophy of doing aggressive cleanups/rewrites. Maybe it'll improve things on the very long term, but you will have a really, really long period where your product is completely unusable, and will drive a lot of pure frustration.
I hope some big entity ends up throwing money at the situation, it seems fixable, just a lack of manpower to fix it. I mean, Google relies on it a whole lot for one.
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.
> why doesn't someone (like VLC) take the best features from both projects and create their own library?
Because that in itself would be a huge project, with moving targets as the source projects develop over time. If it were that easy the VLC people would just implement everything themselves and not need either 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.
The problem is, of course, the humans.
People sometimes take things very personally even when not meant that way. A significant fork for no good reason can distract from the work of the core project and dilute the user-base, and people will not always agree on what a good reason is/n't. Sometimes the problem is stated as poor code and/or procedure quality, and this can be taken as a rather direct insult.
Sometimes massive forks happen because of differing priorities between different groups of people and everything is perfectly amicable - you don't hear about these cases much (unless it inconveniences the userbase) because there is no drama to make a noise about. Sometimes these forks later re-merge, sometimes one becomes clearly superior and the other fades out, sometimes they go on to be completely separate projects.
It sounds like three are personal issues involved in this particular mess that we don't exactly know about so can#t hope to fully understand because the discussions started in private and have not been published and as we all know any argument, especially one that has gone on for some time, people can lose track of the true chronology of the issue and that can make reconciliation near impossible.
I agree with everything you say however, if the two things you rely upon are, in their own words, such a mess then I have to imagine that mess consumes an equal if not more inordinate amount of time to integrate with.
I'm a software developer too. In my career I've had to implement logic to work around buggy libraries, spend time looking into bugs in others code... It seems that at some point that the means don't justify the end and having my own code base that I'm familiar with would be easier than fixing theirs and waiting for disputed parties to figure out what they are going to do.
And I never claimed doing your own was easy. All I'm suggesting is that at some point it's easier than dealing with what you got.
> 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?
If I remember correctly, a big part of the reason that ffmpeg ended up with two resampling libraries is that after they'd created theirs, libav wrote their own with a different, totally incompatible API and ffmpeg wanted to support applications that were written for the libav API.
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.
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!
Writing clean code is not an academic exercise. It means comprehending it takes longer, writing features takes longer, testing it takes longer. It makes every interaction with the codebase harder.
That might not be quite as bad in a proprietary codebase since you have somewhat more of a captive audience, but in an open source project where you want a long-tail of contributions from many people, that is a serious problem.
The issue is the "you" implied there. So you fork it and start working on your own. What do the other contributors working on the previously-existing project do?
This seems to resolve itself when there's a clearly superior project and developers and distributions switch to the newer project.
However, if both projects continue to simultaneously develop...
> 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?
These days I just use gStreamer which can wrap either one in a sane API and is 1000x easier to extend.
Is the info about the attempted coup d'état wrong then? Because that's completely nasty. If you don't like the project leader, make a real fork and hope there is enough of you who will jump ship. Abusing the fact that you control the infrastructure to try and lock out the old leader is bad.
> Is the info about the attempted coup d'état wrong then?
It's partially untrue, yes. There was an actual vote from all the active developers to remove Michael from leadership, and that included the infrastructure developers.
>It's partially untrue, yes. There was an actual vote from all the active developers to remove Michael from leadership, and that included the infrastructure developers.
Then why did so many remain with the ffmpeg project instead of going with libav ?
"I think the statistics indicate that the situation is much worse than
I expected. Please keep in mind that because of the daily merges, all
commits that are made in Libav also appear in FFmpeg, but not the
other way round. With a finger-in-the-wind estimate of subtracting the
numbers in the Libav table from the FFmpeg table, the distance between
Michael and the other FFmpeg developers because even more extreme."
Like jbk, I'd like to hope it will happen, but the combination of significant tribalism, plus the very different development philosophies may prevent this.
For the merging to happen, there would have to be both some agreement on the technical direction of the two projects, as well as some sort of social resolution, which would likely involve some maintainers of one fork or the other leaving.
Regardless, from my point of view, it seems unsustainable to keep on merging from libav to ffmpeg at the pace that Michael has been doing, so the projects will end up diverging enough at one point that momentum ends up behind one or the other.
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/
"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."
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.
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:
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.
Less a different time, more a different company. The sad part is, that sort of culture is why they "lost".
Thinking about more than yourself never seems to work out in this world. I really, really wish it would. And I'll personally continue to follow my conscience over my wallet. But the wallet always wins in the public arena. In all facets of life.
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.
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.
Even without if you remove him and the common committers between the 2 projects the 9 first top committers of FFMPEG commit more than top 2 of libav : https://lwn.net/Articles/650816/
That's incorrect. Those statistics include all the MERGE commits from libav into FFmpeg, which happen several time per day. Michael did not do 1500 commits more than the second commiter.
Michael Niedermayer is an EXTREMELY prolific dev who has been banging out FFMPEG code for more than a decade. It's by no means a one-man show, many other devs make large and valuable contributions - but in relative terms Niedermayer absolutely dominates FFMPEG, both in terms of personality and code output.
This post is from someone involved in libav but it refers to the different public e-mails that were exchanged when the fork was originated and they document factually things (at least, as far as I can understand)
I've read that before and it comes across as overly defensive and very personally biased. If I were heavily invested in one side or another I possibly would have written a similar post defending one side or another.
I'm not saying the points aren't valid, but I stand by my statement that "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 agree. There is a lot of seething rage, but not a lot of citations for the point he's putting forward.
'..making FFmpeg effectively a strict derivative of Libav' is a pretty egregious display of bias, one that to some degree shows the distortion of the author's viewpoint.
I had never heard of any of this mess until today, don't particularly care about either project, but this comes across as extremely biased, even from the most basic aspect of tone.
>former FFmpeg leader Michael Niedermayer.
Former? Well, he resigned today, but this blog seems quite old.
>Since FFmpeg was a project famous for horrid code quality and sketchy and irregular API
Was it? Is it? All I know is a bunch of stuff uses it. Where is that fame?
>“The people behind Libav stole the FFmpeg infrastructure”, some of the admins even got questioned in their workplace if they really stole something. Pity that most of the people related in keeping the infrastructure functional were doing so on their own hardware and co-location, but obviously checking facts is hard, better go help shoveling manure on people.
Server infrastructure is one thing. You mention yourself that you guys didn't have the trademark, yet you took the domain name too? I dunno about the laws in all of the locations where this played out, but in the US at least, that'd be theft.
>started to merge daily everything Libav does more or less since the beginning, making FFmpeg effectively a strict derivative of Libav.
Again, tone, wording, etc. This statement does not stand on its own: If I have a 50 million line project that had a small subsection forked, and every day the fork's changes were merged, that does not make my project a strict derivative. I'm not saying libav is a small subsection, or making any sort of claim about the ratio of ffmpeg original work vs. libav merges, but you have provided zero information or evidence to support the claim one way or the other either.
>Now things are a little more fair and at least FFmpeg more or less states that is a derivative of Libav with additional features in their download page.
Ah, here you go. Kinda. But again, tone. And not much evidence. The ffmpeg download page seems to be open about including code from libav, but uh, additional features could be major. What's the difference in features? What is the actual volume of work in comparison?
>On the other hand I’m not cool at all in having an unfair competition, with a side piggy-backing on the other like it is happening: everything in Libav is merged inf FFmpeg, enjoying the fact the code is polished and cleaned before.
This is a feature, not a bug. Unfair competition? Piggy backing? You are developing an open source project. Do you only want things to be open if the people using it are people you like?
>sometimes the amount of nonsense thrown at you by those rabid fans not knowing anything is appalling.
You write this, and immediately follow with:
>Hopefully writing more about it might help defusing this situation.
Blog posts like this are very inflammatory. You hurl insults, make a lot of claims without providing evidence that backs them, and generally come across as someone who has a lot of personal bias on the matter.
That isn't to say that you're wrong: I have no idea who is right or wrong on this. I don't particularly care. But your blog post is about as biased as it gets. And to note, biased doesn't necessarily mean wrong - you can be biased and still be right.
> Former? Well, he resigned today, but this blog seems quite old.
He got demoted, as written in the blog post, did you read it with attention or you just went through looking for bits you could use?
> Was it? Is it? All I know is a bunch of stuff uses it. Where is that fame?
You can ask the GStreamer people or the VLC people, I started being involved in MPlayer and FFmpeg because the code was not really working on PPC...
> Server infrastructure is one thing. You mention yourself that you guys didn't have the trademark, yet you took the domain name too? I dunno about the laws in all of the locations where this played out, but in the US at least, that'd be theft.
We did not took the domain, the owner of the trademark is not Michael Niedermayer.
You claim to know nothing yet you cut quite interesting judgement and you cherry pick in a quite interesting way.
>He got demoted, as written in the blog post, did you read it with attention or you just went through looking for bits you could use?
It certainly seems like he had been leading the ffmpeg project until his resignation.
As for looking for bits I could use, I am quite specifically responding to your question about how the article comes across as biased. I was not looking for parts that seemed unbiased, because you were looking for the biased parts.
>We did not took the domain, the owner of the trademark is not Michael Niedermayer
Your own blog post says " the trademark FFmpeg had been given by the owner of it Fabrice Bellard to the former FFmpeg leader Michael Niedermayer"
Which is it? You say in your post he was given the trademark.
>You claim to know nothing yet you cut quite interesting judgement and you cherry pick in a quite interesting way.
You're defensive. You asked a question about how your article was biased. As an outsider, these are the parts that looked biased.
If you ask a question, you can reasonably expect an answer. If you don't want an answer, don't ask the question.
>"insults" is a quite loaded term btw.
Uh. Thanks for informing me, I guess? I'm not sure how you can in other places say "clean up monkey" is horribly offensive, but "rabid fan" is not an insult at all.
I doubt HN is a bastion of ffmpeg supremacists, and there's no organized movement to suppress your voice, so the reaction your getting should probably be taken as an indication that you should undergo some self introspection. Open source projects depend on community support to exist. Libav may be the best thing since sliced bread, but if you drive away potential users and supporters, you are harming the chances of the project's success.
> Former? Well, he resigned today, but this blog seems quite old.
In context he may consider the vote to keep Michael Niedermayer as team lead a farce. Several of the voters mentioned that they only voted for him to enjoy the resulting drama.
> This is a feature, not a bug. Unfair competition? Piggy backing? You are developing an open source project.
There is hate between the projects. libav was (iirc) started with the intent to be ffmpeg done right, something that is hard to show when the ffmpeg maintainers can simply copy paste every improvement until libav collapses from lack of support/donations.
Not going to take a side in this either, there seemed to be a need to grow up in both groups.
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.
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!
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."
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.
> 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"
> 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"
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.
Aka "my technical skills outshine my people skills and I'm highly motivated to get things done." I'm guilty as charged as well. It's ... exhausting. But it's also the exact set of personality flaws that results in so much stuff actually getting done on the planet. Everyone knows that guy. He's probably fixing your build screwup right now. Give him a hug or a beer. And find him a mentor and some competent helpers.
That's not at all what he's saying. You're trying to validate what you do. Your AKA is pulled completely from your mind and has nothing to do with with original statement. A leader has people skills above all else.
I related to much of what he was saying. Between the lines I felt what was going unsaid. So I brought experience and humanity to the discussion. I am not seeking validation.
> A leader has people skills above all else.
Leadership skills and interpersonal skills and management skills are completely separate. Amazing leaders/motivators who are downright shitty people are not uncommon in our industry.
This particular leader made the classic mistake of doing too much. "Nobody else wants to do it? Nobody wants to take responsibility for this? I will. I'll do it" is the definition of a bad manager. And admitting it in your farewell post doesn't demonstrate great people skills either.
Regardless, these people are all around us. And they deserve a beer and a mentor and some help. Next time you're looking for a project to contribute to, consider helping that guy.
> Leadership skills and interpersonal skills and management skills are completely separate.
No, they aren't. Leadership skills are a subset of interpersonal skills and management skills overlap interpersonal (especially the leadership subset) skills.
They are all different sets, but they aren't completely separate.
If you're drawing a Venn Diagram of "ways to commmunicate" in two dimensions, sure. If you're thinking about humanity and ethics and the way each of those skills is valued by a community in transition, the ellipsoids don't have to touch. Might I suggest the current incarnation of Donald Trump as a case study if Steve Jobs is too trite.
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.
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)
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.
And then we also have the mplayer/mplayer2/mpv split, where the project forked not once, but twice. Between this and ffmpeg/libav, I honestly have to wonder if there's something in the culture of media encoding/decoding technology that causes people to stop working together like this.
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.
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.
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.
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.
It makes them better than the competition, in that I can throw practically any video format in the world at libavformat and friends based players (like vlc or mplayer) and it just works.
It may not be "pleasurable" but it's nothing to be trifled with.
There's no question that ffmpeg set itself a very difficult problem, and largely succeeds. But it does so in a way that is brittle and (whether purposefully or simply out of lack of knowledge) learnt nothing from e.g. QuickTime or DirectShow.
The problem as I see it is that media manipulation is not really suitable for a one-size-fits-all command-line solution, and the API was slave to the command-line tools. This may have changed recently, which would be great.
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.
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.
"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.
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.
"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.
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.
I don't know if he's ever explicitly mentioned his "wrongdoings," but I do feel that he has changed for the better since the libav split. This is in terms of how he's interacted with people on the ffmpeg-devel mailing list, he's shown up consistently on IRC, and getting patches accepted aren't a royal pain as it was in the past. I don't know how real contributors/maintainers feel, but as a user and sometimes patch-submitter, I feel like things have gotten better.
posts like this one is why it went off the rails a long time ago. there is also the one where he suggested a libav dev should commit suicide and later labeled it as "Austrian humour"
Your team won, Michael stepped down. Of his own volition. What positive outcome could possibly be had by still spouting bitterness and negativity against him? Is it because he did not genuinely say "sorry" at some point? After reading [0] and [1], is it not possible to admit that maybe both sides have some genuine "sorries" to pass around? Now seems like the perfect opportunity to make a positive change for developers and users instead of venting frustrations that are only going to further polarize the current division.
(I'm not "automatically" labelling your posts as bitter. Almost all of yours in these comments objectively contain negative language, typically directed at Michael.)
(Keep in mind at least one of the Libav supported got questioned on his dayjob regarding "thievery" because of those lovely examples and the legends the fans kept propagating)
>If noone has time ill fix the memleak and commit and let the libav
cleanup monkeys clean the rest up for me.
Is the kind of inflammatory comment you are so up in arms over, I think you must have lived a very sheltered life. Especially considering this comment looks to have come shortly after the hostile split.
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.
