>> Which isn't even close to what transcode is capable of. > >Well, libavfilter is just in the process of getting merged into trunk >(http://svn.mplayerhq.hu/ffmpeg/trunk/libavfilter/). We will have to >wait and see. Judging from discussions at ffmpeg-devel, they are >aiming to provide support for complex filter graphs.
To be fair, my comment was out of order, since the issue was only the presence or absence of filters, and (as you pointed out) ffmpeg does indeed seem to be getting filters. We'll just have to see how ffmpeg and transcode evolve. >> While transcode interacts with many more libraries/devices, > >http://svn.mplayerhq.hu/ffmpeg/trunk/libavdevice/ >What devices are you missing? Which libraries? You'll forgive me for not reading the whole of every source file there, but at a glance I don't see any ALSA or VNC support in there, nor support for such libraries as PVN or ImageMagick. >> has a much clearer interface (the module system) for third parties to add >> even more. > >And was there ever a "third party" that has done so? There's certainly at least one, because you're talking to him. (That's part of what got me interested in transcode development in the first place.) >> (and the "ffmpeg" executable doesn't count; it's not much more than a >> wrapper). > >Like transcode is just a wrapper for a lot of external (and >potentially unmaintained) libraries? To be honest, between the lack of a man page, the nearly uncommented source code, and the opaque help text, I'm not quite sure what the ffmpeg wrapper _is_ capable of. But to the extent I've used it in the past, I find transcode to provide greater functionality, save perhaps for transcode's difficulty dealing with pipes (one of the things scheduled to be fixed in the new module system). I also don't see what the maintainedness of an external library has to do with anything; code doesn't rot away just because it's not constantly being changed. --Andrew Church [EMAIL PROTECTED] http://achurch.org/
