IRC channel logs

<mark_weaver>regarding mit-scheme: I see that the 'c' file is only downloaded for non-intel platforms, so I'm probably the first person who tested this code.

<a_e>mark_weaver: I updated mesa in master. As for later versions, they do not compile with either nix or guix, see the comment (and the url) given in the package definition.

<a_e>As for mit-scheme, you might need to modify the package definition and fill in the architecture specific file for mips.

<a_e>taylanub: It is amazing that I still remember my comment to which you just replied...

<taylanub>:)

<a_e>taylanub: So you should start using guix tonight ;-)

<taylanub>I'll do it eventually but switching OS is a bother .. I wonder if I should wait for a stand-alone Guix release, or go for Guix-on-another-distro.

<a_e>I use guix on debian, so it is not switching os, so no bother at all.

<a_e>Whatever is not available in guix (so most things for me), I use from debian.

<fddddddd>I'm currently building gcc-4.8.2, then I'd like to test the front ends.

<a_e>fddddddd: Good plan!

<mark_weaver>a_e: thanks for updating mesa! I wasn't sure whether to update the URL or switch to a newer version.

<mark_weaver>a_e: it looks like the build problem for newer versions could be fixed by touching some files before the build, to prevent automake/autoconf from being run.

<mark_weaver>presumably there's a rule in the makefile to run automake or autoconf again if one of the source files is newer than the corresponding generated files. probably the patching that happens as part of nix/guix builds is making that happen.

<mark_weaver>I'll add it to my TODO list :)

<fddddddd>wc -l TODO?

<mark_weaver>fddddddd: my guix todo list isn't too bad at all: 38 lines many of which are blank lines. My Guile TODO list, on the other hand, is _completely_ out of control.

<fddddddd>mark_weaver: How do you organize it? I use org-mode, which I don't know well, so mine is a mess.

<mark_weaver>they're just plain text files, but I really ought to get in the habit of using org-mode. it looks great.

<a_e>mark_weaver: I was expecting the mesa people to fix the bug...

<a_e>Why would it happen only in nix and guix?

<mark_weaver>a_e: are you sure it's a bug in mesa?

<a_e>Well, maybe the patching has an impact.

<fddddddd>What's wrong with gnunet_bot? I noticed that it quits the channel from time to time.

<mark_weaver>a_e: probably because one of the patching/substitution operations is modifying one of the source files used by automake/autoconf, thus triggering the associated Makefile rules that use automake/autoconf to regenerate.

<a_e>fddddddd: It does not record anything right now. So we can speak freely ;-)

<fddddddd>a_e: https://gnunet.org/bot/log/guix/2013-10-27#T264643

<mark_weaver>a_e: are you sure? it's on channel now?

<mark_weaver>s/?$/./

<mark_weaver>however, there's usually some lag time before things show up on the gnunet erweb site.

<a_e>mark_weaver: It started again this evening. Yesterday it did not record anything.

<fddddddd>mark_weaver: It is logging. See the link.

<mark_weaver>fddddddd: I know.

<fddddddd>Right.

<fddddddd>I guess I should ask grothoff.

<mark_weaver>fddddddd: ask him what?

<mark_weaver>are you sure it's not just losing the connection periodically, due to circumstances out of its control?

<mark_weaver>I also log #guix, #guile, and a few others, and my server loses the connection fairly frequently.

<mark_weaver>(and sometimes is not able to get back on for a while)

<fddddddd>I'm not sure.

<mark_weaver>fddddddd: do you want me to send you what gnunet_bot missed?

<mark_weaver>wow, gnunet_bot was offline for quite a long time.

<viric>who is gnunet_bot?

<fddddddd>I am.

<fddddddd>viric: I think it's grothoff's bot, so I asked him about the downtime.

<viric>I understand. But how come it's in #guix? :)

<fddddddd>I think that mark_weaver asked grothoff to log the channel.

<mark_weaver>I didn't ask grothoff to log this channel, but I was here when he started logging it, and then I asked him to log #guile as well.

<mark_weaver>viric: if I remember correctly, Grothoff is interested in Guix for security reasons, and as a deployment method for gnunet.

<mark_weaver>specifically, I believe he's interested in the potential for Guix to produce bit-for-bit reproducable (and thus verifiable) builds.

<mark_weaver>and when I saw him setting up logging for #guix, I asked him to log #guile as well, which he was willing to do because guile is such a core part of guix.

<viric>ok

<fddddddd>viric: IIUC, grothoff said that the bot is poorly written. Here's the code: https://drupal.org/project/bot

<fddddddd>So if anyone wants to look into it, that would be appreciated.

<mark_weaver>well, drupal is based on PHP, isn't it? I wouldn't touch PHP with a ten foot pole.

<fddddddd>grothoff said it's PHP, yes.

<fddddddd>haha

<mark_weaver>a_e: btw, did you successfully build coreutils on MIPS?

<a_e>Yes, no problem.

<a_e>So problems might be due to fd...d's exotic file systems.

<mark_weaver>what kernel were you using when you built it?

<mark_weaver>fddddddd is back on ext3, I believe.

<fddddddd>yep

<a_e>3.2.0-4-loongson-2f from debian wheezy

<fddddddd>mark_weaver: re yeeloong: I haven't tried anything since I don't actually know what causes the problem.

<mark_weaver>fddddddd: and what system and kernel are you building Guix/MIPS on?

<fddddddd>gnewsense; can't remember the kernel version. let me check.

<mark_weaver>I wonder if it was just a strange fluke. maybe you should try building it a second time.

<fddddddd>OK, I'll try. If it fails, maybe I should try to compile the version you're using. Would you like to share your kernel config?

<mark_weaver>sure

<fddddddd>a_e: I'm currently building gccgo-4.8.2. I'd like to check whether it needs the -g option as the previous version. Then I should be able to start working on the patches.

<fddddddd>mark_weaver: Could you send it via email please?

<mark_weaver>I made a fairly minimal config for linux-libre 3.10.15, the one with loongson patches produced for gnewsense.

<a_e>fddddddd: Which patches? Those that add the compilers to the distribution?

<a_e>I am looking forward to gfortran, it is needed for gnu octave.

<fddddddd>a_e: The gcc upgrade and the frontends.

<a_e>Excellent!

<mark_weaver>however, I should warn you that I cannot use the wireless network on that kernel. it panics very soon after connecting to wireless.

<mark_weaver>and it locks up randomly, very occasionally.

<mark_weaver>for now, most of the time, I use a much older 2.6.39.1 kernel that is rock solid. but that's not what I was using when I built coreutils.

<fddddddd>a_e: If the new version of gccgo doesn't need the -g option, then we could push the frontends to master and upgrade gcc in core-updates. otherwise, everything would be done in core-updates.

<a_e>Okay.

<fddddddd>mark_weaver: Are you using initrd? It significantly slows down the boot time.

<fddddddd>mark_weaver: On my YeeLoong, I'm using 3.5.3-gnu from gnewsense with the defaults.

<mark_weaver>fddddddd: no, I don't use an initrd.

<fddddddd>mark_weaver: re the wireless problem: is it a connected with the config or simply a bug?

<mark_weaver>a bug

<fddddddd>mark_weaver: fyi, I'm trying to build coreutils again.

<fddddddd>a_e: Nope, the -g option is still needed for gccgo.

<fddddddd>a_e: So would you need gccgo and the other frontends in master? Or should I prepare the patch for core-updates?

<mark_weaver>fddddddd: thanks, let me know how the coreutils build goes.

<fddddddd>sure

<mark_weaver>(I'll be afk quite a bit, so expect delays, but I'll read the backlog)

<fddddddd>mark_weaver: Wow, you were right. I successfully built hello.

<mark_weaver>fddddddd: that's great news!

<mark_weaver>does that mean coreutils built also?

<fddddddd>Indeed. Your advice saved me a lot of time.

<mark_weaver>(I don't know off-hand if it's a dependency)

<fddddddd>Yes, I sent a message to the list.

<mark_weaver>great!

<fddddddd>Just to make sure, what's the hash of your hello package?

<mark_weaver>fyi, here's my current list of packages that fail to build on MIPS for me: libmad, alsa-lib, mit-krb5, gprolog, guix, libtheora, ocaml, pari-gp

<fddddddd>Oh, there were only two a couple of days ago.

<mark_weaver>fddddddd: and here's what I've successfully built so far: http://paste.lisp.org/+2ZRO

<mark_weaver>there is some redundancy in there, because I had to rebuild a bunch of stuff after fixing libffi.

<fddddddd>mark_weaver: How can I build all packages, by the way? Do you use some script to pass all names to guix build?

<fddddddd>gzg: Any news regarding Mediagoblin?

<mark_weaver>fddddddd: I'm not doing anything fancy. just: for pkg in blah blah blah; do echo ===== $pkg; ./pre-inst-env guix build -K $pkg; done

<mark_weaver>where "blah blah blah" is something I typed by hand from looking at: guix package -A .

<fddddddd>OK.

<gzg>fddddddd: Still need to get python-lxml, but besides that -- All depends sdould be done.

<fddddddd>gzg: Great! Thanks for working on it. Did you send your patches (the deps) to the list?

<mark_weaver>(I could have extracted the full list from "guix package -A ." easily enough, but I didn't want to build everything. I wanted to start with a smaller list)

<fddddddd>What's the difference?

<gzg> fddddddd: I'm going to see if I can get pythoen-lxml going before I go to bed tonight, if not -- yeah, I'll submit a patch for python.scm; I'll probably upload what I have thus far, for network.scm too,

<fddddddd>gzg: Thank you.

<gzg>Should I move related network utils from linux and base.scm to network.scm?

<fddddddd>gzg: I'm not sure. We could always move them if Ludo doesn't like network.scm for whatever reason.

<gzg>why when I add a "2" to an expressions name (say python2-virtualenv) there's a problem? Snould I just leave the expression name bare and just leave it in the package name?

<fddddddd>what do you mean by the term "problem"? could you paste the error?

<gzg>fddddddd: It just tells me my package is unknown, when it builds fine without any mention of said 2.

<fddddddd>hm

<fddddddd>you could also try to run the interpreter and import your module to get a more informative error message

<fddddddd>./pre-inst-env guile

<fddddddd>,use (gnu packages foo)

<fddddddd>Also, take a look at the python package. python-2 is a variable, python is a name, version is set to 2.7.5. Could you try to do a similar thing?

<fddddddd>gzg: For instance, if I try to build it like this: ./pre-inst-env guix build python-2 I get "package not found for version 2". Either a name or a name-version should be used.

<mark_weaver>gzg: my impression is that base.scm is specifically for things that almost everything else depends on, so that set of packages need to be treated specially. I suspect it's a bad idea to move anything out of that module without understanding the ramifications. civodul would know though.

<fddddddd>Yes, I also think the same.

<gzg>fddddddd: Okay, python2-virtualenv, imaging, and cssselect now builds.

<fddddddd>Awesome.

<mark_weaver>gzg: what in base.scm is network related, anyway?

<gzg>mark_weaver: IIRC, inetutils?

<mark_weaver>inetutils is in system.scm

<gzg>Should cython be prefaced by python2?

<gzg>mark_weaver: Ah, maybe I was mixing the tw;. :^P

<gzg>two*

<mark_weaver>I guess that system.scm and linux.scm are not nearly as fundamental, so it wouldn't be unreasonable to propose a reorganization to civodul.

<mark_weaver>but if a package only works on linux (and not on other kernels such as the hurd), then it probably belongs in linux.scm.

<mark_weaver>(fyi, whenever I say "linux", I mean the kernel)

<gzg>Yeah, I gotcha.

<mark_weaver>s/to civodul/to guix-devel/

<gzg>I'll bbl, going to late lunch. o/

<fddddddd>jxself, taylanub, mark_weaver: I read the FFmpeg vs. Libav discussion. IIUC, both can do similar things, but the former uses the dictator model and promotes a free-software-unfriendly patented codec. Is it correct? If it's not, could you start a new thread on the list? IMO, such things should be discussed there.

<jxself>I'm not certain if it can be stated that the FFmpeg project promotes any particular codec over another.

<mark_weaver>fddddddd: I agree that we need a list discussion. but I find it sometimes helps to discuss on IRC first.

<fddddddd>jxself: I meant the name.

<jxself>We should rename the kernel too? It references something with non-free stuff in it.

<fddddddd>jxself: It has been done.

<fddddddd>It's called Linux-libre.

<jxself>Yes, "Linux"

<fddddddd>mark_weaver: Right, but it's much easier to search the list archives. And I'm not sure whether Ludo reads the logs or not.

<jxself>Just like "MPEG" is part of the program name.

<taylanub>(Which references Unix which is non-free.)

<fddddddd>Haha.

<fddddddd>Let's stop it.

<a_e>fddddddd: Do what you have to do for the front ends! I do not actually need octave. I just tried to build it once (for my Paris talk, I think) and noticed it needed gfortran. One more step towards having all of the gnu project in guix.

<a_e>mark_weaver: pari-gp cannot build on mips n32. It requires sizeof(long)==sizeof(void*).

<mark_weaver>that's the case on N32

<mark_weaver>both long and pointers are 32 bits.

<mark_weaver>jxself: I think putting Linux in the same category as MPEG is a bit hard to swallow.

<a_e>Okay, right. But it also reauires sizeof(void*)==sizeof(mp_limb_t), which is the word size from gmp big integers; they happen to be long long of size 64 bit.

<fddddddd>jxself, taylanub: I didn't write that to start a flamewar. That's why I suggested the list. I'd like to see the facts. (But if both can do the same things, why can't we choose the one with a free-software-friendly name?)

<mark_weaver>ah, well, that's a drag.

<mark_weaver>so pari-gp won't work on x32 either.

<a_e>Right.

<jxself>I think I'm just saying that if we're to start evaluating program names, what's the criteria?

<jxself>And it should probably be noted that MPEG-LA != MPEG

<a_e>It requires a sane memory model...

<jxself> https://en.wikipedia.org/wiki/MPEG vs. https://en.wikipedia.org/wiki/MPEG_LA

<fddddddd>jxself, taylanub: You seem to prefer FFmpeg. Could you elaborate on the list please? I don't think that we'll ever agree if we keep the discussion here. Thank you.

<pigoz>maybe you could find this informative https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav

<taylanub>fddddddd: I don't have a strong opinion, I just got negative vibes, through second-hand sources, from the Libav people, in terms of attitude/behavior/personality.

<jxself>"and decided to take over."

<jxself>Yeah, I read about the domain hijacking somewhere.

<jxself>I think the first paragraph in the "Situation Today" section describes it.

<jxself>Why I like FFmpeg.

<mark_weaver>jxself: I'm aware that MPEG != MPEG-LA. MPEG publishes standards that cannot be used by free software without the threat of patent infringment lawsuits. In fact, as far as I know, they don't publish any standards that we can use.

<mark_weaver>jxself: link to "Situation Today" please?

<jxself>Thr https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav that pigoz did.

<jxself>That's also where I quote the "and decided to take over."

<jxself>from

<jxself>I seem to recall reading about the domain hijacking somewhere.

<mark_weaver>a basic problem we have here is that virtually everyone who is involved enough in that code base to be competent to judge the comparative merits has probably chosen sides, and thus is likely to be unfair to the other side.

<mark_weaver>given how hostile the two camps are to each other.

<mark_weaver>so it's hard to collect data that's unbiased.

<jxself>It might also be important to note what that document says, and which I've seen mentioned elsewhere, that the Libav folks ban FFmpeg developers from participating. Doesn't seem very nice.

<jxself>Whereas FFmpeg keeps pulling in stuff from Libav, so it seems that there's at least an attempt to work together.

<jxself>Even if the Libav folk refuse to allow work to go in both directions.

<mark_weaver>Given how hostile the two camps are to each other, it's hard to say whether such bans are unjustified.

<jxself>Even still, the code could be re-used by Libav.

<jxself>But it seems, from reading stuff, they refuse.

<jxself>And so that certainly doesn't help either.

<mark_weaver>if ffmpeg people went on to the libav fora and tried to convince everyone that libav was junk, then I can see why libav would react that way.

<jxself>But code doesn't require any Libav people to talk to any FFmpeg person.

<jxself>It's all public & could be easily obtained.

<jxself>Anonymously even.

<mark_weaver>I was responding to "the Libav folks ban FFmpeg developers from participating. Doesn't seem very nice."

<jxself>I think they're both integrated. Libav refuses to play ball, it seems, but FFmpeg at least tries by pulling in Libav changes even if they're not allowed to talk to the Libav developers.

<a_e>What a mess!

<jxself>Both issues, I mean. Talking and code sharing.

<mark_weaver>given that the entire purpose of the libav fork in the first place was to unseat a dictator, I don't think it's fair to make them look like the bad guys because they "refuse to play ball" with the former dictator.

<mark_weaver>it's been pointed out that the former dictator has become a lot better since the libav was created and became so widely used (due to debian and ubuntu choosing to use libav).

<mark_weaver>but to my mind, that doesn't mean that we should let him gain a position of dominance again.

<jxself>I'm talking of refusing to play with anyone.

<mark_weaver>People who slip into dictatorial mode once can easily slip into it again, if given the chance.

<jxself>"We don't like this person so we'll ignore the entire project and everyone in it."

<mark_weaver>and then we'd have to go through this all over again.

<jxself>Seems a bit much to me to say that.

<taylanub>By the way does anyone have sources on all the things the dictator did wrong, which initially made the later-to-be-Libav people mad ?

<mark_weaver>and again, I will point out that this dictator does not seem to consider support for theora/vorbis to be a priority. if his priorities were at least aligned with ours, _maybe_ it would be reasonable to let him stay in that position.

<jxself>You seem to attribute all project decision to this single person. How many people work on FFmpeg again?

<a_e>I found an interesting source which I am reading right now:

<a_e> http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html

<jxself> http://codecs.multimedia.cx/?p=339

<jxself> https://lwn.net/Articles/423702/

<mark_weaver>in a project with a dictatorial model, I think it's reasonable to blame the dictator for not putting much effort into good support for free software friendly formats.

<fddddddd>mark_weaver: I don't think so.

<fddddddd>Maybe the project leader doesn't have enough experience in those areas.

<jxself>mark_weaver: For this to be valid I think you'd need to show that said person actively blocked others from improving support in this area.

<jxself>Otherwise it's saying that this single person is single handedly repsonsible for every single bug and problem in the project, which is unrealistic I think.

<mark_weaver>okay, that's true. we need more data.

<fddddddd>I also agree.

<mark_weaver>and of course, whatever you all decide, I can do whatever I want in my own private guix branch.

<fddddddd>haha

<mark_weaver>For one thing, I used libav in Debian Wheezy and never had problems watching whatever videos I wanted to.

<mark_weaver>For another, I don't want a package on my system whose very name promotes an organization that I despise.

<mark_weaver>but, obviously, just as the two camps have strong feelings about this, some of us here also seem to have strong feelings. it's hard to be objective or open-minded.

<jxself>FFmpeg is named after MPEG-LA?

<jxself>Wikipedia claims "The name of the project comes from the MPEG video standards group, together with "FF" for "fast forward"."

<mark_weaver>What is there to like about MPEG ?

<a_e>Speaking practically: Do programs such as mplayer and vlc work with both libraries? Or would we need to hand-patch them for one or the other?

<a_e>So far, I have the vague impression that these two are rather on the ffmpeg side.

<mark_weaver>what's there to like about a standards group whose standards are hostile to us?

<jxself>a_e: I think that's talked about in https://github.com/mpv-player/mpv/wiki/FFmpeg-versus-Libav

<jxself>In the Is FFmpeg or Libav preferred for use with mpv? and later sections.

<a_e>jxself: For mpv; so far, I am using only mplayer and sometimes vlc. But preferences may vary, of course.

<jxself>mark_weaver: More conflating with MPEG & MPEG-LA it seems.

*jxself ponders that

<mark_weaver>jxself: can you name a single video codec that MPEG standarized that is not patented?

<jxself>MPEG LA is not affiliated with MPEG, the Moving Picture Experts Group.

<jxself> https://en.wikipedia.org/wiki/MPEG-LA

<mark_weaver>I never claimed they were. what makes you think I conflated them?

<jxself>That is probably not a fair comparison, though, considering that the patent system is broken and people can get patents on practically anything & everything.

<jxself>Because of your statements.

<mark_weaver>what statements?

<jxself>MPEG-LA is the patent agressor, not the Motion Picture Experts Group.

<jxself> what's there to like about a standards group whose standards are hostile to us?

<jxself>But it's not the standards group doing this.

<mark_weaver>no, MPEG doesn't go after us. MPEG just creates the standards that MPEG-LA will go after us if we try to use.

<jxself>Yo ustill seem to think there's a connection. I'm not sure what to do.

<mark_weaver>standards groups for techniques used by software should *not* create standards that cannot be used without violating patents.

<jxself>Given how the patent system is broken, that would probably be impossibile.

<jxself>er; I can't type.

*jxself forms OGG-LA

<mark_weaver>I have to go afk. I have a 2.5 year old climbing over me to get to the keyboard, and I can keep him off only so long. ttyl.

<jxself>Now I will go after everyone doing stuff with Theora, Vorbis, FLAC, etc.

<jxself>I have a similiar name but no connection....

<mark_weaver>jxself: I never said there was a connection.

<mark_weaver>Are patent aggressors the only organizations I'm allowed to dislike?

*jxself sighs

*jxself gives up

<jxself>There's no getting through

<mark_weaver>MPEG publishes standards that they KNOW are patented, and that cannot be used by free software.

<mark_weaver>wow.

<mark_weaver>anyway, gotta go afk..

<mark_weaver>wow, I'd expect the FSF webmaster to understand this.

<a_e>It seems like vlc would be compatible with both:

<a_e> http://forums.gentoo.org/viewtopic-p-7404998.html

<mark_weaver>I'll have to ask RMS if he thinks it's unreasonable to dislike MPEG (as opposed to MPEG-LA)

<a_e>mark_weaver, jxself: Independently of the name, both ffmpeg and libav implement the same codecs. So in practice, using one or the other does not solve nor create any patent problems. Liking or not "mpeg" as part of the name should not, I think, drive our decision of which one to package.

<taylanub>a_e: jxself has left I'm afraid.

<taylanub>BTW tiny nitpick: libav.org has the header "Open source audio and video processing tools" under its logo. (Otherwise ffmpeg.org and libav.org seem equivalent in wording regarding free software, licenses, etc.)

<taylanub>If I find time I'll try some more to get information on the respective projects' attitude towards FSF ideals.

<fddddddd>taylanub: Thanks.

<a_e>mplayer uses ffmpeg; at

<a_e> http://www.mplayerhq.hu/design7/dload.html

<a_e>they say "currently there is also a reasonably recent release available, which includes an FFmpeg snapshot".

<a_e>As I remember, ffmpeg was a spin-off of code from mplayer anyway.

<wm4>no, they were always separate, but very close to each other

<taylanub>wm4: Hidy ho

<a_e>wm4: Okay. Maybe I am confused since mplayer seems to ship ffmpeg as part of its sources.

<wm4>both projects (ffmpeg and Libav) hate the GPL btw.

<taylanub>ouch

<fddddddd>haha

<wm4>they also support linking to some non-free libraries

<wm4>(you can build nice unredistributable binaries if you set the right options)

<taylanub>Indeed, I noticed there's --enable-nonfree .. I wonder if it's default.

<wm4>so I don't think deciding by their attitudes towards the FSF is a great idea

<a_e>taylanub: In both ffmpeg and libav, --enable-nonfree is off by default.

<a_e>wm4: I am afraid it might boil down to a matter of taste in the end.

<wm4>well, ffmpeg is slightly more active, has slightly more features, and has slightly fewer bugs

<fddddddd>a_e: mark_weaver was also worried about FFmpeg theora/vorbis support. Is there a difference between FFmpeg and Libav in this sense?

<wm4>no

<a_e>Both have --enable-libtheora and --enable-libvorbis.

<wm4>they have a native vorbis decoder and encoder too

<fddddddd>What about the quality? Is it the same?

<wm4>between native encoders and libvorbis? no idea

<a_e>From what I read in the given web pages, ffmpeg merges in all? most? changes from libav.

<wm4>yes it does

<a_e>fddddddd: If you speak about quality differences between ffmpeg and libav, that is, and not between native and external encoding.

<fddddddd>Yes, I meant the former.

<a_e>wm4: So technically, the differences should be slim; the web pages I have read give a minor technical advantage to ffmpeg.

<wm4>since ffmpeg merges everything from libav, and since ffmpeg still is the project with more visibility, ... well you can draw your own conclusions

<a_e>With quicker bug fixing and more interest in security fixes.

<wm4>(btw. I'm the author of that FFmpeg-versus-Libav wiki article someone linked earlier)

<fddddddd>But what's missing in Libav? What does FFmpeg have that Libav doesn't?

<wm4>mostly obscure stuff

<a_e>wm4: The one on blog.pkh.me?

<wm4>a_e: no, not that one

<fddddddd>the one on github?

<wm4>yes

<wm4>for example, ffmpeg has ported all mplayer video filters, while libav has only some

<a_e>wm4: Does mpv have an encoder part? I just read that it is based on mplayer2 and that mplayer2 has removed mencoder.

<wm4>yes mpv has an encoder part, it's something newly written and not based on mencoder

IRC channel logs

2013-10-27.log