Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 19/08/2014 04:50, Ondřej Surý wrote: P.S.: libav doesn't seem to be using Coverity Scan actively: https://scan.coverity.com/projects/106 (last scan was 4 months ago) FWIW if you (or anyone else) is interested in preparing and running a coverity scan on Libav out of curiosity, I can probably set you up, just let me know off-list. Cheers, Vittorio -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53febe1c.6040...@gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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! We look forward to seeing you in Dublin then. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAK+ULv47B21JMGwyjA66JEL46Aa=xhzafvzbhybugbk83tr...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/19/2014 12:45 PM, Clément Bœsch wrote: See: http://fate.ffmpeg.org/ http://coverage.ffmpeg.org/ The 2nd link to coverage (which should show the LCOV output, I guess) seems to be broken: I get a 404 Not Found :( Regards, Pb -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f464c1.9080...@das-werkstatt.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Wed, Aug 20, 2014 at 11:05:05AM +0200, Peter B. wrote: On 08/19/2014 12:45 PM, Clément Bœsch wrote: See: http://fate.ffmpeg.org/ http://coverage.ffmpeg.org/ The 2nd link to coverage (which should show the LCOV output, I guess) seems to be broken: I get a 404 Not Found :( Sorry about that, should be fixed. [...] -- Clément B. pgpfSXJUd4gfZ.pgp Description: PGP signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Thu, 14 Aug 2014 13:58:07 +0200 Stefano Sabatini stefa...@gmail.com wrote: If you trully want to mend ways, then you and your fellow FFmpeg developers should stop this constant spreading of lies, this defamation campaing against libav and its developers that has been going on for the last 3 and a half years and show at least the minimum respect you would show to a stranger you meet on the street. Until you do this, i see very little chance for a healthy cooperation. Please refrain from claiming other people are spreading lies, especially with no specific references (and this is not the place where to discuss such things). Carl Eugen just recently (2014-06-22) wrote on ffmpeg-devel: Sean supports the thieves [...] (http://article.gmane.org/gmane.comp.video.ffmpeg.devel/179271) Do i need to say more? I guess i speak in the name of everyone related to libav, that we would not mind if you kept saying that ffmpeg is better, faster, has more features, etc. That could be at least discussed on a technical, neutral level. What we mind are comments like that above, targeted solely at insulting and slander individuals. And as we can see from what Joe Neal wrote, the often repeated lie becomes truth soon enough. Then you should be aware that the way the Libav fork was created was hostile towards FFmpeg Actually, no. The whole thing started as getting Michael off his throne and to stop him screwing the whole project. It was not ment to be a fork. Attila Kinali -- I pity people who can't find laughter or at least some bit of amusement in the little doings of the day. I believe I could find something ridiculous even in the saddest moment, if necessary. It has nothing to do with being superficial. It's a matter of joy in life. -- Sophie Scholl -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821025941.3d660cf65d862194d54da...@kinali.ch
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, 16 Aug 2014 17:11:29 +0200 Nicolas George geo...@nsup.org wrote: The most galling in this issue is that there is no clear decision behind this orientation. The fork's manifesto stated that everyone was equal amongst equals, with or without commit rights, but the people who do have the commit rights are few and of a common mind, they can just give the cold shoulder to proposed changes that do not suit their personal view of the project. Err... If i counted correctly, there are currently 21 people who have commit rights to the libav repo. If you call that few i would like to know what you would consider as many? Also, i can asure you, that they are not of one mind. There are many fights on how to do things and whether a patch should go in or not. Heck, they are visible even to someone like me, who sits at the sidelines (i'm not a developer and have not written one line of code for libav. i dont even read the mailinglists). Considering these differences in policy, I do not believe the fork can be merged. Speaking as someone who proposed a few of these unnecessary features, because they were fun or immediately useful, I would not like to work on a project that would reject them by principle. Though a program be but three lines long, someday it will have to be maintained. -- The Tao of Programming Attila Kinali -- I pity people who can't find laughter or at least some bit of amusement in the little doings of the day. I believe I could find something ridiculous even in the saddest moment, if necessary. It has nothing to do with being superficial. It's a matter of joy in life. -- Sophie Scholl -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821033523.75a022d583c077c3f8bef...@kinali.ch
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, 18 Aug 2014 13:42:36 +0200 Nicolas George geo...@nsup.org wrote: The reason for switching from FFmpeg to libav in the first place just after the fork is much simpler than that. Yes, the reason was that Reinhard, who was the maintainer of the ffmpeg package back then, was on the libav side after the split. BTW: for those who do not know. Michael raised the issue of the ffmpeg - libav switch at ubuntu back then [1]. The technical board decided to go with the decision of the package maintainer [2,3,4]. I think most people will find [3] the most interesting, as it explains why Reinhard thought (and still thinks) that libav was the better choice. Attila Kinali [1] https://lists.ubuntu.com/archives/technical-board/2011-April/000794.html [2] http://irclogs.ubuntu.com/2011/05/19/%23ubuntu-meeting.html#t19:10 [3] https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html [4] http://irclogs.ubuntu.com/2011/06/02/%23ubuntu-meeting.html#t19:01 -- I pity people who can't find laughter or at least some bit of amusement in the little doings of the day. I believe I could find something ridiculous even in the saddest moment, if necessary. It has nothing to do with being superficial. It's a matter of joy in life. -- Sophie Scholl -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140821035247.c8b056da7130982bdefad...@kinali.ch
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Attila, I will do a small self-intro, as you most likely don't know me: I am a high school student who mainly writes documentation for FFmpeg, but sometimes do small code fixes and patch review (mainly related to documentation), both for FFmpeg and Libav. I sent my first patch to FFmpeg last year in March. I don't know much about the split, but I have read the most important discussions on ffmpeg-devel on the split. On Wed, Aug 20, 2014 at 6:52 PM, Attila Kinali att...@kinali.ch wrote: On Mon, 18 Aug 2014 13:42:36 +0200 Nicolas George geo...@nsup.org wrote: The reason for switching from FFmpeg to libav in the first place just after the fork is much simpler than that. Yes, the reason was that Reinhard, who was the maintainer of the ffmpeg package back then, was on the libav side after the split. BTW: for those who do not know. Michael raised the issue of the ffmpeg - libav switch at ubuntu back then [1]. The technical board decided to go with the decision of the package maintainer [2,3,4]. I think most people will find [3] the most interesting, as it explains why Reinhard thought (and still thinks) that libav was the better choice. Most, if not all of the reasons in [3] have been eliminated, so bringing this up only causes more confusion. Also, the discussion appeared during a time when FFmpeg had flamewars, mainly from Libav developers. Because the split was just forming, FFmpeg was not that different from Libav then. It is not fair therefore to compare the two projects at that time. However, there are technical advantages towards FFmpeg now. Also, keep in mind that Debian cares about maintainable (and maintained) code **now** more than how a project leader behaves (or rather, behave_d_). I will now quote and explain how Reinhard's mail does not apply to the current FFmpeg/Libav situation. Reinhard Tartler wrote (https://lists.ubuntu.com/archives/technical-board/2011-May/000891.html): On various occasions [Michael Niedermayer's] quite strict rules on code quality and reviews doesn't seem to apply to him This has not been the case since the split (at least within the past year, as I joined FFmpeg last year). There are still some post-commit oopses, but not nearly to a level that brings a discussion among developers. After the fork, Michael has insulted almost everyone involved with founding Libav at least once, used libel and death threats as 'jokes', I don't mean that I don't believe your insulting story, but there is no public mailing list archive or IRC log or anything that supports this. Even if Michael did these terrible things, he is certainly not doing it now. The only insult I can find is in the thread you mentioned https://lists.ubuntu.com/archives/technical-board/2011-May/000900.html , which is an insult from Mans Rullgard, a former Libav developer and former former FFmpeg developer. but OTOH keeps merging the work done at Libav both with and without insults. I am interested to see any evidences to back up this statement. Note that Michael does sometimes express disagreement with Libav commits, but that's only because of technical issues, at least within the past year. Also from this quote Reinhard seems to not like the spirit of LGPL... Interestingly, his standards and attitude to external work have totally changed: He has committed his mplayer filter wrapper despite predominant rejections, This is one of the most significant sources of new filters, and one of the reasons users (like me) use FFmpeg. ffmpeg-mt has been merged (partially with wrong attribution!) I can't comment on the mistake in attribution as I was not involved in FFmpeg during that time, and I am sure it is fixed (besides Git history, which is unfortunately unfixable). But the only people I have seen stripping attribution is Libav during their cleanups, and Michael is actively restoring lost attribution: http://git.videolan.org/?p=ffmpeg.gita=searchh=HEADst=commits=attribution See for example http://git.videolan.org/?p=ffmpeg.git;a=blobdiff;f=libavcodec/me_cmp.c;fp=libavcodec/dsputil.c;h=9fcc93739a7c76fea5906bae94c174de558c132b;hp=ba71a99852d8f3fbad25f8ea7b4947e18e5592cd;hb=2d60444331fca1910510038dd3817bea885c2367;hpb=a578b0407dc983aecd72028e1127062689b67089 among others. despite various tests still failing (when running them with more than one thread), just to name a few. Well it doesn't fail anymore now, so this is not a viable argument now. Now he argues that the merged external branches make 'his' tree 'superior'. Well, it is ;) If you look at the git commit statistics, you'll notice that the developers with most commits (both numbers of commits and lines of changed code) in the last year and three years before the fork are in the Libav camp now. Look at http://lucy.pkh.me/ffstats/authors.html now. The following list is sorted in number of commits. Michael Niedermayer -- FFmpeg Diego Biurrun -- Libav Stefano Sabatini -- FFmpeg Anton Khirnov -- Libav
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, Aug 16, 2014, at 17:29, Thomas Goirand wrote: On 08/15/2014 11:53 PM, The Wanderer wrote: It's also something the Linux kernel is still doing, with apparent success. Yes, the Linux kernel is a successful project. Does this mean using a list for reviewing patches is a good thing? No! The workflow with a list is simply horrible. Using git-review and gerrit is so much better. JFTR we have dropped gerrit in favour of gitlab (or github or bitbucket) pull requests since gerrit was too cumbersome to use. So, no, gerrit is no miraculous cure-all. However I think that establishing a procedure that every patch has to be submitted as a pull request and this pull request needs to be acked by other developer is a good practice that can be adapted to any project (the only exception being one-man shows). Ondrej -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408437453.1734025.154279197.7c841...@webmail.messagingengine.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, Aug 16, 2014, at 20:59, Russ Allbery wrote: The problem, however, is that taking security seriously, while possibly necessary, is not sufficient. I'm glad that FFmpeg takes security seriously, but what FFmpeg needs is to *have fewer security bugs*. JFTR the Coverity Scan results for ffmpeg looks promising: https://scan.coverity.com/projects/54 I am not saying that we should base our decisions on Coverity Scan[1] results, but this is one more metric that could help to weight the decision to one or other direction. (Also this is not an advice what should ffmpeg do...) From the security viewpoint, I would be also interested if ffmpeg has tests and what is current code coverage. That could help avoiding regressions when doing security updates. 1. There are also other tools: llvm/clang scan_build, OCLint, cppcheck (and other metrics like Cyclomatic complexity) Cheers, Ondrej P.S.: libav doesn't seem to be using Coverity Scan actively: https://scan.coverity.com/projects/106 (last scan was 4 months ago) -- Ondřej Surý ond...@sury.org Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1408438231.1736622.154282345.60f00...@webmail.messagingengine.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On Tue, Aug 19, 2014 at 10:50:31AM +0200, Ondřej Surý wrote: [...] From the security viewpoint, I would be also interested if ffmpeg has tests and what is current code coverage. That could help avoiding regressions when doing security updates. 1. There are also other tools: llvm/clang scan_build, OCLint, cppcheck (and other metrics like Cyclomatic complexity) See: http://fate.ffmpeg.org/ http://coverage.ffmpeg.org/ [...] Best Regards, -- Clément B. pgpxNoF329KNl.pgp Description: PGP signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/16/2014 11:44 PM, wm4 wrote: This reasoning may work when you have only a small amount of information to read. When you are overwhelmed with it, having different places to do different things is a much better approach. Sending patches to a list simply doesn't scale. Also, with a list, it's not convenient at all to point out a line in a patch in a mailing list. You must extract the relevant lines, cut/past them, and comment them. Instead, double clicking on the line of the patch which is displayed on a web interface is much more convenient. What? Most patches are posted inline (with git-send-email). Even worse then! It makes it hard to copy to your local fs. Anyway, have a look here, if you want to see how the review process works: https://review.openstack.org/ click on any patch proposal, and see how nice the interaction is (see patch comments, the result of jenkins unit tests, etc.). This helps a lot with QA, for sure. There's nothing wrong with having discussion in those various areas, of course; it's probably inevitable, and it's even a good thing. It's just that it's a lot harder for someone not intimately involved with the project to follow discussion if it happens in such a variety of places, and there's value to be found in making sure that everything passes through one central (discussion-enabled) point before landing. Lists are good tools for discussing where a project should go, release goals, and so on. They aren't good tools to do patch reviews. I've used both, and I'm convinced of that. What we need is solving the FFmpeg/Libav split, not well-meant suggestions by outsiders how to change our development model. The problem, as much as I understand it, was the review process and enforcing policies. So it's natural to give advice on that, with a tool which will make sure that policies are enforced. If you don't want advices, and want to have a private discussion, then why writing to debian-devel@l.d.o? Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f19b3e.2080...@debian.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/16/2014 11:11 PM, Nicolas George wrote: L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit : Using Gerrit and file ownersip are not mutually exclusive. Gerrit can be configured to automatically invite the right people for review based on the changed path. We recently migrated to Gerrit at the Wireshark project and it helps a lot in coordinating the reviews. I am afraid this discussion on Gerrit or other similar tools is pointless: this is trying to solve a human problem with technical means: it never works. The problem was enforcing patch review policies. This technical solution makes it possible to enforce rules. Sure, it doesn't fix the social issue completely, but at least if you implement it, it's going to be a way more difficult to bypass the review system, and the one who does will really look bad, so it's very unlikely it will happen. [...] The fork's manifesto stated that everyone was equal amongst equals, with or without commit rights, but the people who do have the commit rights are few [...] Really, when I read commit rights, in a collaborative process, I feel like there's something wrong. It becomes bad when people not involved in the project start to suffer from the consequences of the fork. This is what is happening here, for two reasons: * distributions adopting one side of the fork for non-technical reasons; There's been a very well commented technical reason stated here: the release team don't want to deal with 2 of the same library that are doing (nearly) the same things, with potentially the same security issues that we'd have to fix twice rather than once. Now, the which side debate is a different one, which I don't think Debian people are interested in (at least, *I* am not): we are just suffering from the consequences of the fork, as you wrote, and would prefer it never happened. * one side of the fork not caring about compatibility with the other side. Of course, these reasons are interconnected. Yeah. If both were fully compatible, there would be no issue using one or the other. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f19ef7@debian.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/16/2014 11:30 PM, Nicolas George wrote: So what about the code? Shall the FFmpeg developers discard three years of work and start working on libav? Or shall the libav developers accept to work with the code from FFmpeg that they do not like? FFmpeg folks should rework the code to make it acceptable for the libav people, and libav people should relax their policy. With *both* sides trying to work on this, it may happen. If even *only one* of the teams find excuses to not do a step forward, it wont. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f1a0d3.2070...@debian.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/17/2014 07:41 PM, Andreas Cadhalpun wrote: Michael Niedermayer already volunteered to help with all security related problems of FFmpeg in Debian. So what should he do to relieve the impact on the security and release teams? Let's say he would take the role of patching stuff in Stable, there would still be double work for the release team and security team for at least: - Checking the packages before upload of security fixes (that's security team work), or upload of bugfixes to proposed-updates (that's the release team) - Making security announces There's nothing Michael could do to reduce that work. However, as stated before, uploading to Sid or Experimental could be done (if the SONAME clash gets fixed), and I don't think anyone would oppose for more contribution in Debian, especially with correct security support! Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f1a270.2040...@debian.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
❦ 18 août 2014 14:20 +0800, Thomas Goirand z...@debian.org : What? Most patches are posted inline (with git-send-email). Even worse then! It makes it hard to copy to your local fs. The whole email is a valid patch in this case. -- Follow each decision as closely as possible with its associated action. - The Elements of Programming Style (Kernighan Plauger) signature.asc Description: PGP signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Thomas, On 18.08.2014 08:36, Thomas Goirand wrote: There's been a very well commented technical reason stated here: the release team don't want to deal with 2 of the same library that are doing (nearly) the same things, with potentially the same security issues that we'd have to fix twice rather than once. Why is it a security problem to have FFmpeg and Libav, but apparently no problem to have MySQL, MariaDB and PerconaDB? This seems quite arbitrary to me, especially since there have been already 36 CVEs in 2014 for MySQL [1], of which 26 apparently are also relevant for MariaDB [2] and PerconaDB [3], but only 7 for FFmpeg [4] and 8 for Libav [5] in the same time. Best regards, Andreas 1: https://security-tracker.debian.org/tracker/source-package/mysql-5.5 2: https://security-tracker.debian.org/tracker/source-package/mariadb-5.5 3: https://security-tracker.debian.org/tracker/source-package/percona-xtradb-cluster-5.5 4: https://security-tracker.debian.org/tracker/source-package/ffmpeg 5: https://security-tracker.debian.org/tracker/source-package/libav -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f1e5f9.4030...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Le primidi 1er fructidor, an CCXXII, Thomas Goirand a écrit : The problem was enforcing patch review policies. No, it never was. There's been a very well commented technical reason stated here: the release team don't want to deal with 2 of the same library that are doing (nearly) the same things That the reason for keeping only one; other have discussed the validity of the reason. The reason for switching from FFmpeg to libav in the first place just after the fork is much simpler than that. Yeah. If both were fully compatible, there would be no issue using one or the other. Are there known current cases where FFmpeg can not emulate libav? Regards, -- Nicolas George signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Russ, On 16.08.2014 18:33, Russ Allbery wrote: All the renaming and cordial co-existence in the world won't change this. The things that would change this is for one or both projects to develop a better security track record and a history of higher-quality code releases that require less ongoing work in stable, Let's just have a look at FFmpeg's security track record. The easiest way I found to do this quantitatively, is to count the CVEs on FFmpegs security page [1] per year. 2011: 39 2012: 55 2013: 66 This indeed looks bad and even getting worse. But don't forget that e.g. in 2012 the systematic fuzzing by Jurczyk and Coldwind began. By now, more than half of 2014 is over and so far only 5 CVEs [3] have been fixed in FFmpeg this year. I must admit that I'm no security expert, but I think this shows that FFmpeg's security has improved a lot. or for the people who care deeply about this to somehow find a way to relieve the impact on those teams in some way acceptable to those teams. Michael Niedermayer already volunteered to help with all security related problems of FFmpeg in Debian. So what should he do to relieve the impact on the security and release teams? Short of that, there's clearly a need for software of this type in Debian, and at the same time it's clearly a ton of work. The teams involved have indicated that they're willing (if not necessarily happy) to deal with one version of the source base, but not two. This still confuses me, because apparently nobody has a problem with having three binary compatible MySQL variants in Debian: MySQL, MariaDB and PerconaDB [4] Best regards, Andreas 1: https://ffmpeg.org/security.html 2: http://j00ru.vexillium.org/?p=2211 3: The security page shows 6 CVEs, but CVE-2014-4609 and CVE-2014-4610 are the same, once reported for Libav and once for FFmpeg. 4: https://lists.debian.org/debian-devel/2014/08/msg00016.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53f094d6.4070...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit : Using Gerrit and file ownersip are not mutually exclusive. Gerrit can be configured to automatically invite the right people for review based on the changed path. We recently migrated to Gerrit at the Wireshark project and it helps a lot in coordinating the reviews. I am afraid this discussion on Gerrit or other similar tools is pointless: this is trying to solve a human problem with technical means: it never works. Actually, I believe all this peer-review business to be a red herring. On the FFmpeg side, most patches except the very simple ones are sent to the mailing-list for peer-review, even patches by people with commit rights working on their own code; they do so not because a rule states they have too but because this is the best thing to achieve good code. On the other hand, I remember having seen patches somewhat rushed through the mandatory review on libav-devel and applied when someone else still had remarks; I have not kept tabs on that though. The real issue between the mandatory peer-review on the mailing-list is, IMHO, control of the project orientation. Not is this patch correct? but do we want this patch?. If you are involved in the project, it is very obvious that both branches have rather opposed views on the project orientation: libav has made a point of trimming unnecessary features and rejecting new ones while FFmpeg kept them and added some. A few examples: * Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit message said appears simpler to write a new replacement from scratch, but in the meantime, users are left without the feature. * Libav removed the framerate detection code, FFmpeg built on it to handle it in filtering too. I do not find them right now, but I have found a few files that avconv wanted to encode at an insane frame rate while ffmpeg correctly guessed; and right now, -vf fps does not work alone with very common formats in avconv. * Libav removed the keyboard interaction (Press [q] to stop) while FFmpeg extended it. Beyond these obvious cases, FFmpeg has gained quite a few features that, I am pretty certain of it, would not have been accepted into libav: the concat demuxer (has been called hack on the mailing-lists IIRC), the lavfi sources made for testing, support for some obscure format through an external library, subtitles hard-burning, etc. The most galling in this issue is that there is no clear decision behind this orientation. The fork's manifesto stated that everyone was equal amongst equals, with or without commit rights, but the people who do have the commit rights are few and of a common mind, they can just give the cold shoulder to proposed changes that do not suit their personal view of the project. Considering these differences in policy, I do not believe the fork can be merged. Speaking as someone who proposed a few of these unnecessary features, because they were fun or immediately useful, I would not like to work on a project that would reject them by principle. But I can recognize, for someone who needs serious professional software, the need of working on something driven with a firmer hand. Having a fork is not inherently bad, and it becomes necessary when people have different views for the orientation of the projects. It becomes bad when people not involved in the project start to suffer from the consequences of the fork. This is what is happening here, for two reasons: * distributions adopting one side of the fork for non-technical reasons; * one side of the fork not caring about compatibility with the other side. Of course, these reasons are interconnected. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/15/2014 11:53 PM, The Wanderer wrote: It's also something the Linux kernel is still doing, with apparent success. Yes, the Linux kernel is a successful project. Does this mean using a list for reviewing patches is a good thing? No! The workflow with a list is simply horrible. Using git-review and gerrit is so much better. I for one consider it to be a much more public, transparent, and discoverable way to let proposed patches and the review of same be open to public view, compared to the way various other projects seem to do it. Making sure everything passes through the mailing list, and most if not all substantive discussion happens on the mailing list, is a lot better than having some discussion on the mailing lists and some on a bug tracker and some on IRC and some via private mail and so on. (The most ridiculously extreme example of this fragmentation that I know of is probably the Mozilla project.) This reasoning may work when you have only a small amount of information to read. When you are overwhelmed with it, having different places to do different things is a much better approach. Sending patches to a list simply doesn't scale. Also, with a list, it's not convenient at all to point out a line in a patch in a mailing list. You must extract the relevant lines, cut/past them, and comment them. Instead, double clicking on the line of the patch which is displayed on a web interface is much more convenient. There's nothing wrong with having discussion in those various areas, of course; it's probably inevitable, and it's even a good thing. It's just that it's a lot harder for someone not intimately involved with the project to follow discussion if it happens in such a variety of places, and there's value to be found in making sure that everything passes through one central (discussion-enabled) point before landing. Lists are good tools for discussing where a project should go, release goals, and so on. They aren't good tools to do patch reviews. I've used both, and I'm convinced of that. Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ef78f4.2090...@debian.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Le septidi 27 thermidor, an CCXXII, Thomas Goirand a écrit : If you guys could find a solution to try to work together again, and merge back both projects, that'd be best for everyone. When people suggest that, I always wonder how they see that happening with regard to the code. In more than three years since the fork, development has continued on both branches. Changes are continuously ported from libav to FFmpeg, but code was also written for FFmpeg and never merged by libav. Some of this code, the libav people have made very clear they specifically did not want it. So what about the code? Shall the FFmpeg developers discard three years of work and start working on libav? Or shall the libav developers accept to work with the code from FFmpeg that they do not like? I see neither as an option. The only option is to make sure the users do not suffer from the fork, by making sure they can easily use the version that is most suited for their need without being sucked into the developers' disagreements. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org wrote: The only option is to make sure the users do not suffer from the fork, by making sure they can easily use the version that is most suited for their need without being sucked into the developers' disagreements. Can we get back on topic? With or without libav in Debian, there are solid technical reasons to have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although they parted ways in a civilized way: different library names), and we certainly have a ton of librarys which provide very similar features. Since before the fork, the libav developers have been sabotaging ffmpeg as much as possible, in every combat field: library names, library versions, taking distributions hostage (ffmpeg package that installs libav!?), etc. This is not the way to fork anything. This is a fact. I don't care whether Michael Nidermayer was a dictator or not. I don't care whether the code-review rules in libav are better or worse. I don't care what the Linux kernel does. The only thing I care about is Debian is shipping a less-capable (i. e. less multimedia formats supported) distribution due to this conflict. This has to stop. ffmpeg is not yet in Debian due to the filename clashing, which will most certainly cause binary problems. If libav and ffmpeg maintainers cannot reach an agreement regarding library names and it's not possible to simply use either ffmpeg or libav indistinctly due missing features binary compatibility, etc, the obvious solution is that BOTH libav and ffmpeg rename their libraries in Debian. E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done in the past. And before someone mentions it: I don't think it's too late. It's getting too late because nobody with the right to act is doing anything. In the end, our users are the ones being harmed and we are left wondering why they are increasingly moving to other distributions or Mac OS X. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, 16 Aug 2014 23:29:56 +0800 Thomas Goirand z...@debian.org wrote: On 08/15/2014 11:53 PM, The Wanderer wrote: It's also something the Linux kernel is still doing, with apparent success. Yes, the Linux kernel is a successful project. Does this mean using a list for reviewing patches is a good thing? No! The workflow with a list is simply horrible. Using git-review and gerrit is so much better. I for one consider it to be a much more public, transparent, and discoverable way to let proposed patches and the review of same be open to public view, compared to the way various other projects seem to do it. Making sure everything passes through the mailing list, and most if not all substantive discussion happens on the mailing list, is a lot better than having some discussion on the mailing lists and some on a bug tracker and some on IRC and some via private mail and so on. (The most ridiculously extreme example of this fragmentation that I know of is probably the Mozilla project.) This reasoning may work when you have only a small amount of information to read. When you are overwhelmed with it, having different places to do different things is a much better approach. Sending patches to a list simply doesn't scale. Also, with a list, it's not convenient at all to point out a line in a patch in a mailing list. You must extract the relevant lines, cut/past them, and comment them. Instead, double clicking on the line of the patch which is displayed on a web interface is much more convenient. What? Most patches are posted inline (with git-send-email). There's nothing wrong with having discussion in those various areas, of course; it's probably inevitable, and it's even a good thing. It's just that it's a lot harder for someone not intimately involved with the project to follow discussion if it happens in such a variety of places, and there's value to be found in making sure that everything passes through one central (discussion-enabled) point before landing. Lists are good tools for discussing where a project should go, release goals, and so on. They aren't good tools to do patch reviews. I've used both, and I'm convinced of that. What we need is solving the FFmpeg/Libav split, not well-meant suggestions by outsiders how to change our development model. Thomas Goirand (zigo) ___ ffmpeg-devel mailing list ffmpeg-de...@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140816174433.1f3f496b@debian
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Pau Garcia i Quiles pgqui...@elpauer.org writes: If libav and ffmpeg maintainers cannot reach an agreement regarding library names and it's not possible to simply use either ffmpeg or libav indistinctly due missing features binary compatibility, etc, the obvious solution is that BOTH libav and ffmpeg rename their libraries in Debian. E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done in the past. None of this is why libav and FFmpeg can't both be in the archive. They can't both be in the archive because both the release team and the security team have said that they're not interested in trying to support both, due to the amount of work involved. All the renaming and cordial co-existence in the world won't change this. The things that would change this is for one or both projects to develop a better security track record and a history of higher-quality code releases that require less ongoing work in stable, or for the people who care deeply about this to somehow find a way to relieve the impact on those teams in some way acceptable to those teams. Short of that, there's clearly a need for software of this type in Debian, and at the same time it's clearly a ton of work. The teams involved have indicated that they're willing (if not necessarily happy) to deal with one version of the source base, but not two. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878umobdj5@hope.eyrie.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Russ, Russ Allbery r...@debian.org (2014-08-16): None of this is why libav and FFmpeg can't both be in the archive. They can't both be in the archive because both the release team and the security team have said that they're not interested in trying to support both, due to the amount of work involved. the release team only has a say on what ends up in testing (and then in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from entering the archive. FTP masters have the control over the archive as a whole. Mraw, KiBi. signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Cyril Brulebois k...@debian.org writes: Russ Allbery r...@debian.org (2014-08-16): None of this is why libav and FFmpeg can't both be in the archive. They can't both be in the archive because both the release team and the security team have said that they're not interested in trying to support both, due to the amount of work involved. the release team only has a say on what ends up in testing (and then in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from entering the archive. FTP masters have the control over the archive as a whole. Sorry, yes, good point. I should have been clearer. I assume the goal was to get both into a stable release. If people wanted to upload FFmpeg only to unstable without propagation to testing or making it part of a release, that's a possibly different situation with different tradeoffs and issues involved. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87y4uo9xr1@hope.eyrie.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 8/16/14, Pau Garcia i Quiles pgqui...@elpauer.org wrote: On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org wrote: The only option is to make sure the users do not suffer from the fork, by making sure they can easily use the version that is most suited for their need without being sucked into the developers' disagreements. Can we get back on topic? With or without libav in Debian, there are solid technical reasons to have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although they parted ways in a civilized way: different library names), and we certainly have a ton of librarys which provide very similar features. Since before the fork, the libav developers have been sabotaging ffmpeg as much as possible, in every combat field: library names, library versions, taking distributions hostage (ffmpeg package that installs libav!?), etc. This is not the way to fork anything. This is a fact. I don't care whether Michael Nidermayer was a dictator or not. I don't care whether the code-review rules in libav are better or worse. I don't care what the Linux kernel does. The only thing I care about is Debian is shipping a less-capable (i. e. less multimedia formats supported) distribution due to this conflict. This has to stop. ffmpeg is not yet in Debian due to the filename clashing, which will most certainly cause binary problems. If libav and ffmpeg maintainers cannot reach an agreement regarding library names and it's not possible to simply use either ffmpeg or libav indistinctly due missing features binary compatibility, etc, the obvious solution is that BOTH libav and ffmpeg rename their libraries in Debian. E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. Maybe even use alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done in the past. AFAIK, Andreas' package uses libavcodec-ffmpeg.so . FFmpeg configure does have option --build-suffix=_ffmpeg that would append that suffix to library names and pkg-config files. Since applications might have problem finding the ffmpeg libraries, the pkg-config files should be with the old common names and this creates a conflict in the -dev packages. Libav and FFmpeg can coexist side by side. There are no conflicts or overlap for binary users. The current goal of FFmpeg is not replacing Libav. The current goal is establishing a native presence in the most popular distribution(s). I'm quite sure the Security team is full of capable people who can handle one more package. FFmpeg takes security seriously. The best scenario for everybody is: 1. Libav stays and all QA tested programs are not touched. 2. FFmpeg is included in a way that does not obstruct the rest of the ecosystem. 3. Optionally, programs that use _only_ FFmpeg could be included back in Debian. Optionally. The inclusion would allow for a real-life estimate to be done of the FFmpeg performance, security, bug and feature wise. Only after assessing real-life data, a final decision could be reached, if there is still demand for such thing. Best Regards Ivan Kalvachev -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CABA=pqdclh+p4kqx99gmrnu-f24wpxkfnthjwryl5dnyzue...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Nicolas, 2014-08-16 17:11 GMT+02:00 Nicolas George geo...@nsup.org: L'octidi 28 thermidor, an CCXXII, Bálint Réczey a écrit : Using Gerrit and file ownersip are not mutually exclusive. Gerrit can be configured to automatically invite the right people for review based on the changed path. We recently migrated to Gerrit at the Wireshark project and it helps a lot in coordinating the reviews. I am afraid this discussion on Gerrit or other similar tools is pointless: this is trying to solve a human problem with technical means: it never works. I did not want to sell Gerrit over mailing-list discussion because the work-flow is something which should be chosen by the development team and not outsiders, but wanted to show that tools can help enforcing some parts of the work-flow. On the human problems vs. technical means questions I think we have different opinions. Technical means are exceptionally great tools for solving _some_ human problems. If the human problem is being not satisfied with peers' behavior of not following a specific work-flow a toll which enforces the work-flow would solve it. Making mistakes is an other (mostly) human problem and we have lintian for example which helps pointing them out. Actually, I believe all this peer-review business to be a red herring. On the FFmpeg side, most patches except the very simple ones are sent to the mailing-list for peer-review, even patches by people with commit rights working on their own code; they do so not because a rule states they have too but because this is the best thing to achieve good code. On the other hand, I remember having seen patches somewhat rushed through the mandatory review on libav-devel and applied when someone else still had remarks; I have not kept tabs on that though. The real issue between the mandatory peer-review on the mailing-list is, IMHO, control of the project orientation. Not is this patch correct? but do we want this patch?. If you are involved in the project, it is very obvious that both branches have rather opposed views on the project orientation: libav has made a point of trimming unnecessary features and rejecting new ones while FFmpeg kept them and added some. IMO the trimming/rejecting strategy is not something which would ever make Libav popular among developers/users and this is how we ended in the current situation. While Libav's communicated release strategy can attract integrators and distributions like Debian, FFmpeg attracts developers/users of software based on Libav/FFmpeg due to more features. Sticking to those core strategies the two forks will compete forever until one of them give up - which I see unlikely to happen voluntarily - and users will keep complaining about Libav's missing features to distributions' maintainers where FFmpeg is not packaged. I think the best way out of this situation would be relaxing the review requirements on Libav's side and letting not-yet-proven of FFmpeg features in through an experimental/staging phase. If FFmpeg devs could collaborate with them this way the two forks could be converged and finally merged and the combined team could maintain a lot better media library than the current forks are separately. Cheers, Balint A few examples: * Libav removed ffserver, FFmpeg kept it, trying to unbreak it. The commit message said appears simpler to write a new replacement from scratch, but in the meantime, users are left without the feature. * Libav removed the framerate detection code, FFmpeg built on it to handle it in filtering too. I do not find them right now, but I have found a few files that avconv wanted to encode at an insane frame rate while ffmpeg correctly guessed; and right now, -vf fps does not work alone with very common formats in avconv. * Libav removed the keyboard interaction (Press [q] to stop) while FFmpeg extended it. Beyond these obvious cases, FFmpeg has gained quite a few features that, I am pretty certain of it, would not have been accepted into libav: the concat demuxer (has been called hack on the mailing-lists IIRC), the lavfi sources made for testing, support for some obscure format through an external library, subtitles hard-burning, etc. The most galling in this issue is that there is no clear decision behind this orientation. The fork's manifesto stated that everyone was equal amongst equals, with or without commit rights, but the people who do have the commit rights are few and of a common mind, they can just give the cold shoulder to proposed changes that do not suit their personal view of the project. Considering these differences in policy, I do not believe the fork can be merged. Speaking as someone who proposed a few of these unnecessary features, because they were fun or immediately useful, I would not like to work on a project that would reject them by principle. But I can recognize, for someone who needs serious professional software, the need of
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Russ, 2014-08-16 18:59 GMT+02:00 Russ Allbery r...@debian.org: Cyril Brulebois k...@debian.org writes: Russ Allbery r...@debian.org (2014-08-16): None of this is why libav and FFmpeg can't both be in the archive. They can't both be in the archive because both the release team and the security team have said that they're not interested in trying to support both, due to the amount of work involved. the release team only has a say on what ends up in testing (and then in stable); it cannot, and AFAICT hasn't tried to, block ffmpeg from entering the archive. FTP masters have the control over the archive as a whole. Sorry, yes, good point. I should have been clearer. I assume the goal was to get both into a stable release. If people wanted to upload FFmpeg only to unstable without propagation to testing or making it part of a release, that's a possibly different situation with different tradeoffs and issues involved. For now the target is not stable, but unstable/experimental. Both the Security and Release Teams could keep an RC bug on the package until they are fine with letting it into testing. Cheers, Balint -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cak0odpzp7jri7zwhd5t_bh+trbtznnx139lequ-+rkwkrbw...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Ivan Kalvachev ikalvac...@gmail.com writes: I'm quite sure the Security team is full of capable people who can handle one more package. One, no, this statement is not correct. Not because the security team is not capable -- they are very capable -- but because they are not *full*. You imply that the security team has tons of resources and time to spare. Let me assure you that this is far from the case. This isn't even the case for security teams consisting of full-time staff paid by commercial Linux distributions, let alone volunteers for the Debian project. Two, the security team has already said that FFmpeg is not just one more package, and that no, they can't handle the substantial incremental load from adding FFmpeg without removing libav. You may not think that should be the case, but I'm afraid your opinion on the topic doesn't matter unless you're finding a way to either reduce that work or add more resources. FFmpeg takes security seriously. I'm sure that it does. The problem, however, is that taking security seriously, while possibly necessary, is not sufficient. I'm glad that FFmpeg takes security seriously, but what FFmpeg needs is to *have fewer security bugs*. This isn't about anyone's good intentions. It's about the reality of past, very negative experience with FFmpeg's security track record. It's clear that efforts are underway to improve that, such as through the fuzz testing work that Google (among others) has been doing. That's great, but I'm sure you can also understand that the past track record has been sufficiently bad that everyone will continue to be leery for a while. To change that impression, FFmpeg is going to have to substantially improve on its past security track record and then *maintain* that new level of security for some period of time. Note that all of the above statements also apply to libav. As near as I can tell, this is not a distinguishing characteristic between the two projects. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/87fvgw9s6v@hope.eyrie.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sat, 16 Aug 2014 11:59:20 -0700 Russ Allbery r...@debian.org wrote: The problem, however, is that taking security seriously, while possibly necessary, is not sufficient. I'm glad that FFmpeg takes security seriously, but what FFmpeg needs is to *have fewer security bugs*. That is very valuable advice. We'll get to work right away. Note that all of the above statements also apply to libav. As near as I can tell, this is not a distinguishing characteristic between the two projects. And that's an argument against switching to FFmpeg exactly how? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140817002757.6516bd91@debian
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On 16.08.2014 17:49, Pau Garcia i Quiles wrote: On Sat, Aug 16, 2014 at 5:30 PM, Nicolas George geo...@nsup.org mailto:geo...@nsup.org wrote: The only option is to make sure the users do not suffer from the fork, by making sure they can easily use the version that is most suited for their need without being sucked into the developers' disagreements. Can we get back on topic? Yes. I have now sent the pkg-config patches to the BTS [1]. With or without libav in Debian, there are solid technical reasons to have ffmpeg in Debian. We have both GraphicsMagick and ImageMagick (although they parted ways in a civilized way: different library names), and we certainly have a ton of librarys which provide very similar features. This is also my point of view. Since before the fork, the libav developers have been sabotaging ffmpeg as much as possible, in every combat field: library names, library versions, taking distributions hostage (ffmpeg package that installs libav!?), etc. This is not the way to fork anything. This is a fact. It would be nice, if everyone, including you, would refrain from posting such flamebaits on debian-devel. Please try to follow Debian's code of conduct [2]. I don't care whether Michael Nidermayer was a dictator or not. I don't care whether the code-review rules in libav are better or worse. I don't care what the Linux kernel does. The only thing I care about is Debian is shipping a less-capable (i. e. less multimedia formats supported) distribution due to this conflict. This has to stop. ffmpeg is not yet in Debian due to the filename clashing, which will most certainly cause binary problems. This is wrong, because the FFmpeg Debian packaging avoids filename conflicts. If libav and ffmpeg maintainers cannot reach an agreement regarding library names and it's not possible to simply use either ffmpeg or libav indistinctly due missing features binary compatibility, etc, the obvious solution is that BOTH libav and ffmpeg rename their libraries in Debian. E. g. libavcodec-ffmpeg.so and libavcodec-libav.so, etc. This is already done in the FFmpeg Debian packages. Maybe even use alternatives to provide the binaries (ffmpeg, ffplay, etc). It's been done in the past. This is not necessary, because the Libav binaries already have different names, avconv, avplay and so on. And before someone mentions it: I don't think it's too late. It's getting too late because nobody with the right to act is doing anything. In the end, our users are the ones being harmed and we are left wondering why they are increasingly moving to other distributions or Mac OS X. Indeed it's getting late, because the FFmpeg package has been waiting in the NEW queue for more than 3 months. Best regards, Andreas 1: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=reintroducing-ffmpeg;users=andreas.cadhal...@googlemail.com 2: https://www.debian.org/code_of_conduct -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53efdfea.8000...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 8/16/2014 11:27 PM, wm4 wrote: That is very valuable advice. We'll get to work right away. I've added it to my TODO: * Don't write bugs. - Derek -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53efdcbe.5050...@gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
wm4 nfx...@googlemail.com writes: Russ Allbery r...@debian.org wrote: Note that all of the above statements also apply to libav. As near as I can tell, this is not a distinguishing characteristic between the two projects. And that's an argument against switching to FFmpeg exactly how? It's not. Nor was I trying to make one. This part of the thread was discussing introducing FFmpeg into Debian alongside libav. As I believe I mentioned previously, although the code base underlying both projects has a bad past security track record, currently FFmpeg appears to be doing somewhat better than libav. I believe a member of the security team made a similar observation. So, when picking one, the security argument seems to be at least partly in FFmpeg's favor. That was not my point; my point was that picking both of them is something that had already been discussed and rejected for what to me feel like sound reasons. Security of course isn't the only consideration when picking one of the two, and regardless I'm not the person who would be deciding anything. Mostly I'm speaking up because it felt like people were going down blind alleys arguing about things that aren't really at issue. Note that experimental doesn't receive security support. I may be missing something (and here it's ftp-master that is the relevant decision-making party), but I haven't seen any obvious reason why one shouldn't introduce FFmpeg packages into experimental, particularly if people feel like there's anything to be gained by seeing concrete packaging work, letting people more easily experiment with the packages, and so forth. Of course, that by itself doesn't imply anything about the broader question of replacing libav with FFmpeg or not. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/878umo81wo@hope.eyrie.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Derek Buitenhuis derek.buitenh...@gmail.com writes: On 8/16/2014 11:27 PM, wm4 wrote: That is very valuable advice. We'll get to work right away. I've added it to my TODO: * Don't write bugs. That's a really bad way of avoiding security bugs. I'm sure you know that and are just being flippant, but I have to say that, as an outsider to the project who would like to use the software but who cares a lot about not introducing security weaknesses, it's hard to shake the feeling that this dismissive attitude is part of the problem. There were earlier responses in the thread along the same lines, arguing that the nature of FFmpeg means it will just inevitably have a bunch of security bugs. This sort of learned helplessness is really off-putting. Thankfully, I get the impression from other research that I was doing that it's *not* typical of FFmpeg as a whole, and that you all are, in fact, doing exactly the sorts of things that I would recommend. So this is probably just one of those pointless Internet arguments where everyone says things more aggressively than they actually mean them, and much heat is created with little light. But, for the record, what I was actually getting at is that the way to avoid a bunch of security bugs is not to stop writing bugs, because no one is going to achieve that. It's to put in place supporting infrastructure that makes it easier to write secure code and harder to write code where bugs create security problems. Trying to be closer to perfect in the code you write is a horrible way to achieve security. It doesn't work. Adding surrounding protective structure to the code so that the bugs do not compromise security, and putting systems in place that let the computer do lots more security sanity checking for you, are how other projects with similar challenges have achieved considerable improvements in security bug rates. In case there's anyone reading this who doesn't have a feel for what this looks like, the process the LibreSSL project is going through (regardless of one's opinion on the desirability of an OpenSSL fork) is very interesting. I've personally learned quite a bit from it, have now introduced reallocarray in my own code, and am planning on introducing strtonum. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/871tsg81dc@hope.eyrie.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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. 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. 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. With Gerrit, it's possible to comment directly in the patch, which helps going in the right direction. Of course, a technical solution will not solve all social issues, but it may improve the workflow and process, and avoid frictions. I hope this helps, Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53edae55.4090...@debian.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 15, 2014 at 2:53 PM, Thomas Goirand wrote: Hum... Well, to me, what's important is that the code gets peer-reviewed. ... by both humans and by automatically by computers; compiler warnings, static analysis tools, fuzz testers etc. -- bye, pabs https://wiki.debian.org/PaulWise -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAKTje6E5Ow=ywhmzjqt-wotwolikj6_cveeqyyzzk4rxno4...@mail.gmail.com
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
On 08/15/2014 08:20 PM, Michael Niedermayer wrote: 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. Hum... Hang on here then! Does this mean that, in FFmpeg and/or Libav, there's some parts of the code which are understood by no-one? Scary! So if that person posts a patch for review, theres noone who could do a real review Then the person who posts the patch can leave it for review for a while (you should define a policy so that for a while means something: for example 2 or 3 weeks), and then if there's no negative review, he can self-approve his patch. 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! Well, using a mailing list to review patches is something we were doing 10 years ago. You should really consider using Gerrit (or something equivalent, but I don't know anything that works the way Gerrit does). The workflow will influence a lot the way contributors interact with each other. Almost certainly in a *good* way. Cheers, Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ee25d9.7020...@debian.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/15/2014 11:23 AM, Thomas Goirand wrote: On 08/15/2014 08:20 PM, Michael Niedermayer wrote: 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! Well, using a mailing list to review patches is something we were doing 10 years ago. It's also something the Linux kernel is still doing, with apparent success. I for one consider it to be a much more public, transparent, and discoverable way to let proposed patches and the review of same be open to public view, compared to the way various other projects seem to do it. Making sure everything passes through the mailing list, and most if not all substantive discussion happens on the mailing list, is a lot better than having some discussion on the mailing lists and some on a bug tracker and some on IRC and some via private mail and so on. (The most ridiculously extreme example of this fragmentation that I know of is probably the Mozilla project.) There's nothing wrong with having discussion in those various areas, of course; it's probably inevitable, and it's even a good thing. It's just that it's a lot harder for someone not intimately involved with the project to follow discussion if it happens in such a variety of places, and there's value to be found in making sure that everything passes through one central (discussion-enabled) point before landing. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJT7izqAAoJEASpNY00KDJr8PwP+gNPrmz3G1SDFBP0WPW7WEn/ BBFAFkWXEkezThYnjqYfHxUjwHBZOOpLfykfhlx7uV5O+nqy5BDDMHLzBxVEvaKp 5On9SaRB6/DYzAf9HvSJm+teHqRtNP0xKrcjRI+AgQ9n3Meax3OWi7jiNSIijAlX srvhfjqgRAdNIB+dAnv8uhWhsAbN0njAPqegolFunAG8ZlWA4kcA5zt5uVaQrWPZ y8LqZ/bB7xYbqTAO+kENhNoMzItqANUKZNhJKW/Fk6Dln/kIKWYE5Uiiil2BOHc7 KNyPxvrfjAj/LYdazgknu2tcAlgHbPBbbjjqYFivkc2sG+9s1t5QkEdkdJw7w3v8 OQpUwwF3gRGHebp1ODtyCuVC8jsmtBAwM+s0H5aqF0Tp6NyjgYFxtYrfHvvnvXmX 1lew8VW6WogIlJ1wDXCS8057gR877wMa8r61d6XbdHXcnARxoFYI1ngUUsKYjXyU YJkRgxTZTtUZ9QNfex8sdja1PiIw96m4XLeW1uTozRR0EcQRBarphBCscQhmp0Sm pdopwrFYMnZtNOE2nEqbwQtkNm1AXmABG18GbhcPX7LqEXsys6Odn8o1zqJYpx2h 7aQzpXbhjHUwihelR5yV6dASRt1LBD3icCR0uoWaAb80b0Li9cdV07FLon20XExS mwURtzhiqxowV931+Bvh =Jxa+ -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ee2cea.1080...@fastmail.fm
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, 2014-08-15 14:20 GMT+02:00 Michael Niedermayer michae...@gmx.at: 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 This situation is not totally unique to FFmpeg/Libav. IMO in this real-life situation peers can do a best-effort review and people doing so would sooner or later will get familiar with those parts of the code as well. In case of a widely used library like this the biggest issue is breaking the ABI or modifying the ABI in a way which does not align with the team's vision about the ABI roadmap. That type of change can be pointed out by less experienced developers, too. Internal regressions in the code can be easily fixed even if they are not discovered during testing and enter the release. 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. Using Gerrit and file ownersip are not mutually exclusive. Gerrit can be configured to automatically invite the right people for review based on the changed path. We recently migrated to Gerrit at the Wireshark project and it helps a lot in coordinating the reviews. Cheers, Balint 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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cak0odpwaj1irea2ymdznjqwkw+hhep3yg-vvuy8mp8hje3d...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Wed, Aug 13, 2014 at 12:53:41AM +0100, Kieran Kunhya 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. I never understood why people who once where friends became mutually so hostile The big elephant in the room in any discussion about even moving an iota in the direction of something resembling a resolution is that you as FFmpeg leader are a hidden leader. Every year at VDD when there is any informal discussion of any reconciliation as Attila alludes to the line we can't get anywhere since Michael isn't here is uttered and then everyone moves on. Guys, this is getting nowhere. You need to solve this in a non-public discussion. Given the amount of noise this has generated on debian-devel, I am sure some of the Debian oldtimers[1] will be happy[2] to act as mediators for such a discussion if it is organized in a somewhat convenient location/conference/etc and if both sides consider such a mediation helpful. [1] With or without previous contacts with ffmpeg/libav. [2] Think of it like spending some hours to fix the issue vs spending some hours to read more mails on debian-devel. Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814065750.GA30581@t61
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded: On Wed, 13 Aug 2014 00:30:05 +0200 Michael Niedermayer michae...@gmx.at wrote: I never understood why people who once where friends became mutually so hostile You should know that better than anyone else! You still claim to be my friend, yet you said and did things that i have not seen from my enemies, let alone from my friends. To this day, after 3 years, i still get accused by random people of thing i supposedly have done against FFmpeg and the spirit of open source. After 3 years i still have to defend myself against these baseless attacks! If you trully want to mend ways, then you and your fellow FFmpeg developers should stop this constant spreading of lies, this defamation campaing against libav and its developers that has been going on for the last 3 and a half years and show at least the minimum respect you would show to a stranger you meet on the street. Until you do this, i see very little chance for a healthy cooperation. Please refrain from claiming other people are spreading lies, especially with no specific references (and this is not the place where to discuss such things). As for me, I don't consider Libav developers neither friends nor enemies. We reached a point when we got two different projects with different policies, culture, and guidelines. Then you should be aware that the way the Libav fork was created was hostile towards FFmpeg, so 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. -- FFmpeg = Faithful Foolish Multipurpose Peaceless Extensive God -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140814115807.GG11331@barisone
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
2014-08-14 13:58 GMT+02:00 Stefano Sabatini stefa...@gmail.com: On date Wednesday 2014-08-13 16:27:20 +0200, Attila Kinali encoded: On Wed, 13 Aug 2014 00:30:05 +0200 Michael Niedermayer michae...@gmx.at wrote: I never understood why people who once where friends became mutually so hostile You should know that better than anyone else! You still claim to be my friend, yet you said and did things that i have not seen from my enemies, let alone from my friends. To this day, after 3 years, i still get accused by random people of thing i supposedly have done against FFmpeg and the spirit of open source. After 3 years i still have to defend myself against these baseless attacks! If you trully want to mend ways, then you and your fellow FFmpeg developers should stop this constant spreading of lies, this defamation campaing against libav and its developers that has been going on for the last 3 and a half years and show at least the minimum respect you would show to a stranger you meet on the street. Until you do this, i see very little chance for a healthy cooperation. Please refrain from claiming other people are spreading lies, especially with no specific references (and this is not the place where to discuss such things). As for me, I don't consider Libav developers neither friends nor enemies. We reached a point when we got two different projects with different policies, culture, and guidelines. Then you should be aware that the way the Libav fork was created was hostile towards FFmpeg, so 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. I have no problem with FFmpeg and Libav developers discussing collaboration on debian-devel especially if they finally sit together and find a way in which they could join efforts after years of working in separation. This would be Legen... ...dary. :-) Cheers, Balint -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cak0odpwp7rzzwmpkpwc9txtb2na3zp7bb8t2mdgktiztxfd...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/13/2014 07:53 AM, Kieran Kunhya wrote: Whatever, people can work on their own code happily but the rest of the world (cf this thread) has to deal with this annoying FFmpeg/libav madness. Right! Not only a core of a few upstream authors are affected, but also downstream distributions (where we have to deal with numerous build issues), and final users (who may loose the possibility to use some nice software...). If you guys could find a solution to try to work together again, and merge back both projects, that'd be best for everyone. 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? Thomas Goirand (zigo) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ecd562.1070...@debian.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 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. - -- The Wanderer Secrecy is the beginning of tyranny. A government exists to serve its citizens, not to control them. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBCgAGBQJT7Nz0AAoJEASpNY00KDJrGzwP/Rn3aW9i+b8YfDhrkKrP1QfW HhfxOnIzEiGTJZnMWSCyJ/3K2zAmwvqCwTgGi2E04ud92AZdAjdMLzKUyvnblhmV iN56iahO5dfX8J42jXh9C3d+kbKOHYhc1I2DgzNyeNTfOdfc5kQkPEdTwR1Mfbl/ NXyICwnURhvaZaRrwNQQfN7DSRwdB++hi0OExVzyrX4xI5OvWV5TcwKheXykYgGe RrHtdkobACM1p9z5x/fGl5RC5KTQ9/qfP+IrOqfrZ0f8Sp3LvWyOjjliHWuQ0fwh tx9oX6BfgwFqqEZ/FSO0hfdRz1ec37yo/ZpapgMNkRUaXP4jhHRlOmljpE6JiuoH sJne9r1OAXQV5md4bZYjHfXkk9Rw6BXNLVfaHpmdlXZAUqEd6/GTYRLlUNmjvsM1 pySPCT+z+BN2U6RkVeBGDIkW2E2Q/Wwa50MQTcvrJ4Tixa3vC3x84HuNj3ykWuof UnwQD2ktBfQlwEBjC+qVLt5+mSKfAqtJUqm+lULISx9OFdX/f8/7Z+k60cJ+U3Qx q1MsqcAot7oUcibj3a/m9I+wW7LvpzP4Xt/DEwgUx9TDUHTYMv/EDWq1uxl1S25v 1hvawkiabpgYeNw4pXo9Kt/YqpNB9mlq6V1lDi6XqecxcXyy4RCRhpUAtHRxVKAN 6mXiIK5hvhv0R4nedkC1 =Fo9z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53ecdcf4.1020...@fastmail.fm
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Wed, 13 Aug 2014 00:30:05 +0200 Michael Niedermayer michae...@gmx.at wrote: I never understood why people who once where friends became mutually so hostile You should know that better than anyone else! You still claim to be my friend, yet you said and did things that i have not seen from my enemies, let alone from my friends. To this day, after 3 years, i still get accused by random people of thing i supposedly have done against FFmpeg and the spirit of open source. After 3 years i still have to defend myself against these baseless attacks! If you trully want to mend ways, then you and your fellow FFmpeg developers should stop this constant spreading of lies, this defamation campaing against libav and its developers that has been going on for the last 3 and a half years and show at least the minimum respect you would show to a stranger you meet on the street. Until you do this, i see very little chance for a healthy cooperation. That said, i invite all FFmpeg developers to come to VDD next month and sit together with everyone. So that we can have a healthy discussion once again. Drink beer, hot chocolate and have fun together. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140813162720.79a96a770f4ed5dca7ea0...@kinali.ch
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, 11 Aug 2014 18:34:23 -0400 Theodore Ts'o ty...@mit.edu wrote: On Mon, Aug 11, 2014 at 10:53:56PM +0200, wm4 wrote: To be fair, FFmpeg does its own manual symbol versioning by appending increasing numbers to function names. But the real problem are not these functions, but public structs. Imagine a new API user fighting to guess which fields in AVCodecContext must be set, or which must not be set. Seasoned FFmpeg developers probably don't know the horror. There are some best practices in API design; one of them is to minimize public structs as much as possible. Instead, have blind pointers which are handed back by an initialize object function, and then have setter/getter functions that allow you to fetch various parameters or flags which modify how the object behaves. This allows you to add or deprecate new flags, configuration parameters, in a relatively sane way. Yes. Unfortunately, central data structures are still public, and just making them opaque and adding accessors on top of them would lead to a major compatibility issue, and all developers using ffmpeg would complain big time. In fact, the API cleanup is an ongoing process, and is what causes the incompatibilities with each release. For example, a C library should have a consistent naming schema. FFmpeg/Libav decided to use AV and av_ as prefixes for all symbols in the public header files. This required fixing some symbols, which of course broke some applications. I have this dream/fantasy where all of the energy over developing and maintaining two forks was replaced by a spirit of cooperations and the developers working together to design a new API from scratch that could be guaranteed to be stable, and then applications migrated over to use this stable, well-designed, future-proofed API. Call me a naive, over-optimistic dreamer, but :-) (And, the yes, the new API probably should be a bit higher level.) Can we all just get along? -- https://www.youtube.com/watch?v=1sONfxPCTU0 - Ted Yes, that would be nice. The FFmpeg/Libav split is mostly a political/social issue though: it seems some (not all) members from each side just can't deal with some (not all) members from the other side. How do you fix this? It seems impossible. (Also, btw.: sometimes the low level aspect of the libraries is simply needed. It's just that most applications would be better off with a more high level API.) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812144854.30b7fc46@debian
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 02:54:39 +0200 Matthias Urlichs matth...@urlichs.de wrote: Hi, wm4: Build something on a newer glibc system, and try to run the binary on an older system. It most likely won't work - even if it could in theory. (At least it was this way some years ago. Probably still is.) What would be the point of introducing new or updated interfaces if you then couldn't use them? Apparently this happens even if an application only uses C99 and POSIX standard symbols. ABI backwards compatibility is not a goal I would want to spend any time on. Forward compatibility, on the other hand … Well, I think it's a pretty common complaint from commercial software vendors. That you can't distribute precompiled binaries reasonably. To be fair, FFmpeg does its own manual symbol versioning by appending increasing numbers to function names. But the real problem are not these functions, but public structs. Imagine a new API user fighting to guess which fields in AVCodecContext must be set, or which must not be set. Seasoned FFmpeg developers probably don't know the horror. That's reasonably easy – you add a function to allocate the structure for you. That function sets a version field and/or initializes everything to a sane default. Also, you never shrink the structure, or move fields. Obviously, you also tell people to never ever embed the thing directly in something else, assuming that you can't keep it opaque entirely. That's already the case with most libav* data structures. Of course, it's only easy if you design your API that way from the beginning … I think the largest issue with FFmpeg is actually that it's so low-level. Users usually have to connect the individual libraries themselves, and that is very error prone. Hell, even the official FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem to be broken to hell. I think there should be a higher-level FFmpeg library that takes care of these things. gstreamer-ffmpeg? gstreamer has more problems than it solves. (Forces glib/gobject on you, GTK-style OOP, pretty crashy, tons of low-quality plugins, complicated API and design, ...) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812145351.4136acee@debian
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, wm4: ABI backwards compatibility is not a goal I would want to spend any time on. Forward compatibility, on the other hand … Well, I think it's a pretty common complaint from commercial software vendors. That you can't distribute precompiled binaries reasonably. They need to compile the software with the lowest-possible version of the library which they can reasonably use (and which is still API compatible with the hightest that's in general use). This is hardly rocket science, but requires care from all participants. gstreamer-ffmpeg? gstreamer has more problems than it solves. (Forces glib/gobject on you, GTK-style OOP, pretty crashy, tons of low-quality plugins, complicated API and design, ...) Yeah, I know. Missing Snarky Smiley Syndrome on my part. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812143559.gm1...@smurf.noris.de
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, wm4: In fact, the API cleanup is an ongoing process, and is what causes the incompatibilities with each release. For example, a C library should have a consistent naming schema. FFmpeg/Libav decided to use AV and av_ as prefixes for all symbols in the public header files. This required fixing some symbols, which of course broke some applications. One could add weak aliases and/or marked-as-deprecated C macros instead of doing a hard renaming. To be fair, the GCC change which even allowed emitting a warning upon use of a macro isn't _that_ old … Yes, that would be nice. The FFmpeg/Libav split is mostly a political/social issue though: it seems some (not all) members from each side just can't deal with some (not all) members from the other side. How do you fix this? It seems impossible. Kick the non-cooperating people off both projects. :-P (One slight problem with this solution is that the net effect is likely to be three forks instead of two, not one …) (Also, btw.: sometimes the low level aspect of the libraries is simply needed. It's just that most applications would be better off with a more high level API.) Most CS problems can be solved by adding yet another level of indirection – except for the problem of having too many levels of indirection and – relevant here – the associated decrease in speed. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812145139.gn1...@smurf.noris.de
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Le mardi 12 août 2014 à 14:53 +0200, wm4 a écrit : gstreamer has more problems than it solves. (Forces glib/gobject on you, GTK-style OOP, pretty crashy, tons of low-quality plugins, complicated API and design, ...) Hummm, I know FUD when I see it… -- .''`.Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1407856083.18756.2.camel@dsp0698014
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 16:51:40 +0200 Matthias Urlichs matth...@urlichs.de wrote: Hi, wm4: In fact, the API cleanup is an ongoing process, and is what causes the incompatibilities with each release. For example, a C library should have a consistent naming schema. FFmpeg/Libav decided to use AV and av_ as prefixes for all symbols in the public header files. This required fixing some symbols, which of course broke some applications. One could add weak aliases and/or marked-as-deprecated C macros instead of doing a hard renaming. But this was done: http://git.videolan.org/?p=ffmpeg.git;a=commit;h=104e10fb426f903ba9157fdbfe30292d0e4c3d72 FFmpeg still has them, Libav removed them about half a year after adding them. To be fair, the GCC change which even allowed emitting a warning upon use of a macro isn't _that_ old … Yes, that would be nice. The FFmpeg/Libav split is mostly a political/social issue though: it seems some (not all) members from each side just can't deal with some (not all) members from the other side. How do you fix this? It seems impossible. Kick the non-cooperating people off both projects. :-P (One slight problem with this solution is that the net effect is likely to be three forks instead of two, not one …) Yes, or kill the project entirely, since key people would have to be kicked off. A bit of a problem, as you see. (Also, btw.: sometimes the low level aspect of the libraries is simply needed. It's just that most applications would be better off with a more high level API.) Most CS problems can be solved by adding yet another level of indirection – except for the problem of having too many levels of indirection and – relevant here – the associated decrease in speed. Speed wouldn't be affected here, since the hard work is done in libavcodec anyway. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812170355.1c628b44@debian
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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]. 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?) The only piece of hardware on which FFmpeg could have any claim on, the mphq server, was handed over to a friend of Reimar Döffinger (head of MPlayer) later that year (in August, if i'm not mistaken), to be taken somewhere, where MPlayer could host it again. What happend to the server afterwards, i do not know. TL;DR: no piece of infrastructure of FFmpeg was ever stolen. In fact, it's pure slime. The fact that up until this point the Debian Project has been so accepting of a fork that runs so contrary to the free software spirit in its ethics has darkened my view of the entire project. Well, if you believe in lies, then of course your view of the world will darken. But i hope that this email clears things up. Attila Kinali [1] http://article.gmane.org/gmane.comp.video.ffmpeg.devel/123868 [2] http://article.gmane.org/gmane.comp.video.mplayer.devel/59283 [3] Interestingly, a few people on the MPlayer side didn't like the involvment of root (the people who had root on mphq) in the whole FFmpeg thing. A few even said that we should step down and hand over the server to someone else. I offered back then, to hand the server to anyone who had a claim on it, given they take over all the legal registration as well (the server and its IP
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 17:13:17 +0200 Attila Kinali att...@kinali.ch wrote: Well, if you believe in lies, then of course your view of the world will darken. But i hope that this email clears things up. If I am spreading falsehoods then I apologize. The ffmpeg/libav split broke a video sharing site that I built for a client. Fixing it resulted in many hours of unbillable labor. That's my main relationship to problem and reason for complaining. 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. 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. On a semi unrelated note: I'm pretty sure it's not my place to ask this, but shouldn't Sam Hocevar weigh in on this issues? As former ffmpeg maintainer and DPL it seems like he'd be uniquely qualified speak on what's in the best interest of -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812104435.4df6d80d@bob
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 16:51:40 +0200 Matthias Urlichs matth...@urlichs.de wrote: Hi, Yes, that would be nice. The FFmpeg/Libav split is mostly a political/social issue though: it seems some (not all) members from each side just can't deal with some (not all) members from the other side. How do you fix this? It seems impossible. Kick the non-cooperating people off both projects. :-P at least 6+ devels refuse to work with each other , thats only a quick estimation, i havent polled everyone lately. ffmpeg and libav devs dont even TALK to each other. theres a couple devs who frequent both irc/lists, most do not. (One slight problem with this solution is that the net effect is likely to be three forks instead of two, not one …) i wrote up a current status of the projects, http://wiki.multimedia.cx/index.php?title=User_talk:Compn yes, you are correct, baptiste left and created ffmbc. ffmbc is nice, if we play our cards correctly we can get it merged into ffmpeg. -compn -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812140432.4...@mi.rr.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 14:04:32 -0400 compn te...@mi.rr.com wrote: at least 6+ devels refuse to work with each other , thats only a quick estimation, i havent polled everyone lately. ffmpeg and libav devs dont even TALK to each other. theres a couple devs who frequent both irc/lists, most do not. This is not entirely true. There are people who talk to eachother. But it is mostly kept under wraps as some zealots think that talking to the others is a mortal sin and anyone who does it needs to be punished. Heck, i remember how i was sitting with some FFmpeg guys during lunch at the Videolan Developers Days last year. We had some discussion going on, nothing serious, mostly smalltalk, but still a discussion. When Diego Biurrun joined our table everyone suddenly fell silent. It felt like being in some second rate sitcom... But that's personal issues between the developers and does not belong to debian-devel. i wrote up a current status of the projects, http://wiki.multimedia.cx/index.php?title=User_talk:Compn Thanks for writing that up. There are certain things i would like to add there or write diffently, but i will contact you off list for that. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812212011.2b818f475c3d94d9885d4...@kinali.ch
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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. At that time there was some discussion going on between some of the most active developers of that time, what to do about Michael and the issues he causes. There were several attempts to solve the whole issue toghether with Michael, but after all failed, it was decided that it would be the best to proceed without Michael as head developer. In the days before the coup d'état we tried to get hold of all the developers that we thought were still active. Most of the people we contacted agreed with us, some of them signed the mail i linked earlier. There were some who said they didn't care and wanted to stay out of the whole issue and also some that we could not reach in time. Having most of the active base of FFmpeg agreeing with us, we thought that the dethroning of Michael would be a quick and painless thing. We couldn't have been more wrong... The rest, as they say is history... I'm pretty sure it's not my place to ask this, but shouldn't Sam Hocevar weigh in on this issues? As former ffmpeg maintainer and DPL it seems like he'd be uniquely qualified speak on what's in the best interest of I think you are confusing a few things. Sam was, as far as i know, never active in FFmpeg. He was (and i think still is) a big figure in VLC development. PS: It has been brought to my attention that claiming i have bought the mphq server is a bit misleading. The money that bought the server was donation money. What i did was handling the buying using my contacts i had to HP back then, to get a quite decent machine to one third of the price we would have paid otherwise. Ie, i handled the suffling of the money and the legal paperwork. Attila Kinali -- It is upon moral qualities that a society is ultimately founded. All the prosperity and technological sophistication in the world is of no use without that foundation. -- Miss Matheson, The Diamond Age, Neil Stephenson -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812214537.0bc793c5bbdebd8efd9f3...@kinali.ch
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
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 big elephant in the room in any discussion about even moving an iota in the direction of something resembling a resolution is that you as FFmpeg leader are a hidden leader. Every year at VDD when there is any informal discussion of any reconciliation as Attila alludes to the line we can't get anywhere since Michael isn't here is uttered and then everyone moves on. Things have changed a lot in the 3.5 years since the split but since you never show your face and because many libav people don't follow FFmpeg they just imagine conditions to be the same and remember the same anger that caused all this. Yes there is a lot of anger around still but meeting in person dampens things. Lets be honest, Google is definitely FFmpeg home turf, at previous VDDs there were plenty of FFmpeg people and J-b has offered to pay your travel/accommodation etc for many years - there is literally nothing more that they could do beyond hosting a conference at your home. Every year however, it's always silence when talking about this to you. I appreciate you may not want to meet people face to face but if you are seriously interested in moving in the right direction this is the *ONLY* way forward and I cannot stress this more. I suspect you won't hear it publicly but it's fair to say that this view is unanimous on both sides of the fence - if you're physically not there nothing will change and we'll all have to waste stupid amounts of time dealing with the current state. Whatever, people can work on their own code happily but the rest of the world (cf this thread) has to deal with this annoying FFmpeg/libav madness. Getting it into Debian isn't going to change much (I get the feeling some FFmpeg people expect it to be a massive game-changer of some sort). (of course this is going to get me lots of angry private messages and emails like the last set of emails) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAK+ULv6xSYeBUpK0=tsrkrw8ni3alkbzqvzp3zyzimbz0x0...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Tue, 12 Aug 2014 21:45:37 +0200 Attila Kinali att...@kinali.ch wrote: I think you are confusing a few things. Sam was, as far as i know, never active in FFmpeg. He was (and i think still is) a big figure in VLC development. I was only speaking of him as maintainer of the ffmpeg packages in debian. I had correspondence with him in this capacity. I have no knowledge of his upstream involvement in any projects or lack thereof. I mentioned it more as a random aside to debian-devel than as a response to any part of your email. As things now seem to be getting a bit heated, I'm going to remove myself from this discussion entirely. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812210426.6795d0f3@bob
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, On Montag, 11. August 2014, Ben Hutchings wrote: dvswitch was also broken by the removal of support for downscaled decoding of DV video. I don't know whether that change is specific to libav or was also made in FFmpeg. dvswitch is still broken and there is no dvswitch in jessie... We have a daily job testing against libav from git, but that was alwayys broken everyday in the last half year or so. Maybe it would be useful to setup building against ffmpeg. cheers, Holger signature.asc Description: This is a digitally signed message part.
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 2014-08-09 18:26:19 +0100, Kieran Kunhya wrote: We also use a fork specifically to work around very wasteful calculations in libswscale during 10-bit chroma conversion that involve multiplying a pixel by a 2^n value with 32-bit precision and then shifting that value down by n back to 16-bit precision (achieving nothing). The fix breaks other codepaths that we don't use but the performance gain is big enough to warrant a fork. What is the performance gain? I'm wondering what performance gain is important enough to justify a fork in Debian. Well, not just a fork, just recompiling with static linking can yield a significant improvement. For instance, I could obtain up to a 37% gain with a static link against MPFR. -- Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811133947.ga16...@xvii.vinc17.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
+++ Wookey [2014-08-08 16:05 +0100]: My expertise here is extremely limited, but some practical experience shows that mythtv does at least basically work fine with libav. It turns out that this is completely wrong (as hinted at in later mails). I was mislead by info in bugreports. The (prospective) Debian and Ubuntu (and deb-multimedia) Mythtv packages do not use libav. So far as I can tell they all use the internal ffmpeg fork (for the reasons explained elsewhere in this thread). It would appear that rebuilding against libav is a non-trivial piece of work. Rebuilding against system ffmpeg would presumably be easier, but still not necessarily simple. Both will reduce speed and/or functionality and at least initially probably introduce bugs. Unless we were to decide to make an exception re internal libraries (which seems unlikely in this case given the general discussion on security load), this package is not going to make it into Debian anytime soon, which from my POV is very sad - I had thought we were closer than this. Still, it's only been 5 years so far - don't want to rush these things :-) I hope we can at least maintain some compatible packages outside the archive. Hopefully some tuits will be found to make some progress on this (we're (well Simon Iremonger is) doing some mythtv-on-arm builds/testing at the moment) to see what does/doesn't work there. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811142032.gi7...@stoneboat.aleph1.co.uk
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Wookey woo...@wookware.org schrieb: Unless we were to decide to make an exception re internal libraries (which seems unlikely in this case given the general discussion on security load), this package is not going to make it into Debian anytime soon, which from my POV is very sad - I had thought we were closer than this. I don't know mythtv, but if it's just a digital video recorder, there's no significant risk ever needing security updates. A local, forked copy is problematic for a video player since someone may open a malformed video file, but malformed DVB streams are a different ballpark. Please contact us at t...@security.debian.org so that we sort that out. Cheers, Moritz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/slrnluhrq3.61t@inutil.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, Aug 11, 2014 at 06:28:51PM +0200, Moritz Mühlenhoff wrote: I don't know mythtv, but if it's just a digital video recorder, there's no significant risk ever needing security updates. A local, forked copy is problematic for a video player since someone may open a malformed video file, but malformed DVB streams are a different ballpark. Please contact us at t...@security.debian.org so that we sort that out. A stream from a TV tuner should be considered just as suspect as one from a shady video download website. see e.g., http://en.wikipedia.org/wiki/Hybrid_Broadcast_Broadband_TV#Security_Concerns for just one problem that arises when you assume that an adversary is willing to aim a low-power broadcast at your antenna. Jeff -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811164606.ga28...@unpythonic.net
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hello, Apologies for not being able to resist answering even if it is getting off-topic. On Sun, Aug 10, 2014 at 05:43:33PM -0400, Theodore Ts'o wrote: On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew Kelley wrote: High quality libraries must iterate on their API. Especially for a library trying to solve such a complex problem as audio and video encoding and decoding for every codec and format. It is unreasonable to expect no incompatible changes. Also both ffmpeg and libav codebases have a lot of legacy cruft. Libav is making a more concentrated effort at improving this, and the evolving API is a side-effect of that. I beg to differ. My definition of a high quality library is one where careful design is taken into account when designing the ABI/API's in the first place, and which if absolutely necessary, uses ELF symbol versioning to maintain ABI compatibility. There are plenty of high quality libraries (glibc, libext2fs, etc.) where we've been able to maintain full ABI compatibility even while adding new features --- including in the case of libext2fs, migrating from 32-bit to 64-bit block numbers. And if you're careful in your design and implementation, the amount of cruft required can be kept to a very low minimum. While you certainly have a point that we have a lot to learn and improve, your comparison is not entirely fair, for reasons like a) glibc, libext2fs are much older projects, we still have to pay for old sins, from times where everyone was happy when their video played at all on Linux and nobody complained about ABI compatibility. Not to mention few of us having much experience in software development. b) A good number of our users are on Windows, which makes symbol versioning a very undesirable solution. Sometimes that means alternative solutions which are messier or more likely to break compatibility by accident c) For libext2fs your users won't claim a file system is ext2, when it is actually btrfs and still expect your ext2 library to work with it! That is very much the standard in multimedia (everything is .avi, I don't care what format it is, I just want it to play, ...). Nor do you have competing ext2 implementations adding completely mis-designed extensions to it, with everyone expecting you to support it, that definitely makes API design a _lot_ more challenging. d) At least in the case of glibc that backwards-compatibility is not at all free to its current users. _IO_stdin_used is a prime example of that, anyone playing with methods to reduce binary size/strip symbols will stumble over that and curse very loudly at some point. I certainly would have preferred it to not be ABI compatible in that case! Regards, Reimar -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811184028.ga14...@reimardoeffinger.de
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Mon, 11 Aug 2014 20:40:28 +0200 Reimar Döffinger reimar.doeffin...@gmx.de wrote: Hello, Apologies for not being able to resist answering even if it is getting off-topic. On Sun, Aug 10, 2014 at 05:43:33PM -0400, Theodore Ts'o wrote: On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew Kelley wrote: High quality libraries must iterate on their API. Especially for a library trying to solve such a complex problem as audio and video encoding and decoding for every codec and format. It is unreasonable to expect no incompatible changes. Also both ffmpeg and libav codebases have a lot of legacy cruft. Libav is making a more concentrated effort at improving this, and the evolving API is a side-effect of that. I beg to differ. My definition of a high quality library is one where careful design is taken into account when designing the ABI/API's in the first place, and which if absolutely necessary, uses ELF symbol versioning to maintain ABI compatibility. There are plenty of high quality libraries (glibc, libext2fs, etc.) where we've been able to maintain full ABI compatibility even while adding new features --- including in the case of libext2fs, migrating from 32-bit to 64-bit block numbers. And if you're careful in your design and implementation, the amount of cruft required can be kept to a very low minimum. While you certainly have a point that we have a lot to learn and improve, your comparison is not entirely fair, for reasons like a) glibc, libext2fs are much older projects, we still have to pay for old sins, from times where everyone was happy when their video played at all on Linux and nobody complained about ABI compatibility. Not to mention few of us having much experience in software development. Build something on a newer glibc system, and try to run the binary on an older system. It most likely won't work - even if it could in theory. (At least it was this way some years ago. Probably still is.) So glibc might achieve some ABI backwards-compatibility, but the truth is that they have many many issues, and the symbol versioning merely paints them over. They can only dream of ABI compatibility as solid as kernel32.dll's. b) A good number of our users are on Windows, which makes symbol versioning a very undesirable solution. Sometimes that means alternative solutions which are messier or more likely to break compatibility by accident To be fair, FFmpeg does its own manual symbol versioning by appending increasing numbers to function names. But the real problem are not these functions, but public structs. Imagine a new API user fighting to guess which fields in AVCodecContext must be set, or which must not be set. Seasoned FFmpeg developers probably don't know the horror. c) For libext2fs your users won't claim a file system is ext2, when it is actually btrfs and still expect your ext2 library to work with it! That is very much the standard in multimedia (everything is .avi, I don't care what format it is, I just want it to play, ...). Nor do you have competing ext2 implementations adding completely mis-designed extensions to it, with everyone expecting you to support it, that definitely makes API design a _lot_ more challenging. Even more importantly, libext2fs has a very specific use case. Not only is there only ext2fs vendor, it's also a pretty simple problem. IF you really want to make a fair comparison, you'd have to compare FFmpeg with a filesystem abstraction library that allows low-level accesses. I think the largest issue with FFmpeg is actually that it's so low-level. Users usually have to connect the individual libraries themselves, and that is very error prone. Hell, even the official FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem to be broken to hell. I think there should be a higher-level FFmpeg library that takes care of these things. d) At least in the case of glibc that backwards-compatibility is not at all free to its current users. _IO_stdin_used is a prime example of that, anyone playing with methods to reduce binary size/strip symbols will stumble over that and curse very loudly at some point. I certainly would have preferred it to not be ABI compatible in that case! I have the feeling glibc would have it easier if they wouldn't expose so many internals. If you compile a program written against standard C and POSIX, it will reference the strangest glibc symbols. Regards, Reimar ___ ffmpeg-devel mailing list ffmpeg-de...@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811225356.10314342@debian
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 Mon, Aug 11, 2014 at 10:53:56PM +0200, wm4 wrote: To be fair, FFmpeg does its own manual symbol versioning by appending increasing numbers to function names. But the real problem are not these functions, but public structs. Imagine a new API user fighting to guess which fields in AVCodecContext must be set, or which must not be set. Seasoned FFmpeg developers probably don't know the horror. There are some best practices in API design; one of them is to minimize public structs as much as possible. Instead, have blind pointers which are handed back by an initialize object function, and then have setter/getter functions that allow you to fetch various parameters or flags which modify how the object behaves. This allows you to add or deprecate new flags, configuration parameters, in a relatively sane way. I have this dream/fantasy where all of the energy over developing and maintaining two forks was replaced by a spirit of cooperations and the developers working together to design a new API from scratch that could be guaranteed to be stable, and then applications migrated over to use this stable, well-designed, future-proofed API. Call me a naive, over-optimistic dreamer, but :-) (And, the yes, the new API probably should be a bit higher level.) Can we all just get along? -- https://www.youtube.com/watch?v=1sONfxPCTU0 - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140811223423.ga7...@thunk.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, wm4: Build something on a newer glibc system, and try to run the binary on an older system. It most likely won't work - even if it could in theory. (At least it was this way some years ago. Probably still is.) What would be the point of introducing new or updated interfaces if you then couldn't use them? ABI backwards compatibility is not a goal I would want to spend any time on. Forward compatibility, on the other hand … To be fair, FFmpeg does its own manual symbol versioning by appending increasing numbers to function names. But the real problem are not these functions, but public structs. Imagine a new API user fighting to guess which fields in AVCodecContext must be set, or which must not be set. Seasoned FFmpeg developers probably don't know the horror. That's reasonably easy – you add a function to allocate the structure for you. That function sets a version field and/or initializes everything to a sane default. Also, you never shrink the structure, or move fields. Obviously, you also tell people to never ever embed the thing directly in something else, assuming that you can't keep it opaque entirely. Of course, it's only easy if you design your API that way from the beginning … I think the largest issue with FFmpeg is actually that it's so low-level. Users usually have to connect the individual libraries themselves, and that is very error prone. Hell, even the official FFmpeg examples are buggy, and _all_ unofficial FFmpeg tutorials seem to be broken to hell. I think there should be a higher-level FFmpeg library that takes care of these things. gstreamer-ffmpeg? -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140812005439.gl15...@smurf.noris.de
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, Jean-Yves Avenard: Including rename of constants (code enums id for example). Another nail in libav's coffin, then. IMHO it's reasonable to expect core APIs to be upwards-compatible and keep deprecated interfaces around for another release or two. Keeping your own static version is the only reasonable approach. That may be OK on Windows. However, a proper Linux distribution is supposed to be an integrated whole and not a haphazard collection of programs, each bringing along their own copy of core libraries and their own un- or semi-fixed security problems. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810070126.gr1...@smurf.noris.de
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Aug 10, 2014 at 12:01 AM, Matthias Urlichs matth...@urlichs.de wrote: Jean-Yves Avenard: Including rename of constants (code enums id for example). Another nail in libav's coffin, then. IMHO it's reasonable to expect core APIs to be upwards-compatible and keep deprecated interfaces around for another release or two. High quality libraries must iterate on their API. Especially for a library trying to solve such a complex problem as audio and video encoding and decoding for every codec and format. It is unreasonable to expect no incompatible changes. Also both ffmpeg and libav codebases have a lot of legacy cruft. Libav is making a more concentrated effort at improving this, and the evolving API is a side-effect of that.
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, Andrew Kelley: It is unreasonable to expect no incompatible changes. When somebody renames constants, a compatibility #ifdef or two is not too much to ask, IMHO. Libav is making a more concentrated effort at improving this, and the evolving API is a side-effect of that. That begs the question whether they're still essentially the same library, i.e. whether it's at all reasonable to expect code built using FFmpeg to work with libav. Consequently, Debian should at least include it, even if it really _is_ too late to switch (which I'm not conviced of). -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810074303.gb1...@smurf.noris.de
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi On 10 August 2014 17:01, Matthias Urlichs matth...@urlichs.de wrote: Hi, IMHO it's reasonable to expect core APIs to be upwards-compatible and keep deprecated interfaces around for another release or two. Then it becomes unreasonable for a piece of software to be compatible with multiple version of the same library, and support all of those. When a used come to use complaining that something is broken, that a file doesn't play or what else. It's a moot point trying to expect them to understand that the issue is due to a 3rd party library. MythTV aimed to be an appliance-like application. You install it and you forget about it. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANpj82JkPYGbXDC+mkEkACrYZ0H01+6Ng_UniPZ_bvHMG07p=q...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Aug 10, 2014 at 1:48 AM, Jean-Yves Avenard jyaven...@gmail.com wrote: Then it becomes unreasonable for a piece of software to be compatible with multiple version of the same library, and support all of those. IMO it's not worth the effort to support multiple versions of the same library. If you want to use an old library, use an old version of the software.
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 10 August 2014 18:53, Andrew Kelley superjo...@gmail.com wrote: IMO it's not worth the effort to support multiple versions of the same library. If you want to use an old library, use an old version of the software. In our case, we have very long release cycles. Usually only once a year at best. We have users on virtually all platforms. We can't assume the OS/distribution it will be running on will have the library we're hoping for. In the perfect world, sure all platforms would all be running the same versions of a given lib at a given time... In practice it never happens. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANpj82L-GU18cPF=euuukhpknpdy_cvk+ax2w89ydmwksb4...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 08/08/2014 09:22 PM, Matthias Urlichs wrote: We'd also benefit from the fact that Upstream tends to use FFmpeg. I'd hate to report some intractable codec bug which Upstream closes with an it works with FFmpeg comment Oh, btw, just a few days ago, that's exactly what happened on kdenlive [1]. A developer posted the following statement on an issue which is open for more than 1.5 years now: [quote] Confirm this is a libav problem, use builds with ffmpeg or wait debian (derivatives) to bring ffmpeg back [/quote] Just thought this might fit here... Regards, Pb == References: [1] http://www.kdenlive.org/mantis/view.php?id=2943#c10195 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e7388b.8030...@das-werkstatt.com
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: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 10 August 2014 13:38, Michael Niedermayer michae...@gmx.at wrote: 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). http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b5875b91113a0f3de6ad61e9ff8b74b81de94760 There was no mailing list discussion and initial bugs had to be discussed on ffmpeg-cvs. It appeared out of nowhere and there was no discussion about the API. Many of the contributors were cleaning the inline asm up or various other fixes or had worked on the original resample code. The comparison you make is highly misleading. On the other hand libavresample was developed by consensus and the API discussed beforehand. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cak+ulv4crhyvmfohmdlixdnsmyvezknplqartx3hpr-hkcv...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Aug 10, 2014 at 3:01 AM, Matthias Urlichs matth...@urlichs.de wrote: Hi, Jean-Yves Avenard: Including rename of constants (code enums id for example). Another nail in libav's coffin, then. That's one way to see it. To me, this makes mythtv unsuitable for inclusion into Debian. Let me explain why: 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. [1] at least statements such as https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160876.html strongly suggest this (at least if you have followed the libavresample/libswresample mess). Keeping your own static version is the only reasonable approach. That may be OK on Windows. However, a proper Linux distribution is supposed to be an integrated whole and not a haphazard collection of programs, each bringing along their own copy of core libraries and their own un- or semi-fixed security problems. BTW Jean-Yves outlines an approach that used to be very common on the past: Pick some particular snapshot of FFmpeg and maintain that in a downstream project, and expect users to use that because it is too much effort to keep up with FFmpeg's release frequency. Prominent examples of projects that did this (and actually, still do) include xine-lib, mplayer, xbmc, and many more. This lead exactly to the mess I was talking about in my previous email: dozens of embedded code-copies that were accepted into the Debian archive. Over many years, I've spearheaded a significant effort in Debian with packaging and in upstream with introducing a release culture in FFmpeg (as release manager) to get to somewhat same release frequencies, so that downstream projects at least had a chance to agree on common versions of FFmpeg. At the time of the split, I was worried that this work would have been in vain. Considering that most active developers of FFmpeg at that time (which coincidentally supported my approach to release management and frequency) joined what is now known as Libav, I continued my work as upstream release manager in Libav, because I consider Libav as much more suited for Debian than FFmpeg. Today, I still firmly believe that this was the right move for Debian as a project. I do strongly believe that projects that require people to use FFmpeg actually mean to use their own private fork (cf. the mythtv debacle), and given the amount of packages in Debian, it would significantly much more effort to port (or patch as Andreas is phrasing it) them to some common version of FFmpeg than doing what we are doing now: Making sure they work with the version of Libav's libavcodec.so implementation. This thread has shown a couple of examples that support this argument: Mythtv, but also mplayer that claims to work with a system libavcodec.so, which is true as long as it matches the version that is was built against. This is what makes mplayer so hard to package, and was ultimately the reason why I requested mplayer's removal (which is more than ironic, given that back then, I fought with ftp-master for many years to get it included into Debian in the first place). On a related note: Most Libav developers are very tired of the constant flamewars and defamation attempts that arises from FFmpeg. Over years, Libav tries to convinced everyone by providing usable software releases. Nevertheless, this particular debate is very worrisome: The silence from the Libav camp seems to not to be taken as consent. Quite the contrary is true. How to proceed from here? TBH, I'm not sure. Ideally, both projects would find some common ground and just merge (however that would technically look like). However, this very debate within Debian shows that this is unlikely to happen anytime soon: There is way to much disagreement on very fundamental questions that require agreement within a free software project, and the hostile and
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Reinhard, On 10.08.2014 15:10, 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 also has a deprecation process and keeps deprecated features around longer than Libav. For example, avcodec_encode_video, av_close_input_file and avcodec_decode_audio3 are still present in FFmpeg, but already removed from Libav. 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. The deprecation cycle is not related to the release frequency, as many FFmpeg release are API/ABI backwards compatible with the previous one. 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. I think you won't be able to keep that promise, because it wouldn't make much sense to stop merging changes from Libav (especially, if they are useful) after doing it for such a long time. Even in the unlikely event that this might happen, there is no reason to change the handling of deprecations. [1] at least statements such as https://ffmpeg.org/pipermail/ffmpeg-devel/2014-August/160876.html strongly suggest this (at least if you have followed the libavresample/libswresample mess). I'm understanding this mail differently: What Michael is explaining is that it is more difficult for FFmpeg to change things in libavresample than in libswresample, because Libav is unlikely to merge back changes, but FFmpeg tries to be compatible with Libav. In reality, there hasn't been any backwards incompatible change in libswresample (still soversion 0), but there has been one in libavresample (now at soversion 1). Keeping your own static version is the only reasonable approach. That may be OK on Windows. However, a proper Linux distribution is supposed to be an integrated whole and not a haphazard collection of programs, each bringing along their own copy of core libraries and their own un- or semi-fixed security problems. BTW Jean-Yves outlines an approach that used to be very common on the past: Pick some particular snapshot of FFmpeg and maintain that in a downstream project, and expect users to use that because it is too much effort to keep up with FFmpeg's release frequency. It is easy to 'keep up' with releases that are API/ABI compatible, which many FFmpeg releases are. One doesn't even have to recompile dependent programs (if they are not buggy), one can just install the new version of the libraries. Prominent examples of projects that did this (and actually, still do) include xine-lib, mplayer, xbmc, and many more. This lead exactly to the mess I was talking about in my previous email: dozens of embedded code-copies that were accepted into the Debian archive. As you must know, xine-lib and xbmc are - and mplayer was - compiled against the system version of Libav in Debian. Over many years, I've spearheaded a significant effort in Debian with packaging and in upstream with introducing a release culture in FFmpeg (as release manager) to get to somewhat same release frequencies, so that downstream projects at least had a chance to agree on common versions of FFmpeg. At the time of the split, I was worried that this work would have been in vain. It appears your work has not have been in vain, as FFmpeg's current release culture takes into account that any backwards incompatible API change means a lot of work for everyone using it. I believe this is handled now much better than in the times before the 0.5 release. If you are unhappy with how the releases are managed in FFmpeg, you can always send your concerns to ffmpeg-devel (and I think you still have commit rights for FFmpeg's git repository as well). Considering that most active developers of FFmpeg at that time (which coincidentally supported my approach to release management and frequency) joined what is now known as Libav, I continued my work as upstream release manager in Libav, because I
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, Aug 10, 2014 at 12:25:33AM -0700, Andrew Kelley wrote: High quality libraries must iterate on their API. Especially for a library trying to solve such a complex problem as audio and video encoding and decoding for every codec and format. It is unreasonable to expect no incompatible changes. Also both ffmpeg and libav codebases have a lot of legacy cruft. Libav is making a more concentrated effort at improving this, and the evolving API is a side-effect of that. I beg to differ. My definition of a high quality library is one where careful design is taken into account when designing the ABI/API's in the first place, and which if absolutely necessary, uses ELF symbol versioning to maintain ABI compatibility. There are plenty of high quality libraries (glibc, libext2fs, etc.) where we've been able to maintain full ABI compatibility even while adding new features --- including in the case of libext2fs, migrating from 32-bit to 64-bit block numbers. And if you're careful in your design and implementation, the amount of cruft required can be kept to a very low minimum. - Ted -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140810214333.ga22...@thunk.org
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Sun, 2014-08-10 at 23:02 +0200, Andreas Cadhalpun wrote: [...] * dvswitch: Still uses CodecID (and also avcodec_encode_video, but that is still present in FFmpeg.) [3] [...] dvswitch was also broken by the removal of support for downscaled decoding of DV video. I don't know whether that change is specific to libav or was also made in FFmpeg. Ben. -- Ben Hutchings Any sufficiently advanced bug is indistinguishable from a feature. signature.asc Description: This is a digitally signed message part
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, Jean-Yves Avenard: We have attempted for many years to get our changes merged in FFmpeg but gave up. It might be a good idea to restart this effort. To end this message: I fail to see how debian's decision on which version of FFmpeg or LibAV would have any impact on MythTV, we use neither Most forks cause additional work which, in the long term, is better spent elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal world, you wouldn't need the mythtv fork either. Debian's position is that we _really_ want to avoid having multiple copies of essentially the same code in the archive; it's additional work for the security team (if they even know about the copies), needlessly eats memory when the two are in use simultaneously, and causes no end of trouble when a plug-in is linked against copy A while the main code (or another plugin) uses copy B (unless everybody is very careful WRT symbol versioning). -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140809070317.gl1...@smurf.noris.de
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, 2014-08-08 20:06 GMT+02:00 Andreas Cadhalpun andreas.cadhal...@googlemail.com: Hi Reinhard, On 08.08.2014 14:29, Reinhard Tartler wrote: On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs matth...@urlichs.de wrote: I intended to come up with a more timely full response, but I just didn't get to it so far. Thanks for explaining your point of view here. For now, please refer to http://lwn.net/Articles/607662/, Have a look at: http://lwn.net/Articles/608040/ I was not there, when the FFmpeg/Libav split happened and I don't want to judge, whether it was a good thing or not. But it clearly caused a lot of bad blood between the developers involved, which in my opinion hurts the development of the multimedia framework in recent times. http://codecs.multimedia.cx/?p=370 (rather old, but still true), and If these features weren't used, they wouldn't have been developed. And many new features have been added to FFmpeg after that post. http://codecs.multimedia.cx/?p=674 (recent update on that matter) Let me quote from there: But that’s not what kills the fun, “security holes” do. With an advance of automatic fuzz tools it’s easy to generate millions of damaged files that crash your decoder and yet there are no tools for generating correct patches. Fixing those crashes is tedious, requires a lot of thinking (should I disable it? will it affect decoding correct files? etc.) and in other words not fun at all. That seems as if he doesn't want to continue Libav development, because fixing security issues is tedious work. It has basically nothing to do with whether FFmpeg is of good quality security wise or not, or a good or bad competitor against Libav. Regarding Marco's argument that libav had few friends, well, let me point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 for instance. One person thinking that the code is 'beautiful' is no convincing argument. The number of people expressing their interest in having FFmpeg back in Debian is a lot more convincing. IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. I think that is totally out of question: Uploading FFmpeg to our archive will break the Debian archive so hard that it will take months to get everything back to testing, if it works at all. Let me repeat what I wrote in my initial mail in this thread: Having FFmpeg in the Debian archive breaks absolutely *nothing*, but it gives developers and users a choice between the two. Even if Libav were to be removed, a transition to FFmpeg could be rather smooth, as all the necessary patches already exist. But you're right that the time to test the resulting packages is getting rather short for the coming freeze. Still it can make sense for packages that are tested with FFmpeg upstream and have known issues with Libav. So if you and the other Libav maintainers were to support the idea of having both, the security and release teams could perhaps be convinced to allow that. This has been my goal from the beginning and I hoped that would be appreciated. To the best of my knowledge, there are only two high-profile projects that play hardball to require FFmpeg: Mplayer and mythtv. Neither of those do that (again to the best of my knowledge) mainly because of technical but rather very political reasons. The case of mplayer has been elaborated extensively in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the following discussion with Reimar - my conclusion from that is while technically possible, nobody wants to make mplayer work with Libav - and that's why it was removed, not because of the FFmpeg dependency). For Mythtv I can only say that they didn't even bother engaging any discussion. That FFmpeg has more features is a rather technical argument. Note that also many other projects are developed mainly with FFmpeg, they just happen to not break completely when compiled against Libav. For example, mpv prefers FFmpeg for good reasons: Although mpv attempts to work well with both FFmpeg and Libav, FFmpeg is preferred in general. This is simply because FFmpeg merges from Libav, and seems to have more features and fewer bugs than Libav. [1] These features are actually requested by users, see e.g. [2]. (All) other high-profile downstream projects, including VLC or XBMC (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may Just fine? Did you see the bugs I mentioned in my initial mail? And how does it come that XBMC needs the '--enable-libav-compat' configure option, which then uses code from lib/xbmc-libav-hacks, to build against Libav? Being the xbmc maintainer I feel being addressed and let me share my POV regarding XBMC. :-) XBMC works with Libav for most use-cases while it fails in the rest, notably it can not use VDPAU acceleration which is being (understandably)
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Quoting Bálint Réczey (2014-08-09 11:38:54) XBMC works with Libav for most use-cases while it fails in the rest, notably it can not use VDPAU acceleration which is being (understandably) complained about very often (#742896). Another issue is Libav crashing on bad input which makes XBMC/Libav unusable in PVR configurations when signal is corrupted sometimes (#741170). Ok, so you know factually that some things are broken when linking XBMC with Libav instead of XBMC-FFmpeg. Upstream makes sure all their use-cases work well with FFmpeg and not interested in Libav-related issues. According to XBMC, they only make sure their code works with XBMC-FFmpeg. I can't fix the problems because I don't have any HW reproducing them, and I don't get help from Libav upstream/maintainers either in fixing those issues. That sounds to me like you do not factually know if XBMC will be broken also when linked against FFmeg (you only really know about XBMC-FFmpeg). I would like to have flawlessly working XBMC in Debian as well, but it can't happen without fixing the Libav issues I mentioned above or letting FFmpeg entering Debian. I do understand how it is easier for you to link XBMC against FFmpeg than against Libav, since FFmpeg has similar/same API as XBMC-FFmpeg, but it seems to me that you are jumping to conclusions when stating that linking against (non-XBMC-)FFmpeg will make XBMC work flawlessly. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
2014-08-09 13:41 GMT+02:00 Jonas Smedegaard d...@jones.dk: Quoting Bálint Réczey (2014-08-09 11:38:54) XBMC works with Libav for most use-cases while it fails in the rest, notably it can not use VDPAU acceleration which is being (understandably) complained about very often (#742896). Another issue is Libav crashing on bad input which makes XBMC/Libav unusable in PVR configurations when signal is corrupted sometimes (#741170). Ok, so you know factually that some things are broken when linking XBMC with Libav instead of XBMC-FFmpeg. Well, it depends on the definition of factually. I could not test the VDPAU issues myself. :-) Upstream makes sure all their use-cases work well with FFmpeg and not interested in Libav-related issues. According to XBMC, they only make sure their code works with XBMC-FFmpeg. I can't fix the problems because I don't have any HW reproducing them, and I don't get help from Libav upstream/maintainers either in fixing those issues. That sounds to me like you do not factually know if XBMC will be broken also when linked against FFmeg (you only really know about XBMC-FFmpeg). Since XBMC switched to vanilla FFmpeg from their internal fork I would be really surprised if XBMC did not work with the proposed new FFmpeg packages. -dmo packages are built with external FFmpeg, too... If this test is a deal-breaker for accepting FFmpeg into experimental I can provide binaries for testing but probably most curious DD-s having the right HW would be able to test if my theory is right. I would like to have flawlessly working XBMC in Debian as well, but it can't happen without fixing the Libav issues I mentioned above or letting FFmpeg entering Debian. I do understand how it is easier for you to link XBMC against FFmpeg than against Libav, since FFmpeg has similar/same API as XBMC-FFmpeg, but it seems to me that you are jumping to conclusions when stating that linking against (non-XBMC-)FFmpeg will make XBMC work flawlessly. I would say it is not a mathematically correct reasoning, but a strong expectation supported by observations. Prove me wrong if you really think I'm missing something, I will stand corrected. I made falsifiable statements. By flawlessly I mean very close to upstream's expectations and specifically fixing VDPAU and PVR issues I mentioned earlier. Cheers, Balint -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cak0odpwe3+f3xadthd+vy9p-gxnz_gwlvew9cksbp80dxa8...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Most forks cause additional work which, in the long term, is better spent elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal world, you wouldn't need the mythtv fork either. Debian's position is that we _really_ want to avoid having multiple copies of essentially the same code in the archive; it's additional work for the security team (if they even know about the copies), needlessly eats memory when the two are in use simultaneously, and causes no end of trouble when a plug-in is linked against copy A while the main code (or another plugin) uses copy B (unless everybody is very careful WRT symbol versioning). The reality is that in the current state of affairs static linking is the *only* way you are guaranteed to have the features you expect and avoid ABI mismatches. It's very complicated when your users complain about bugs in an underlying library that is either too old on a system or the wrong flavour of the fork. Then your users have to rebuild a massive dependency chain to fix that bug or hope for the best in the future. We also use a fork specifically to work around very wasteful calculations in libswscale during 10-bit chroma conversion that involve multiplying a pixel by a 2^n value with 32-bit precision and then shifting that value down by n back to 16-bit precision (achieving nothing). The fix breaks other codepaths that we don't use but the performance gain is big enough to warrant a fork. FWIW I think debian should also enable libavresample. This code has been proven to be more robust internally and was designed by a larger group instead of libswresample which was basically one person (and literally appeared in git out of nowhere). Kieran -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cak+ulv7ioqqw5wu+p_9hvqewfwq2rhhyp33gnpfdzvx-xjm...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi Kieran, On 09.08.2014 19:26, Kieran Kunhya wrote: The reality is that in the current state of affairs static linking is the *only* way you are guaranteed to have the features you expect and avoid ABI mismatches. It's very complicated when your users complain about bugs in an underlying library that is either too old on a system or the wrong flavour of the fork. Then your users have to rebuild a massive dependency chain to fix that bug or hope for the best in the future. I can understand that statically linking is easier from an upstream point of view, but it has important disadvantages for a distribution such as Debian and thus should be avoided if possible. It is also the responsibility of a distribution to make sure that there are no ABI mismatches or similar problems. We also use a fork specifically to work around very wasteful calculations in libswscale during 10-bit chroma conversion that involve multiplying a pixel by a 2^n value with 32-bit precision and then shifting that value down by n back to 16-bit precision (achieving nothing). The fix breaks other codepaths that we don't use but the performance gain is big enough to warrant a fork. Can you provide a commit/diff/link for reference? The way you describe it makes it appear as if these calculations are needed sometimes, but not always. If so, there should be away to teach libswscale to only do these calculations if they are necessary. FWIW I think debian should also enable libavresample. This code has been proven to be more robust internally and was designed by a larger group instead of libswresample which was basically one person (and literally appeared in git out of nowhere). FWIW I already enabled libavresample in the Debian FFmpeg package for compatibility reasons [1]. Still I would be interested in any proof of libavresample being 'more robust internally'. Best regards, Andreas 1: https://anonscm.debian.org/cgit/collab-maint/ffmpeg.git/commit/?id=e6d32135ec5ada648465aba8d4daad58b86ff8d0 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53e66785.4020...@googlemail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 9 August 2014 19:25, Andreas Cadhalpun andreas.cadhal...@googlemail.com wrote: I can understand that statically linking is easier from an upstream point of view, but it has important disadvantages for a distribution such as Debian and thus should be avoided if possible. It is also the responsibility of a distribution to make sure that there are no ABI mismatches or similar problems. I'm not saying Debian should do that - just that it is sometimes worthwhile for people like myself and mythtv to do so. Can you provide a commit/diff/link for reference? The way you describe it makes it appear as if these calculations are needed sometimes, but not always. If so, there should be away to teach libswscale to only do these calculations if they are necessary. I hacked it in: https://github.com/kierank/ffmpeg-obe/commit/5a354020872bec61bea6be7604ec8809af463021 I made it a bit cleaner later but still ugly overall. Kieran -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAK+ULv6FwBSRAbw+Dq_DPLeZn9=vawxu4aoaut5ny7hbasv...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Quoting Bálint Réczey (2014-08-09 14:39:09) 2014-08-09 13:41 GMT+02:00 Jonas Smedegaard d...@jones.dk: Quoting Bálint Réczey (2014-08-09 11:38:54) Upstream makes sure all their use-cases work well with FFmpeg and not interested in Libav-related issues. According to XBMC, they only make sure their code works with XBMC-FFmpeg. I can't fix the problems because I don't have any HW reproducing them, and I don't get help from Libav upstream/maintainers either in fixing those issues. That sounds to me like you do not factually know if XBMC will be broken also when linked against FFmeg (you only really know about XBMC-FFmpeg). Since XBMC switched to vanilla FFmpeg from their internal fork I would be really surprised if XBMC did not work with the proposed new FFmpeg packages. Whoops - I confused XBMC and MythTV. Sorry for the noise. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On 9 August 2014 17:03, Matthias Urlichs matth...@urlichs.de wrote: Most forks cause additional work which, in the long term, is better spent elsewhere. The ffmpeg/libav split is ample proof of that; in an ideal world, you wouldn't need the mythtv fork either. Debian's position is that we _really_ want to avoid having multiple copies of essentially the same code in the archive; it's additional work for the security team (if they even know about the copies), needlessly eats memory when the two are in use simultaneously, and causes no end of trouble when a plug-in is linked against copy A while the main code (or another plugin) uses copy B (unless everybody is very careful WRT symbol versioning). I beg to differ. What would be a massive amount of waste, both in time and resources, would be to have a project such as MythTV having to handle multiple versions of a dependency. Especially one such as libav* where the API changes often, and more often than not in a totally incompatible manner from one API to the next. Including rename of constants (code enums id for example). You would have to keep your own headers (like what Firefox/Mozilla is doing) and have multiple code paths only adding to the difficulty of proper coverage testing... Keeping your own static version is the only reasonable approach. As far as naming and conflicts, I don't see what the problem is unless it's improperly packaged, or for example when the packagers decide that they know better than the original authors and start to do weird thing, modify the code as they wish. That's where the issues are most of the time. Sounds familiar ? :) -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CANpj82+bthc3cu9YQXvj4E6meK1BbPA7FO=krozc1r26ck6...@mail.gmail.com
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Hi, Andreas Cadhalpun: Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It has been removed from sid, since it fails to build against Libav, but it builds fine against FFmpeg. (It uses some of the features only provided by FFmpeg.) Yet another reason why solely depending on libav is a bad idea. That leaves the question of the official opinion of the libav maintainers (pkg-multimedia-maintain...@lists.alioth.debian.org). Did none of them write anything in defense of libav, or have I simply missed it? IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. -- -- Matthias Urlichs -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808111329.gi15...@smurf.noris.de
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Aug 08, Matthias Urlichs matth...@urlichs.de wrote: IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. Agreed. The interested parties should really raise this with the CTTE ASAP. -- ciao, Marco signature.asc Description: Digital signature
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
On Fri, Aug 8, 2014 at 7:13 AM, Matthias Urlichs matth...@urlichs.de wrote: Hi, Andreas Cadhalpun: Once FFmpeg is back in the archive, it'll be easy to reintroduce MPlayer. It has been removed from sid, since it fails to build against Libav, but it builds fine against FFmpeg. (It uses some of the features only provided by FFmpeg.) Yet another reason why solely depending on libav is a bad idea. That leaves the question of the official opinion of the libav maintainers (pkg-multimedia-maintain...@lists.alioth.debian.org). Did none of them write anything in defense of libav, or have I simply missed it? I intended to come up with a more timely full response, but I just didn't get to it so far. For now, please refer to http://lwn.net/Articles/607662/, http://codecs.multimedia.cx/?p=370 (rather old, but still true), and http://codecs.multimedia.cx/?p=674 (recent update on that matter) Regarding Marco's argument that libav had few friends, well, let me point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 for instance. IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. I think that is totally out of question: Uploading FFmpeg to our archive will break the Debian archive so hard that it will take months to get everything back to testing, if it works at all. To the best of my knowledge, there are only two high-profile projects that play hardball to require FFmpeg: Mplayer and mythtv. Neither of those do that (again to the best of my knowledge) mainly because of technical but rather very political reasons. The case of mplayer has been elaborated extensively in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159#79 (see the following discussion with Reimar - my conclusion from that is while technically possible, nobody wants to make mplayer work with Libav - and that's why it was removed, not because of the FFmpeg dependency). For Mythtv I can only say that they didn't even bother engaging any discussion. (All) other high-profile downstream projects, including VLC or XBMC (now Kodi) work demonstrably just fine with Libav. Sure, FFmpeg may provide them with extra features, but why on earth would anyone want 3 different implementations of a ProRes encoder (seriously, and FFmpeg seems to claim to provide security support for each of them), or support for fringe codecs such as Wing Command 3 (yes, you can decode the videos from that video game). There are a number of legitimate requested backports, such as for some of FFmpeg's additional filters in libavfilter, and similar. All of them are rather easy to backport, and this is done on a regular basis. However, with the due diligence and attention such a widely used and high-profile library requires. Which brings me to my next point: Release frequency. FFmpeg has an insane frequency of releases, and still seems to support (at least providing updates) to all of them, including 0.5 which is currently in oldstable (needless to say none of these patches made it to oldstable-security, why is still a mystery to me). The effect of that is that downstream projects have a hard time to choose what version of FFmpeg they want to support. This brings effectively back to the situation I was in when I took over maintenance of the package many years ago: Back then, Michael Niedermeyer strongly recommended all downstreams to avoid shared libraries and just link statically against libavcodec.a to avoid problems regarding incompatible library versions. I see exactly this problem arising again: Both mythtv and mplayer upstream (btw, xbmc as well) bundle some copy of ffmpeg in their sources and recommend everyone to just use the internal copy to avoid problems. Needless to say that this is not acceptable for use in Debian. Yes, I agree that this situation is a mess. A big mess. My fear is that switching to FFmpeg will bring us back to the mess we where 8 years ago, and I worked on for years. Libav is far from being perfect. That's true. I don't know why exactly FFmpeg seems to have more manpower, but it's not all black or white. For instance, there are a number of developers that actively contribute to both projects and are essential in keeping both projects in good health. Also I don't really buy the security argument. True, FFmpeg has more security updates, but backporting them to Libav turned out to be difficult because many if not most of them turn out to be either incomplete, invalid or require further clarification. Libav developers prefer to go the unpleasant road of fully understanding the issue, which takes extra time. For all these reasons, I do not see the necessity to do any drastic and dangerous steps right now. I now seriously wonder if the last 45 minutes in which I wrote this email wouldn't have been better spent with preparing the next upload for stable-security. YMMV. -- regards, Reinhard -- To UNSUBSCRIBE, email to
Re: Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
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. In fact, it's pure slime. The fact that up until this point the Debian Project has been so accepting of a fork that runs so contrary to the free software spirit in its ethics has darkened my view of the entire project. -- Joe Neal vlvtel...@speakeasy.net -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140808081624.dabc0d29631e24ade9c73...@speakeasy.net
Re: [FFmpeg-devel] Reintroducing FFmpeg to Debian
Quoting Reinhard Tartler (2014-08-08 14:29:59) For now, please refer to http://lwn.net/Articles/607662/, http://codecs.multimedia.cx/?p=370 (rather old, but still true), and http://codecs.multimedia.cx/?p=674 (recent update on that matter) Regarding Marco's argument that libav had few friends, well, let me point to https://medium.com/libre-parole/libav-is-beautiful-4c1a2c886948 for instance. IMHO the best idea at this point would be to toss out libav, and rebuild the rdeps with ffmpeg. Now, before it's too late for jessie. I think that is totally out of question: Uploading FFmpeg to our archive will break the Debian archive so hard that it will take months to get everything back to testing, if it works at all. To the best of my knowledge, there are only two high-profile projects that play hardball to require FFmpeg: Mplayer and mythtv. Neither of those do that (again to the best of my knowledge) mainly because of technical but rather very political reasons. [snip] I now seriously wonder if the last 45 minutes in which I wrote this email wouldn't have been better spent with preparing the next upload for stable-security. YMMV. Thanks a lot for your input, Reinhard. Even if the loud ones in this thread may not, I doubt I am the only one finding value in your references and arguments. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
