links for 2007-07-17
July 17, 2007 11:32 pm freesoftware, General, openwengo- [Ffmpeg-devel] Using ffmpeg libs in an OSS project is a nightmare
From what I can tell, this is still current affairs. Looking at the ffmpeg FAQ, it seems like the developers are not particularly committed to API stability or any kind of release management.
July 18th, 2007 at 12:59 am
I am personally bummed because of non-automatic letterbox option:
http://eugenia.blogsome.com/2007/03/16/the-shit-thats-called-ffmpeg/
Mencoder is not better either though. Here you have an mpeg2 video that you want to transcode to motionjpeg format (for better video editing abilities), and the aspect ratio gets stuck to 4:3 even if you specifically ask for anamorphic 16:9.
Personally, I can’t trust any of these two programs to do my job, that’s why I moved my video workload to Sony Vegas and QuickTime under Windows.
July 18th, 2007 at 4:51 am
I don’t think you understand the point of ffmpeg. Ffmpeg is not an application library like gtk. It could be used as such, but it’s better not. Ffmpeg is a toolbox on its own, it’s an incredible collection of codecs and such, no better exists or will ever exist. In order to support the ever-growing range of codecs completely, it needs change, constant, continuous change. This includes many API changes and many feature additions to existing code. You want stability, you fork the codebase like everyone does and maintain your own copy. It’s the recommended way of doing it, and it works for everyone else.
If you try to force ffmpeg into the conservative and dysfunctional armour of API stability, something that nobody will ever be able to do anyway, the result will be that it will stagnate and be forgotten, and the star developers will turn somewhere else. The power is that all star multimedia developers now hack on a single project, one that does it all. New codecs get developed first, foremost and often even only for ffmpeg and everyone, from Sun to IBM to Intel to all those other companies has people working on, documenting, and trying to understand ffmpeg. It’s amazing, unforeseen, unexpected and incredibly unexplainable. And apparently difficult for people like you. Live with it, and ask developers like those of the powerful gstreamer framework to use their sweet sugar candy API to wrap ffmpeg and provide API stability.
That way, we all win, and we get a most remarkable piece of free software for it in return.
Eugenia: the ffmpeg application is crap. Nobody uses it, not even its developers. Ffmpeg, for all practical purposes, is the library providing codecs and containers, lavcodec and lavformat (plus their dependency lavutil). They are some of the star products of the free software community.
July 18th, 2007 at 9:33 am
Ronald, you know that’s not true. FFmpeg is marketed as a regular library, not as some unstable crap you shouldn’t use. And it’s even moreso marketed as such by the distros.
The real issue is that everyone is depending on such unstable crap and noone has a way of dealing with people that develop software instead of doing release management.
But I did a rant about that a while ago on my blog.
July 18th, 2007 at 12:46 pm
It’s true that ffmpeg needs releases, and for that they’ll need people doing the work. Just nobody ranting about it appears to want to do the work. Known issue in the free software world, I guess…
Since Dave is so passionate about it, maybe he should do it? :-).
July 18th, 2007 at 5:45 pm
>the ffmpeg application is crap. Nobody uses it
THAT’s where you are wrong! Many people use it, because there is nothing better. This “Reference” implementation is all there is and front-ends, scripts etc are all using it. The fact that is crap does not sway them away because simply, there is nothing else!
July 18th, 2007 at 8:26 pm
@rbultje: If the ffmpeg developers displayed any willingness to have release management, I might just do that – I’ve been a release manager before, and I know what it takes to get to a stable release. But the fact is that they haven’t.
July 19th, 2007 at 12:12 am
rbultje, IME the gstreamer-ffmpeg plugins are completely unstable and often non-functional, quite probably because of the issues outlined by Dave.
As for saying that “new codecs get developed first, foremost and often even only for ffmpeg”, that’s a very bold claim and I’d rather see some hard evidence before believing it… For example the x264 library looks like an independent project, not an ffmpeg spin-off.