[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Jean-Baptiste Kempf]

On Mon, Jan 26, 2009 at 10:05:05PM +0000, M?ns Rullg?rd wrote :
> Robert Swain <robert.swain at gmail.com> writes:
> > I just had a chat with some of the videolan developers to see if I
> > could get them involved in this discussion. We ended up having a
> > discussion off list, but these were their points:

Let me answer quite straight, we were asked: "what could be improved in
FFmpeg from your point of view?"

We have not many problems with FFmpeg, and we are able to mix FFmpeg
codecs and formats with others, and we have no issue with it (contrarly
what $vendor says that this is impossible to have game formats and own
demuxers).
Therefore we DON'T complain, we just gave a few random thoughts.

VLC uses FFmpeg HEAD for stupid OSes (Win32 and Mac) without
forking it in our tree. For those, we see few regressions and issues
since the Fate came up and we moved to gcc4. Therefore, releases is HEAD
for us.

For OSes with library dependencies, having or not releases will not
change anything, since we will have to deal with debian/stable and
ubuntu/next_version at the same time...


> We've done that ONCE.  It's unlikely to happen again.  The old layout
> was causing problems of its own too.
Great. That was just a random remark, don't take it as a reproach,
please.

> > - fix .pc (package config files)
> That's impossible until all those who demands this agree on what the
> correct files should look like.
We'll try to be more concrete on that.

> > - less dependency of libavformat on libavcodec would be welcome
> That's an orthogonal issue.  Besides, changing it would mean *massive*
> API/ABI breakage.
We are just reporting that, because that would be nice, but we know that
this is very difficult.
The thing is when you have a module using libavformat and you link
statically, you need to have both libavcodec and libavformat in it, so
the size is big.
Once again, this is NOT a reproach nor a rant, this is just a "That
would be cool".

> > - detail API/ABI changes would be very very welcome
> svn log avcodec.h etc...
Sorry, svn log is not documentation, but OK.

> Backward compatible changes don't need a major version bump.  Updating
> the minor number when things are added is of course nice since it lets
> apps check for a specific number before using some feature.  We try to
> do this, but sometimes people forget.
Ok.

> That table maps lavc codec IDs to VLCs internal ID system.  Are they
> really suggesting that *we* supply ID tags internal to *every* app
> that uses lav*?  Or just to them, selfishly?
Sorry, this was not clear. Let me rephrase:
With more and more distributions removing or adding features, a way to
request dynamically what feature is in or is not would be nice.

Moreover, once again, this was not a rant and your answer is a bit
aggressive.

Sorry if the message wasn't clearly formulated, but we don't have many
issues and we don't really share the global rant againt FFmpeg.

About libavformat API, I'll let fenrir discuss that, because I am
clearly NOT up to date with the (non-)issue.

Btw, is there a discussion room for FFmpeg at Fosdem?

Best Regards,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/