
The FFmpeg/Libav situation - ux
http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
======
afhof
I know its a limited view of reality, but I was debugging ffserver, found the
bug and mentioned it on FFmpeg's IRC channel. Michael added my own one-liner
change and listed me as the author for the git commit. This is a GREAT feeling
for a newcomer to a project and it makes me want to keep helping with FFmpeg.

I agree with the author of this article in that FFmpeg will eventually win
out, just for little things like this.

~~~
zobzu
That's true. I'm always annoyed when I send a patch for a project, it's
integrated and that's it. No thanks. No mention of what I did. Just as if the
author just found something and added it. Sometimes it's one liners (which may
take hours to debug as usual), sometimes its a few thousand lines.

This behavior kills the will to contribute quickly.

~~~
adimitrov
That's what github is doing so nicely with pull-requests: you maintain
authorship of your fixes (it's even cryptographically secured,) and the entire
process is visible and documented on the project's source home page.

~~~
zokier
That is not unique to github pull requests, is it? I thought that was common
to all of git, and the reason why git has separate "author" and "commiter"
fields

~~~
zobzu
yes, as they gotta pull from you for that. github just makes the process
easier and it is more trouble not to attribute via github.

in both cases you can make a patch (=copy/paste) instead. and in the first
case you often actually provide a patch because it might be easier or because
they're using something else than a git or git-like vcs

------
ghshephard
I read the entire article carefully, thinking about various other schisms in
the Open Source World (Net/OpenBDS being the one that came to my mind first) -
and reflected on how important leadership is in many of those communities. For
better or worse, the (in most cases) benevolent dictatorship of people like
Theo (OpenBSD), Linus (Linux), and Guido (Python) play an important role in
herding their respective cats.

It might be interesting to see how effective (if such a thing could even be
measured) communities with benevolent dictators perform as compared to those
that operate by consensus/voting.

~~~
Palomides
are there any significant projects other than debian that have elections?

~~~
scottjad
For some value of significant, Squeak. The turn out has been down for the last
few elections, with the last one getting around a hundred votes, with around
450 people authorized to vote.

~~~
protomyth
Some of the decline is probably linked to the Pharo fork <http://www.pharo-
project.org/home>

------
nkurz
I tried to get involved in FFmpeg development several years ago, and felt
driven off by the existing community. It wasn't so much any one individual,
but the absence any "adult" voice trying to keep things moving forward. There
are a lot of smart programmers there, and a lot of loud people on the list,
but no real correspondence between the two traits.

The quality of the code base also left something to be desired. It was fast,
and generally worked, but they certainly didn't subscribe to the camp that
believes in treating compiler warnings as errors. I remember using Valgrind
and discovering that some memory was being used uninitialized, and submitting
a patch. The patch was rejected with a comment such as "not needed". I still
don't know if this was correct, but I do know that being a static initializer
my patch wasn't going to slow anything down.

~~~
kevingadd
Static initializers aren't always free, FYI. They can slow down app startup
(this is a _serious_ issue for Firefox).

~~~
tedunangst
I think the word static was misused in nkurz's post. static variables are
always initialized, at least to 0. Initializing a stack variable shouldn't
harm performance.

~~~
nkurz
Correct, I was trying to describe initializing a stack variable to a constant
array, and shouldn't have used the word static. In retrospect, I think the
cost of this is probably just the same as zeroing it, since behind the scenes
it has to be copied from a constant? But the rejection wasn't due to the
performance harm, but was based on a philosophy that one shouldn't change
"provably" correct just to make it more compliant.

------
gillianseed
I was curious as to which distros default to ffmpeg and which default to
libav, looking at my distro of choice (Arch Linux) it's ffmpeg, there's no
libav in the official repos as far as I can tell and programs like VLC,
Blender, MPlayer2 all link to ffmpeg, Mplayer on the other hand links directly
against the core codec libraries unless I'm mistaken.

The article states that Debian (and Ubuntu?) uses libav (and yes, the bs about
ffmpeg being deprecated is obviously a douchebag move), so does anyone know
what other distros are defaulting to, Gentoo, Fedora, OpenSUSE etc?

~~~
hasboth
Gentoo offers both libav and ffmpeg in Portage, though they cannot currently
be installed at the same time. However, I would not be surprised if they are
eventually changed to be installable at the same time and use the eselect
system to switch between them (similar to the "alternatives" system in
Debian).

------
Game_Ender
My only direct interaction with ffmpeg and libavcodec/libavformat has been
from a user and developer stand point. Most of it has been very poor, the code
works well, but their API both the C interface and the CLI could be a lot
better.

~~~
jlarocco
Couldn't agree more on the C API. The time I had to use it was a nightmare.
There's almost no documentation, and the interface changes so often it's
nearly impossible to find working sample code.

~~~
ux
We did some work to improve this a little, see for example:
[http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc/examples;...](http://git.videolan.org/?p=ffmpeg.git;a=tree;f=doc/examples;hb=HEAD)

This should be deployed with any new fresh ffmpeg install.

The filtering code is still unstable due to what's explained in the blog
post...

~~~
revelation
Its a start, but missing the point nonetheless. The grand idea is to have all
the codecs and formats unified into one API, but the reality is that said API
has become a gigantic dump yard. Redundant options and variables with one
codec using one set and a different codec another. Not to mention to have
stuff fail because a particular codec does not like a specific configuration.

------
nothacker
This all sounds very Hatfield/McCoy to me. Whether or not libav is a PITA/POS,
I don't know, but of the two, I had only heard of and used ffmpeg until now.
That said, I really don't give a crap how either of them operate, and neither
should anyone else but the maintainers. This reminds me so much of the
volunteer work that happens at our school. So many personalities involved and
people get so upset because they've poured their heart and soul into it. You
don't find that as often on the business/corporate side of things. Even though
real money is on the line there, it is just a job. I think the same thing
applies here. These people are getting so upset, but I doubt they realize that
95-98% of users _don't give a crap_. We are just glad that you are providing
great libraries and utilities. So... take a chill pill and get over it. And
thanks for your work.

~~~
keithpeter
"This reminds me so much of the volunteer work that happens at our school. So
many personalities involved and people get so upset because they've poured
their heart and soul into it."

Its the 'meaning' thing that makes your volunteers give up their own time and
do free work. Open source projects will probably have similar
loyalty/emotional investments.

------
dbcooper
Has Hendrik Leppkes ever discussed why he chose FFmpeg for his popular LAV
Filters project?

------
euphemize
well this is fitting. lost ~4 hours yesteday trying to compile ffmpeg properly
to work with newly enabled codecs and kdenlive - errors on errors on errors -
with very little resources to help out. what a mess.

------
Aissen
Debian's maintainer stance isn't really an issue since Christian Marillat is
the defacto Multimedia maintainer: <http://www.deb-multimedia.org/>

------
NotA20YearOld
For me the link is an unreadable low contrast website. Come on folks; make
your websites accessible.

~~~
shelf
I'm not sure what your definition of contrast is, sir. That was a fairly
bright grey on a fairly dark grey. Returning to HN from this article was an
unpleasant retinal shock.

Confusing a bright, backlit monitor with a piece of paper is some pretty nasty
1990s logic.

~~~
caladri
Note the use of the word "accessible" in the original post. This is not a
synonym for "pretty" or some way of demanding a particular aesthetic style for
its own sake. The reality is that some degree visual impairment is not at all
uncommon and that difficulty with contrast can result from any number of
conditions.

I'm not sure about the original poster's statement that that site isn't
accessible. I haven't tried applying a stylesheet from my browser to it, and I
don't use anything to enhance contrast of text in web pages, as my vision is
not impaired in that way. There's an argument to be made, though, that modern
websites use coloring, layers, and a bunch of other things to achieve layouts,
looks and feels to the extent that if you want to see content as it is
presented, or to even find it readable or usable at all, you'll have a hard
time with applying styles using your browser.

Believing that just because the web can be used differently to black-type-on-
white-paper in a wide variety of ways means that every way of using it
differently is virtuous is pretty mid-2000s web 2.0 logic. Contrast is useful,
and its proven track record for rendering text is no mark of antediluvian
shame, of irrelevance or datedness.

~~~
shelf
Would you call that low-contrast, though? My comment suggests that both colors
are quite some distance apart, so despite the inversion, the contrast is quite
reasonable. It just has the added bonus of, you know, not burning the crap out
of my eyes.

You seem to have read something in my comment that wasn't there.

