[Ffmpeg-devel] Using ffmpeg libs in an OSS project is a nightmare

[Dave Airlie]

> 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...)

> 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.