[kde-freebsd] KDE4/Qt4 porting efforts?
danny at ricin.com
Wed Jan 9 03:00:09 CET 2008
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
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
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.
More information about the kde-freebsd