[kde-freebsd] KDE4/Qt4 porting efforts?

[Danny Pansters]

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