Disclaimer: the word “schizophrenia” is used here as it’s perceived by majority, not to denote a certain psychological condition. Feel free to be offended.
I’ve wasted about a decade working at two multimedia projects (plus a patch or two to unrelated projects) and what I’ve seen there leads me to the conclusion they both suffer from schizophrenia, albeit in different forms.
FFmpeg
FFmpeg features two forms of schizophrenia—developers and code.
Developers schizophrenia can be seen in how some developers believe they are also Libav developers. Mostly they brag because they’ve sent a patch or two to Libav and now can use it as a free review service. While I dislike Carl Eugen he’s at least honest and acts to his beliefs (here, an amended Elenril’s Law fulfilled; in case you’ve forgotten it says “Every FFmpeg-related discussion ends up mentioning Michael. Or Carl Eugen.”).
Code schizophrenia is more celebrated. The most prominent example is ProRes support—they offer two decoders and two encoders for it. There are two ASF demuxers as well. And two audio resampling libraries. And there are talks about adding second libswscale (*shudder*). The best part is that if you ask why it will probably go like this:
— Why do you have feature X in two versions?
— Because Libav has it.
— But why do you take it if you have your own version?
— To make merging Libav codebase easier.
— But why do you need to merge it at all?
— To make merging Libav codebase easier.
Please please tell me I’m wrong and provide proper reasons why FFmpeg keeps merging Libav stuff and keeps several versions of the same feature.
Libav
Here it’s somewhat more interesting—you have developers with physical multiple personalities disorder. Unlike the case in FFmpeg here you have people that work solely on Libav but as several different people. Most prominent examples are Luca (known as lu_zero and koda on IRC) who is really several instances not always agreeing with themselves (and if you subscribe to Lu_zianism then he’s also both Michael and Carl Eugen too, if you don’t believe it—you should because it annoys him/them). And there’s also Alexandra (aka beta elenril) and Anton (aka sasshka 2.0). And that’s the majority of core Libav developers anyway.
But at least the project seems to be more happy with itself and probably has a dream similar to the Ukrainian dream (which is “bugger off you damned Russians” in case you didn’t know).
It was somewhat fun to watch the fate of proposed bitstream reader replacement. Alexandra (she’s also Top Libav Blogger ?2 by the way—simply because she blogs) proposed a new bitstream reader to replace the old horror (which is a good idea), and that new bitstream reader turned out to be faster than the old mess too, and what was the result? If I’d be British I’d call it sheep-worrying.
Those developers from FFmpeg that believe they also should have a say in Libav process started to express their opinions. While there were independent benchmarking proving the new implementation is indeed faster (which is a good thing to provide) those benchmarks were also run on the decoder not present in Libav, with badly converted functions for code reading, and that turned out to have some problems because of the encoder used (also not in Libav) that produced nonconforming stream and screwed multi-threaded decoding benchmarks (that one can be seen as both trollish and arrogant—kinda like judging The Beatles performance from an excerpt sung by your not very talented neighbour).
But mostly it was bikeshedding and asking why it was not using old get_bits interface. The answer for the latter is simple—because it was built from horrible macros used in half of the places directly so you should either to make everything follow those macros design or convert the old UPDATE_CACHE(); LAST_SKIP_BITS(); ... CLOSE_READER(); into saner get_bits(); skip_bits(); anyway. And Libav developers decided it’s better to have fully new interface anyway and to make it consistent with bytestream reading while at it.
So why did people who should have nothing to do with it bikeshedded that much? Probably because they know in their hearts that as soon as it hits Libav the work on copying it into FFmpeg starts and sooner or later it will reside in FFmpeg codebase probably along with old get_bits.h with most decoders switched to the new bitstream reader anyway. Why? See the theoretical conversation above. I’d like to know the answer why merges are really done but I guess I’ll get it no sooner than this bitstream reader is accepted into Libav master (i.e. never).
MOAR FEATURES!!!!
1.
From us users’ POV, the merges are useful, because we don’t want to be excluded from features from either sides of you guys’ mess. We don’t want to switch from fork to fork depending on which stuff we need at the time, after all we usually use your stuff through another software (ffms2, mpv, LAV filters, VLC). We the users sincerely don’t care about your personal problems.
Libav is too proud to import ffmpeg’s additions, so our only option is to go with ffmpeg which is less headstrong in this (thank God).
2.
When you take that as a premise, “making merges easier/possible” is a bloody good reason. The problems with duplicate encoders and such (and if you read the ffmpeg-irc logs – they are publicly available so I look at them sometimes – you would know that most of the devs do mind that, they rant about two prores codecs 5-10 times a month) probably usually rises for various situational factors like somebody liking the old code, different API so that people’s code would get broken, or different features in each implementations.
Generally in life, I think you need to know the details to understand things… So it is impossible to give a general answer to “why are things twice” since reasons vary, I would say.
1 — that still does not answer why to pick everything from Libav instead of porting just some requested features. And why to maintain compatibility at all.
2 — that’s a fancy way to say “nobody knows”.
It is not a matter of pride but a matter of doing what we want in our spare time.
Writing code that is interesting or solves a problem to the person writing it comes first.
We do not have a bulimic tendency about the features the other project has so there isn’t anybody looking at what the other side is doing and taking everything every day.
You are welcome to cherry-pick anything you want from FFmpeg and put it on review if you really want.
@Kostya
You really think it isn’t an answer?
Look at the situation with HEVC and VP9 encoding. Those are major features because tons of people have CPUs that are on the fence of feasibility of say 1080p playback and whether they can or can not watch such stuff depends on how many speed optimizations the decoder has.
Now the F side afaik has more advanced VP9 decoder than L, the merging stopped, users with L backend suffer.
The HEVC decoder is more complicated. Again from what I heard this component in F hasn’t been kept in synch with L and is now also more advanced and faster (feel free to correct me with benches?). So at first the user just won if he/she went with F and was done with it. But later L worked on their own assembly that was however unmergable into F. There codebase was too different at that point. AFAIK that code was considered potentially helpful as it implemented stuff not implemented in F, but F was forced to not take it. Because merge was too difficult.
So there you have it, users would definitely benefit from that merge. Not a good reason? Unless you give a shit about users (or maybe more precisely the usability/quality of your work?), of course.*
Sorry that I am going to offend the L developers now, but apparently they are satisfied with a state where their users are fucked because they don’t have decoder as good as F users, as long as they managed to return the “favour” a bit. Slovakians have a saying that goes “KeÄ mi skape koza, nech aj susedovi!” Even if that was not conscious goal there, unconsciously it still went there and the result was/is just as bad.
Users that want to (God forbid!) use realtime VP9 or HEVC playback kinda don’t put somebody’s personal vendettas above the function.
*
I am not a programmer, but I do other sort of stuff where your “product” made in free time is then given to random people on the internet to benefit from. It costs relatively large amount of time and I earnnothing from it. But I do both the fun, easy work that is needed in it as well as the parts that I absolutely hate. The reason why I do that is that I realized that if I did a halfassed job, my product would be compromised in value. That compromisedness and low quality would make my prior work and expended time wasted. Therefore I push myself even into more annoying aspects of the work, so that all the time that I lost pays of in some form. It is still time lost for me, but it is not wasted uselessly.
I don’t want to moralise or force anyone to anything, but I think it is a good advice to think about this. I think that many people do stuff without realizing this problem and are needlessly wasting their time, because ultimately the usefulness of their work (the return) is lowered. Life is short, so it is sad when people make mistakes in investing that precious time.
Again, why care what Libav does? It would be much simpler just to forget it exists and not even try to keep compatibility. If HEVC decoder is not fast enough then optimise it, there are enough talented developers in FFmpeg for that.
Thought maybe the answer is exactly what you said—FFmpeg does what it does because users demand it. But that’s exactly why I’m not going to return to either of the projects, I’m sick of all those users asking for various things (I got a mail asking for help with ProRes encoder just last week for example) and, even worse, demanding them.
If you look at Luca’s response, the idea of Libav is it’s rather a hobby project, not an enterprise software with an extended support package. See my previous post on how much money it all earns and check whether Libav aims for world domination.
To clarify better: if you want enterprise level of support you have to pay for it.
If somebody pays people to take our stuff and merge it to FFmpeg, it is their money and the people’s effort.
I find really disgusting the fact we get complaints because we do not make easier taking what we do in our spare time or for our specific purposes.
Same thing regarding demands about free support for code that isn’t even in Libav because somebody took something from my public personal tree and “merged” in FFmpeg (used to happen to me about once per month, quite annoying).
Well, what I was arguing for is why it is useful to merge and hence to make merges viable. I do use F, because it is now used in most user software I think. But as I pointed out, even as a F user I could have benefited from the L improvements in HEVC, if the merging wasn’t too hard in that case. My point was to show how merges are useful and why not a specific ones, but in general, because as the codebase differs, these situations where a specific and beneficial cherry-pick will get infeasible are bound to happen.
As for the “just for hobby” thing, I can surely accept that and I am aware of it. I as I noted in my post scriptum rant in previous post though, I wouldn’t be able to do it like that myself, though. IMHO it is a pity the usefulness of the work on both sides is compromised by the split. Nothing I can do about that though, obviously.
My posts here are just trying to give point of view on the stuff, not really to demand anything.
@Luca
I think you completely misunderstood me at some point.
The last two posts are solely about FFmpeg. As Kostya said, I don’t have to worry about Libav at all, I don’t use it. The question Kostya raised however was about the reason/usefullness of merges – and merges happen *in FFmpeg*. You Libav guys don’t generally do that AFAIK, except maybe some cherry picks.
The topic of usefulness of merges (#1) *in FFmpeg* and the topic of the usefulness of easy merges (#2) *in FFmpeg* again only matters in context of merges. So this whole argument only concerns FFmpeg, why and what FFmpeg does. You guys only came to be mentioned because you released a piece of code under LGPL which as permissible under that license became a possible candidate for improving *FFmpeg* for me, the user.
However, because of factors #1 and #2 didn’t play out right, that code had to be left unused *in FFmpeg*. But again, that is just something that concerns FFmpeg?
TL;DR
Kostya asked about FFmpeg, I said stuff about FFmpeg in answer.
End of story, I never demanded anything from Libav in this context, if you read my point as I intended it. You guys can do what you want (as I said, that “advice” of mine was just that, well meant advice, not intended to make you do something for my sake).
——————————————
Speaking in general though, I believe it has a lot of legs to complain about the schism situation in general from users’ PoV. I hope you can understand why we feel it has its downsides for us?
I’m afraid the fact English lacks a different word for impersonal, singular and plural second-person pronoun made everything more confusing.
You mentioned Libav, and Kostya found it funny enough to tell me, thus my answers about Libav.
TL;DR
It is not a matter of Pride, it is a matter of Money: somebody is paid for taking the Libav stuff and putting in FFmpeg, nobody is paid for taking the FFmpeg stuff and putting in Libav.
IMHO, this behaviour is the result of all the “obvious work” being done in both projects.
@Peter
It’s not obvious to me though.
This is related, although I don’t know if you’ll accept it you didn’t see the usefulness of merging the two messes together for the user.
http://mplayerhq.hu/pipermail/ffmpeg-devel/2016-June/195732.html
“The most important one is that we don’t want our users to have to choose between two distributors of libraries of the exact same name in order to have a different set of features and bugfixes. By taking the responsibility of unifying the two codebases, we allow users to benefit from the changes from the two teams.”
Thank for the notification, it’s a pity such document appeared that late. Maybe there will be a bikeshed and some more things will be clarified.
@Mandarinka but that is the whole point of open source! Forking, and freedom of choice!
Think how many successful projects came out of successful because they forked!
Just to name a few OpenSSL/LibreSSL, OpenOffice/LibreOffice, Netscape/Firefox, khtml/webkit, XFree/XOrg!
With the merging process, any possible competition is being neutered, and a fundamental right of the users is negated!
@Mandarinka That’s the biased idea of somebody that takes lots of work from another project and does not even thanks for it.
“For the user” is yet another “for the greater good” justification to do whatever one wants and feels good about it.
@koda
Competition is only good for the users if one of the codebases quickly dies or the schism is sorted out by remerging (happens very seldom I think, with compiz IIRC?) or otherwise.
Else you just have two sets of features and you have to select which one you will be able to use and which ones you won’t be able to. Don’t you see how for me, the end user, that sucks?
Since 5 years have passed (yikes) and both groups keep going, apparently the competition failed to bring a succesfull end of the “two popes” snafu.
And besides end users, I don’t think that developers of other software depending on your codebase share your enthusiasm wrt competition, either.
Actually, since you use the “competition being neutered” point… isn’t merging libav just something that ffmpeg was pushed into exactly by the forces of competition you are appreciating here? And from my PoV, us end-users did benefit indeed.
Maybe what is happening is not that competition is being neutered, but the opposite. I guess that their merging is putting competitive pressure on you, in turn? In that case, nothing bars you from responding with the same and merging their stuff. You know, competition will make both codebases better.
(But maybe you just made to go too deep into this silly debate.)
@Mandarinka sorry, I believe you have a different definition of “competition” than mine. A positive competition is when two projects are allowed to focus on what they want and carry out whatever they want to do. If a project shamelessly takes whatever the other project does, without returning anything back, it’s not competition, it’s parasitism.
As you say, the only ones to benefit from the situation are the ffmpeg users but only those ones who hate libav developer for whatever reason. And I interpret the merging process the opposite as you do, the competitive pressure forces ffmpeg to merge from libav daily because they are afraid of becoming irrelevant, and missing important features that they need (be them user facing or dev facing).
And by your reasoning, it means that Chrome and Firefox should be dead by now, since Internet Explorer is the oldest and best browser. And what about llvm and GCC? Should they disappear in a fire too?
The reality is that open source is all about choice, both for the user and for the developer, but in this case one project decided to neglect this right. And after years of this, the only losers in this conflict are you, the users.
I think you don’t properly gauge what competition and competetive pressure means at all, and how the competition pressure on the competitors look. No, it is not supposed to be comfortable or enjoyable.
Chrome and Firefox are different case. They are completely different programs, not forks of the same.
That stuff about ffmpeg destroying right of choice or competition is just weird to me, I don’t get reasoning behind that at all, frankly.
@Mandarinka. Well, let’s start with definition of the terms then.
Competition (definition from The Oxford Dictionaries): the activity or condition of striving to gain or win something by defeating or establishing superiority over others. I.e. when you have several parties that try to grab something (e.g. prize) or bigger share of something (market, attention, fame etc).
Positive competition is obviously not defined but it’s supposed to mean a competition that leads to some common good, not just for the winning competitor (in this case—users?).
Competitive pressure is hard to define but it’s probably can be formulated through the losses to the competing side (i.e. if I don’t win or decrease my share of something will it lead to some losses that I need to consider and thus try harder to prevent them?). I believe that in this case it’s a very subjective thing and differs much for both projects.
Now let’s sum it up. Is there a competition? Yes, for the user base and for developers. Is there competitive pressure? Yes, but it seems to be more for FFmpeg side because Libav seems to be relaxed (even after not being the library of choice in Debian anymore). Is there a positive competition? No, I don’t think so because FFmpeg with its actions is actively hurting everybody: there’s self-imposed punishment on its developers who do merges, at least two of Libav developers left because their code was merged with no feedback—even if it’s allowed it doesn’t mean it’s moral, because of their actions both projects were denied participation in GSoC etc etc. And whether projects are based on the same code is not relevant—look at the Linux distributions and if that’s not enough look at BSD.
Market style competition is never to the good of the participants, hence why there are rules that bar them from using anticompetetive practices and why most companies try to find ways how to mitigate the competition – they tray to make products with some sorts of exlusive features, or try to lock consumer in somehow, or they try to manufacture brand strength that works more religiously than based on practical criteria.
Market competition is only beneficial for the customer, because it is a factor that forces the competitng producers to lower prices, offer better products, to literally compete for the same resource (demand, buyer). As you know, competition leads to companies going out of business or losing profits, as opposed to monopoly, cartel schemes, or situation like Apple where the marketing plots managed to create an image of specialness…
I don’t think that the idea of “positive competition” can be used with regard to the producer, those are always going to be hurt by the competition.
The part about developer resources being wasted is true (that merge document admits it IIRC?). But that since competition always does that, that doesn’t make it bad. Good competition for consumer = bad things for producer/seller.
———————————–
Anyway I think arguing about the competition idea kinda obscures this. Since this isn’t business but FOSS and the producers don’t charge money from user, the good thing for users would be some balance between the satisfaction of both sides. You say that ffmpeg suffers because they need to merge and libav suffers because it hurts their feelings. Well, the reason for that is the schism. (Get rid of it?)
But as for us, users of ffmpeg would hurt if you guys had your way and both libav and ffmpeg diverged completely. Users of libav I guess hurt already.
TBH I don’t think that Libav is rational there, with taking offense and feeling wronged as you describe. First – it is GPL and somebody above mentioned freedom (and even forking I think). So the “they don’t thank me” argument, idunno.
Second – ffmpeg grumbles that the existence of split causes work if they decide to merge the other side’s commits. It is kinda okay to grumble since that is real work, but they just grumble for themselves? I don’t think they come to say to you: “stop your development, it annoys us”. In comparison – libav guys complain that the other guys do work they are lazy/unwilling/opposed to do. That is a bit weird or dishonest, isn’t it? Kinda like a company complaining that the other sells more beer for 1 € and saying it is not fair. You (or libav) basically do that “stop your development, it annoys us [even though it doesn’t cause us to do any work, really]” speech, when you insist that for this or that reason, ffmpeg should stop their merges.
And now you’re starting to twist terms. What I wrote was a generic model of competition applicable to market, sport even romance.
“Market competition” as you put it doesn’t work well here because it implies that you get a reward for controlling market share. And what do we have here? Money—for selected developers only, ego stroking maybe?
> I don’t think that the idea of “positive competition” can be used with regard to the producer…
I agree and that’s why I defined it “for common good”. Like with cars in old days—every manufacturer tried to improve his models and in results modern cars are much better than the original Benz model. And don’t people gain from that?
Monopoly is just a case of competition ending because someone has won enough (just think of immortal sports team that has much more experience than other teams so it wins every time—isn’t that monopoly in that sport too?). Yes, that is quite often sad but that’s what people want sometimes (like you want to have one ultimate solution instead of two distinct ones) and the only way to prevent monopoly or oligopoly is to have rules and an entity to control players and enforce the rules when needed. Otherwise you get free market or a situation similar to the free software world.
> Good competition for consumer = bad things for producer/seller.
It’s the consumer who judges the competition. If the producer doesn’t win their heart that producer loses. And that’s not bad, that’s logical.
> Anyway I think arguing about the competition idea kinda obscures this.
On the contrary, this is clarification—who does what and such. If you disagree that there’s a competition between FFmpeg and Libav then you have to define what is that—revenge, war or simply parasitism (I’m fine with any your point of view as long as you can clarify what you mean and why you think so).
I cannot speak for Libav developers since I’m not one of them any more but from my point of view while there is nothing wrong from legal point of view with what FFmpeg does, it feels morally wrong. Here’s an analogy—yes, the world benefited from Marconi’s radio but it was based on the work of various engineers around the world like Tesla or Popov whose work he simply used without even giving credit and there were virtually no improvements by him. And some of those engineers made their work available for free so it was no stealing either (in some cases). Make the moral yourself.
@Mandarinka you are totally missing the point, but since you are such perfect fan I guess it is expected.
I like to spend my spare time working on a project I like with the rules I like (I do not like bullies, I do not like people that feels entitled to be more equal than others after all), that project is Libav.
I would not care about FFmpeg, but random people keep asking me about it, send me email ordering me to do what’s my “duty” in FFmpeg assuming they are entitled to receive free support and in general wastes my time asking me question about a project I do not belong to.
Surely I do not like being depicted to be the EVIL guy because according some body taking my stuff I’m making harder for him doing that (I like it even less since such guy is asking and taking money for doing that) so I do not appreciate what you and other fans keep spouting around.
Since the people involved in Libav do what they do mostly in their spare time some decided to quit since being harassed by FFmpeg fans made it not worth it.
Is that easier to understand?
No, that is not hard to understand.
But it sounds to me you have problem with
1) bullies. Do those actually come from FFmpeg to pester you? Well, according to what peepz in #Darkhold say about him, the Carl E. H. of Kostya’s might, heh.
2) misinformed random people sending you misinformed email and whatnot.
3) Somebody saying stuff about you that you don’t like (thanks for my nice new sticker, btw).
4) ffmpeg fans… harrassing you? Hmm, aren’t you making a bit of a drama here, seriously? You don’t have to go into a debate with me, if you don’t like it, you know. I just stated my opinion here but it is not like I am important in this or anything, you know?
So in those 4 points – where exactly do FFmpeg’s merges come into play? I don’t see how they would cause any of those four problems for you. Yet you vigorously complain specifically about them and even lead long debate with somebody totally random that dared say these merges are good specifically for him. (I mean, was there really a reason to debate that? I think we both wasted a lot of time.)
Rhetoric question (because I intend to stop bugging you and will try to not comment further, although when you say dubious things it provokes me) – are you really bugged by the merges themselves, or do you just generally mind FFmpeg and wish it disappeared? Granted, that would not be nice to say in public, but might help you if you admit it just to yourself 🙂 o/
From what I heard it would be enough if FFmpeg went into its own direction and forgot about Libav existence at all (maybe it would be better even for users let alone FFmpeg developers).
Anyway, this should be a good time to close comments.