On Tuesday 08 January 2008 10:01:13 Adriaan de Groot wrote: > On Sunday 06 January 2008, Danny Pansters wrote: > > IMHO both xine and gstreamer were piss-poor choices for the a/v backend, > > they should have built their own infrastructure around ffmpeg instead > > which in any event is the *real* a/v engine that eventually gets used, > > would have left the multimedia backend framework basically up to > > themselves, possibly manpower shortage was the main reason for this? > > Manpower, and the desire *not* to write a mm backend, but only the 80% > solution (common functionality, no specialized needs) KDE API for the > majority of KDE applications. It's always been a stated goal of the KDE4 MM > framework *not* to impinge on the space where people who know what they're > doing and who have specific needs to do MM with ffmpeg. > > Ah, and arts has left a bad taste in the mouth.
Ok, I can understand that, but still, now you have two wrappers wrapping wrappers... :) I think one major reason was (aside of perhaps -- mistakingly? -- embracing gstreamer early on) that xinelib was already known and used (and now it's sort of the safety net when gstreamer doean't work). Correct? Don't make it good choices though. I don't want to argue over this, but I think a (somewhat educated) opinion is never a bad thing, and having looked at and worked with ffmpeg over the past few weeks, I have to say that xine-lib is very limited for a library (add to that GPL licenses on header files). I very quickly gravitated to the real thing, ffmpeg (also the only MM library that has more modern mpeg2 support than the bolted-on-mpeg2dec that once was the selling point of xine). One merely has to look at performance. And really, if I -- with my almost nonexistant C knowledge -- can turn ffplay into a small viewer library for my application in a few days, I have the feeling that it has been shunned perhaps a little too fast. As for gstreamer... I haven't used it but it looks interesting, though likely overengineered. And let's face it, it's a gnome thing, and one with an unstable API. I'm sure that with gnome/totem and the fluendo plugin$ it'll work well. But for KDE? Oh yeah, arts. Arts. Our dear lil arts :) Talk about overengineered :) PulseAudio is where it's going to be happening now I reckon, and that's probably good (if only because it hopefully strongly discourages ALASA-only code). The MM points (xine/gst vs ffmpeg) are moot, I know. But they can still be made. BTW, I really appreciate that harsh criticism can be voiced over such things without a knee-jerk "you just hate us, go away!" reaction. Cheers, Dan _______________________________________________ kde-freebsd mailing list kde-freebsd@kde.org https://mail.kde.org/mailman/listinfo/kde-freebsd