Easier?
|
| Author | Content |
|---|---|
| swbrown Feb 06, 2007 10:59 PM EDT |
How does adding Yet Another API to the mix make multimedia easier? Can't folks just standardize on a highly active project like GStreamer and patch the hell out of it to make it work for all cases rather than add to the confusion? |
| herzeleid Feb 07, 2007 8:09 AM EDT |
(shrug) a quick read tells me that what they are doing is not so much "adding another api to the mix", as standardizing on one. |
| swbrown Feb 07, 2007 9:53 PM EDT |
They're adding another API - it's a meta-API that then covers other APIs. Kinda like GStreamer and Xine, but at another level up. And of course, the API is Qt-style guaranteeing it will never be a standard adopted by everyone, so the API proliferation continues. If people could just standardize on one of them and improve it for all cases, we'd have a solution rather than a repeat of the sound server era. |
| Sander_Marechal Feb 07, 2007 10:09 PM EDT |
The API does make sense. Instead of having to set A/V configurations for each applications you can do it once for all of KDE. It also makes application development easier. For example, instead of totem GUI + totem-gstreamer + totem-xine you would just have totem. But it would be better of Gnome, KDE and Xfce had collaborated on one standard API for this. |
| jimf Feb 07, 2007 10:12 PM EDT |
> better of Gnome, KDE and Xfce had collaborated Dream on :D |
| swbrown Feb 07, 2007 10:29 PM EDT |
> The API does make sense. Instead of having to set A/V configurations for each applications you can do it once for all of KDE. But now your A/V configurations will be different for KDE, GNOME, etc. apps. If they standardized at a lower level rather than proliferating APIs, you could configure it once for everything. That was the whole point of GStreamer (which also works on non-Linux systems like Windows, standalone, etc.). There's no reason they couldn't have contributed whatever features they needed to an existing project. You'd think they'd not want to repeat the past with another aRts, but here we are: a duplicate API in a language that can't be common to all projects that has heavyweight requirements and isn't portable. Great.. |
| swbrown Feb 07, 2007 10:33 PM EDT |
As another example of useless API proliferation being done at the wrong level, look at GNOME/KDE/etc.'s 'virtual filesystem' setups. VFS for GNOME, IOSlaves for KDE, etc.. This should be implemented at a much lower level. It's now almost possible to implement this at the kernel level so that /everything/ on the system can benefit from the functionality rather than just a specific higher level desktop and related apps. All it takes is FUSE and the multiple filesystem namespace work going on in the kernel atm (so you can have user mountpoints that are only visible to that specific user) to make the user-visible 'virtual filesystems' /actual/ filesystems you can access with any program. 'tar filesystems', 'ssh filesystems', 'vorbis CD ripping filesystems' etc. can all be implemented at the very lowest level of the OS so everyone can use them with any program. |
| Sander_Marechal Feb 08, 2007 4:35 AM EDT |
True, but that has little to do with this new KDE API. KDE cannot fold it into gstreamer. They have nothing to fold in. Gstreamer's main competition are Xine and VLC. If you want a single API exposed to the desktop then you need to lay an API on top of those three. That's what KDE *can* do. After that it's making sure that Xine and VLC functionality gets into Gstreamer. This is something KDE cannot do. Other people will have to. When they succeeded and Gstreamer emerges as the defacto standard, KDE's additional API will have become superfluous and can be removed again. The alternative is for KDE to do nothing and have each application deal separately with the three major A/V API's. |
| swbrown Feb 08, 2007 5:39 AM EDT |
> KDE cannot fold it into gstreamer. They have nothing to fold in. Phonon is not implemented as just a side-API that provides additional KDE functionality/state, it wraps the other APIs at a higher level. That's the problem, why it's controversial, and why it's API proliferation. So, e.g., if a specific app, a game for example, was using Phonon which was using GStreamer and wanted to set GStreamer source parameters for modplug to skip to a pattern, you're out of luck - your app can't do it as that level is abstracted out of its reach. If you want to do it, you have to tunnel a new path through the Phonon API so it can be implemented between any Phonon backend. That kind of implementation obviously leads to a /lot/ of duplication of APIs, as when people need a lower level feature, they wind up duplicating the API as they tunnel it through the higher level API for all backends. > If you want a single API exposed to the desktop then you need to lay an API on top of those three No, you can standardize on one and make it work for all cases rather than leaving the mess that is GNU/Linux multimedia as-is, or making it worse. There's nothing wrong with collaborating. > When they succeeded and Gstreamer emerges as the defacto standard, KDE's additional API will have become superfluous and can be removed again. It took a decade to weed OSS + sound servers out of applications despite people making that same statement. Let's not repeat that. |
| Sander_Marechal Feb 08, 2007 7:02 AM EDT |
Quoting:If you want to do it, you have to tunnel a new path through the Phonon API so it can be implemented between any Phonon backend. That kind of implementation obviously leads to a /lot/ of duplication of APIs, as when people need a lower level feature, they wind up duplicating the API as they tunnel it through the higher level API for all backends. That's just dumb programming. If your app needs access to such lower lever features, don't use a higher level API that won't let you. In your example, the game should have been programmed with the Gstreamer API, not the Phonon API. If you want to do something about the API proliferation, promote Gstreamer to the exclusion of Xine and VLC. Develop elements that implements Xine and VLC's unique features in Gstreamer and fix bugs. Don't blame KDE for trying to hide the proliferation from it's users. |
| swbrown Feb 08, 2007 7:31 AM EDT |
> That's just dumb programming. If your app needs access to such lower lever features, don't use a higher level API that won't let you. In your example, the game should have been programmed with the Gstreamer API, not the Phonon API. And there you go. Rather than using GStreamer as both the high and low level API, which it's perfectly good at doing, you now have Phonon which is usable only as a high level API in a specific language and heavyweight application scenario. API proliferation. > If you want to do something about the API proliferation, promote Gstreamer to the exclusion of Xine and VLC. Been doing that for a while. :) (Btw, VLC isn't really competing for this space) I was a ways into replacing mikmod's mixer with ALSA's approach to improve its handling of tracked formats (I love scenemusic) when they shifted to modplug making it obsolete - I'd like to see about getting the modplug backend into 'good' and maybe write a plugin for sc68 but my new system has an X-Fi card which apparently can't even play basic stereo as Creative are being pricks about specs. Since it's a Dell system, there's no fallback on the motherboard, either (Dell removes anything they see as 'redundant'). :P So, I'm temporarily shut down on the sound front. > Don't blame KDE for trying to hide the proliferation from it's users. I do blame KDE. They should be working with the GStreamer folks instead of adding to the confusion by creating a duplicate and half-assed API. |
| swbrown Feb 08, 2007 7:45 AM EDT |
Btw, just as an aside, here's a great tune to test support of tracked formats - Jeroen Tel's Stranglehold. It's all sine waves (so you definitely will hear any degradation) and is a really good workout (BASS/XMPlay's author uses it as proof of superiority of his code): [url=http://www.variadic.org/music/Jeroen Tel/jt_strng.xm]http://www.variadic.org/music/Jeroen Tel/jt_strng.xm[/url] - Mikmod: Pops and crackles (mixer crossover) - Modplug: Severe low volume (mixer degradation), slight ringing - VLC (uses Modplug): Can't configure surround, etc. - BASS/XMPlay (non-free, Windows): Beautiful Modplug is really close - if any of y'all are good at the mathy side of CS, consider this a plea to the heavens. :) I'm much more architect-side. |
Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]
Becoming a member of LXer is easy and free. Join Us!