From kde-multimedia Mon Sep 06 02:20:47 2004 From: Scott Wheeler Date: Mon, 06 Sep 2004 02:20:47 +0000 To: kde-multimedia Subject: summary of the aKademy meetings Message-Id: <200409060420.47150.wheeler () kde ! org> X-MARC-Message: https://marc.info/?l=kde-multimedia&m=109443725713883 Ok, so here goes something of a summary from the various KDE Multimedia activities and a basic description of what's going on in make_it_cool. Those that were involved are encouraged to provide corrections / more details. Also I wanted to run this by some other people first, but I'll be heading out for vacation in a few days and wanted to get this rolling before I disappear for three weeks. Apologies for any inaccuracies. Our largest meeting was on Sunday night when there were 16 multimedia people at dinner together counting 2 from NMM, 1 from MAS and two from GStreamer / Fluendo. This made for the largest group of KDE multimedia developers ever in one place. I'll see if I can get the names out (just listing primary projects -- don't get upset that it isn't comprehensive): Matthias Kretz (aRts) Allan Sandfeld Jensen (aKode) Scott Wheeler (JuK) Helio Castro (KMix) Christian Esken (KMix) Christian Muehlhaeuser (amaroK) Mark Kretschmann (amaroK) Max Howell (amaroK) Tim Jansen (GStreamer bindings) ...and well, there were 11 KDE people, but there were at least a couple not doing MM stuff, but then I'm probably forgetting someone too -- sorry -- couldn't find a photo... Matthais, Allan and I talked a lot informally about some of the structures and also later in the week the three of us plus Max and Chris from amaroK got together with Leon from MAS to discuss its relevance to KDE. Ok, down to the details of what we're planning on for KDE 4. All of this is subject to change of course, but these details represent the concensus as it stood (and most of this is pasted from a mail that I ran by several people during the conference): *) We'll have a simple, abstract player interface that can handle audio or video and is not tied to a specific backend. This interface will support most of the common cases that application developers need. *) Because such an interface was needed anyway and there was very little overhead required to make it plugable, well, it is. (There was some previous discussion of configuring this earlier on the list.) *) Packagers or system administrators will be able to change the backend based on their specific needs. *) GStreamer will be the default backend as it at the moment best addresses the problem set that we're dealing with. It looks like we'll also have aRts, NMM, aKode (direct output) and possible MAS plugins as well (more on MAS later). *) At some point there will most likely be a (not particularly strong) recommendation for a default sound server; however as the abstraction at that layer will be handled by the backends this doesn't presently have a significant influence on our development so we're not in much of a hurry to make such a decision. *) There's some discussion on whether or not to have a recommended lower level API for applications that need such. It's not clear if this will happen or not. We also talked a lot with Leon about MAS. Leon is naturally very interested in seeing MAS as an option for our default media framework. At the moment there's a pretty huge gap between what it provides and what we need; we talked a lot with him about what those requirements are and I believe he's subscribed to this list now, so ideally he'll keep us posted on how things unfold there. At the moment it however only solves the more low level problems and leaves things like demuxing [en/trans/de]coding, largely unimplemented, so it's mostly in the hands of the MAS developers as to whether or not it's a contender to NMM and GStreamer for us. NMM also had a very impressive show of their technology at aKademy and based on currently implemented features is the only contender to GStreamer. However there was a concensus between the KDE folks that at this point GStreamer is more mature and as such a better default for KDE 4. However there were a number of people interested in following NMM more closely in the future and tracking its progress and helping it build up a more traditional OSS community and mature as a project towards something that may be a suitable default for KDE in the future. So, what's going on in make_it_cool. There's a basic API in kdelibs/kdemm that outlines three abstractions. I'll omit the details of the APIs (you can read that yourselves) but try to give a general overview: *) Backend - handles creating channels and players - manages a list of channels - reports on supported mimetypes *) Channel - essentially encapsulates a logical group of playable stuff - makes it possible to control the volume of such a group -- i.e. to set the volume for "notifications", "music" or "video" and have all apps using the framework respect this *) Player - basic player controls -- load, play, pause, stop, seek, volume, etc. - has a subclass, VideoPlayer that creates a QWidget for displaying video - outputs through a specific channel These classes are implemented through concrete backends currently in kdemultimedia/kdemmbackends. One of these will be moved to kdelibs for KDE 4. JuK also has already been ported to use these backends when appropriate files are updated to the make_it_cool branch and can be used for testing the backends at the moment. Well, I think that's about it. I've tried to keep my opinions out of this as much as possible (and hopefully succeeded); I'd appreciate if corrections could be distinguished from general responses. Cheers, -Scott _______________________________________________ kde-multimedia mailing list kde-multimedia@kde.org https://mail.kde.org/mailman/listinfo/kde-multimedia