Re: Reintroducing FFmpeg to Debian
Hi Vittorio On Thu, Aug 28, 2014 at 12:45:42AM -0400, Vittorio Giovara wrote: On 12/08/2014 18:30, Michael Niedermayer wrote: Also ive offered my resignation in the past. I do still offer to resign from the FFmpeg leader position, if it resolves this split between FFmpeg and Libav and make everyone work together again. Hi Michael, sorry to come late to the party, but I just wanted to say that I am very glad that you think in this way. I do not fully understand why this could not have happened three years ago, but let bygones be bygones. For what is worth, in my personal opinion, you could even stay appointed as the leader, after all noone better than you represents the ffmpeg way of thinking, and you've got some PR skills which are rare to find in technical people. However there are other more practical problems. For example, FFmpeg merges patches daily and this over time has created a somewhat difficult to navigate git tree, it's enough to go back one year that you start having 4 or 5 layers of branching and bisecting is more complex than it needs it to be. The true history is complex, theres not a single linear chain of changes after the fork. But thats no problem for git bisect, git bisect has actually no problem with that at all. As someone who uses git bisect i can say it works very well, also i know from carl, who does more bisecting in FFmpeg than i do, that git bisect nowadays works very well in pratice with the tree. I am not saying that the theoretical merged project should use Libav tree either, but would you cooperate in the creation of a single linear history where merges are not allowed? The history is not a single linear chain of commits, the only way by which one can make it into one is by rebasing commits and making the actual (non linear) history harder to access Right now, you can bisect in ffmpeg git and the bisect can identify if a bug came from a commit in libav, one from ffmpeg or from a merge (unless some checkout cannot be tested), this will not work with a single linear chain of commits. also it would break everyones checkout, it would break every fork of FFmpeg and Libav on github, every developers private git tree and every reference to a git checkout in bug reports or mailing lists. And no this is not a neccesary thing to happen for a combined FFmpeg+Libav project If you just checkout libav and do a git merge ffmpeg/master you would effectively change libavs checkout to match ffmpeg and nothing would break. You still could Change anything in that checkout you like, like for example to rename all FFmpeg to Libav or revert any hunks that the merge brougt in which you dont like. and rewriting 3 years of history of 2 active projects to somehow interleave their commits could easily (depending on how its done) turn commits/checkouts that once worked and where tested into no longer working ones. Which would render debuging and bisecting a quite unpleasant thing to do. So to awnser your question, I think noone should spend time on creating such linear history, It could be alot of work to do and cause more work once done. Time could be spend much better in improving code and fixing bugs. That is i think we (FFmpeg and Libav) should not go this direction. But if we do go this direction, sure ill walk with the community. Also history drifts away, assuming the projects would reunify. In a few years noone would even notice in daily work that there where 2 forks in the past. Like noone notices how messy commits where 10 years ago by todays standards Other problem might be the name of this shared project, it's clear that the ffmpeg of the past ended with the split and the mpeg term is a company trademark anyway. I think /ffav/ would not sound that bad and would represent the new spirit of this collaboration, where everyone is treated as equals and respect each other work (and person). The part i insist on though is that everyone must be able to work on their code without people uninvolved in that specific parts maintaince or authorship being able to block their work. I don't think anyone would object to that, but there are of course many more problems to unwind. This might be quite long (and perhaps tedious) to discuss by email, so I would think that the best place to talk about a possible merge would be at the upcoming VDD in Dublin, where the whole group could meet, discuss problems, outline the new project policies and design goal and similar topics. git log | grep '^Author:' | tr '[:upper:]' '[:lower:]' | sed 's/.*//'| sort | uniq -c | wc gives 1155 now some of these are duplicates and some have just 1 commit in FFmpeg/Libav but still the maybe 10-20 or so FFmpegLibav developers who might be at VDD are quite far from the whole group and while i think discussing the Libav-FFmpeg split and ways to resolve it at VDD makes a lot of sense, quite litterally more than 90% of the developers wont be there. I also wont be there also iam
Re: Reintroducing FFmpeg to Debian
Hi Vittorio also please dont remove ffmpeg-devel from the CC I had missed that you removed it so my reply went just to debian-devel full quote left below for ffmpeg-devel, no further inline comments below Thanks On Fri, Aug 29, 2014 at 07:17:55PM +0200, Michael Niedermayer wrote: Hi Vittorio On Thu, Aug 28, 2014 at 12:45:42AM -0400, Vittorio Giovara wrote: On 12/08/2014 18:30, Michael Niedermayer wrote: Also ive offered my resignation in the past. I do still offer to resign from the FFmpeg leader position, if it resolves this split between FFmpeg and Libav and make everyone work together again. Hi Michael, sorry to come late to the party, but I just wanted to say that I am very glad that you think in this way. I do not fully understand why this could not have happened three years ago, but let bygones be bygones. For what is worth, in my personal opinion, you could even stay appointed as the leader, after all noone better than you represents the ffmpeg way of thinking, and you've got some PR skills which are rare to find in technical people. However there are other more practical problems. For example, FFmpeg merges patches daily and this over time has created a somewhat difficult to navigate git tree, it's enough to go back one year that you start having 4 or 5 layers of branching and bisecting is more complex than it needs it to be. The true history is complex, theres not a single linear chain of changes after the fork. But thats no problem for git bisect, git bisect has actually no problem with that at all. As someone who uses git bisect i can say it works very well, also i know from carl, who does more bisecting in FFmpeg than i do, that git bisect nowadays works very well in pratice with the tree. I am not saying that the theoretical merged project should use Libav tree either, but would you cooperate in the creation of a single linear history where merges are not allowed? The history is not a single linear chain of commits, the only way by which one can make it into one is by rebasing commits and making the actual (non linear) history harder to access Right now, you can bisect in ffmpeg git and the bisect can identify if a bug came from a commit in libav, one from ffmpeg or from a merge (unless some checkout cannot be tested), this will not work with a single linear chain of commits. also it would break everyones checkout, it would break every fork of FFmpeg and Libav on github, every developers private git tree and every reference to a git checkout in bug reports or mailing lists. And no this is not a neccesary thing to happen for a combined FFmpeg+Libav project If you just checkout libav and do a git merge ffmpeg/master you would effectively change libavs checkout to match ffmpeg and nothing would break. You still could Change anything in that checkout you like, like for example to rename all FFmpeg to Libav or revert any hunks that the merge brougt in which you dont like. and rewriting 3 years of history of 2 active projects to somehow interleave their commits could easily (depending on how its done) turn commits/checkouts that once worked and where tested into no longer working ones. Which would render debuging and bisecting a quite unpleasant thing to do. So to awnser your question, I think noone should spend time on creating such linear history, It could be alot of work to do and cause more work once done. Time could be spend much better in improving code and fixing bugs. That is i think we (FFmpeg and Libav) should not go this direction. But if we do go this direction, sure ill walk with the community. Also history drifts away, assuming the projects would reunify. In a few years noone would even notice in daily work that there where 2 forks in the past. Like noone notices how messy commits where 10 years ago by todays standards Other problem might be the name of this shared project, it's clear that the ffmpeg of the past ended with the split and the mpeg term is a company trademark anyway. I think /ffav/ would not sound that bad and would represent the new spirit of this collaboration, where everyone is treated as equals and respect each other work (and person). The part i insist on though is that everyone must be able to work on their code without people uninvolved in that specific parts maintaince or authorship being able to block their work. I don't think anyone would object to that, but there are of course many more problems to unwind. This might be quite long (and perhaps tedious) to discuss by email, so I would think that the best place to talk about a possible merge would be at the upcoming VDD in Dublin, where the whole group could meet, discuss problems, outline the new project policies and design goal and similar topics. git log | grep '^Author:' | tr '[:upper:]' '[:lower:]' | sed 's/.*//'| sort | uniq -c | wc gives 1155 now
Re: Reintroducing FFmpeg to Debian
Hi On Thu, Aug 21, 2014 at 03:16:50AM +0200, Attila Kinali wrote: Servus, On Wed, 20 Aug 2014 18:43:18 +0900 Norbert Preining prein...@logic.at wrote: By continuing old fights, inspite of the very clearly friendly and open offers and suggestions byu Michael, you and others from AV continue simply to insult and be nasty. Sorry, but this is not true. Yes, Michael always offers to mend ways and to do this and that. But he never does. It's just lip service. He didn't do it before the split and he didn't happen after the split. Theres something about your statements, the one above as well as the ones in other mails in this thread that i dont fully understand You said in this thread that i'm not a developer and have not written one line of code for libav. i dont even read the mailinglists (https://lists.debian.org/debian-devel/2014/08/msg00782.html) and IIRC you also didnt read the ffmpeg mailing lists in the time before the fork, except some specific threads, nor are you on the ffmpeg IRC channels and i belive you arent subscribed to the FFmpeg mailing lists now either. I definitly found a unsubscribe statement for your address from march 2011 in the logs. Given that, how can you even know anything about FFmpeg or what its developers do or say or not do or not say ? FFmpeg development discussions are mainly on our mailing list. with a tiny bit on our IRC channels I know you did read some specific threads which where related to the fork as you participated in them. But these where possibly the most heated and aggressive discussions we ever had on ffmpeg-devel. And certainly are not representative for FFmpeg either before or after the fork. Yes, the people at libav are bitter. Yes, they are angry. But how would you feel if people would walk up to you at random OSS events and tell you that X just told them you are the bad guy, that you steal childrens ice cream? (Yes, this has happend) I am really impressed by the ability of Michael to take this without changing into a more inpolite tone. Which you and others from AV are definitely doing. If you mean me by others, then i would like to ask where i have been impolite. * AV maintainers are averse o any cooperation, and just licking their wounds since several years You know, that FFmpeg and libav have been cooperating ever since the split? FFmpeg merges all (or almost all?) patches commited to libav without further review. normally (for example in the kernel) code is reviewed before it is pushed and not when it is merged. Yet i _try_ to review and test what i merge from libav. To proof that, here are some examples of bugfixes and decissions based on such reviews. These wouldnt exist if the code wouldnt be reviewed. 4 days ago: libav added some () to a condition: https://github.com/libav/libav/commit/d456baafb68cd80c0f537f1d843076e4dd853558 on the ffmpeg side the code was instead changed the following way a year ago http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=1e2ab98460761c86268993e7a7ee690876df5efd libav decided not to pick this change, and instead made their own different change as shown above and in the merge i tested both to double check that our solution is correct and libavs isnt, and kept our solution. More precissely libavs breaks decoding of http://samples.ffmpeg.org/ffmpeg-bugs/roundup/issue414/black_screen_VC-1.mkv or for example 16days ago libav fixed a few memory leaks https://github.com/libav/libav/commit/5b220e1e19c17b202d83d9be0868d152109ae8f0 but they used the wrong deallocation function, that is free() instead of av_free*() which can lead to memory corruption, Multiple people noticed that and it was fixed in the same git push that pushed the merge http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=92deb28945a5f2b58908d383f183cfc1bc1d7fae also there where multiple other related issues found when reviewing the change from libav which where fixed in ffmpeg in the same push as well: http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=12b59e57f3d7a37ef7b29d8a1df5eb886b00b4ba http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=31eaecfee9d84381945f3d5201775b9b00161d7a http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=92a28e9f562124732fa27f0c62118f15a6fee239 http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=5f8300afc6537e2e06f8f90989d5f268884bb79c but either way, id like to suggest again, we move forward and rather discuss how we can improve the situation, do something about the split and move toward un-doing it! Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature
Re: Reintroducing FFmpeg to Debian
On Mon, Aug 18, 2014 at 12:15:10AM +0200, Clément Bœsch wrote: On Sun, Aug 17, 2014 at 09:14:47PM +0200, Luca Barbato wrote: [...] Ive asked [1][2] back then what policy in place was broken - you tried to commit code that was blatantly below the already lax quality requirements (e.g. it contained tabs, it was (and still is) hard to read, it contains dubious, aka security-concerning, practices), I told you not to commit those as-is and you blatantly ignored me and the others against it. I'm referring to the mplayer filters. Weren't mplayer filters pushed post fork? I dont remember, they dont seem to be in the libav git history also there are no tabs in the mplayer filters in ffmpeg, and IIRC no security bugs in the filters have been found in them since they where pushed. Also its hard for there to be security bugs as they are only used when explicitly selected by the user - your interaction with whoever wasn't in full agreement with you was horrible, I told you for months in public and private, you seemed to agree just to behave in even worse way later. The interactions with Mans are probably the best example of this. Interactions with Måns and everyone else were also pretty terrible, to the point that he also left Libav in a rage quit (see #libav-devel on 2011/09/17 for related, when he left. Michael was not here). Note that I'm not saying this is the reason he completely left the project. - your interaction with whoever provided infrastructure service was horrible[1]. As Attila already stated here[2] and here[3] AFAICT this has nothing to do with the policy rules in place. There is no question i made mistakes 4 years ago, and no question i could and should have interacted with developers in a less abrasive way back then. Iam a technical person not a diplomat nor politican. [...] - you putting in FFmpeg pretty much every patch from every branch you can come by, including my incomplete work from github (you did for pulse and segment with interesting results, hopefully you won't do that again anymore). Yes, with full authorship, because those were requested needed in FFmpeg. Also, communication does not work with you (we FFmpeg are definitely ignored by most of the people on Libav); this means that obviously we are not going to annoy you for information or status about your progress. May I remind you that Michael is banned from the mailing-list, IRC and some of the developers repositories? Why would you expect him to even try to communicate with you about these contributions? also about pulse, we did take lucas incomplete code but the current code we use is quite different from that and has evolved alot. The original used the simple API from pulse pulse/simple.h, FFmpegs current code does not. Also i think our current code is more based on work by the pulse audio developers and Lukasz Marek than lucas original. And theres pulse input and output support in FFmpeg, the original code from luca and libav only support input through the simple API [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature
Re: Reintroducing FFmpeg to Debian
On Fri, Aug 15, 2014 at 01:19:38AM +0200, Luca Barbato wrote: Stefano Sabatini wrote: [...] The list is quite long and debunking each of the statements could take a lot of time. I'm going to address two historical misrepresentations: # The change of management Michael Niedermayer managed to get demoted from his leader position by the topmost 18[1] people involved in FFmpeg by the time due his tendency of not following the rules. that after weeks from being voted to stay as leader by 15, 5 explicitly stating their vote was conditioned by his behaviour and 1 definitely against him.[2] There was a vote on the ffmpeg-devel list, everyone can recount the votes although its probably a bit work to do given its a large thread with lots of other discussions (the links below point to that thread) I dont remember the exact numbers but there was a majority in support of me in all possible variants in which one could count the votes That said, i dont mind if people like to see me as dictator His demotion is due to acts in full disregard of the policies in place, Ive asked [1][2] back then what policy in place was broken IIRC noone pointed at anything thats part of the written policy[3] Some good suggestions where made in the discussion though. And the policy was somewhat amended toward them [4]. In retrospect, bigger changes should have been made to the policy if that had avoided the takeover attempt and fork, but the takeover attempt came a bit out of the blue, at least for me and it definitely left the feeling that there was more interrest in seizing the opertunity for a takeover instead of discussing and amending the policy. Also i remember alot more discussions about whitespaces than patch review policy from that time. even those enforced automatically by the svn hooks. yes, we wanted to check in some files that would be shared between mplayer and ffmpeg, and for ease of syncing changes between them either tabstrailing whitespace had to be removed from mplayers side or the svn hook in ffmpeg would have needed an exception They where removed from mplayer in SVN rev 32789 and 32790 The commit message of 32789 Convert some tabs to whitespace to allow using MPlayer filter sourcecode in FFmpeg. [...] you shouldn't be surprised that there was (and still there is) a perceived hostility between the two projects. If you or other Libav or FFmpeg developers want the two projects to collaborate more, this can be discussed, possibly with *specific* proposals, but again, debian-devel is not the right place where to discuss such things. Personally I have no problems in collaborating with anybody. Then i think we should reunite the projects with some common development policy most are happy with. PS: please spare the world of these defamation attempts and i also think we should look forward and solve the issues we have now and not fight over what happenend 3-4 years ago or who made more mistakes ... [...] [1] http://article.gmane.org/gmane.comp.video.ffmpeg.devel/118606 [2] http://article.gmane.org/gmane.comp.video.ffmpeg.devel/118652 [3] http://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/developer.texi;hb=f2c44ad51160da4c0c27429e874265c0dff3d117#l122 [4] http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7c0460496b5eeb1713f00c00e2e61b420bb928e7 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 15, 2014 at 02:53:09PM +0800, Thomas Goirand wrote: On 08/14/2014 11:59 PM, The Wanderer wrote: On 08/14/2014 11:27 AM, Thomas Goirand wrote: On 08/13/2014 07:53 AM, Kieran Kunhya wrote: On 08/13/2014 06:30 AM, Michael Niedermayer wrote: Also ive offered my resignation in the past. I do still offer to resign from the FFmpeg leader position, if it resolves this split between FFmpeg and Libav and make everyone work together again. Why not just take the offer, and move on? Probably because of the condition he attached to it, which also dates back to the arguments preceding the original split: The part i insist on though is that everyone must be able to work on their code without people uninvolved in that specific parts maintaince or authorship being able to block their work. In other words, as I think I understand it from the discussion back then: people not involved with a particular area of the code can't NACK the work of someone who is working on it, and someone who works on a particular area of the code doesn't have to wait on review of people who aren't involved with that area of the code. Since one of the motivations of the people behind the libav side of the split seems, IIRC, to have been no code gets in without having been reviewed by someone other than the author, this was apparently deemed an unacceptable condition. Hum... Well, to me, what's important is that the code gets peer-reviewed. Yes, the tricky part in FFmpeg and Libav in relation to this is that theres quite a bit of code that is only well understood by a single person even if you would combine both projects together. So if that person posts a patch for review, theres noone who could do a real review Setting-up something like gerrit may help, as it can be setup in a way that review becomes mandatory. Then discussing who's core-reviewer and can approve this or that part of the code can be setup within gerrit. This should be discussed, and setup based on technical merit. Not commenting about gerrit as i dont have experience with it, but FFmpeg currently uses a simple file in main ffmpeg git that lists which part is maintained by whom, and these developers would in the rare case of a dispute have the final say in each area. OTOH, Libav early deleted their forked version of this file, and iam not aware of any replacement. But others should explain how it works in Libav ... Having a NACK review is often disappointing. It goes the wrong way if there's only a NACK with no comments on how to improve things, so that the code becomes acceptable. Absolutely everyone should *always* be able to leave comments, be it positive or negative. yes, i fully agree and this also was always so in FFmpeg. In that sense everyone is welcome to subscribe to ffmpeg-devel and review and comment patches. That of course includes Libav developers and everyone else. And more reviewers would also certainly help, so yeah anyone reading this and wanting to help review patches, you are welcome! Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi On Tue, Aug 12, 2014 at 05:13:17PM +0200, Attila Kinali wrote: Hi, On Fri, 8 Aug 2014 08:16:24 -0500 Joe Neal vlvtel...@speakeasy.net wrote: On both servers and desktops, I've been a Debian user since Sarge. I use Debian not only because of its strong technical merits, but because of the strong sense of ethics the project has always had. A fork that tries to forcibly steal the name and infrastructure from the original project while ousting the original maintainer and a good number of developers is not ethical. This lie has been spread over the last few years and repeated multiple times. I would like to apoligize for being off topic and using debian-devel to debunk this lie. But for me, this is a personal insult. Back in 2004, when the main server that MPlayer used (and FFmpeg used as cvs repository only, nothing else yet) died, MPlayer started to collect donations to buy a new machine. FFmpeg joined the efford, as they used part of the same infrastructure. Thus end of 2004 a new server was bought by me and set up together with Diego Buirrun and Mans Rullgard. The server was set up at an ISP which were friends of mine as a personal favor. Also, legally, the server was registered under my name, as MPlayer (who officially owned the server) was not legal entity. In the following years most of the infrastructure used by MPlayer and FFmpeg were provided by Mans Rullgard, Diego Petteno, Luca Barbato, my brother, a dozen of my friends and me. These included stuff like mirrors, blogs, testing infrastructure, DNS and mail servers, etc. I.e. almost everything that MPlayer and FFmpeg used as their infrastructure were linked to just 4 people: Mans Rullgard, Diego Petteno, Luca Barbato and me. I would like to point out that none of my friends nor my brother ever had any relationship to MPlayer of FFmpeg, beside knowing me. I also want to point out, that up to 2011, the main server on which most stuff run was considered beloning to MPlayer with FFmpeg being a paying guest. That was also the reason why everyone refered to the server as mphq back then. In 2011, when the split happend, the three people who were root on mphq (Diego Biurrun, Mans Rullgard and me) and Luca Barbato were signatories of the document that was the first public start of the split[1]. The one missing name from that list, Diego Petteno, was also of that group that later became libav, but did not sign the mail as he didn't consider himself an FFmpeg developer. At that time, we (we being root, ie Mans Rullgard, Diego Buirrun and me) explicitly tried not to involve MPlayer at all, because we thought of this as an FFmpeg internal issue. That's why mphq (the server) was otherwise untouched. [3] Unfortunately, in April 2011, Michael Niedermayer threatened to sue me personally over a redirection on the MPlayer homepage (for some reason http://ffmpeg.mplayerhq.hu redirected to http://libav.org), which i was not even aware of that it existed (i was not involved in the website at all, beside keeping the webserver running). Incidentally, he claimed to write to me in the name of all MPlayer maintainers. Because i didn't want to waste my time and money in a pointless legal battle, i decided to end my, over a decade long, involvement in MPlayer and shut down mphq after some grace period to give them time to move the services to an other server[2]. attila, you know me, we met in person before the split, i would never sue you, i dont understand why after 3 years you still think so. also i had stated that immedeatly after the mail you quoted back then http://article.gmane.org/gmane.comp.video.mplayer.devel/59284 I wont sue you or anyone else from libav. Iam a boring geeki guy spending most of the day and night infront of my computer, i dont sue people, even less so other free software developers. As you can see, all the infrastructure that people claim have been stolen, misapproriated etc belonged to people who were of the libav camp in the first place. And naturally, this infrastructure went with them in the split. (would you invest your time and energy into maintaining infrastructure for a project where its main proponents call you a lying pig and threaten you with their lawyers?) i dont even have a lawyer, i never needed one and i sure hope i never will. The closest i got to needing a lawyer was when i got a snail mail from one of the root admins lawyers about the ffmpeg logo but lets not follow that path of mudslinging, that would only make any resolution of the ffmpeg / libav conflict harder. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, Aug 12, 2014 at 09:45:37PM +0200, Attila Kinali wrote: On Tue, 12 Aug 2014 10:44:35 -0500 Joe Neal vlvtel...@speakeasy.net wrote: When this happened I scoured the net, including mailing lists from both projects to try and figure out what had happened. The overwhelming evidence based on mailing list posts, blog posts, forum discussions and pretty much everywhere else I could look all led me to the overwhelming conclusion of what I stated before. This is the only time I've ever seen anything to the contrary stated and I looked good and hard for another side of the story, as have many other people. Part of the reason for this is that the people around libav decided that they didn't want to participate in the mudslinging. Only the most blatant lies were refuted and all the name calling was mostly ignored. In hindsight that was a mistake. I still don't know who is in the right, but at least you've put an end to the weirdness where only one side of the story existed on the net and there was just conspicuous silence on the other. I'd like to give here a short account on what happend before the split, even though this not the right place. I think i should write up something longer after my vacations and put it somewhere online. Before 2011 there were quite a few issues within FFmpeg. Most of those revolved around Michael Niedermayer playing by his own set of rules and ignoring the advise of everyone else. His behaviour has resulted in quite a bit of ... anger.. to put it mildly. A few people left because of him. Heck, even i wanted to leave everything that was related to FFmpeg in any way, even though all i did was keeping the server running and was not involved in the development or anything else at all. Its a long time ago, but IIRC when i asked about what rules it was that where broken back then it was a mix of silence and someone who admited he mixed the rules of FFmpeg up with another project. Also ive offered my resignation in the past. I do still offer to resign from the FFmpeg leader position, if it resolves this split between FFmpeg and Libav and make everyone work together again. I never understood why people who once where friends became mutually so hostile The part i insist on though is that everyone must be able to work on their code without people uninvolved in that specific parts maintaince or authorship being able to block their work. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi On Sun, Aug 10, 2014 at 09:10:23AM -0400, Reinhard Tartler wrote: On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs matth...@urlichs.de wrote: [...] IMHO it's reasonable to expect core APIs to be upwards-compatible and keep deprecated interfaces around for another release or two. This is exactly what Libav is doing: The deprecation process for symbols, APIs, enums, etc. takes *years*, because so many software packages in Debian and else where use them, and it is so believably painful to change them. Just have a look at the last two Libav transitions, and the massive amount of patches it took to get packages fixed and eventually to get Debian to the new Libav release. Now enter FFmpeg. FFmpeg has a significant higher release frequency, (it seems to me about every 3-4 months), so that you would get a deprecation cycle that is considerably less than a year. In practice, the deprecation cycle more or less seems to match Libav's cycle, because at least right now, FFmpeg tracks Libav's API. If that were not the case (and I promise you FFmpeg would stop tracking Libav as soon as it replaces Libav in Debian), I can almost guarantee [1] you that FFmpeg would very much prefer to resume to the deprecation cycle the project before: None, i.e., every piece of software is expected to keep up with FFmpeg's master branch for reasons Jean-Yves outlines. These fears are unfounded and these predictions not only do not match reality they also lack any reason or motive for FFmpeg. We would be shooting us in our own foot if we randomly broke API or stopped integrating improvments It has always been my wish to provide the best multimedia software to the world. And sure us including all improvments and bugfixes from Libav is in line with that. also you have write access to FFmpeg git ... and iam happy to work together with andreas and anyone else on debian lifecycle releases. And you are certainly welcome too [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, Aug 09, 2014 at 06:26:19PM +0100, Kieran Kunhya wrote: [...] ... and was designed by a larger group instead of libswresample which was basically one person (and literally appeared in git out of nowhere). For the record: $ git shortlog libswresample/ | grep '^[^ ]' Alexander Strasser (1): Andreas Cadhalpun (1): Andrew Wason (1): Carl Eugen Hoyos (4): Clément Bœsch (45): Derek Buitenhuis (1): Hendrik Leppkes (1): James Almer (19): Justin Ruggles (4): Lou Logan (2): Mans Rullgard (3): Martin Storsjö (1): Marton Balint (2): Matt Oliver (2): Michael Niedermayer (308): Nicolas George (8): Paul B Mahol (4): Reimar Döffinger (3): Rob Sykes (7): Ronald S. Bultje (15): Stefano Sabatini (6): Timothy Gu (10): jamal (2): $ git shortlog libavresample/ | grep '^[^ ]' Anton Khirnov (25): Derek Buitenhuis (2): Diego Biurrun (22): Hendrik Leppkes (1): James Almer (2): Janne Grunau (5): John Stebbins (2): Justin Ruggles (71): Luca Barbato (1): Mans Rullgard (4): Martin Storsjö (6): Michael Niedermayer (97): Peter Meerwald (1): Reimar Döffinger (2): Ronald S. Bultje (2): Thilo Borgmann (1): Tim Walker (2): [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: Digital signature
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Wed, Jul 30, 2014 at 02:12:25AM +0200, Andreas Cadhalpun wrote: On 30.07.2014 00:54, Russ Allbery wrote: Andreas Cadhalpun andreas.cadhal...@googlemail.com writes: I must have failed to make my point again. :( As far as I know there are hundreds of security updates (for all packages together) in the lifetime of a stable release. Compared to that 10 is not large. And, as I already mentioned, I think that some of the FFmpeg updates are minor enough to go through stable-updates. It doesn't make a software less secure, if (even minor) security fixes get backported even to old release branches, rather the contrary. Well... backporting security fixes more of a bare minimum -- that's just something that has to happen if we're going to support the software at all, with a handful of exceptions where the software is, for one reason or another, important enough that we're willing to release with it even though security patches aren't backported properly and then terminate support in the middle of our normal stable process. So it's good that FFmpeg upstream does that backporting. But software should also not pose a significant security load in the first place. That quantity of security vulnerabilities tells me that something is deeply wrong with FFmpeg as an upstream source base. That's a sign of code with a bad smell. In my opinion the large amount of security fixes is due to the fact that FFmpeg is a large codebase and that most of the code has to deal with untrusted data, a.k.a. multimedia files. Now, that doesn't necessarily mean that it doesn't belong in Debian. Sometimes we have to hold our nose and live with that, and it sounds like libav isn't necessarily a lot better. On the contrary I think that Libav is worse, as it doesn't even apply all patches for security vulnerabilities fixed in FFmpeg that also affect Libav. Just have a look at the security tracker of Libav[1]. But those are really painful statistics that, to me at least, indicate the world is crying out for a replacement code base that accomplishes the same goals but was written with a higher level of quality in mind. Obviously easier said than done, of course. The time needed to do that would likely be spent a lot better with trying to find and fix the remaining vulnerabilities in FFmpeg, because any rewrite of such a large code base inevitably introduces it's own security bugs. Is upstream aware that this is a really bad track record and trying to do something proactive to increase the quality of the code, like comprehensive auditing, or proactive rewrites to use more secure coding practices such as some of the work that the LibreSSL team has been doing? On 30.07.2014 01:01, Russ Allbery wrote: Ah, I should have Googled my own question. http://googleonlinesecurity.blogspot.com/2014/01/ffmpeg-and-thousand-fixes.html Well, that's... better than nothing. It's certainly part of an overall strategy, although that number of issues still indicates to me that there are style and architecture issues here that could benefit from more proactive design work. I could be wrong, having not looked at the code personally -- maybe the problem space is just really hard. But that seems like quite a lot of errors. You could also have asked FFmpeg upstream. (I've CCed Michael Niedermayer now.) Yes the problem space is hard ... The problem with multimedia in relation to security is that * There are hundreads of different formats, requireing alot of code to support them * The input files and streams can generally not be trusted, which makes most of the code security relevant and a potential target for an exploit * Many and especially the most important and efficient formats are very complex * The code must be very fast, users want to see their movies play in realtime not waiting for each frame to be decoded. And most of the code is speed relevant Above applies to any implementation, and constrains architecture options ... What we do to combat that is All patches going into FFmpeg are reviewed with security in mind The codebase was repeatledly tested with fuzzed files to uncover all kinds of anomalies, all such found anomalies where fixed. Also independant of googles fuzzing efforts, some of our users have done their own fuzzing. And during google code in several students have as well manually tried to find security issues. FFmpeg is regularly tested with static code analyzsers like coverity and most issues found get quickly fixed FFmpeg is tested regularly with runtime memory checkers like valgrind, address sanitizer and others and all reproduceable issues are fixed, iam not aware of any open and reproduceable one Almost all of the internal APIs used in FFmpeg are designed to be secure, always passing array sizes and checking them instead of assuming the caller knows they are large enough, exceptions to this are just the most speed critical
Re: Bug#729203: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Jul 28, 2014 at 04:05:46PM +0200, Andreas Cadhalpun wrote: On 28.07.2014 13:52, Henrique de Moraes Holschuh wrote: On Mon, 28 Jul 2014, Norbert Preining wrote: On Sun, 27 Jul 2014, Reinhard Tartler wrote: In [1], Moritz from the security team clearly stated that he is more than uncomfortable with having more than one copy of libavcodec in debian/testing. In consequence this means that any package that builds against the ffmpeg packages currently in NEW won't make it into testing either. I am therefore surprised about the given answer to the More than uncomfortable does not mean will not be included Yes, it does. Someone will have to convince the security team somehow, likely by offering to do the work themselves _and_ convincing them that these new members will be around for long enough. Michael Niedermayer from FFmpeg upstream volunteered to help with any future security issues in FFmpeg packages in debian [1]. Yes, i do! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature
