The ability to learn from history prevents one from repeating the same mistakes in the same way. Ignore history and run the probability of making the same mistakes those before you did. After all, those mistakes were made by people probably as intelligent as you and likely with similar amounts of information. But history gives you an advantage in that it gives you, should you choose to take advantage of it, more information than those who made poor, though well intentioned or even seemingly wise at the time, decisions in the past.
Christian Schaller has blogged again about Phonon and GStreamer and sadly commits both of these sins.
First, he says:
"First of all my original blog post was in direct response to a claim by Aaron that Phonon was a good choice also for non-Qt developers doing cross platform applications." - Christian
He does say that English is not his first language and admits that maybe he misunderstood. Let me clear that up: he certainly did. Reading in any language requires reading full thoughts, not fragments of sentences.
Christan quotes me as saying, "Phonon is also more than just an option for Qt apps." but that is not what I wrote. Here's the original quote, unedited:
"Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it." - me
See how the period doesn't follow the words "apps"? No, it's a colon (:) and the sentence continues on for another whole phrase. My point was that if you are using Qt, then using Phonon is the best choice, not simply an option as Lennart had implied.
This makes Christian's original blog post on the matter, which was written in all sorts of poor form, a strawman. Nobody was making the claims he apparently based his statement on. But that mistake, once revealed, was not enough for Christian to gracefully back off. Instead, he says:
"Sure you ‘don’t get a hard dependency on any one multimedia system’ with Phonon, but you do get a dependency on Phonon and its dependencies instead."
This too is a strawman argument. You see, Phonon uses what is available on the system. That's the whole point. So trying to make it out like Phonon actually extends your dependency graph when in reality it does the opposite is pure doublespeak. Or, as Stephen Colbert would put it, it's full of truthiness.
Christian goes on to say:
"Aaron also repeated the oft heard argument that Phonon is for KDE about not repeating the mistakes of Arts. And I guess this is one of the big differences in perception. Because for Aaron for KDE to have used GStreamer would have been repeating Arts, but for me Phonon is repeating the Arts story."
Evidently Christian is ignorant of the history of things here: aRts (not Arts, by-the-by) was, like GStreamer, a really good option in its day but once written to aRts you were stuck using aRts. aRts, also like GStreamer, did much of the heavy lifting such as tying into codecs for decoding. Phonon is a thin layer above the realm that GStreamer (and once upon a time, aRts) lives in preventing KDE apps from running into the same problems we did in the past: our media playback only worked where aRts was installed, and when we looked beyond aRts we had to rewrite code. Phonon solves both those future oriented issues, and today many users of Phonon apps actually use GStreamer.
Of course, if you think that GStreamer is installed or even works everywhere, you are vastly deluded. I know many Linux users for whom GStreamer simply doesn't work. Thankfully for most it does. And lets not even get into the absurdity of it all by wondering out loud just how many Mac users have GStreamer raring to go.
Phonon works in those situations as well. Today. Without us writing any new code.
Christian continued:
"Back in the day if one dared to take issue about any of the wonderous claims made about Arts one got tons of comments about just being partisan and ‘hating Arts or hating KDE’. Kinda like how it is today when one tries to point out that Phonon is not the universal wonder solution that Aaron likes to paint it as."
This is another strawman. I'm not making Phonon out to be a universal wonder solution: it's the right solution for apps written with Qt or KDE, so much so that some people may even elect to write their app using Qt because of Phonon. This still doesn't make it a "universal wonder solution", and I'd highly appreciate it if Christian would stop putting such words into my mouth. It's poor form that even having English as a second language can't make an excuse for.
As for 'hating Arts (sic) or hating KDE' this again is a strawman. It's simply about representing Phonon accurately, or if you don't have the knowledge to do so then to be quiet about it altogether. It has nothing to do with hating anything, let alone KDE. In fact, I think it has a lot more to do with a blind love of GStreamer than hating anything.
Christian just can't stop erecting the strawmen though:
"I am taking issue with the promotion of Phonon as a better solution than just using GStreamer for a lot of specific use cases including cross-platform development. "
As I said in my original blog post on this matter, Phonon is not the right solution in all situations. I even gave an example: pro audio tools probably want to write to a lower layer directly. Once again, he's addressing a phantom argument that nobody is making.
"The strength of Phonon lies in providing a familiar API to existing Qt developers, giving them access to some limited multimedia functionality, but in terms of promoting itself as a generic cross platform multimedia development API it falls down, Phonon is attempting to do what wxWidgets tries to do for GUI components, and I never thought it worked very well for wxWidgets either."
So first some daming with faint praise and then an actually interesting point: is Phonon flawed in the same ways Christian feels wxWidgets is? Well, I think wxWidgets is not overly great due to its API not the "wrap native widgets" concept. Of course, those who use wxWidgets think its API is probably quite grand. Likewise, I find Phonon's API quite grand.
What is the user's experience with Phonon? It just works. For them it's a complete win.
What is the Qt developer's experience with Phonon? It feels natural, it integrates beautifully with the rest of the code and it future proofs their application development efforts.
What is the non-Qt developer's experience with Phonon? Irrelevant as they won't be using it.
And that, simply, is what matters. I don't care what Christian chooses to use hiself, but I do care when he makes unsubstantiated claims, false arguments and, for a reason only he can know, decides to dog the choices I and the community I belong to make. Remember, this did not start with me saying anything about GStreamer, but rather some pretty pointless statements being made by people involved with GStreamer about Phonon. You bet I'm going to correct those statements in as public a forum as they were originally made, and it's time they stepped back from trying to defend the indefensible with strawmen and other useless debatery.
The great irony here is that prior to KDE4, very very few KDE apps could use GStreamer at all and those that could did not default to it; while in the KDE4 era, all KDE apps can (and in many cases do) use GStreamer because we invested both serious amounts of money and time into making a Phonon GStreamer backend. You'd think they'd be happy, perhaps even congratulatory.
39 comments:
Hello Aaron,
Just want to say you than i really think that you dont have anything to prove.
You are a beautiful person and open source community really has a lot of luck to have you in its family.
Sure that we all know that.
Keep like you are.
Dont waste your time with that.
Cheers
Loic
The way you quote Christian quoting you makes you look like a total jerk, because both quotations are the same.
Please re-read what you wrote.
"Christan quotes me as saying, "Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it." but that is not what I wrote. Here's the original quote, unedited:
"Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it." - me"
Maybe I'm missing something, but both those quotes contain a semicolon :). But it might be an error with copy/paste, I do get what you are saying. Christian was basically making a claim that you think that Phonon is the ideal solution for anyone doing cross-platform developement, regardless of the underlying toolkit you happen to be using (be it Qt or something else). But you did not make that claim, you were talking about Qt-developement alone.
If only people (including Mr. Schaller) really understood what they were reading/hearing. The world would be a lot better place that way...
I think having a go at Christian for misunderstanding you is a touch unfair. Your statement "Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it." can be read in one of two ways:
(a) Phonon is an option for more application than just those based on Qt
(b) Phonon is more than "just an option" for Qt apps
You meant the latter, but it can be (and was) read as the former.
BTW: your quote of Christian quoting you and your quote of yourself are identical. I think your quote of Christian quoting you should stop at the semicolon.
@hans, @janne: that was a copy/paste error, yes. i've corrected it in the blog entry so that it is the actual quote from Christian's blog.
thanks for pointing that out.
@randomguy3: if that was the extent of it, maybe we could argue about it. it isn't.
moreover, if you read the full blog entry instead of cherry picking half of a sentence out of it, it's pretty clear.
if it was misunderstood, it still doesn't doesn't support the conclusion being posited by either Christian or Lennart.
I honestly don't understand gstreamer guys' stance. They hate higher level APIs or what?
@shiny: i don't think they hate higher level APIs, per se; gstreamer is a higher level API itself, after all.
it's certainly easier to use gstreamer than to directly use what lays beneath gstreamer; that's the whole point of the gstreamer project in fact. =) so they do appreciate the benefits of such a thing.
it does seem, however, that some people simply don't have a complete understanding of what Phonon is and why others might choose Phonon due to the things it offers.
there are indeed too many things in this word to learn about them all in one life time. but one probably shouldn't be giving public advice about those things, either.
Hmm... perhaps I should have been clearer myself :-)
I meant that that particular part of it was unfair. It happened to be what you started with, so it was the part with the most impact.
But really what shocked me was some of the commenters on Christian's blog. I'd forgotten about the wealth of idiots (or at least idiocy) on the internet.
@aseigo: well said.
Can you all please stop bickering now?
A "strawman argument" means the other person intentionally misrepresented your position. This was just a misunderstanding.
After reading your original post, I, a native English speaker, came to the same misunderstanding. It's an ambiguous sentence.
Secondly, why do people keep calling a colon a semicolon? :)
Its interesting that you seem to be saying that you did us (the GStreamer people) a favour when doing a Phonon back-end for GStreamer when its actually the case that many in major distributions (like Red Hat), it's the only media framework that's shipped (for patents reasons mostly) and that therefore, if you wanted KDE/Phonon to be distributed there, you just had no choice.
Also, to be honest, when reading your original post, I read it the exact same way that Christian did (that you think that Phonon was good even for non-Qt apps).. So its clearly not a strawman, but more like a case of unclear blogging.
Finally, you're argument about arts/gstreamer can also be applied to Phonon, if Phonon fails (or is canned or something), then you'll also have to re-write your applications.
@Tester: "that you did us (the GStreamer people) a favour when doing a Phonon back-end for GStreamer"
you have an interesting viewpoint on the value of 3rd party developers.
imho, every time someone uses a framework, they are adding value to it and validating it.
"when its actually the case that many in major distributions (like Red Hat), it's the only media framework that's shipped (for patents reasons mostly) and that therefore, if you wanted KDE/Phonon to be distributed there, you just had no choice."
did Red Hat's choices stop us when we used aRts?
providing a gstreamer backend was indeed a good and pragmatic choice, at least as pragmatic as most of the other backends in fact. nobody is arguing that, especially not me.
but let's be honest here: there are very, very few APIs in this world that one *must* use in the way you suggest about gstreamer. outside of some glaring examples (mostly on closely held and proprietary platforms like Windows) there are choices to be had.
your viewpoint of gstreamer's position in the world is vastly overinflated.
"I read it the exact same way that Christian did [...] So its clearly not a strawman, but more like a case of unclear blogging."
let's give you (and Chris above you there) the benefit of the doubt on this one.
it still doesn't explain or excuse the other strawmen that were erected in Christian's blog entry that i addressed. nor does it explain or excuse his evident lack of understanding of the difference between aRts and Phonon as technologies.
"if Phonon fails (or is canned or something), then you'll also have to re-write your applications."
let's try to clarify by using an analogy here:
we have $1000 to invest. while we want that money to grow over time, we happen to be more interested in making sure the $1000 doesn't become $0 (which would spell disaster for us in this scenario) than we are in turning that $1000 into $2000 overnight.
we can invest in publicly traded stocks or gold. which should we choose?
history shows us that publicly traded stocks are far more likely to hit $0 due to becoming highly devalued after a corporate failure than it is for the bottom to drop out of the gold market and gold to suddenly become worthless. history also shows that gold tends to become worth more over time.
therefore with our risk-to-expectations profile we will put our money into gold.
now lets bring it back to media APIs.
history has shown that media frameworks come and go over time. i don't think we can argue with that.
history has also shown that what 99%+ of applications want to *do* with media frameworks doesn't change all that much over time: play me a sound, play this song, pipe me this music stream, show this video with syncronized audio, apply this affect to that bit of media as it plays, etc...
the changes in media apps have generally been in the delivery mechanisms (internet streaming and purchasing mp3s were two such changes), the user interaction layers and the actual codecs used.
iow, the API that *applications* have needed hasn't changed in a radical fashion, while the media frameworks themselves have.
so in this case, you're suggesting something akin to the value of gold becoming zero and therefore we should all go invest all our money in stocks, preferably publicly traded banks because they have been so amazingly stable this past 25 years, right?
a good investment advisor always takes into consideration the risk/expectations profile of the client.
to take the analogy further, some people do put their money in stock (most investors do a blended portfolio, of course, but.. yeah.. ) and some of those people do just GREAT.
moreover, the value of gold can be affected by the valuations in the stock market.
likewise, for some people using gstreamer directly would be a fine choice.
for others, and that happens to include 99%+ of KDE applications, it makes more sense to rely on something more stable and historically less likely to falter.
btw, one main reason Phonon is almost guaranteed not to falter is that it isn't a media system. we in KDE and Qt Software have all the required expertise to maintain something like Phonon, and we are fairly certain we can rely on ourselves when it comes to APIs like this. we've been doing it for 15+ years in Qt, after all.
Phonon has the flexibility underneath to adapt as necessary, and we have the expertise to do it.
if gstreamer takes over the whole world, we're still 100% fine.
if gstreamer fails miserably in 5 years time (and i'm not saying it will; right now it looks really good on Linux), we're still 100% fine.
if some target system out there (and they exist already, by the millions) don't have gstreamer on them, we're still 100% fine.
and if i *personally* had to choose between, say, DirectShow9 or Quicktime and using gstreamer from Phonon i'd pick gstreamer.
it has nothing to do with not liking gstreamer, having some reason to expect it to fail.
it has everything to do with being able to trust in the value of gold. er. an API such as Phonon.
As much as I agree with you on Phonon being the best solution for most Qt programs, I don't see how this discussion is getting anywhere. Couldn't you (all) try to find out what you can agree on and what you can't agree on and then decide whether to continue arguing about these issues or agree to disagree?
As far as my understanding goes, it went like this: Lennart blogged about Linux audio systems and you felt that Phonon wasn't presented fairly, so you replied with a post showing the advantages of Phonon. Other people understood that you wanted to say that Phonon was the best solution for most programs (not only Qt ones) and couldn't agree due to disadvantages like Qt dependency and more restrictive licensing (GPL).
So can everyone agree on Phonon being a great solution for Qt programs, as it provides an easy, high-level and familiar API and provides flexibility by not relying on a single audio subsystem? And that it has some limitations when it comes to more advanced features, in which case a lower-level API like GStreamer is to be used? And that for programming non-Qt applications it is probably best to follow the guide by Lennart?
So the only point some people still disagree is, as far as I can see, if GStreamer should be used directly by Qt developers or only via Phonon.
I suggest to try to reduce the debate on the points you really want to argue about. Discussions can go on endlessly if everyone picks out arguments of the other person and tries to prove them wrong. I don't want to lecture anyone, I just hope all the energy spent on this discussion could be used in a more constructive way.
And please do know that all your work, be it on Phonon or GStreamer or any other part of the Free Software stack, is appreciated by a lot of people (including me).
I am really sad to see such discussion between key developers of the free desktop, this is an example of how hard to make more cooperation between kde and gnome, I really can't understand why there is such hostility between different projects ?
I don't get what all this arguing is about. It seems dead simple to me.
If you're writing an application using Qt, and your multimedia needs are relatively simple, use Phonon.
If you're not using Qt, or want to do more complex stuff media stuff, use GStreamer.
Can't we all just agree on that?
i am a simple KDE user who prefer KDE apps and i dont get all this phonon gstreamer thing ..most KDE audio/video players (atleast the ones i know and use)defaults to using mplayer and xine and they appear to work well for me ..why dont we hear about these other backends? what do they feel about phonon?
..i am currently running kde4 svn and my back end is xine .. as far as i know there are three audio/video backends in linux, mplayer, xine and gstreamer ..
where is this bickering btw phonon and gstreamer coming from? how come we dont see it coming from mplayer or xine? ..what is so special about gstreamer that causes all this bickering?
@Tester:
> when its actually the case that many in major distributions (like Red Hat), it's the only media framework that's shipped (for patents reasons mostly)
We have been shipping a version of xine-lib without the patent-encumbered plugins in Fedora for a while. (Those plugins can easily be added from a third-party repository without having to replace or recompile xine-lib. Xine-lib has a plugin architecture just like GStreamer.) Xine-lib is also included in EPEL, so it's also available for RHEL users. In addition, we (Fedora) also ship aRts (for the legacy KDE 3 apps), as does RHEL (where KDE 3 is still the default until the upcoming RHEL 6).
> and that therefore, if you wanted KDE/Phonon to be distributed there, you just had no choice.
We've had Phonon in Fedora before it even had a GStreamer backend, and to this day we still default to the xine-lib backend because Phonon's GStreamer backend handles device selection in a weird way which causes trouble with PulseAudio. (But the plan is to make the GStreamer backend the default once that's sorted out.)
As for RHEL, I'm sure the xine-lib packages from Fedora or EPEL (they're mostly the same) can and will be pulled in if they're needed. GStreamer is the preferred media framework in Fedora and RHEL, but not the only one.
Am I totally wrong here or has an important feature of Phonon been left out of the story (perhaps I'm making it up or the feature hasn't been implemented):
I thought Phonon had the ability also to try more than one back-end, so if your default couldn't play a particular file it could see whether you have anything else that would.
While I'm really on your side and see why you are frustrated I do think that you could be a bit more generous to Chritian et. al. It may have been out of order to suggest that Phonon was irrelevant outside KDE but I don't think he was intentionally misrepresenting you.
Reminds me of something you blogged about (I think it was you) some time ago: The difference between what people write and what they would say face-to-face. I think it would be great if somehow the appropriate people from the two camps could get together for an informal conference on desktop audio architecture. (Nokia: d'you fancy investing in peace and interoperability).
A big plus also to your point: just listen to what the developers whao have used phonon say: mostly "It only takes a few lines of code to add media functionality" and the users, at least me "it just works"
I am not a developer or studied the Phonon.
But as far I have found in time when the Phonon and Gstreamer has be in media...
The Phonon IS better for Qt apps.
As far I know (I can be totally wrong here!), the Phonon is just like a "HAL" between the application and the multiple different hardware/soundservices.
So when you make the Qt application, you are designing it for multiple platform.
If I would make the Qt application what use video/audio etc, I would be sure I use Phonon so I could get them work easily on multiple OS's like on Windows NT, Linux and Mac OS X.
The Gstreamer is like aRts... you just tie yourself to one technology, while if you tie yourself to Phonon, you can use multiple without problems.
So all what I see here, is the problems comes about reading the Aarons posts, not the technology what the Phonon is.
My main problem having layer over layer over layer (phonon->gstreamer->alsa) is the following:
- top layer must catter to the least common denominator
- if the top level layer do not support the feature you want (and you discover that late in the development process) you're screwed and must use the more featureful lower layer
- multiplication of potential bugs over the layers
- error handling (which usually is tricky to get right) must traverse every layer and there some signifiant chance some of it get lost.
And at least on win and mac there's a dplication of functionality betwen phonon and gstreamer as both are able to talk to the native audio stack.
@fliegenderfrosch and morphado
I don't think this kind of debate is about fighting or finding something to agree on. It is about helpinh each other to refine their position, pointing out ambiguous phrasing or factual errors.
Additionally it introduces observers to new information which might be obvious if one follows the development of either side quite closely but might have been hidden for someone not doing that.
For example it was pretty new to me that GStreamer nowadays has API and ABI stability comittment for a time frame comparable to KDE4's life cycle.
This whole discussion is imo a waste of energy, it's a pity that some people still think in the way of "us and them", I see the OpenSource comunity as team.
I think the targets are generally the same, only the way to reach that target may differ some times and that's good. We all can learn something by different approaches to solve problems.
@Aaron though I agree on what you posted on Phonon I do not agree on the gold part.
Gold is by far not stable and per se winning value over time. [1] This myth is allways repeated -- not saying that you do -- than the economy has problems. Yes it's unlikely that gold will lose all of its value, but same goes for shares if you are careful -- something these bankes weren't -- and handle the risk but not hide it.
Stocks aren't per se risky, it depends on what stocks you buy. Looking at the facts (figures) buying stocks from these now bankcrupt bankes wouldn't have been clever anyways and imo would have been speculating.
Same would go for buying Ford shares --> look at its equity rate and compare that with BWM, VW etc, a real bad equity rate would be my no-go criteria. Before I'd buy anything I'd look up the figures (balance sheet, financial ration ...) of the company, its ratings, what they plan for the future etc.
I see shares as a long time investment -- that's what shares have been invented for -- and not as something I sell the next day.
[1] http://de.wikipedia.org/w/index.php?title=Bild:Historical_price_of_gold.png&filetimestamp=20080329222603
This argument is very indicative of the "us vs them" mentality.
Just some examples
"Of course, if you think that GStreamer is installed or even works everywhere, you are vastly deluded. I know many Linux users for whom GStreamer simply doesn't work."
You could have just as many people if not more who cannot get Phonon to work. What's your point? Hardware compatibility and software issues have always been iffy with Linux - even X.Org has been problematic for people, I wouldn't expect a sound system to work flawlessly. This is quite an irrelevant point and doesn't put either Gstreamer or Phonon on better ground, though if I had to make a guess, Gstreamer, on account of being an older technology and being used by more projects than just Gnome apps, should be more mature than the recent Phonon.
"Phonon works in those situations as well. Today. Without us writing any new code."
I wouldn't say it with such certainty as of yet. GNOME technologies in general are far more mature and stable due to their development cycle - if Phonon is anything like the other KDE4 components, than you are just trying to sell off an unfinished software as completely working and the better solution. No matter what preferance of your desktop environment is, Gnome is certainly far more stable and reliable solution at this point in time.
On the argument itself, you have no idea what a strawmen argument is, and yet you accuse Christian of using on throughout the post. It is debatable whether it was a misunderstanding on his part or not (though I certainly don't want to get into that, since your entire argument rests on your statement having a semicolon which does nothing to alter the meaning of the statement or Christian's understand of it) - a strawman argument is that in which a person deliberately tries to steer the argument into another direction by using an irrelevant or unrelated point. None of the examples you give show it, by any degree of the imagination. To put it in simpler terms, a misunderstanding =/= attempt to deliberately derail the argument.
Lastly, as a user I would expect the leader of a project that tries to promote itself as caring for the community and fostering healthy relationships for open-source development to be more mature, well-versed in conversation and above semantics and the "us vs them" mentality. I have been sorely dissapointed.
The utter crap they talk about wastes every one's time, it doesn't help between gnome & kde and I just don't see the value of all this fuss. If it was a perfect place freedesktop would create a multimedia framework / soundsytem to suit everybodies needs. Phonon fills that gap, but what I personally look forward to is the vlc backend which should theoretically be able to play anything. Can gstreamer do that, well it's a lot of fuss for the average user, and to be honest giving the users flexibility and not boasting which framework is the best is more important.
Keep up the great work Aaron and the phonon guys - there's nothing you need to defend yourself over.
Hi,
Just to say that in fairness to Christian, I also misread your comment "Phonon is also more than just an option for Qt apps: you'd be making a huge mistake not to use it."
I understood that you were saying that it was not only an option for Qt apps, and that any application developer would be making a mistake not to use it.
Reparse the sentence as "Phonon is more than simply an option if you're building a Qt app: it is the best audio framework available in that case, and it would be a mistake not to use it" and suddenly your entire post reads better.
Cheers,
Dave.
I don't want to continue this whole argument further, but there are some points I feel must be addressed. Warning: this is kinda meta.
1. Colons, semi-colons, and periods DO affect the meaning of sentences. If you don't believe punctuation makes a difference, just read the introduction to "Eats, Shoots & Leaves".
2. Reading only half a sentence, or even a full sentence out of context does not guarantee proper comprehension. You must read the full article carefully, not just one phrase, to make sure you understand properly. This is true of any language.
3. The whole argument would be over by now, but people keep grasping at straws, which are obviously untrue. Eg. the idea that phonon is basically the same as aRts.
4. A straw man argument does not require *intentional* misrepresentation. If you read the wikipedia article on it, this is clear. Under the heading "Reasoning", point 2.2 perfectly describes the (perhaps unintentional) misquote out of context by Christan.
Finally, the moral of the story is:
DO YOUR RESEARCH BEFORE CRITICIZING ANYTHING!
@shaloob
I don't think you understand what Phonon is. It took me about 2 minutes to understand what it does knowing nothing about it, you should do a little research before you start talking about hardware compatibility and gstreamer being more mature and therefore a better choice.
Phonon isn't a multimedia framework. Its just a very thin API so you can use any multimedia framework you want. Its stupid to compare it to GStreamer.
It would be like comparing TCP/IP to ethernet. Comparing two technologies at different levels in the stack makes no sense.
I think it's valid to debate if adding another layer to the multimedia stack is a good idea, Personally I think so.
On the point of the misunderstood sentence. I also misread it as a native speaker.
Regards
Jared Kells
He Aaron,
There really is no need for you to go there :-)
With the excellent KDE4 release, just let the code do the talking.
Jord
I'm afraid Christian is just spinning because GStreamer has not gained the traction that he hoped that it might. Trying to paint GSteamer as cross-platform so you don't have to worry about Linux multimedia, Microsoft's Direct stuff or Quicktime on Mac OS is just downright bizarre. GStreamer is not cross-platform by any stretch of the imagination. He just seems to have got worried about Phonon as an option for cross-platform multimedia.
I just don't see what is so difficult to get about Phonon, and I find it difficult to understand that intelligent people don't get the benefits of an abstraction layer for KDE and Qt here. It's probably a good idea for other applications to have such a layer, but that's up to them:
1. It is not a multimedia stack Christian, so relax. It doesn't compete with GStreamer.
2. Abstracting audio and multimedia away for Qt and KDE applications is entirely sensible, and is probably what other non-Qt applications should do as well:
a) The Linux and open source multimedia landscape is littered with train wrecks, and GStreamer is shaping up to be another one. Tying all KDE applications to it is not a fantastic idea.
b) Phonon can be used by Qt and KDE applications on different platforms. GStreamer is not cross-platform.
c) Accessing multimedia functionality for Qt applications can be done through some nice looking and universally usable Qt classes that act like any others. A KDE or Qt application developer does not have to know about GStreamer's API or the API of any other multimedia framework.
d) Oh, and all the desktop multimedia code goes into one place and is simply reused. In the past, applications duplicated an awful lot of code between them.
"The Linux and open source multimedia landscape is littered with train wrecks, and GStreamer is shaping up to be another one"
I hope your wrong because it does show the most promise. It's been around for 12 years now and has more support than ever its just a pitty its still crap (from my experience (bizzarre Green quadrangles down the right of the screen - some audio/video synching issues but that is almost completely resolved)) - VLC seems to be the best to me (9 year old project)...
"GStreamer is not cross-platform"
I think it is - it can already use DirectShow codecs on Windows and Quicktime codecs on Mac and it compiles and works on Windows and Mac so that's quite cross platform.
"I'm afraid Christian is just spinning because GStreamer has not gained the traction that he hoped that it might"
I'd say your right, I can't think of any other reason, but I do see his thought train because GStreamer does show so much promise and a little faith above a meritocracy is the only way new frameworks will ever up the par.
Infact thinking rationally with no bias, I do just want to press play and watch my movie etc and trusting that my distro picks the most sensible option at the time of release to do so then Phonon FTW.
Slight correct GStreamer is almost 10 years old and VLC is almost 8 years old.
Agh, mis-interpretation. Its bound to occur on the intermanets. I agree that Aaron's sentence could be read two ways, but I also agree with Aaron's rebuttal of the further mis-interpretations that Christian made about Phonon.
I think Aaron has done well to explain where the problems lie with Christians interpretation of Phonon.
Some people are saying that the 'bickering should stop' and that we should get back to the coding. While I agree that confrontation isn't pleasant and should be a last resort - I do believe that we can't let falsehoods spread just because we don't want to upset anyone. So kudos to Aaron for taking the time to correct a mis-interpretation of Phonon.
Now, lets code. =D
Two words, XINE BACKEND... a lot less trouble...
Dear Aaron, misunderstanding is not the same as using a strawman argument. You admit that christian might have misunderstood what you said, but accuse him of using a strawman argument nontheless. You dont assume good intention and you are hurting the cause with this childish behavior. Please act to your age. Thank you.
@heintje and the others saying "it's a misinterpretation!":
even if Christian got that one point wrong, it doesn't excuse all the other strawmen he erected which i covered in this entry.
Christian took exception to something and then ran with it adding dubious point after dubious point. completely unnecessary.
if you're going to produce a public commentary in the course of a conversation that is swaying public opinion, you'd really better be triple sure you've got it right before lambasting someone.
if there a possibility of ambiguity, phrase your objection in terms of a question to allow the other side to offer clarification if they wish. that way you don't come off sounding poorly when it turns out you just ranted and raved for no good reason.
were it simply a conversation between he and i, i would've just shaken my head and moved on. being part of the public discourse, it was something that needed to be addressed.
you get what you give.
I hope your wrong because it does show the most promise. It's been around for 12 years now and has more support than ever its just a pitty its still crap
GStreamer really should be past showing promise.
I'm afraid when you consider how long it has been around, it's problematic reliability on Linux, nevermind other platforms, and other frameworks such as Xine have actually matured into reliable systems with less manpower pumped into them then you have to start calling a duck a duck really.
Even beyond that, Linux and open source multimedia still has problems that GStreamer hasn't begun to solve.
Post a Comment