summary of the aKademy meetings

[Scott Wheeler]

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