[FFmpeg-devel] [RFC] ffmpeg.c refactoring
Wed Jun 11 19:06:41 CEST 2008
On Wed, Jun 11, 2008 at 06:57:27PM +0200, Ralf Terdic wrote:
> On Wednesday 11 June 2008 18:30:27 Reimar D?ffinger wrote:
> > > If Java is the problem, the solution is to eliminate Java.
> > Well, a more diplomatic way to put it: If Java is the problem, fix Java.
> > File a bug report or whatever they offer with Sun, I can seen no reason
> > at all why executing a system binary should be significantly slower with
> > Java than with C, so essentially this sounds to me like a case of "oh, we
> > had an intern implement this and not looked at the code ever since, nobody
> > cares anyway".
> There's no alternative option to Java for me, as the rest of the app is in
> Java, so let's stop this "Java or not" discussion. For this reason, I haven't
> done any benchmarks which involve invoking ffmpeg from other languages than
Well, I suggested to try to find out why Java is so slow and get that
> As the maintainers don't see any benefit in an encoding API using the code in
> ffmpeg.c, I'll do what others have done before me: see what other projects
> have to offer.
Well, if you consider that the best approach instead of first trying to
improve on the real problem (slow exec in Java) that might come to bite you in
many other cases later as well...
Also, I do not think anyone has a problem with moving some of the ffmpeg
functionality into libav* or possibly a new library, but just hacking
ffmpeg with brute force into a .dll/.so, avoiding such things as "proper API
design" as far as possible IMO will be rejected for very good reasons.
More information about the ffmpeg-devel