Posted by: Anonymous Coward
on May 09, 2006 10:56 PM
A very nice article. Well written, and full of information. Well done<nobr> <wbr></nobr>:-)
Here some thoughts I had while I was reading the article: Some people complain that it is dubbling of effort to write Phonon and that it would make sense to integrate gstreamer directly since it *is* the de facto standard at the moment and could also emerge into a Linux standard.
The knowledge which is missing in these cases (and I miss in the article a bit also) is that there has to be an API for KDE even if gstreamer would be integrated as the only solution: KDE developers are used to KDE APIs, and gstreamer has nothing similar, so even with gstreamer KDE would have Phonon. And together with the history of aRts and the fact that gstreamer is nice, but still far away from perfect and that the competitors of gstreamer are quite strong also, it just makes sense to expand the API to adopt more than one backend.
And about 80-20 - if you write a professional application you normally try to access the underlying framework as close as possible - like gstreamer, helix or even direct ALSA, etc. And in these case you also need the framework - imagine a helix based program in a non-flexible gstreamer environment. That would be bad. In KDE 4 you could just switch Phonon to the helix backend, and everything, your normal apps plus the high professional app, is working with helix. There would be no need to start both multimedia frameworks.
Learn about Linux
Download Linux
Get Linux help
Nice article! Something to add:
Posted by: Anonymous Coward on May 09, 2006 10:56 PMHere some thoughts I had while I was reading the article:
Some people complain that it is dubbling of effort to write Phonon and that it would make sense to integrate gstreamer directly since it *is* the de facto standard at the moment and could also emerge into a Linux standard.
The knowledge which is missing in these cases (and I miss in the article a bit also) is that there has to be an API for KDE even if gstreamer would be integrated as the only solution:
KDE developers are used to KDE APIs, and gstreamer has nothing similar, so even with gstreamer KDE would have Phonon.
And together with the history of aRts and the fact that gstreamer is nice, but still far away from perfect and that the competitors of gstreamer are quite strong also, it just makes sense to expand the API to adopt more than one backend.
And about 80-20 - if you write a professional application you normally try to access the underlying framework as close as possible - like gstreamer, helix or even direct ALSA, etc. And in these case you also need the framework - imagine a helix based program in a non-flexible gstreamer environment. That would be bad. In KDE 4 you could just switch Phonon to the helix backend, and everything, your normal apps plus the high professional app, is working with helix. There would be no need to start both multimedia frameworks.
#