Using ffmpeg libs in an OSS project is a nightmare

[Kenneth Lavrsen]

Dear Developers of ffmpeg

ffmpeg is a very nice project from a technical point of view

But from the view of a developer and project maintainer of a project that
uses ffmpeg - the project is a nightmare.

My name is Kenneth Lavrsen. I maintain the project Motion which has been
using ffmpeg for years now. (yes please add to the list).

http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome

Motion is a software motion detector. Motion is a program that monitors the
video signal from one or more cameras and is able to detect if a
significant part of the picture has changed; in other words, it can detect
motion. Motion is a command line based tool whose output can be either
jpeg, ppm fies or mpeg video sequences. It is made for Linux and FreeBSD.

I am receiving almost daily support requests all releated to people having
problem building Motion with ffmpeg support. Besides the usual problem with
people not having the -devel RPMs installed the most common problem is that
they have downloaded the "latest CVS" of ffmpeg and get compilation errors.

And the answer is so often to install an older RPM or deb.

We try to keep up with the API changes in libavformat and libavcodec but
there is now so many #ifdef statements in the code that I have lost control.
This is highly depressing and time consuming and the minute I found a
useful alternative option I would stop using ffmpeg for Motion. And that is
sad.

So what is the problem? There are two:

Problem 1 and the most severe and EASY TO FIX
The problem is that you guys running the ffmpeg project seems to be very
little aware of the importance of very basic and simple software configuration
management.

From your website: "New, official "releases" are few and far between. In
short, if you want to work with FFmpeg, you are advised to go along with
CVS development rather than relying on formal releases." This is the key
problem. This is BAD ADVICE and a BAD POLICY. At least it is for the
libraries. Maybe this is acceptable for the command line tools which do not
change user interface that much and where the user adjustment is keying
something different. But for the libraries changing API all the time this
is a nightmare.

ffmpeg is used very widely. People have ffmpeg installed for other reasons
than Motion and often they cannot use those MUSEUM releases you have on the
Sourceforge download site which you make less than once per year and never
really fully do. The fact that 0.4.9pre1 never became 0.4.9 is rediculous.

As maintainer of a project that depends on libavcodec and libavformat:
Please make more formal releases! Please make a formal release every time
you add major new features.
The packagers such as Livna, AT and Dag - and the debian packagers will
then take these and package and 99% of the users will use these.
And I as Motion maintainer will ensure to have my software working against
the latest release.
I cannot do that today when the releases are so scarce.
And if that is too difficult for you to manage - then do the simplest of
solutions. Take the CVS snapshot from each end of a quarter and give it one
minor version number higher and upload it on Sourceforge. The daily snaps
you have now are not manageable. I cannot check daily if Motion no longer
works because of API changes or severe ffmpeg bugs.
At least with quarterly releases I could check and fix 4 times a year.

Please change this "latest CVS policy" and help both projects and packagers.


Problem 2. And I know you have heard this before.
Please document the API of the libraries!!!
The "look at the code example" is not sufficient. It is so dificult to code
against the libraries and each time you change the API it is a pain for us
to find out how to make our program work again and which #ifdef's to put in
the code so it is backwards compatible to older ffmpeg versions. The
Doxygen pages are not very useful. I might as well just try and read the code.

A last advice.
You should look at the Motion TWiki site. Making that was the best thing I
ever did for the project Motion. And it enables putting the burden of
maintaining API docs and users docs on many people incl users.
It has made maintaining release notes, maintaining and integrating patches
etc a very easy task. I have even given up using the Sourceforge tracker
because the TWiki applications I have made gives much more interaction and
collaboration and it gives me and the other coders more time to code.
Look at the links below how I have made the API docs for the pwc driver for
example. And for the Motion remote control API.


Regards
Kenneth Lavrsen

Project maintainer of Motion
http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome
http://sourceforge.net/projects/motion/

Maintainer of the Wiki for the pwc driver
http://www.lavrsen.dk/twiki/bin/view/PWC/WebHome

API for Motion remote control
http://www.lavrsen.dk/twiki/bin/view/Motion/MotionHttpAPI


--
Kenneth Lavrsen,
Glostrup, Denmark
***@lavrsen.dk
Home Page - http://www.lavrsen.dk

[Diego Biurrun]

Post by Kenneth Lavrsen
My name is Kenneth Lavrsen. I maintain the project Motion which has been
using ffmpeg for years now. (yes please add to the list).
http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome

Added.

Post by Kenneth Lavrsen
Problem 1 and the most severe and EASY TO FIX
From your website: "New, official "releases" are few and far between. In
short, if you want to work with FFmpeg, you are advised to go along with
CVS development rather than relying on formal releases." This is the key
problem. This is BAD ADVICE and a BAD POLICY. At least it is for the
libraries. Maybe this is acceptable for the command line tools which do not
change user interface that much and where the user adjustment is keying
something different. But for the libraries changing API all the time this
is a nightmare.

There is a solution to this problem available to you: Include a working
CVS snapshot of FFmpeg in Motion. It's what many other projects
building on FFmpeg do, at the very least all the players, i.e. MPlayer,
xine, vlc, avifile, tcvp.

Post by Kenneth Lavrsen
A last advice.
You should look at the Motion TWiki site. Making that was the best thing I
ever did for the project Motion. And it enables putting the burden of
maintaining API docs and users docs on many people incl users.

Noted.

Diego

[j***@v2v.cc]

Post by Diego Biurrun
There is a solution to this problem available to you: Include a working
CVS snapshot of FFmpeg in Motion. It's what many other projects
building on FFmpeg do, at the very least all the players, i.e. MPlayer,
xine, vlc, avifile, tcvp.

which is totally brain dead. each project has to redo integrating
ffmpeg, each time i compile a project i spend the most time compiling
ffmpeg. one of the nice things about the the invention called
shared library is, that you do not have to compile it each time you
use it.

its also a bad excuse not do be able or willing to do release
management; to spend some thought about a stable api etc...

j

[Kenneth Lavrsen]

Post by Diego Biurrun
Added.

Post by Kenneth Lavrsen
Problem 1 and the most severe and EASY TO FIX
From your website: "New, official "releases" are few and far between. In
short, if you want to work with FFmpeg, you are advised to go along with
CVS development rather than relying on formal releases." This is the key
problem. This is BAD ADVICE and a BAD POLICY. At least it is for the
libraries. Maybe this is acceptable for the command line tools which do

not

Post by Kenneth Lavrsen
change user interface that much and where the user adjustment is keying
something different. But for the libraries changing API all the time this
is a nightmare.

There is a solution to this problem available to you: Include a working
CVS snapshot of FFmpeg in Motion. It's what many other projects
building on FFmpeg do, at the very least all the players, i.e. MPlayer,
xine, vlc, avifile, tcvp.

That is not a very good solution. Naturally that has been discussed in the
Motion team. Both placing known good ffmpeg sources and known good RPMs and
debs for download on the Motion sourceforge files page. And we probably
will do that.

But it is a very bad solution because ffmpeg is not just used for Motion.
If it was it was not a big issue. But ffmpeg is used for so many other
projects. Project that most people have and are using also. And it creates
nothing but errors, trouble, bug reports, people giving up when they both
have some old RPM of ffmpeg installed, and then install from sources from
some CVS snapshot. It is totally out of control.

I get support questions daily related to ffmpeg. I am so tired of this
situation. And I am sure maintainer of other project feels like I do.

90% of users download and install an RPM. Only few install from sources.
And then it always ends up with downloading some RPM from Dag, or ATRPMs or
Livna and then things break. MPlayer does not work or Motion does not work.
All the time because you guys change the API for the libs more often than I
change my underwear and with no change control, release notes, version
control whatsoever. Just a daily CVS snap. You really make it difficult -
almost impossible - to use the ffmpeg libs in other projects.
And the packagers do not know which ffmpeg snaps to release to they seem to
take a pick when encouraged to and the major packagers are not at all in
sync. Add to this Gentoo which relies on sources and you have a big mess.

ffmpeg is the ONLY open source project making shared libraries that are
this much out of control. Please listen to your users and try and learn. I
am sure you do not spend this much time on developing the code without
caring about if others can actually use the work project.


What does it take to do a release?

You have an automatic script making a "release" every day. What is it that
takes so long that you cannot give it a version number and upload it to the
Sourceforge file area?
If you start doing that - lets say every 3 or 6 months - the well known
packagers will for sure take only these and create their packages. You guys
only need to produce the source tar.gz.

Naturally you could do it the 100% automatic way. Just pick the snap from
31st of March = 0.4.9, 30th of June = 0.4.10, 30th of September = 0.4.11,
31st of December = 0.4.12.
It would be better than nothing.

Better would be to pick a known pretty good snap and release that.

There is always one more bug! There is always one more known problem not
yet resolved. If you wait for the day that ffmpeg is just perfect you will
die unhappy.
The purpose of formal releases is to give the projects that depend on it -
and the end users - BASELINES. And to give us a some reasonable conditions
so that we known we do not have to fight with ever changing APIs. Just the
last 2 months I have had to update Motion TWICE because of libavformat API
changes. And I am only using the mpeg1 / mpeg4 / msmpeg4 codecs.

It is truely a nightmare and for you it is only a matter of spending 15
minutes to rename a date marked ffmpeg tar.gz and upload it to Sourceforge.
And if you want to do a little better job - an extra 15 minutes to write a
10-20 line release note listing new features AND changed APIs.

You really have no excuse for not doing it. It took me longer to write this
email than it took me to release last version of Motion.

I would recommend making a list of dates. Minimum twice a year. Max 4
times. Maybe 3 time is a good value.

Put these dates on the ffmpeg web site.

People know that the CVS of that day becomes next release so the developers
take a little care a week or two before not to break anything. And then
when the date arrives you take the 15 minutes to rename the tar.gz and
upload it to Sourceforge along with a brief release note.

It also makes it possible to uprev the shared lib packages without reaching
version 80 in a year because it would only be at the formal release date
that you would consider upreving the shared lib version. Shared lib version
control would make it possible for Motion to use one version and Mplayer to
use another. That is the whole idea of shared libs and many projects taking
advantage of the hard work done on a lib such as ffmpeg. You cannot
continue the "pick the last CVS" and "just pack a known good ffmpeg CVS
source tree with your sources". It does not do the job anymore.

Kenneth

[Diego Biurrun]

Post by Kenneth Lavrsen

Post by Diego Biurrun
There is a solution to this problem available to you: Include a working
CVS snapshot of FFmpeg in Motion. It's what many other projects
building on FFmpeg do, at the very least all the players, i.e. MPlayer,
xine, vlc, avifile, tcvp.

That is not a very good solution. Naturally that has been discussed in the
Motion team. Both placing known good ffmpeg sources and known good RPMs and
debs for download on the Motion sourceforge files page. And we probably
will do that.
But it is a very bad solution because ffmpeg is not just used for Motion.
If it was it was not a big issue. But ffmpeg is used for so many other
projects. Project that most people have and are using also. And it creates
nothing but errors, trouble, bug reports, people giving up when they both
have some old RPM of ffmpeg installed, and then install from sources from
some CVS snapshot. It is totally out of control.

You seem to have misunderstood. What you can do is copy FFmpeg sources
into Motion and link _statically_, not dynamically. This is the way it
works for all the above-mentioned projects and it will make all your
problems go away. People will even be saved the trouble of installing
an FFmpeg RPM.

As Michael said, if you wish this to change, come over and make it
happen yourself, I'm sure nobody will refuse a helping hand.

Diego

[Michael Niedermayer]

Hi

Post by Kenneth Lavrsen

Post by Diego Biurrun
Added.

Post by Kenneth Lavrsen
Problem 1 and the most severe and EASY TO FIX
From your website: "New, official "releases" are few and far between.
In short, if you want to work with FFmpeg, you are advised to go along
with CVS development rather than relying on formal releases." This is
the key problem. This is BAD ADVICE and a BAD POLICY. At least it is
for the libraries. Maybe this is acceptable for the command line tools
which do

not

Post by Kenneth Lavrsen
change user interface that much and where the user adjustment is keying
something different. But for the libraries changing API all the time
this is a nightmare.

There is a solution to this problem available to you: Include a working
CVS snapshot of FFmpeg in Motion. It's what many other projects
building on FFmpeg do, at the very least all the players, i.e. MPlayer,
xine, vlc, avifile, tcvp.

[...]

Post by Kenneth Lavrsen
But it is a very bad solution because ffmpeg is not just used for Motion.
If it was it was not a big issue. But ffmpeg is used for so many other
projects. Project that most people have and are using also. And it creates
nothing but errors, trouble, bug reports, people giving up when they both
have some old RPM of ffmpeg installed, and then install from sources from
some CVS snapshot. It is totally out of control.

distributions which are far behind cvs head or even have just the yearly
releases are not supported in any way by me/us? and i dont care at all what
happens to them, these old releases have _known_ security bugs and any work
toward making them more useable is work toward getting the users systems
hacked, thats not something i want to contribute to

Post by Kenneth Lavrsen
I get support questions daily related to ffmpeg. I am so tired of this
situation. And I am sure maintainer of other project feels like I do.
90% of users download and install an RPM. Only few install from sources.
And then it always ends up with downloading some RPM from Dag, or ATRPMs or
Livna and then things break. MPlayer does not work or Motion does not work.

well you are ignoring the suggestions of both the ffmpeg & mplayer developers
and then complain that libav*+mplayer breaks what do you expect?

Post by Kenneth Lavrsen
All the time because you guys change the API for the libs more often than I
change my underwear

ok thats the first valid complaint in your mail, we should really try harder
to avoid api breakage

Post by Kenneth Lavrsen
and with no change control, release notes,

there are release notes, they are called cvslog, if you dislike that, just
volunteer to write better ones for the cvs snapshots, and just to preempt the
obvious troll, the number of changes in the snapshots are the same as in
releases over time X so its not really more work


[...]

Post by Kenneth Lavrsen
What does it take to do a release?
You have an automatic script making a "release" every day. What is it that
takes so long that you cannot give it a version number and upload it to the
Sourceforge file area?
If you start doing that - lets say every 3 or 6 months - the well known
packagers will for sure take only these and create their packages. You guys
only need to produce the source tar.gz.

[...]

Post by Kenneth Lavrsen
There is always one more bug! There is always one more known problem not
yet resolved. If you wait for the day that ffmpeg is just perfect you will
die unhappy.
The purpose of formal releases is to give the projects that depend on it -
and the end users - BASELINES. And to give us a some reasonable conditions
so that we known we do not have to fight with ever changing APIs. Just the
last 2 months I have had to update Motion TWICE because of libavformat API
changes. And I am only using the mpeg1 / mpeg4 / msmpeg4 codecs.

calling a random or not random snapshot every 3 month a release will IMHO not
help much, you still have to deal with every single API change and thouse who
use cvs or a non release snapshot will have a lot of problems, now thouse
using cvs are the developers and they are much more important then the users
simply because a project with no developers is a dead project, it depends
upon them
the real problem are the API changes and the fact noone cares about the shared
lib support (we just have an army of trolls complaining)


furhermore ffmpeg is a free software project developed by volunteers, if you
want something done/changed/... the first and absolutely necessary thing is
to volunteer to do the related work, you cant expect us to do what you want
for you for free

[...]

[Kenneth Lavrsen]

Post by Michael Niedermayer
distributions which are far behind cvs head or even have just the yearly
releases are not supported in any way by me/us? and i dont care at all what
happens to them, these old releases have _known_ security bugs and any work
toward making them more useable is work toward getting the users systems
hacked, thats not something i want to contribute to

Distributions in general do not contain ffmpeg for patent reasons. That is
why rpms are made by people outside USA by people independent from the distros.

Post by Michael Niedermayer

Post by Kenneth Lavrsen
I get support questions daily related to ffmpeg. I am so tired of this
situation. And I am sure maintainer of other project feels like I do.
90% of users download and install an RPM. Only few install from sources.
And then it always ends up with downloading some RPM from Dag, or ATRPMs or
Livna and then things break. MPlayer does not work or Motion does not work.

well you are ignoring the suggestions of both the ffmpeg & mplayer developers
and then complain that libav*+mplayer breaks what do you expect?

I am not ignoring anything. Installing RPM packages is the way 90% or maybe
rather 99% of users install and run software. Especially libraries.
And WHY should your little project as the only one be so different from the
others? Why are you right and the whole open source software world in
general so wrong?

Post by Michael Niedermayer

Post by Kenneth Lavrsen
All the time because you guys change the API for the libs more often than I
change my underwear

ok thats the first valid complaint in your mail, we should really try harder
to avoid api breakage

You bet!
But as a programmer and project maintainer I also know that sometimes it is
necessary. And when I decide to change the API - I do it in an announced
and controlled manor.
Example. When Motion changed its remote control interface (used by any GUI
frontends) I announced my intentions many months before, wrote a new API
doc that was reviewed (announced to mailing list - nothing fancy here) and
when implemented Motion changed version from 3.1.17 to 3.2.1. And I even
continued the 3.1 branch a few extra minor bug releases until 3.1.20 when I
finally declared the old branch dead. That is called change control. That
is called caring about the users and the programmers that work on projects
that depend on yours.

Post by Michael Niedermayer
there are release notes, they are called cvslog, if you dislike that, just
volunteer to write better ones for the cvs snapshots, and just to preempt the
obvious troll, the number of changes in the snapshots are the same as in
releases over time X so its not really more work

Noone needs the detailed changes. You need to summarise the changes.
You know dammed well that CVS log entries are made to be understood here
and now by the other programmers.
ffmpeg is just one little package that Motion and other projects rely on.
You cannot expect us to sit and read 1000s of CVS entries and try to
decipher what that means. It is totally unrealistic.
If you work on a project and maintain it - you should spend the extra 30
minutes per 3 months and summarize the big picture. Ie. feature changes - 1
line per feature - and API changes - 1 line per change. Simple. And only
the maintainer with the overview can realisticly do it.

Post by Michael Niedermayer
calling a random or not random snapshot every 3 month a release will IMHO not
help much, you still have to deal with every single API change and thouse who
use cvs or a non release snapshot will have a lot of problems, now thouse
using cvs are the developers and they are much more important then the users
simply because a project with no developers is a dead project, it depends
upon them

developers are more important than the users??
You really mean that? ffmpeg without projects that uses the project is a
command line tool and a set of libs. The many nice projects puts it to
life. You should be proud that the work you have done is now used by so
many different projects. And it is a real wonderful project you have made
from technical perspective. Some really cool brains are behind the many
codelines in ffmpeg.

You should really care about the developers of the projects that uses
ffmpeg. We spend a lot of time on our projects too you know.

Post by Michael Niedermayer
the real problem are the API changes and the fact noone cares about the shared
lib support (we just have an army of trolls complaining)

You have an army of trolls complaining. Maybe you should start listening
and ope your ind to the fact that maybe they are all right. I am not a
troll. I am an open source developer who maintains TWO open source projects
(Motion and Open2300) and helps with documentation on the PWC driver. I
spend 2-3 hours a day on open source development. And often 8 hours a day
in the weekends and vacations. And it is not my daytime job. I have a full
time job on top of that. I am not paid either for my work. And I do not
even accept donations. I think I am doing my share for the open source
community and do not need to be called a troll.

I am sure that making 3 releases per year would cost you less time to do
than answering emails when "trolls" try to convince you to run your project
a little more adult way.

Post by Michael Niedermayer
furhermore ffmpeg is a free software project developed by volunteers, if you
want something done/changed/... the first and absolutely necessary thing is
to volunteer to do the related work, you cant expect us to do what you want
for you for free

As I already wrote above. I am doing my share to the open source community.
If you need a helping hand to upload the files to Sourceforge 3 times a
year I think I can find the time for that. That is easy. I just need to
know which daily snap is the best from the previous few days. Or we could
put recommendations from developers on a Wiki page.

I can also make a few topic on my TWiki where developers can add a line now
and then for the release note and for voting for best release candidate.
But I really do not think this is a problem with human resources or anyones
time. It is a lack of understand of basic version control and its importance

I would like to hear the oppinions from other developers of projects using
ffmpeg.

Would a fixed release schedule - let us say February 1st, June 1st, October
1st where you know there is a fixed release be someone that would be useful
and helpful to you?
(naturally one can delay it a few days if a severe bug has just been found
and needs to be fixed and naturally one can do a quick follow up release if
something really serious is broken. But something is always broken. And if
it is a problem - the support answer will always be to download latest CVS
snap. Noone will fix an old version.).

And to the developers of ffmpeg - would that really disturb your sleep
knowing that every 4 month you work gets released with a new version number
and a bunch of packagers create their packages for RH, Fedora, Suse,
Gentoo, Debian etc etc?

And if any packagers are following this mailing list - would you prefer to
package these scheduled releases instead of some random daily snaps?

Kenneth

[Diego Biurrun]

Post by Kenneth Lavrsen

Post by Michael Niedermayer
well you are ignoring the suggestions of both the ffmpeg & mplayer developers
and then complain that libav*+mplayer breaks what do you expect?

I am not ignoring anything. Installing RPM packages is the way 90% or maybe
rather 99% of users install and run software. Especially libraries.
And WHY should your little project as the only one be so different from the
others? Why are you right and the whole open source software world in
general so wrong?

You are ignoring advice, repeatedly even. Why can't you just link
statically to FFmpeg and be done with it? The rest of the world does
it, are they all wrong and you are right insisting on dynamic linking?

Post by Kenneth Lavrsen
ffmpeg is just one little package that Motion and other projects rely on.

And Motion is just one little insignificant program that no one around
here has heard about before. I don't mean to be rude, but put yourself
in the other side's shoes.

Post by Kenneth Lavrsen
developers are more important than the users??

You have to differentiate between end-users and "users" that are
developers themselves, people like you that reuse code or include
libraries.

You forget that with free sw projects the developers are users
themselves. If you drop all the users, you still have the devs using
their own stuff. If you drop all the devs, you have no software to use.

Post by Kenneth Lavrsen

Post by Michael Niedermayer
the real problem are the API changes and the fact noone cares about the
shared lib support (we just have an army of trolls complaining)

You have an army of trolls complaining. Maybe you should start listening
and ope your ind to the fact that maybe they are all right. I am not a
troll.

But maybe you are not tackling a real issue in a constructive manner.
If you wish to have this problem solved, provide manpower or funding.

Post by Kenneth Lavrsen
I am an open source developer who maintains TWO open source projects
(Motion and Open2300) and helps with documentation on the PWC driver. I
spend 2-3 hours a day on open source development. And often 8 hours a day
in the weekends and vacations. And it is not my daytime job. I have a full
time job on top of that. I am not paid either for my work. And I do not
even accept donations. I think I am doing my share for the open source
community and do not need to be called a troll.

These numbers are not going to impress anyone around here. There are
members of this mailing list that spend (or have spent) considerably
more time on free sw than you.

Post by Kenneth Lavrsen
[snip some constructive arguments]

I'm not trying to be dismissive of your arguments, you are making some
valid points, but it's nothing that we were not aware of. Your attitude
is not really helping I'm afraid, though. Please try to make this a
constructive dialog, ranting will not help.

Diego

[Kenneth Lavrsen]

I do not wish to include the ffmpeg sources as part of Motion for two reasons.

1. For the same reason that I do not build the program with the other libs
we use like MySQL-client, PostgreSQL-client , libjpeg, glibc, libpthread,
libz, etc etc.
Shared libraries. That is the smart way. ffmpeg also relies on shared libs.

2. You also have to remember that once you put application and library
together as a full binary package, you expose yourself much more to the
legal aspects of certain IP contained within ffmpeg. Motion is also
distributed as binary RPMs and debian packages are being made also. Keeping
things seperate is a good idea seen in that light. This is my deepest
concern more than argument 1.

About manpower or funding.
I just offered to do the upload to Sourceforge 3 times a years. That is the
real manpower required. And no funding needed. This is not a manpower
issue. The issue is the ffmpeg core team to make a simple decision saying -
OK - we will upload a tar.gz 3 times a year and give it a new version number.

I am not going to hang around here nagging you for days. I started this
debate. I am argueing today hoping in the long run I can make you think
about things. And my offer to upload things every 4 months and maintain a
few wiki pages for the release note stands. You know where to find me.

I must admit that I may be ranting and be a real pain in the butt today.
But I am not alone. Many people have raised these issues before and with no
result. So sometimes someone has to come by and provoke things a bit and
start a real debate to get oppinions moving. As you say you are already
aware of the issues. So lets help each other finding a simple compromise
solution which hardly cost any resources (minutes not hours).

I don't think the discussion will lead much further today. I have already
started repeating myself. Sleep on it a few days.

I will encourage that any follow-ups on this posting will ignore all the
above and work in these repeated constructive suggestions below the bar.

-------------------------------

Would a fixed release schedule - let us say February 1st, June 1st, October
1st where you know there is a fixed release be someone that would be useful
and helpful to you?
(naturally one can delay it a few days if a severe bug has just been found
and needs to be fixed and naturally one can do a quick follow up release if
something really serious is broken. But something is always broken. And if
it is a problem - the support answer will always be to download latest CVS
snap. Noone will fix an old version.).

And to the developers of ffmpeg - would that really disturb your sleep
knowing that every 4 month you work gets released with a new version number
and a bunch of packagers create their packages for RH, Fedora, Suse,
Gentoo, Debian etc etc?

And if any packagers are following this mailing list - would you prefer to
package these scheduled releases instead of some random daily snaps?

Enjoy your weekend.
Kenneth

[Dave Airlie]

Post by Diego Biurrun

Post by Kenneth Lavrsen
I am not ignoring anything. Installing RPM packages is the way 90% or maybe
rather 99% of users install and run software. Especially libraries.
And WHY should your little project as the only one be so different from the
others? Why are you right and the whole open source software world in
general so wrong?

You are ignoring advice, repeatedly even. Why can't you just link
statically to FFmpeg and be done with it? The rest of the world does
it, are they all wrong and you are right insisting on dynamic linking?

The rest of the world doesn't statically link anything ever, dynamic
linking works for every single library based project in existence
today, and I'm asking the question what make ffmpeg different? please
answer I've seen nothing from the ffmpeg developers apart from sheer
this is my project and we don't care about anyone but us ffmpeg
developers which to be honest means the project needs to grow up a
bit...

Post by Diego Biurrun
You have to differentiate between end-users and "users" that are
developers themselves, people like you that reuse code or include
libraries.
You forget that with free sw projects the developers are users
themselves. If you drop all the users, you still have the devs using
their own stuff. If you drop all the devs, you have no software to use.

You do, you still have the last release of the software, developers
believing they are more important than users is one of those little
mistakes open source developers are always making...

Post by Diego Biurrun
But maybe you are not tackling a real issue in a constructive manner.
If you wish to have this problem solved, provide manpower or funding.

how much funding would be required to do what Kenneth asks? 50
dollars, it involves renaming snapshots once every 3 months with a
fixed version number to provide a baseline for other projects... I
really can't believe the arrogance and condescending answers he is
getting back from the developers...

Post by Diego Biurrun

Post by Kenneth Lavrsen
I am an open source developer who maintains TWO open source projects
(Motion and Open2300) and helps with documentation on the PWC driver. I
spend 2-3 hours a day on open source development. And often 8 hours a day
in the weekends and vacations. And it is not my daytime job. I have a full
time job on top of that. I am not paid either for my work. And I do not
even accept donations. I think I am doing my share for the open source
community and do not need to be called a troll.

These numbers are not going to impress anyone around here. There are
members of this mailing list that spend (or have spent) considerably
more time on free sw than you.

Again condescending answers, you missed the point completely.. he
spends his time contributing where he feels he can help on open source
projects, he is trying to start a reasonable debate and the only
answer I've seen so far is "we don't want to" a small bit of technical
reasoning mightn't go astray...

Post by Diego Biurrun
I'm not trying to be dismissive of your arguments, you are making some
valid points, but it's nothing that we were not aware of. Your attitude
is not really helping I'm afraid, though. Please try to make this a
constructive dialog, ranting will not help.

Okay state what needs to be done to enable ffmpeg to do a release
every 3-4 months and why currently no ffmpeg developer has the
time/resources to do so and perhaps someone will step up and do it. A
timed release isn't going to happen unless there is some buy-in from
the core developers (i.e. you don't have to do the work, you just have
to not checkin half-finished changes two days before a release date is
coming), so far I'm seeing nothing from the ffmpeg developers that
shows they are even willing to do this....

again for the final time I'll ask what makes ffmpeg so different? why
does this project think it can't do what every other open source
library has been doing for ever... if you can give me a technical
reason I'll accept it, but I seriously doubt you can.....

Dave.

[Paul Curtis]

Post by Dave Airlie
The rest of the world doesn't statically link anything ever, dynamic
linking works for every single library based project in existence
today, and I'm asking the question what make ffmpeg different?

Ask the 'mplayer' developers why it's statically linked with ffmpeg.

It is the developers choice to have their project built anyway they
choose. If you don't like it, use something else. If there isn't
something else, fork it and create your own.

Post by Dave Airlie
again for the final time I'll ask what makes ffmpeg so different?

The developers CHOSE to implement it this way. That's what makes it
different. It's a CHOICE. All developers make CHOICES when implementing
anything. Why do you think the ffmpeg developers have to do "what every
other open source library has been doing for ever"?

It has nothing to do with technology ... it has to do with making a
choice. These developers made a choice. If you don't like it, then don't
use libavformat/libavcodec. It's really that simple.

Regards,
Paul

[Diego Biurrun]

Post by Dave Airlie

Post by Diego Biurrun
You are ignoring advice, repeatedly even. Why can't you just link
statically to FFmpeg and be done with it? The rest of the world does
it, are they all wrong and you are right insisting on dynamic linking?

The rest of the world doesn't statically link anything ever, dynamic
linking works for every single library based project in existence
today, and I'm asking the question what make ffmpeg different? please
answer I've seen nothing from the ffmpeg developers apart from sheer
this is my project and we don't care about anyone but us ffmpeg
developers which to be honest means the project needs to grow up a
bit...

The FFmpeg API changes frequently, thus it is best to link statically
and avoid problems. There are several projects that work this way with
FFmpeg and they are not having problems.

Post by Dave Airlie

Post by Diego Biurrun
You have to differentiate between end-users and "users" that are
developers themselves, people like you that reuse code or include
libraries.
You forget that with free sw projects the developers are users
themselves. If you drop all the users, you still have the devs using
their own stuff. If you drop all the devs, you have no software to use.

You do, you still have the last release of the software,

I was referring to the fact that software needs to be written before it
can be used...

Post by Dave Airlie
developers believing they are more important than users is one of
those little mistakes open source developers are always making...

We learned this from Microsoft: Developers, developers, developers,
developers. Seriously, it has never been about anything else.
Users and developers share some sort of symbiotic relationship, but
developers really do come first, they are the ones that move the
software along. Healthy projects are the ones that have enough
developers, not the ones that have plenty of users.

Post by Dave Airlie

Post by Diego Biurrun

Post by Kenneth Lavrsen
I am an open source developer who maintains TWO open source projects
(Motion and Open2300) and helps with documentation on the PWC driver. I
spend 2-3 hours a day on open source development. And often 8 hours a day
in the weekends and vacations. And it is not my daytime job. I have a full
time job on top of that. I am not paid either for my work. And I do not
even accept donations. I think I am doing my share for the open source
community and do not need to be called a troll.

These numbers are not going to impress anyone around here. There are
members of this mailing list that spend (or have spent) considerably
more time on free sw than you.

Again condescending answers, you missed the point completely.. he
spends his time contributing where he feels he can help on open source
projects, he is trying to start a reasonable debate and the only
answer I've seen so far is "we don't want to" a small bit of technical
reasoning mightn't go astray...

We have suggested static linking several times and all the answer we get
is "I don't want to.". How is that different?

Post by Dave Airlie

Post by Diego Biurrun
But maybe you are not tackling a real issue in a constructive manner.
If you wish to have this problem solved, provide manpower or funding.

how much funding would be required to do what Kenneth asks? 50
dollars, it involves renaming snapshots once every 3 months with a
fixed version number to provide a baseline for other projects... I
really can't believe the arrogance and condescending answers he is
getting back from the developers...

Making good releases takes much more than that. I have updated the
ChangeLog for the last few MPlayer releases and boy I can tell you it's
a tedious task that takes more hours than you would expect it to. For
the last release I was tired of doing it and it took me quite some
effort to recruit someone from the "Hey, let's make a release!"-crowd to
do it instead of me. After finishing he said "Hats off to the people
who have been doing this for the previous releases."

Let's try to move this flamefest^wdiscussion back into a more
constructive direction. What I would really like to see is people
volunteering to help instead of ranting. Michael made a list of things
to do for a release:

http://mplayerhq.hu/pipermail/ffmpeg-devel/2005-June/002242.html

Pick one and do it, the release will be out in no time.

Diego

[Dave Airlie]

Post by Diego Biurrun
We have suggested static linking several times and all the answer we get
is "I don't want to.". How is that different?

static linking ignores the issue, if everyone is to keep their own
fork of the codebase they benefits of having a library are reduced,
static linking is not a solution to any problem it is a workaround...

Post by Diego Biurrun
Making good releases takes much more than that. I have updated the
ChangeLog for the last few MPlayer releases and boy I can tell you it's
a tedious task that takes more hours than you would expect it to. For
the last release I was tired of doing it and it took me quite some
effort to recruit someone from the "Hey, let's make a release!"-crowd to
do it instead of me. After finishing he said "Hats off to the people
who have been doing this for the previous releases."

I don't think anyone has requested high quality releases at this time,
I think what most external project would like are sync points, where
you say well the CVS tree was considered stable at this point, none of
the main developers were in the middle of a large sweeping change that
affects the whole project... stick a version number on it, drop a
tarball say here's a good point to work with until the next one, the
issue with working with CVS tarballs is at any point the only people
who know what state they are in are the developers working on it, so
the external project maintainer has to spend an inappropriate amount
of time tracking changes made to CVS to see if what is there might be
a good idea to incorporate into their own fork....

Post by Diego Biurrun
http://mplayerhq.hu/pipermail/ffmpeg-devel/2005-June/002242.html

All good ideas if you want a major release, I'm not sure people want
or need this at this stage, maybe if you start small by just doing
sync points people might be more willing to join in and do the
rest....

Things like Changelogs aren't hugely necessary if you have CVS trees,
in Xorg we make people to the Changelog on every CVS commit, in the
kernel the Changelog is the commit list since the last one...
spending time transcribing CVS commits into Changelog files for a
release isn't the way forward and I can understand why anyone doing so
would get annoyed at having to do a release...

Dave.

[Reimar Döffinger]

Hi,

Post by Dave Airlie
I don't think anyone has requested high quality releases at this time,
I think what most external project would like are sync points, where
you say well the CVS tree was considered stable at this point, none of
the main developers were in the middle of a large sweeping change that
affects the whole project... stick a version number on it, drop a
tarball say here's a good point to work with until the next one, the
issue with working with CVS tarballs is at any point the only people
who know what state they are in are the developers working on it, so
the external project maintainer has to spend an inappropriate amount
of time tracking changes made to CVS to see if what is there might be
a good idea to incorporate into their own fork....

I think then you really didn't get how Fmpeg and MPlayer development
works. All CVS snapshots are supposed to be in that state, and at
least 90% of the time they actually are.
It really looks to me like you didn't really try to find a solution to
your problem yourself and instead expect the people here to implement
your ideas.
I'm sorry, I prefer Micheal and all the others working on better codec
support instead of caring about API stability and documentation - if
that is important to enough people, IMHO it should be possible to find
somebody who does it.
Sorry if it (currently?) doesn't fit your needs.

Greetings,
Reimar Döffinger

[Dave Airlie]

Post by Reimar Döffinger
I think then you really didn't get how Fmpeg and MPlayer development
works. All CVS snapshots are supposed to be in that state, and at
least 90% of the time they actually are.
It really looks to me like you didn't really try to find a solution to
your problem yourself and instead expect the people here to implement
your ideas.

I don't really have a major issue, I've forked my codebase internally
for a project a long time ago, its just to think about doing a resync
it would be nice to have a clue when the project is in the 10% phase
and when the project is in the 90% phase and again I say the only
people who actually know this are the developers, I can lurk on lists
and CVS commits all I want but I don't have an in-depth knowledge to
know what changes might be stabilising and what ones might be
destabilising.. my thoughts are that if developers could maybe expend
a little extra work to say, well we think this should be stable, lets
give it a number, it would maybe save other developers on other
projects all wasting a large amount of time figuring it our for
themselves... I don't expect anyone to implement anything, I'm just
trying to figure out why the project is very anti- it, unlike most
others I've work on...

Post by Reimar Döffinger
I'm sorry, I prefer Micheal and all the others working on better codec
support instead of caring about API stability and documentation - if
that is important to enough people, IMHO it should be possible to find
somebody who does it.

I haven't mentioned stability or documentation, the idea being put
forward was just to do some baseline releases that people could
synchronize off, I'll give you an example,

I've got my great new project called helloworld that uses ffmpeg, I
forked way back at 0.4.8, I now want to update my fork with the latest
codeset from ffmpeg, I've no idea what the current state of the tree
is, so I grab CVS HEAD and import it and suddenly my MPEG4 movies are
all jerky and don't play smoothly, now currently I'd have to go on a
binary search through CVS tarballs never knowing if a particular
tarball was in anyway stable or going to introduce some other
wierdness. fixing up my APIs as I went. if there was "stable" drops
i.e. the developers felt it was good at that time, then I could just
start picking my way through them at least knowing I wasn't going to
end up in the middle of some construction work...

I think there are people who care about this out there (otherwise you
wouldn't get the constant trolling...) maybe this will provoke them
into it, but it still requires buy-in from the developers and if they
really don't want it to happen, theres no point anyone standing up to
volunteer to do it .. and if they do want it to happen I don't
actually think it is that much work in any case... I certainly ain't
volunteering, my maintainance to hacking ratio on open source projects
is already leaning far too much on the maintainance side...but perhaps
if people from many of the ffmpeg using projects got together one
person might decide it is worth it...

Dave.

[Sascha Sommer]

Hi,

Post by Dave Airlie

Post by Reimar Döffinger
I think then you really didn't get how Fmpeg and MPlayer development
works. All CVS snapshots are supposed to be in that state, and at
least 90% of the time they actually are.
It really looks to me like you didn't really try to find a solution to
your problem yourself and instead expect the people here to implement
your ideas.

I don't really have a major issue, I've forked my codebase internally
for a project a long time ago, its just to think about doing a resync
it would be nice to have a clue when the project is in the 10% phase
and when the project is in the 90% phase and again I say the only
people who actually know this are the developers, I can lurk on lists
and CVS commits all I want but I don't have an in-depth knowledge to
know what changes might be stabilising and what ones might be
destabilising.. my thoughts are that if developers could maybe expend
a little extra work to say, well we think this should be stable, lets
give it a number, it would maybe save other developers on other
projects all wasting a large amount of time figuring it our for
themselves... I don't expect anyone to implement anything, I'm just
trying to figure out why the project is very anti- it, unlike most
others I've work on...

As far as I understand FFmpeg and MPlayer development, cvs of these project is
always supposed to be stable. Changes that break certain features should not
go into cvs and if you notice some bug when you update your snapshot you
should check the mailinglist archive if this is already known and report it
otherwise. Then wait a few days until it is fixed and use the fixed snapshot.
The 10% phase is only when one of the developers makes a mistake that noone
noticed so far. If there were releases it would be very likely that the
releases contain these bugs, too.

In my eyes, Michael, besides being briliant coder, has done a wonderful job in
maintaing this project so far. If someone does not like the release policy
then go ahead improve the shared lib support, propose a better abi or
volunteer in doing the releases. Complaining and waiting for more "grown up
developers" won't help anything.

Sascha

[Kenneth Lavrsen]

Post by Sascha Sommer
As far as I understand FFmpeg and MPlayer development, cvs of these project is
always supposed to be stable. Changes that break certain features should not
go into cvs and if you notice some bug when you update your snapshot you
should check the mailinglist archive if this is already known and report it
otherwise. Then wait a few days until it is fixed and use the fixed snapshot.
The 10% phase is only when one of the developers makes a mistake that noone
noticed so far. If there were releases it would be very likely that the
releases contain these bugs, too.

We are talking API stability here more than code stability.
Noone is talking about giving up using your CVS as today or the daily CVS
snaps.
Since we cannot count on the API being stable and documented since this
takes many resources we do the 2nd best - scheduled releases which takes no
resources to do.

We need baseline releases so between them the plain end user that cannot
write a line of C. Can hardly install an RPM can download latest ffmpeg
release and latest project X and get it to work - yes with known bugs with
will have been resolved in

Post by Sascha Sommer
In my eyes, Michael, besides being briliant coder, has done a wonderful job in
maintaing this project so far. If someone does not like the release policy
then go ahead improve the shared lib support, propose a better abi or
volunteer in doing the releases. Complaining and waiting for more "grown up
developers" won't help anything.
Sascha

You already have the volunteer. All we need is a go ahead.

And without a go-ahead I guess we will just have to create "fork" project
which picks the best CVS snap and give it a release number.
This is basically what the packagers today do but very uncoordinated. All
we add is a coordination and a sync so all has the same baseline.

If there is a bug - we will simply ask people to download a CVS snap
tar.gz just like today.
Motion still works fine with ffmpeg-0.4.8 so I am not too worried with
bugs. It is the API changes that causes all the trouble.

But I would prefer releasing on the official ffmpeg sourceforge file system.

Kenneth

[Kenneth Lavrsen]

Post by Reimar Döffinger
I think then you really didn't get how Fmpeg and MPlayer development
works. All CVS snapshots are supposed to be in that state, and at
least 90% of the time they actually are.

90%.

So 10% of users downloading the "latest CVS" gets something not fully
working. That is many. I actually think you are doing better than that -
but even 1% is many 1000s of users per year getting into trouble.

Post by Reimar Döffinger
It really looks to me like you didn't really try to find a solution to
your problem yourself and instead expect the people here to implement
your ideas.

What is there to implement? We are not asking for new features or new
codecs or a lot of work. We are just asking for a tar.gz to be ftp'ed to
Sourceforge 3 times per year.
I am not an expert in CVS but if all the CVS text entries can be compiled
in one file then we may not even need a release note. I will figure out how
to do that. Then I could just read it through and summarize it the best I
can and post that on SF. Maybe post a short note here first for review.

You make it sound like a big burden and I have already said that I can
upload it for you. I release on SF all the time. I can do it in my sleep now.

Post by Reimar Döffinger
I'm sorry, I prefer Micheal and all the others working on better codec
support instead of caring about API stability and documentation - if
that is important to enough people, IMHO it should be possible to find
somebody who does it.

API stability and documentation cost a lot of work. That cannot be argued.
You are 100% right about that. And to get that done you either have to work
less on the codec or get someone to volunteer. That is why I suggest the
not so ideal but very simple solution of releasing 3 times per year at
fixed dates.

So let us just start with 3 releases per year.
Then at least the API only changes 3 times per year seen from the point of
view of developers outside the ffmpeg/Mplayer circles.
Nothing prevents Mplayer to continue using latest CVS. The CVS is still
there. The daily CVS snaps are still there. Noone looses anything. It is a
win win.
What it brings is stability 4 months at a time and RPMs/debs that are
baselines the rest of us can trust and know the state of incl bugs etc.

Why do you resist such a simple solution? You have nothing to loose. Why
not give it a try?

Next date could be October 1st following my suggested February 1st, June
1st, October 1st scheme.
On October 1st I pick the tar.gz of the day and upload it to Sourceforge as
0.4.10.
The release note will be my intrepretation of the CVS entries since 0.4.9pre1.
All the developers have to do is warn me if the October 1st tar.gz is
rotten so I can pick one a week earlier or wait a week.
That is simple. No valuable codec coding time lost for anyone.

Kenneth

[Burkhard Plaum]

Interesting discussion. Actually, I can understand both
points of view. Including ffmpeg into an own project and
link statically solves all problems related to API/ABI
changes and versions. On the other hand, dynamic linking of
external libs is the preferred way for most OSS projects.

I use ffmpeg for 2 projects, libquicktime
(http://libquicktime.sourceforge.net) and gmerlin
(http://gmerlin.sourceforge.net) and I know what it means to
depend on ffmpeg.

The ffmpeg people do a great job for multimedia support on
Linux and other OSes. The developers make decisions, and it
doesn't make sense to discuss if they are right or not.

So my question is the following: Would forking be possible
without offending anyone? If there was another ffmpeg CVS
repository, which is automakified, but otherwise closely
synced with the primary CVS, regular releases can be made
from that. A smart shell script can sync the CVS almost
automatically, even if the build systems are different. If
some projects, which depend on ffmpeg, work together, the
amount of labor stays reasonable. The ffmpeg people can point
to these releases as "unsupported regular releases, using CVS
is preferred". The only things we must make sure, are
that ffmpeg developers aren't bothered with reports about bugs,
they aren't responsible for, and that general bugfixes find their
way back into the original ffmpeg.

Any opinions?

[Luca Barbato]

Post by Burkhard Plaum
Any opinions?

Autotools are more painful than the current build system in my experience.

I think that a better way to invest energy is either help on making a
release (see previous threads about that) or/and improve shared object
support.

lu

[Tim Allen]

Post by Burkhard Plaum
So my question is the following: Would forking be possible
without offending anyone? If there was another ffmpeg CVS
repository, which is automakified, but otherwise closely

Tactical error - leave autoconf etc out of it. Fight your battles one at
a time :-). It's irrelevant to what you want to achieve anyway.

Post by Burkhard Plaum
synced with the primary CVS, regular releases can be made
from that. A smart shell script can sync the CVS almost
automatically, even if the build systems are different. If
some projects, which depend on ffmpeg, work together, the
amount of labor stays reasonable. The ffmpeg people can point
to these releases as "unsupported regular releases, using CVS
is preferred". The only things we must make sure, are
that ffmpeg developers aren't bothered with reports about bugs,
they aren't responsible for, and that general bugfixes find their
way back into the original ffmpeg.
Any opinions?

Ideally, if there was the labour available to make it happen, then
whoever was managing the releases would make a stable branch in the cvs
archive at particular times, and _maintain_ the stable branch. Ie apply
urgent bugfixes, particularly security-related ones, to the stable
branch, and redo stable releases from that branch. Any time cvs head has
enough progress to show, a new branch would be made. You wouldn't need a
new archive for this - as long as you can persuade Michael and others
that you're serious about doing the work, I'm sure they'll let you do it
in the main archive.

In the absence of someone prepared to do that, then there is IMHO
limited value in formalising the releases. The idea that somehow
blessing a particular cvs snapshot and uploading it to sourceforge some
number of times a year is somehow valuable is hard to fathom. Sure, you
get some degree of API stability, but you also get bugs and security
problems and no clear way of fixing them.

In particular, badgering Michael to do the work of release management is
a mistake. He's doing very well working the way he is - leave him alone
and let him get on with it.

Tim

[Diego Biurrun]

Post by Burkhard Plaum
I use ffmpeg for 2 projects, libquicktime
(http://libquicktime.sourceforge.net) and gmerlin
(http://gmerlin.sourceforge.net) and I know what it means to
depend on ffmpeg.

Added to the projects page.

Diego

[Balatoni Denes]

Hi!

vasárnap 07 augusztus 2005 01.37-kor Dave Airlie ezeket a bolcs gondolatokat

Post by Dave Airlie
The rest of the world doesn't statically link anything ever, dynamic
linking works for every single library based project in existence
today, and I'm asking the question what make ffmpeg different?

See http://www.iecc.com/linker/linker08.html, the part
"PIC costs and benefits". When developers have spent a considerable time
to gain even one percent speedup, they probably don't want to see this gain
disappear by the inclusion of the compiler option -fPIC (this is only on
legacy hardware, namely x86). But I am not an official certified ffmpeg
developer.

bye
Denes

[Dave Airlie]

Post by Balatoni Denes
vasárnap 07 augusztus 2005 01.37-kor Dave Airlie ezeket a bolcs gondolatokat

Post by Dave Airlie
The rest of the world doesn't statically link anything ever, dynamic
linking works for every single library based project in existence
today, and I'm asking the question what make ffmpeg different?

See http://www.iecc.com/linker/linker08.html, the part
"PIC costs and benefits". When developers have spent a considerable time
to gain even one percent speedup, they probably don't want to see this gain
disappear by the inclusion of the compiler option -fPIC (this is only on
legacy hardware, namely x86). But I am not an official certified ffmpeg
developer.

It should be no problem building shared libs for ffmpeg without PIC,
we don't use -fPIC to build Mesas OpenGL libraries and drivers due to
the perceived speed loss. but Ulrich's guide[1] to writing DSO says
you should probably use it, he also refutes a lot of the points
made in the iecc link about wasting ebx etc.. when using modern toolchains...

I recommend reading the paper, the guy does maintain the most used
shared library on Linux systems :-)

Dave.

[1]http://people.redhat.com/drepper/dsohowto.pdf

[Attila Kinali]

On Sun, 7 Aug 2005 20:43:04 +1000

Post by Dave Airlie
It should be no problem building shared libs for ffmpeg without PIC,
we don't use -fPIC to build Mesas OpenGL libraries and drivers due to
the perceived speed loss.

If you do not use PIC, then all you get is a static library
which has to be relocated for all programs that use it.
All you get from that is that you save diskspace, but
waste the same amount of memory as you would if you link
staticaly against it.

Attila Kinali

[Balatoni Denes]

Hi!

vasárnap 07 augusztus 2005 12.43-kor Dave Airlie ezeket a bolcs gondolatokat

Post by Dave Airlie
It should be no problem building shared libs for ffmpeg without PIC,
we don't use -fPIC to build Mesas OpenGL libraries and drivers due to
the perceived speed loss.

That's a valid point, so let me wrap up the discussion by referring to the
previous emails about manpower.

Post by Dave Airlie
Dave.

bye
Denes

[Jacob Meuser]

Post by Balatoni Denes
Hi!
vasárnap 07 augusztus 2005 12.43-kor Dave Airlie ezeket a bolcs gondolatokat

Post by Dave Airlie
It should be no problem building shared libs for ffmpeg without PIC,
we don't use -fPIC to build Mesas OpenGL libraries and drivers due to
the perceived speed loss.

That's a valid point, so let me wrap up the discussion by referring to the
previous emails about manpower.

it might not be needed on linux/x86 when linking to a program, but
there are platforms and situations where PIC is _needed_.

[Rich Felker]

Post by Jacob Meuser

Post by Balatoni Denes
Hi!
vasárnap 07 augusztus 2005 12.43-kor Dave Airlie ezeket a bolcs gondolatokat

Post by Dave Airlie
It should be no problem building shared libs for ffmpeg without PIC,
we don't use -fPIC to build Mesas OpenGL libraries and drivers due to
the perceived speed loss.

That's a valid point, so let me wrap up the discussion by referring to the
previous emails about manpower.

it might not be needed on linux/x86 when linking to a program, but
there are platforms and situations where PIC is _needed_.

This is never a fundamental limitation of the architecture, but a
buggy (missing feature) dynamic linker.

Rich

[Jacob Meuser]

Post by Rich Felker

Post by Jacob Meuser

Post by Balatoni Denes
Hi!
vasárnap 07 augusztus 2005 12.43-kor Dave Airlie ezeket a bolcs gondolatokat

Post by Dave Airlie
It should be no problem building shared libs for ffmpeg without PIC,
we don't use -fPIC to build Mesas OpenGL libraries and drivers due to
the perceived speed loss.

That's a valid point, so let me wrap up the discussion by referring to the
previous emails about manpower.

it might not be needed on linux/x86 when linking to a program, but
there are platforms and situations where PIC is _needed_.

This is never a fundamental limitation of the architecture, but a
buggy (missing feature) dynamic linker.

whether it is a bug, or it is intentional, it does not matter;
it is a reality that affects users of ffmpeg.

if you really think such a way, perhaps you should just say
ffmpeg is only supported on linux/x86, and simply ignore posts
like mine.

[Tobias Diedrich]

Post by Dave Airlie
It should be no problem building shared libs for ffmpeg without PIC,
we don't use -fPIC to build Mesas OpenGL libraries and drivers due to
the perceived speed loss. but Ulrich's guide[1] to writing DSO says
you should probably use it, he also refutes a lot of the points
made in the iecc link about wasting ebx etc.. when using modern toolchains...

Sorry for butting in and please correct me if I'm wrong, but AFAICS
I seriously doubt there is much benefit to a shared libavcodec:

Obviously shared libs are good for libs that are used by many
different programs, like glibc.

But in the lavc-case I'd assume that usually you only have one or
two different programs running at the same time that use it.
Multiple instances of the same program should be no problem anyway,
since the code segment is shared and static linking is good since you
don't get the cost of PIC. This would be a point where
mplayer/mencoder would benefit from making the two a single binary,
at least for me those two are the only two applications using lavc
which might run at the same time.

And even if I were running three or four different apps at the same time:
Currently a stripped libavcodec.so weighs in at 2.7MB, so it's not
_that_ much of an issue IMHO (On a 512MB machine at least, it would
be different for a 32MB machine, but those are usually Pentium
class and a bit on the slow side for video processing).

Cheers,

[Rich Felker]

Post by Balatoni Denes
Hi!
vasárnap 07 augusztus 2005 01.37-kor Dave Airlie ezeket a bolcs gondolatokat

Post by Dave Airlie
The rest of the world doesn't statically link anything ever, dynamic
linking works for every single library based project in existence
today, and I'm asking the question what make ffmpeg different?

See http://www.iecc.com/linker/linker08.html, the part
"PIC costs and benefits". When developers have spent a considerable time
to gain even one percent speedup, they probably don't want to see this gain
disappear by the inclusion of the compiler option -fPIC (this is only on
legacy hardware, namely x86). But I am not an official certified ffmpeg
developer.

Not just legacy hardware. Applying an offset to each global symbol
dereference is a huge waste of cycles on pure RISC archs too, and it
adds dependency issues that need to be resolved to prevent stalls. PIC
is just a very very stupid idea, unless the cpu has a special
mechanism for supporting it in hardware without extra instructions. Of
course it does not matter for 99% of the libraries that do
performance-irrelevant tasks, but it DOES MATTER for anything media
related.

Rich

[Paul Curtis]

Post by Kenneth Lavrsen
I am not ignoring anything. Installing RPM packages is the way 90% or
maybe rather 99% of users install and run software. Especially libraries.
And WHY should your little project as the only one be so different from
the others? Why are you right and the whole open source software world
in general so wrong?

If you find the development methodology for this "little project" so
difficult to work with, then don't use it.

I have been involved in ffmpeg for two or so years. I can work with
their development method. If you cannot, then you need to move on and
find another library that fits your personal development style. Many
more people have invested time and effort in ffmpeg, and they don't have
a problem with the development method.

I might suggest using xine lib for your project.

Paul

[Kenneth Lavrsen]

Post by Paul Curtis
I might suggest using xine lib for your project.
Paul

Xine? Hmm. Will take a look.
No comments on your first remark.

Kenneth

[Kenneth Lavrsen]

Post by Kenneth Lavrsen
Xine? Hmm. Will take a look.

Nope. Motion uses ffmpeg to encode mpegs from YUV420P or Monochrome 8 bit.
Motion is a program that can monitor many cameras (V4L or Network
jpeg/mjpeg). It analyses the pictures for Motion using many advanced
features to ensure safe Motion detection. When motion is detected Motion
can save the pictures as jpeg or make small mpeg movies of each event.
Motion uses the mpeg4 or msmpeg4 encoding feature from ffmpeg for this.
Motion can easily monitor 8 or more cameras in parallel so it is important
that the encoding happens fast and ffmpeg is dammed good at doing exactly that.

Xine libs seems to contain decoders only. No mpeg encoding in the libs as
far as I can see. But it seems like a very neatly managed project. Wow.

PS
A similar program is Zoneminder which by the way also uses ffmpeg for the
same purpose. You can add that project to the webpage of projects using
ffmpeg as well. URL is http://www.zoneminder.com/ . They are the
"competition" but we love them anyway :-) Zoneminder is a GUI oriented
program. Motion is a daemon meant to run in the background with as small a
foot print as possible. So two different ways of doing the same thing. But
we borrow ideas from each other. The beauty of OSS.

They also do not distribute the ffmpeg sources. Try and go to their forum
and search for ffmpeg. Yes. They have the exact same problems as Motion
users. Change of API combined with the fact that people download latest
ffmpeg CVS instead of a baseline release, keeps on breaking things for the
end users. I am sure many more projects are in the same situation.

Kenneth

[Diego Biurrun]

Post by Kenneth Lavrsen
A similar program is Zoneminder which by the way also uses ffmpeg for the
same purpose. You can add that project to the webpage of projects using
ffmpeg as well. URL is http://www.zoneminder.com/

Done.

Diego

[Dave Dodge]

Post by Kenneth Lavrsen
Nope. Motion uses ffmpeg to encode mpegs from YUV420P or Monochrome 8 bit.
Motion is a program that can monitor many cameras (V4L or Network
jpeg/mjpeg). It analyses the pictures for Motion using many advanced
features to ensure safe Motion detection. When motion is detected Motion
can save the pictures as jpeg or make small mpeg movies of each event.
Motion uses the mpeg4 or msmpeg4 encoding feature from ffmpeg for this.

If you just need encoding, you might also look at mjpegtools; though
they do MPEG-1 and MPEG-2, not MPEG-4.

http://mjpeg.sourceforge.net/
-Dave Dodge

[Jan Knutar]

Post by Kenneth Lavrsen
ffmpeg is the ONLY open source project making shared libraries

Maybe the solution would be to remove shared library target from
the makefiles :) I think atleast Rich would be happy about that,
static allegedly wasting less processor cycles too :)





























































(note the smileys)

[Reimar Döffinger]

Hi,

Post by Jan Knutar

Post by Kenneth Lavrsen
ffmpeg is the ONLY open source project making shared libraries

Maybe the solution would be to remove shared library target from
the makefiles :) I think atleast Rich would be happy about that,
static allegedly wasting less processor cycles too :)

I suggested removing dynamic libavcodec support from MPlayer several
times, but never got a majority ;-)

Greetings,
Reimar Döffinger

[Rich Felker]

Post by Reimar Döffinger
Hi,

Post by Jan Knutar

Post by Kenneth Lavrsen
ffmpeg is the ONLY open source project making shared libraries

Maybe the solution would be to remove shared library target from
the makefiles :) I think atleast Rich would be happy about that,
static allegedly wasting less processor cycles too :)

I suggested removing dynamic libavcodec support from MPlayer several
times, but never got a majority ;-)

i agree totally with removing it from mplayer. personally i'd like to
remove dynamic library build support from ffmpeg too, but i'm hardly a
developer on this project so i don't really have much say.

rich

[Måns Rullgård]

Post by Diego Biurrun

Post by Kenneth Lavrsen
My name is Kenneth Lavrsen. I maintain the project Motion which has been
using ffmpeg for years now. (yes please add to the list).
http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome

Added.

Post by Kenneth Lavrsen
Problem 1 and the most severe and EASY TO FIX
From your website: "New, official "releases" are few and far between. In
short, if you want to work with FFmpeg, you are advised to go along with
CVS development rather than relying on formal releases." This is the key
problem. This is BAD ADVICE and a BAD POLICY. At least it is for the
libraries. Maybe this is acceptable for the command line tools which do not
change user interface that much and where the user adjustment is keying
something different. But for the libraries changing API all the time this
is a nightmare.

There is a solution to this problem available to you: Include a working
CVS snapshot of FFmpeg in Motion. It's what many other projects
building on FFmpeg do, at the very least all the players, i.e. MPlayer,
xine, vlc, avifile, tcvp.

Correction: tcvp doesn't include a copy of ffmpeg.

[Michael Niedermayer]

Hi

On Saturday 06 August 2005 00:36, Kenneth Lavrsen wrote:
[...]

Post by Kenneth Lavrsen
ffmpeg is used very widely. People have ffmpeg installed for other reasons
than Motion and often they cannot use those MUSEUM releases you have on the
Sourceforge download site which you make less than once per year and never
really fully do. The fact that 0.4.9pre1 never became 0.4.9 is rediculous.
Please make more formal releases! Please make a formal release every time
you add major new features.
The packagers such as Livna, AT and Dag - and the debian packagers will
then take these and package and 99% of the users will use these.
And I as Motion maintainer will ensure to have my software working against
the latest release.
I cannot do that today when the releases are so scarce.
And if that is too difficult for you to manage - then do the simplest of
solutions. Take the CVS snapshot from each end of a quarter and give it one
minor version number higher and upload it on Sourceforge. The daily snaps
you have now are not manageable. I cannot check daily if Motion no longer
works because of API changes or severe ffmpeg bugs.
At least with quarterly releases I could check and fix 4 times a year.
Please change this "latest CVS policy" and help both projects and packagers.

well, as diego said, include a ffmpeg snapshot in your application,
alternatively you could also help improving shared lib libav* support, we
have internal API version compatibility numbers they just arent part of the
soname yet as noone cares, people just complain

about releases, even though the number of people who complain is nearly
unlimited not a single one of them was so far willing to do _any_ work to
make a new release

[...]

[Dave Airlie]

Post by Michael Niedermayer
well, as diego said, include a ffmpeg snapshot in your application,
alternatively you could also help improving shared lib libav* support, we
have internal API version compatibility numbers they just arent part of the
soname yet as noone cares, people just complain

to be honest if you did proper shared lib versioning you'd be up to
libavcodec.so.50.0.0, or something so close...

The way shared libs work, the first version number should be changed
when the API breaks, this happens probably monthly with ffmpeg, this
always makes me think perhaps either the API is too lowlevel, or just
plain wrong..

Dave.

[Michael Niedermayer]

Hi

Post by Dave Airlie

Post by Michael Niedermayer
well, as diego said, include a ffmpeg snapshot in your application,
alternatively you could also help improving shared lib libav* support, we
have internal API version compatibility numbers they just arent part of
the soname yet as noone cares, people just complain

to be honest if you did proper shared lib versioning you'd be up to
libavcodec.so.50.0.0, or something so close...

yes, are you suggesting that you would prefer to hide the api version?

Post by Dave Airlie
The way shared libs work, the first version number should be changed
when the API breaks,

yes

Post by Dave Airlie
this happens probably monthly with ffmpeg, this

hmm, i dont think so

Post by Dave Airlie
always makes me think perhaps either the API is too lowlevel, or just
plain wrong..

its lowlevel because it has to be for performance reasons, write a high level
wraper or improve the api if it can be done without slowdown
and "wrong" well, i dont know what thats supposed to mean in relation to a API

[...]

[Dave Airlie]

Post by Michael Niedermayer
yes, are you suggesting that you would prefer to hide the api version?

nope I'd saying I'd prefer the people who know how this project works
would put the effort into thinkinig about what a semi-stable API might
look like (i.e. think a bit ahead, you don't have to implement it all
just design an API that should be sufficient...)

Post by Michael Niedermayer
its lowlevel because it has to be for performance reasons, write a high level
wraper or improve the api if it can be done without slowdown
and "wrong" well, i dont know what thats supposed to mean in relation to a API

wrong means that the API design needs to change every 2-3 months for
new requirements, it means the initial design of the API was
insufficent for the needs of the project...

I don't want to sound thankless, I appreciate all the ffmpeg project
does and continues doing, I'm just saying it is one of the few
projects I've come across in many years where shared libraries are not
recommended and forking your own version is... how hard is it to
schedule API breakages at certain points, and maybe have a release
cycle (a release doesn't have to work perfectly, it just has to be a
reasonable line in the sand so people can centralise on it and say
okay this is good enough for me until the next one....,you can make
sure that no features are currently in flux and just tag a release,
i.e. for me ffmpeg-0.4.8 can't play some MPEG2 but 0.4.9-pre1 plays
them fine, but ffmpeg-CVS plays my MPEG2s fine and MPEG4s jerky....
with some releases and CVS tags it gives external projects a nice sync
point every so often to test their feature set against... as opposed
to now where I grab a CVS tarball with no idea if something is a work
in development or breakages are temporary or not ...

just my 2c worth it seems to work for a lot of other projects out
there, I wonder why ffmpeg needs to be different...

Dave.

[Burkhard Plaum]

Interesting discussion. Actually, I can understand both
points of view. Including ffmpeg into an own project and
link statically solves all problems related to API/ABI
changes and versions. On the other hand, dynamic linking of
external libs is the preferred way for most OSS projects.

I use ffmpeg for 2 projects, libquicktime
(http://libquicktime.sourceforge.net) and gmerlin
(http://gmerlin.sourceforge.net) and I know what it means to
depend on ffmpeg.

The ffmpeg people do a great job for multimedia support on
Linux and other OSes. The developers make decisions, and it
doesn't make sense to discuss if they are right or not.

So my question is the following: Would forking be possible
without offending anyone? If there was another ffmpeg CVS
repository, which is automakified, but otherwise closely
synced with the primary CVS, regular releases can be made
from that. A smart shell script can sync the CVS almost
automatically, even if the build systems are different. If
some projects, which depend on ffmpeg, work together, the
amount of labor stays reasonable. The ffmpeg people can point
to these releases as "unsupported regular releases, using CVS
is preferred". The only things we must make sure, are
that ffmpeg developers aren't bothered with reports about bugs,
they aren't responsible for, and that general bugfixes find their
way back into the original ffmpeg.
--
_____________________________
Dr.-Ing. Burkhard Plaum
Institut fuer Plasmaforschung
Pfaffenwaldring 31
70569 Stuttgart
Tel.: [phone]
Fax.: -3102


-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf

[Kenneth Lavrsen]

Post by Burkhard Plaum
So my question is the following: Would forking be possible
without offending anyone? If there was another ffmpeg CVS
repository, which is automakified, but otherwise closely
synced with the primary CVS, regular releases can be made
from that. A smart shell script can sync the CVS almost
automatically, even if the build systems are different. If
some projects, which depend on ffmpeg, work together, the
amount of labor stays reasonable. The ffmpeg people can point
to these releases as "unsupported regular releases, using CVS
is preferred". The only things we must make sure, are
that ffmpeg developers aren't bothered with reports about bugs,
they aren't responsible for, and that general bugfixes find their
way back into the original ffmpeg.

I am for sure interested. And I do not even see the reason for an
additional CVS.
We can just agree - 3 times per year - which of the recent CVS snaps we
want to release based on experience and a short test with our own project
that WE do ourselves.

We choose a release candidate - test it - and if it works for all of us -
we release.
If not - we try another one.
That will be very simple and I will be happy to participate in that with
Motion.
I am sure we can arrange with the major packagers that they follow up with
their RPMs and debs.

Kenneth

[Burkhard Plaum]

Post by Kenneth Lavrsen
I am for sure interested. And I do not even see the reason for an
additional CVS.

I just thought it could be handy sometimes to have a reference codebase
available for everyone to test. In principle, this could also be a tar.gz
on a webserver, but I personally would prefer CVS.

Post by Kenneth Lavrsen
We can just agree - 3 times per year -

Doesn't need to be that strict IMHO. We can also try to synchronize it
to the release cycles of our projects. But the more projects participate,
the harder it's gonna be, so 3 times a year might be better then.

Post by Kenneth Lavrsen
We choose a release candidate - test it - and if it works for all of us -
we release.
If not - we try another one.

I would try to report/fix them for the upstream ffmpeg also.
I really think, that the ffmpeg people can have an advantage from that:
Fewer bugreports from years old versions and regular testing phases from
application developers.

Post by Kenneth Lavrsen
That will be very simple and I will be happy to participate in that with
Motion.

Gmerlin and libquicktime would also join :)

Post by Kenneth Lavrsen
I am sure we can arrange with the major packagers that they follow up with
their RPMs and debs.

That would, for sure, help.

Burkhard

[Reimar Döffinger]

Hi,
I'm not an FFmpeg developer so I won't have the last word anyway, but...

Post by Kenneth Lavrsen
I am for sure interested. And I do not even see the reason for an
additional CVS.
We can just agree - 3 times per year - which of the recent CVS snaps we
want to release based on experience and a short test with our own project
that WE do ourselves.
We choose a release candidate - test it - and if it works for all of us -
we release.
If not - we try another one.
That will be very simple and I will be happy to participate in that with
Motion.
I am sure we can arrange with the major packagers that they follow up with
their RPMs and debs.

This sounds to me like basically what you want to do is take some CVS
snapshots and tag them as good/bad and put the good ones more visibly
into the public.
I guess if somebody actually would be doing this testing/bookkeeping
even official FFmpeg releases could be done more frequently - I just
know that when we try to do an MPlayer release we usually don't find
enough people to even test half of the supported architectures/OSes.
So whatever will come out in the end, at least people testing things are
always welcome.

Greetings,
Reimar Döffinger

[Rich Felker]

Post by Burkhard Plaum
Interesting discussion. Actually, I can understand both
points of view. Including ffmpeg into an own project and
link statically solves all problems related to API/ABI
changes and versions. On the other hand, dynamic linking of
external libs is the preferred way for most OSS projects.
I use ffmpeg for 2 projects, libquicktime
(http://libquicktime.sourceforge.net) and gmerlin
(http://gmerlin.sourceforge.net) and I know what it means to
depend on ffmpeg.
The ffmpeg people do a great job for multimedia support on
Linux and other OSes. The developers make decisions, and it
doesn't make sense to discuss if they are right or not.
So my question is the following: Would forking be possible
without offending anyone? If there was another ffmpeg CVS
repository, which is automakified, but otherwise closely
synced with the primary CVS, regular releases can be made
from that. A smart shell script can sync the CVS almost
automatically, even if the build systems are different. If
some projects, which depend on ffmpeg, work together, the
amount of labor stays reasonable. The ffmpeg people can point
to these releases as "unsupported regular releases, using CVS
is preferred". The only things we must make sure, are
that ffmpeg developers aren't bothered with reports about bugs,
they aren't responsible for, and that general bugfixes find their
way back into the original ffmpeg.

This is just as bad. The problem is that everyone is using old crap
and reporting bugs in old crap. There's already a PERFECT solution
that works for everyone who's doing it: include lavc with your project
and static link it.

Rich

[Burkhard Plaum]

Post by Rich Felker

Post by Burkhard Plaum
The only things we must make sure, are
that ffmpeg developers aren't bothered with reports about bugs,
they aren't responsible for, and that general bugfixes find their
way back into the original ffmpeg.

This is just as bad. The problem is that everyone is using old crap
and reporting bugs in old crap.

That's what I wrote above. It must be clearly said, that such releases
aren't supported by the ffmpeg project. Today, you get bugreports for
your latest 0.4.9pre1 or even 0.4.8. With 3 releases a year and a notice,
that ffmpeg people aren't responsible for them, things can only get better :)

Furthermore, when others prepare a release, they'll probably do some intensive
testing before. So you'll get bugreports and patches from developers, who know
at least a bit about multimedia.

Post by Rich Felker
There's already a PERFECT solution
that works for everyone who's doing it: include lavc with your project
and static link it.

That doesn't work, if you need (for whatever reason) dynamic linking.
Furthermore, it's unneccesary labor, when dozens of projects upgrade their
ffmpeg trees all the time. So why not save some energy (and installation
disk space) where it makes sense?

Wondering how many Gigs my linux would need if every gnome applet would be
perfect enough to include and statically link gtk ;)

Burkhard

[Rich Felker]

Post by Burkhard Plaum

Post by Rich Felker

Post by Burkhard Plaum
The only things we must make sure, are
that ffmpeg developers aren't bothered with reports about bugs,
they aren't responsible for, and that general bugfixes find their
way back into the original ffmpeg.

This is just as bad. The problem is that everyone is using old crap
and reporting bugs in old crap.

That's what I wrote above. It must be clearly said, that such releases
aren't supported by the ffmpeg project. Today, you get bugreports for
your latest 0.4.9pre1 or even 0.4.8. With 3 releases a year and a notice,
that ffmpeg people aren't responsible for them, things can only get better :)
Furthermore, when others prepare a release, they'll probably do some intensive
testing before. So you'll get bugreports and patches from developers, who know
at least a bit about multimedia.

LOL. Just a minute ago you were saying we could make snapshots direct
from cvs and call them releases with no effort. Now you've made up
some imaginary team that will clean up and maintain sync with a forked
release codebase... Make up your mind already!

Post by Burkhard Plaum

Post by Rich Felker
There's already a PERFECT solution
that works for everyone who's doing it: include lavc with your project
and static link it.

That doesn't work, if you need (for whatever reason) dynamic linking.
Furthermore, it's unneccesary labor, when dozens of projects upgrade their
ffmpeg trees all the time. So why not save some energy (and installation
disk space) where it makes sense?

You're missing the point: IT WILL NOT SAVE ENERGY! It will take a lot
more work. If you think it's so easy, do it yourself, but chances are
the lavc developers will have no part in it and will not endorse it.

Post by Burkhard Plaum
Wondering how many Gigs my linux would need if every gnome applet would be
perfect enough to include and statically link gtk ;)

Should be zero, because it should not include any gnome shit. :)

Rich

[Burkhard Plaum]

Post by Rich Felker
LOL. Just a minute ago you were saying we could make snapshots direct
from cvs and call them releases with no effort.

That was a suggestion from someone else. I also read this thread.

Post by Rich Felker
Now you've made up
some imaginary team that will clean up and maintain sync with a forked
release codebase...

That's what I said from the very beginning.

Post by Rich Felker
Make up your mind already!

What was that?

Post by Rich Felker
You're missing the point: IT WILL NOT SAVE ENERGY! It will take a lot
more work.

For whom? For the ffmpeg people? I don't think so.
I want a solution everyone can be happy with. So that ffmpeg people can
continue their work (and receive less mails about old releases or autotools).
And application developers have a package, they can depend on.

Post by Rich Felker
If you think it's so easy, do it yourself, but chances are
the lavc developers will have no part in it and will not endorse it.

We did a similar thing with quicktime4linux 4 years ago. Today, libquicktime
is part of many distributions and I know no application (except
cinelerra/xmovie or course), which depends on quicktime4linux anymore.

Unfortunately, communication with the original developer wasn't possible, so
we soon lost sync. I should note, that for libquicktime, we made huge changes
in the sourcecode, which we thought were necessary.

For ffmpeg, the situation is different, because I don't want to make changes to
the sources. The rule must be, that patches are submitted back to ffmpeg.

Burkhard

[Luca Barbato]

Post by Burkhard Plaum
That doesn't work, if you need (for whatever reason) dynamic linking.
Furthermore, it's unneccesary labor, when dozens of projects upgrade their
ffmpeg trees all the time. So why not save some energy (and installation
disk space) where it makes sense?

Those project SHOULD keep their cvs in sync with ffmpeg if they plan to
use the latest and greatest, they could live with a dated one if they
are using just some bits that didn't change within the year... libav* is
a moving target for a reason, not just because is nice to break the ABI
now and then

Post by Burkhard Plaum
Wondering how many Gigs my linux would need if every gnome applet would be
perfect enough to include and statically link gtk ;)

Doesn't make sense. BTW you have to update gtk+ in order to build the
latest and greatest gnome-applets.... Please think about how things work
and why you should or should not update (If Motion is perfectly happy
with a libavcodec why update to a later one? Just for security issues
that may or may not apply to it)

lu

[Dave Airlie]

Post by Rich Felker
This is just as bad. The problem is that everyone is using old crap
and reporting bugs in old crap. There's already a PERFECT solution
that works for everyone who's doing it: include lavc with your project
and static link it.

I think a lot of people are using old crap now, how do security
related updates happen?

If I've got say mplayer, xine and some other ffmpeg using apps
installed, and ffmpeg has a security issue, I've got to go re-build
all of them from their own repostiories and hope that each project has
pulled in the security fix into their trees, chances are most of the
ffmpeg using projects don't stick to the top of ffmpeg CVS like glue
(I assume mplayer does)... they rebase their code from it every so
often when they feel they need to... in this way you are still having
a lot of people running "old crap" whether its statically linked old
crap or dynamic.... at least with dynamic there is chance everyone is
running the same old crap, and someone applying the security fix to
one will make it work for all ...

Dave.

[Jacob Meuser]

Post by Rich Felker

Post by Burkhard Plaum
Interesting discussion. Actually, I can understand both
points of view. Including ffmpeg into an own project and
link statically solves all problems related to API/ABI
changes and versions. On the other hand, dynamic linking of
external libs is the preferred way for most OSS projects.
I use ffmpeg for 2 projects, libquicktime
(http://libquicktime.sourceforge.net) and gmerlin
(http://gmerlin.sourceforge.net) and I know what it means to
depend on ffmpeg.
The ffmpeg people do a great job for multimedia support on
Linux and other OSes. The developers make decisions, and it
doesn't make sense to discuss if they are right or not.
So my question is the following: Would forking be possible
without offending anyone? If there was another ffmpeg CVS
repository, which is automakified, but otherwise closely
synced with the primary CVS, regular releases can be made
from that. A smart shell script can sync the CVS almost
automatically, even if the build systems are different. If
some projects, which depend on ffmpeg, work together, the
amount of labor stays reasonable. The ffmpeg people can point
to these releases as "unsupported regular releases, using CVS
is preferred". The only things we must make sure, are
that ffmpeg developers aren't bothered with reports about bugs,
they aren't responsible for, and that general bugfixes find their
way back into the original ffmpeg.

This is just as bad.

there is/was already ffmpeg-acl.

Post by Rich Felker
The problem is that everyone is using old crap
and reporting bugs in old crap.

perhaps you did not read burkhard's email closely. to me, it seems
he is talking about very regular (daily?) syncs. trust me, burkhard
likes to keep things moving forward :)

besides, if I import ffmpeg sources into my project, then the ffmpeg
version used by whatever release of that project will only be as new
as that project's last release, where with shared libraries from an
external ffmpeg, I could update the ffmpeg version that project is
using (assuming there are no API/ABI problems with a newer version).

Post by Rich Felker
There's already a PERFECT solution
that works for everyone who's doing it: include lavc with your project
and static link it.

I'll say it again, this does not work in all situations.

linking a non-PIC library into a _module_ on amd64 is a good example
of something that just won't work.

[Burkhard Plaum]

Post by Jacob Meuser
there is/was already ffmpeg-acl.

Exactly :)

Post by Jacob Meuser
to me, it seems
he is talking about very regular (daily?) syncs.

How often to sync can be a matter of discussion/manpower.
ffmpeg_acl is/was synced according to the release cycles of libquicktime
and gmerlin, but there might be a need to do it more often.
It should be noted, that both gmerlin and libquicktime work well with the
upstream ffmpeg (an autoconf macro decides, which one to use).
So people are free to do it the "official" way (use a CVS checkout), or
simply install an rpm or tgz.

Post by Jacob Meuser
linking a non-PIC library into a _module_ on amd64 is a good example
of something that just won't work.

I can remember searching for a bug for a long time until I noticed, that
I used 2 libraries, which included different ffmpeg versions.

Burkhard

[Luca Barbato]

Post by Rich Felker
This is just as bad. The problem is that everyone is using old crap
and reporting bugs in old crap. There's already a PERFECT solution
that works for everyone who's doing it: include lavc with your project
and static link it.

Perfect as in :

- Works for sure

- You pick only what you need and nothing more

- easyer to follow if you configure correctly your cvs

But:

- you may end up with different ffmpeg linked together if you are
developing a library yourself and got linked against a program that uses
ffmpeg too (ok, that was/is cinelerra and has its degree of nonsenses
already)

- no other issues that come to my mind.

lu

[Andy Parkins]

Hello,

There's obviously no consensus on this subject. I suppose it's been brought
up before, but just in case:

Would changing to subversion for the ffmpeg repository give everyone what they
want? Because subversion tracks trees rather than files, there would be no
need to create "releases" or tags. Every single checkin would implicitly be
tagged simply from it's revision number.

Then given the two facts:
* The latest revision is always the best
* Some people want a "release"
Simply announce the revision on a particular day as being the "release".



Andy

[François Revol]

Post by Kenneth Lavrsen
Dear Developers of ffmpeg
ffmpeg is a very nice project from a technical point of view
But from the view of a developer and project maintainer of a project that
uses ffmpeg - the project is a nightmare.

The thing that bothers me currently is that libavutil which is one more
lib to care about, and isn't even linked to correctly in libavformat
(undefined syms).

Is it ok now to cvs ci again ?

The use of more and more external GPL libs is also a problem...

François.

[Michel Bardiaux]

Post by François Revol

Post by Kenneth Lavrsen
Dear Developers of ffmpeg
ffmpeg is a very nice project from a technical point of view
But from the view of a developer and project maintainer of a project that
uses ffmpeg - the project is a nightmare.

The thing that bothers me currently is that libavutil which is one more
lib to care about, and isn't even linked to correctly in libavformat
(undefined syms).
Is it ok now to cvs ci again ?
The use of more and more external GPL libs is also a problem...

Which is a problem, 'external' or 'GPL'?

[François Revol]

Post by Michel Bardiaux

Post by François Revol

Post by Kenneth Lavrsen
Dear Developers of ffmpeg
ffmpeg is a very nice project from a technical point of view
But from the view of a developer and project maintainer of a
project
that
uses ffmpeg - the project is a nightmare.

The thing that bothers me currently is that libavutil which is one more
lib to care about, and isn't even linked to correctly in
libavformat
(undefined syms).
Is it ok now to cvs ci again ?
The use of more and more external GPL libs is also a problem...

Which is a problem, 'external' or 'GPL'?

Either.

François.

[Rich Felker]

Post by Michel Bardiaux

Post by François Revol

Post by Kenneth Lavrsen
Dear Developers of ffmpeg
ffmpeg is a very nice project from a technical point of view
But from the view of a developer and project maintainer of a project that
uses ffmpeg - the project is a nightmare.

The thing that bothers me currently is that libavutil which is one more
lib to care about, and isn't even linked to correctly in libavformat
(undefined syms).
Is it ok now to cvs ci again ?
The use of more and more external GPL libs is also a problem...

Which is a problem, 'external' or 'GPL'?

IMO, external. If people want these codecs in lavc they should port
them to use the native lavc dsp functions, etc. rather than linking
external libraries with limited-functionality wrappers.

Rich

[Michel Bardiaux]

Post by Rich Felker

Post by Michel Bardiaux

Post by François Revol
The use of more and more external GPL libs is also a problem...

Which is a problem, 'external' or 'GPL'?

IMO, external. If people want these codecs in lavc they should port
them to use the native lavc dsp functions, etc. rather than linking
external libraries with limited-functionality wrappers.
Rich

Then, "once more with feeling": why is such an important codec as MPEG
Audio Level-3 (aka mp3) still using liblame?

[Martin Boehme]

Post by Michel Bardiaux

Post by Rich Felker

Post by Michel Bardiaux

Post by François Revol
The use of more and more external GPL libs is also a problem...

Which is a problem, 'external' or 'GPL'?

IMO, external. If people want these codecs in lavc they should port
them to use the native lavc dsp functions, etc. rather than linking
external libraries with limited-functionality wrappers.

Then, "once more with feeling": why is such an important codec as MPEG
Audio Level-3 (aka mp3) still using liblame?

Would interest me too... I always assumed automatically it was because
of Fraunhofer IIS and their litigiousness...

Martin

[Michel Bardiaux]

Post by Martin Boehme

Post by Michel Bardiaux

Post by Rich Felker

Post by Michel Bardiaux

Post by François Revol
The use of more and more external GPL libs is also a problem...

Which is a problem, 'external' or 'GPL'?

IMO, external. If people want these codecs in lavc they should port
them to use the native lavc dsp functions, etc. rather than linking
external libraries with limited-functionality wrappers.

Then, "once more with feeling": why is such an important codec as MPEG
Audio Level-3 (aka mp3) still using liblame?

Would interest me too... I always assumed automatically it was because
of Fraunhofer IIS and their litigiousness...
Martin

The usual thing done in lavc for litigious codecs is to put them under
#if. And that's probably the reason mp3lame has to be explicitly
activated during configure. It doesnt explain why an external lib is
tolerated there.

[Alexander Strange]

Post by Michel Bardiaux
Then, "once more with feeling": why is such an important codec as
MPEG Audio Level-3 (aka mp3) still using liblame?

Well, LAME is an extraordinarily heavily tuned mp3 encoder; it would
take a lot of work for an internal encoder to not end up sounding
like BladeEnc.

Something I've always wondered is why ffmpeg has an internal copy of
liba52, rather than an actual ac3 decoder that uses ffmpeg's dsp
functions.

[Rich Felker]

Post by Alexander Strange

Post by Michel Bardiaux
Then, "once more with feeling": why is such an important codec as
MPEG Audio Level-3 (aka mp3) still using liblame?

Well, LAME is an extraordinarily heavily tuned mp3 encoder; it would
take a lot of work for an internal encoder to not end up sounding
like BladeEnc.

LAME is actually very inefficient and produces noticable artifacts
that can be avoided on certains kinds of content. It's not the godly
mp3 encoder people make it out to be..

Post by Alexander Strange
Something I've always wondered is why ffmpeg has an internal copy of
liba52, rather than an actual ac3 decoder that uses ffmpeg's dsp
functions.

Most certainly.. It's because people are lazy. :(

Rich

[Balatoni Denes]

Hi!

Wow. Out of curiosity what mp3 encoder do you recommend?

csütörtök 11 augusztus 2005 18.23-kor Rich Felker ezeket a bolcs gondolatokat

Post by Rich Felker
LAME is actually very inefficient and produces noticable artifacts
that can be avoided on certains kinds of content. It's not the godly
mp3 encoder people make it out to be..
Rich

bye
Denes

[Rich Felker]

Post by Balatoni Denes
Hi!
Wow. Out of curiosity what mp3 encoder do you recommend?

I don't know of any that are better. But in theory, it's possible to
avoid these types of artifacts.

BTW please don't top-post. It makes it hard to reply in a sane way.

Rich

Post by Balatoni Denes
csütörtök 11 augusztus 2005 18.23-kor Rich Felker ezeket a bolcs gondolatokat

Post by Rich Felker
LAME is actually very inefficient and produces noticable artifacts
that can be avoided on certains kinds of content. It's not the godly
mp3 encoder people make it out to be..
Rich

bye
Denes
--
- Use the Source Luke ! -
_______________________________________________
ffmpeg-devel mailing list
http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel

[Alexander Strasser]

Post by François Revol

Post by Kenneth Lavrsen
Dear Developers of ffmpeg
ffmpeg is a very nice project from a technical point of view
But from the view of a developer and project maintainer of a project that
uses ffmpeg - the project is a nightmare.

The thing that bothers me currently is that libavutil which is one more
lib to care about,

Don't know what you mean exactly but it is nothing new,
only reorganized.

Post by François Revol
and isn't even linked to correctly in libavformat
(undefined syms).

Could you be a bit more concrete here. I made it
before my job started and only tested it on one
machine. So it likely that i overlooked problems
or just didn't see them on my target.
I also send it in advance so it can be tested by
other people, but it seems no one did...
Now I am working and I am not at home for 12h a
day, this means i can only work on free software
stuff at the weekends.

Post by François Revol
Is it ok now to cvs ci again ?

What do you want to check in?

Post by François Revol
The use of more and more external GPL libs is also a problem...

Alex (beastd)

[François Revol]

Post by Alexander Strasser

Post by François Revol

Post by Kenneth Lavrsen
Dear Developers of ffmpeg
ffmpeg is a very nice project from a technical point of view
But from the view of a developer and project maintainer of a
project
that
uses ffmpeg - the project is a nightmare.

The thing that bothers me currently is that libavutil which is one more
lib to care about,

Don't know what you mean exactly but it is nothing new,
only reorganized.

No, that means 2 files to install when using libavcodec, and to check
the versions of.

Post by Alexander Strasser

Post by François Revol
and isn't even linked to correctly in libavformat
(undefined syms).

Could you be a bit more concrete here. I made it
before my job started and only tested it on one
machine. So it likely that i overlooked problems
or just didn't see them on my target.

make[1]: Entering directory `/boot/home/devel/ffmpeg/cvs/ffmpeg/
libavformat'
gcc -nostart -Wl,--warn-common -o libavformat.so utils.o cutils.o
os_support.o allformats.o mpeg.o mpegts.o mpegtsenc.o ffm.o crc.o img.o
img2.o raw.o rm.o avienc.o avidec.o wav.o mmf.o swf.o au.o gif.o mov.o
mpjpeg.o dv.o yuv4mpeg.o 4xm.o flvenc.o flvdec.o movenc.o psxstr.o
idroq.o ipmovie.o nut.o wc3movie.o mp3.o westwood.o segafilm.o idcin.o
flic.o sierravmd.o matroska.o sol.o electronicarts.o nsvdec.o asf.o asf
-enc.o ogg2.o oggparsevorbis.o oggparsetheora.o oggparseflac.o pnm.o
yuv.o png.o jpeg.o gifdec.o sgi.o avio.o aviobuf.o file.o framehook.o
udp.o tcp.o http.o rtsp.o rtp.o rtpproto.o -lavcodec -L../libavcodec -
lmp3lame -lbind -lsocket -lz
utils.o(.text+0xaaa): In function `compute_pkt_fields':
: undefined reference to `av_rescale'

IOW: when using shared libs one *must* link to the libs it uses symbols
from.
Some platforms are picky about that, unlike linux.

Post by Alexander Strasser
I also send it in advance so it can be tested by
other people, but it seems no one did...

Didn't have the time.

Post by Alexander Strasser

Post by François Revol
Is it ok now to cvs ci again ?

What do you want to check in?

The fix.


François.

[Alexander Strasser]

Post by François Revol

Post by Alexander Strasser

Post by François Revol
Is it ok now to cvs ci again ?

What do you want to check in?

The fix.

Sorry, i really don't see the connection between your 2 statements
here.
But anyway the attached patch makes shared compilation under
windows work again. Is it enough for your platform too, or does
it need additional lib reordering?

Though i wonder if it is correct to do it that way, but at least
it is analog to how it is done with libavcodec and that was done
before i introduced libavutil.

Alex (beastd)

[François Revol]

Post by Alexander Strasser

Post by François Revol

Post by Alexander Strasser

Post by François Revol
Is it ok now to cvs ci again ?

What do you want to check in?

The fix.

Sorry, i really don't see the connection between your 2 statements
here.

heard mphq had probs and I didn't know if the cvs server was usable
yet.

Post by Alexander Strasser
But anyway the attached patch makes shared compilation under
windows work again. Is it enough for your platform too, or does
it need additional lib reordering?

Yes that's what I did too.

François.

[Alexander Strasser]

Post by François Revol

Post by Alexander Strasser

Post by François Revol

Post by Alexander Strasser

Post by François Revol
Is it ok now to cvs ci again ?

What do you want to check in?

The fix.

Sorry, i really don't see the connection between your 2 statements
here.

heard mphq had probs and I didn't know if the cvs server was usable
yet.

Finally i got it :)
Well CVS should be working again. I hope someone is making backups
of the ffmpeg repository. I know it was in the discussion not too
long time ago, but i don't know if someone actually does it now.

Post by François Revol

Post by Alexander Strasser
But anyway the attached patch makes shared compilation under
windows work again. Is it enough for your platform too, or does
it need additional lib reordering?

Yes that's what I did too.

Ok, i committed that now. Should there be more problems please
fix it. As i said in the other mail i won't always be here for
the next time.

Alex (beastd)