Reply to Media Options for KDE 4

[Marco Lohse]

Hi there,
Tim Jansen just pointed out that there is a discussion about the 
multimedia framework for KDE 4 and asked me to comment on some points 
related to our project called NMM. I will first comment on the questions 
from Neil Stevens

 >NMM (http://www.networkmultimedia.org/):
 >
 >Pro: Audio and Video.  Seems licensed correctly, but I can't tell yet if
 >GPL plugins may be a problem.

I am no expert in the area of licensing, but nearly all our plug-ins are 
distributed under the GPL.

 > Network support.  C++.  Documented.
 >
 >Con:  Non-portable?  Immature.

Unfortunately, I cannot comment on portability, since we only have Linux 
hosts. But NMM is independent of any 'special' libs or low-level 
hardware programming (only some multimedia routines use mmx).

Maturity: Of course, a project like NMM is never 'finished', but since 
we have a strict isolation between interfaces and implementation within 
NMM, applications will not have to be changed (a lot) with new NMM 
versions.


Ok, I will start with a quick introduction and give you some code 
fragments to give you an impression how it feels to program with NMM:

* NMM stands for Network-Integrated Multimedia Middleware
* currently runs under Linux.
* implemented in C++
* base system is distributed under the LGPL
* most of the plug-ins and all applications are distributed under the GPL
* base system has no dependencies on any 'special' libs
* we currently provide about 70 plug-ins, see: 
http://www.networkmultimedia.org/NMM/Status/Plugins/index.html
* we currently maintain 3 applications: the Multimedia-Box ( see: 
http://www.networkmultimedia.org/NMM/Status/MMBox/index.html ), 
qcamcontrol ( for controlling possibly remote firewire cameras ), and 
qregwizard ( for displaying the registries status on a host, see below)

Some more technical facts:
* NMM uses the (well-known) concept of a flow graph:
   - nodes represent fine-grained processing units like file sources, 
displays, audio devices, decoders, mpeg-demultiplexers, ...
   - jacks connect nodes, if the multimedia format associated with the 
jacks 'match'
   - messages flow along the connections. messages are multimedia data 
buffers, or, events (so called in-stream events) to control node behavior
* Synchronisation architecture
* uses pthreads for multi-threading, but other scheduling strategies can 
be easily integrated since every node as a strictly defined state and a 
'run'-method that can be triggered externally.
* NMM provides generic base classes for source, filter, converter, 
demultiplexer, multiplexer, and sink nodes to ease plug-in development
(For instance, graduate students at the Saarland University have 
successfully developed NMM plug-ins and applications with an 1.5 hour 
introduction, see 
http://graphics.cs.uni-sb.de/Courses/ws0102/Multimedia/#Projekt )
* NMM uses an interface definition language (IDL) similar to CORBA IDL.
  IDLs are mapped to interfaces (hpp/cpp) and implementation base 
classes. Intenally, interfaces use events (so called out-of-band events).
* The IDL supports exceptions -> fits into C++

module NMM{
   interface ISourceFileHandler  {
     void setFilename(in string name) raises (FileNotFoundException);
   };
}

* A plug-in programmer simply needs to inherit and implement a wanted 
interface. An application controls nodes via interfaces, which is very 
type-safe and allows 'reflection': you can ask any node for its 
supported interfaces, and every interface for its supported methods.

   class GenericReadNode :
     public GenericSourceNode,  // the node is a source
     public ISourceFileHandlerImpl // and implements this interface
{
    virtual void setFilename(const string& name) throw (const 
FileNotFoundException&) { /* your code */ }
}

* applications 'talk' to nodes via interfaces
     ISourceFileHandler_var file_source 
(readfile->getParentObject()->getCheckedInterface<ISourceFileHandler>());
     file_source->setFilename(files[curr_file_num++]);

* Interfaces allow the application to register as 'listeners' for 
certain events occuring at a node

// readfile is some ISourceFileHandler
readfile->getParentObject()->registerEventListener(ISourceFileHandler::setFilename_event, 
...);

* Although interfaces introduce a small decrease in performance compared 
to a virtual method call, this overhead is not too big: if all 
controlled nodes are within the same address space, a simple pointer 
forwarding is used.
* NMM allows network-transparent control of nodes : remember, nodes are 
controlled via interfaces. nodes on different hosts can be connected to 
a common flow graph.
* We have a networked registry: a server registry runs on each host. you 
can query nodes on any hosts, and instantiate them on any hosts.

     /* Create the 1. request : a GenericReadNode that supports the 
ISourceFileHandler interface */
     NodeDescription request1;
     request1.setNodeName("GenericReadNode");
     request1.addInterface(ISourceFileHandler::ISourceFileHandler_type);

     /* check response and set 1. node */
     list<Response> response1 = registry.initRequest(request1);
     if (response1.empty()) {
       GLOBAL_ERROR_STREAM("Size of response " << response1.size() << endl);
       throw Exception("A required node is not available");
     }
     readfile.reset(registry.requestNode(response1.front()));

* The data flow between two nodes can (in general) use arbitraty 
optimized protocols: pointer forwarding, tcp, udp, rtp, (also MCOP seems 
to be possible)... you can setup and configure these connections (open 
binding)

     CommunicationChannel_var cc(c_connect(mp3dec, audio_play));
     if(cc.get() != 0) {
       cc->setTransportStrategy(cc->getStrategyList().front());
     }

* One big contra: some of the features mentioned above are not available 
in the current release, the next major release 0.2.0 will have all these 
  features (release will be some time after CeBIT, say end of March)

Now that I have written it all down, I see it is a rather long email, I 
hope this is okay....

Have fun,
   Marco.