start media stream type classification framework

src/common/p.hpp

@@ -63,7 +63,7 @@ namespace lumiera
    * std::tr1::shared_ptr, but forwarding type relationships and
    * ordering operators to the pointee objects.
    * @param TAR the visible pointee type
-   * @param the shared-ptr type used as implementation
+   * @param BASE the shared-ptr type used as implementation
    * @note if the BASE smart-ptr type used as implementation
    *       implies another pointer type than the one used on
    *       the interface (=type TAR), then every access to the 

src/common/streamtype.cpp

@@ -0,0 +1,33 @@
+/*
+  StreamType  -  classification of media stream types 
+ 
+  Copyright (C)         Lumiera.org
+    2008,               Hermann Vosseler <Ichthyostega@web.de>
+ 
+  This program is free software; you can redistribute it and/or
+  modify it under the terms of the GNU General Public License as
+  published by the Free Software Foundation; either version 2 of the
+  License, or (at your option) any later version.
+ 
+  This program is distributed in the hope that it will be useful,
+  but WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  GNU General Public License for more details.
+ 
+  You should have received a copy of the GNU General Public License
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ 
+* *****************************************************/
+
+
+#include "common/streamtype.hpp"
+
+
+namespace lumiera
+  {
+
+   /** */
+  
+
+} // namespace lumiera

src/common/streamtype.hpp

@@ -0,0 +1,99 @@
+/*
+  STREAMTYPE.hpp  -  classification of media stream types 
+ 
+  Copyright (C)         Lumiera.org
+    2008,               Hermann Vosseler <Ichthyostega@web.de>
+ 
+  This program is free software; you can redistribute it and/or
+  modify it under the terms of the GNU General Public License as
+  published by the Free Software Foundation; either version 2 of the
+  License, or (at your option) any later version.
+ 
+  This program is distributed in the hope that it will be useful,
+  but WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  GNU General Public License for more details.
+ 
+  You should have received a copy of the GNU General Public License
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ 
+*/
+
+
+#ifndef LUMIERA_STREAMTYPE_HPP
+#define LUMIERA_STREAMTYPE_HPP
+
+
+#include "common/query.hpp"
+
+#include <boost/noncopyable.hpp>
+
+
+namespace lumiera
+  {
+
+
+  /**
+   * 
+   */
+  struct StreamType : boost::noncopyable
+    {
+      enum MediaKind
+        {
+          VIDEO,
+          IMMAGE,
+          AUDIO,
+          MIDI
+        };
+      
+      enum Usage
+        {
+          RAW,
+          SOURCE,
+          TARGET,
+          INTERMEDIARY
+        };
+      
+      struct Prototype;
+      
+      class ImplFacade;
+      
+      
+      MediaKind kind;
+      Prototype const& prototype;
+      ImplFacade * implType;
+      Usage usageTag;
+      
+    };
+  
+  
+  
+  /**
+   * 
+   */
+  struct StreamType::Prototype
+    {
+      Symbol id;
+      
+      bool subsumes (Prototype const& other)  const;
+      bool canConvert (Prototype const& other)  const;
+    };
+  
+  
+  
+  /**
+   * 
+   */
+  class StreamType::ImplFacade
+    {
+    public:
+      Symbol libraryID;
+      
+    };
+    
+  
+
+   
+} // namespace lumiera
+#endif

src/proc/asset/struct.hpp

@@ -74,7 +74,7 @@ namespace asset
     
   /**
    * key abstraction: structural asset
-   * @todo just a stub, have to figure out what a asset::Proc is
+   * @todo just a stub, have to figure out what a asset::Struct is
    */
   class Struct : public Asset
     {

src/proc/engine/procnode.hpp

@@ -61,7 +61,7 @@ namespace engine {
   typedef ProcNode* PNode;
   
   template<class E>
-  struct RefArray
+  struct RefArray    ///< @todo need an implementation and then probably move it into library
     {
       virtual E const& operator[] (uint i)  const =0;
       virtual ~RefArray() {}

src/proc/stypemanager.cpp

@@ -0,0 +1,33 @@
+/*
+  STypeManager  -  entry point for dealing with media stream types
+ 
+  Copyright (C)         Lumiera.org
+    2008,               Hermann Vosseler <Ichthyostega@web.de>
+ 
+  This program is free software; you can redistribute it and/or
+  modify it under the terms of the GNU General Public License as
+  published by the Free Software Foundation; either version 2 of the
+  License, or (at your option) any later version.
+ 
+  This program is distributed in the hope that it will be useful,
+  but WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  GNU General Public License for more details.
+ 
+  You should have received a copy of the GNU General Public License
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ 
+* *****************************************************/
+
+
+#include "proc/stypemanager.hpp"
+
+namespace proc_interface
+  {
+  
+  /** */
+  
+  
+  
+} // namespace proc_interface

src/proc/stypemanager.hpp

@@ -0,0 +1,50 @@
+/*
+  STYPEMANAGER.hpp  -  entry point for dealing with media stream types
+ 
+  Copyright (C)         Lumiera.org
+    2008,               Hermann Vosseler <Ichthyostega@web.de>
+ 
+  This program is free software; you can redistribute it and/or
+  modify it under the terms of the GNU General Public License as
+  published by the Free Software Foundation; either version 2 of the
+  License, or (at your option) any later version.
+ 
+  This program is distributed in the hope that it will be useful,
+  but WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  GNU General Public License for more details.
+ 
+  You should have received a copy of the GNU General Public License
+  along with this program; if not, write to the Free Software
+  Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ 
+*/
+
+
+#ifndef PROC_INTERFACE_STATE_H
+#define PROC_INTERFACE_STATE_H
+
+
+#include "common/streamtype.hpp"
+
+
+
+namespace proc_interface {
+  
+  using lumiera::Symbol;
+  
+  
+  class STypeManager
+    {
+    protected:
+      virtual ~STypeManager() {};
+      
+      
+    public:
+      lumiera::StreamType const& getType (Symbol sTypeID) ;
+    };
+  
+  
+  
+} // namespace proc_interface
+#endif

wiki/renderengine.html

@@ -3310,22 +3310,23 @@ if (oldText.indexOf("SplashScreen")==-1)
 * in a future version, it may also encapsulate the communication in a distributed render farm
 </pre>
 </div>
-<div title="StreamPrototype" modifier="Ichthyostega" modified="200808152103" created="200808152042" tags="def spec" changecount="7">
+<div title="StreamPrototype" modifier="Ichthyostega" modified="200809120021" created="200808152042" tags="def spec" changecount="10">
 <pre>The stream Prototype is part of the specification of a media stream's type. It is a semantic (or problem domain oriented) concept and should be distinguished from the actual implementation type of the media stream. The latter is provided by an [[library implementation|StreamTypeImplFacade]]. While there are some common predefined prototypes, mostly, they are defined within the concrete [[Session]] according to the user's needs. 
 
-Prototypes form an open (extensible) collection, though each prototype belongs to a specific media kind ({{{VIDEO, IMAGE, AUDIO, MIDI,...}}}). The ''distinguishing property'' of a stream prototype is that any [[Pipe]] can process //streams of a specific prototype only.// Thus, two streams with different prototype can be considered &quot;something quite different&quot; from the users point of view, while two streams belonging to the same prototype can be considered equivalent (and will be converted automatically when their implementation types differ). Note this definition is //deliberately fuzzy,// because it depends on the actual situation of the project in question.
+Prototypes form an open (extensible) collection, though each prototype belongs to a specific media kind ({{{VIDEO, IMAGE, AUDIO, MIDI,...}}}).
+The ''distinguishing property'' of a stream prototype is that any [[Pipe]] can process //streams of a specific prototype only.// Thus, two streams with different prototype can be considered &quot;something quite different&quot; from the users point of view, while two streams belonging to the same prototype can be considered equivalent (and will be converted automatically when their implementation types differ). Note this definition is //deliberately fuzzy,// because it depends on the actual situation of the project in question.
 
 Consequently, as we can't get away with an fixed Enum of all stream prototypes, the implementation must rely on a query interface. The intention is to provide a basic set of rules for deciding queries about the most common stream prototypes; besides, a specific session may inject additional rules or utilize a completely different knowledge base. Thus, for a given StreamTypeDescriptor specifying a prototype
 * we can get a [[default|DefaultsManagement]] implementation type
 * we can get a default prototype to a given implementation type by a similar query
-* we can query if a implementation type in question can be //subsumed// under this prototype
+* we can query if a implementation type in question can be //subsumed// by this prototype
 * we can determine if another prototype is //convertible//
 
 !!Examples
-NTSC and PAL video, video versus digitized film, HD video versus SD video, 3D versus flat video, cinemascope versus 4:3, stereophonic versus monaural, periphonic versus panoramic sound, Ambisonics versus 5.1, dolby versus dts,...
+NTSC and PAL video, video versus digitized film, HD video versus SD video, 3D versus flat video, cinemascope versus 4:3, stereophonic versus monaural, periphonic versus panoramic sound, Ambisonics versus 5.1, dolby versus linear PCM...
 </pre>
 </div>
-<div title="StreamType" modifier="Ichthyostega" modified="200808152026" created="200808060244" tags="spec discuss draft" changecount="4">
+<div title="StreamType" modifier="Ichthyostega" modified="200809112341" created="200808060244" tags="spec discuss draft" changecount="7">
 <pre>//how to classify and describe media streams//
 Media data is understood to appear structured as stream(s) over time. While there may be an inherent internal structuring, at a given perspective ''any stream is a unit and homogeneous''. In the context of digital media data processing, streams are always ''quantized'', which means they appear as a temporal sequence of data chunks called ''frames''.
 
@@ -3347,8 +3348,8 @@ A stream type is denoted by a StreamTypeID, which is an identifier, acting as an
 !! Classification
 Within the Proc-Layer, media streams are treated largely in a similar manner. But, looking closer, note everything can be connected together, while on the other hand there may be some classes of media streams which can be considered //equivalent// in most respects. Thus, it seems reasonable to separate the distinction between various media streams into several levels
 * Each media belongs to a fundamental ''kind'' of media, examples being __Video__, __Image__, __Audio__, __MIDI__,... Media streams of different kind can be considered somewhat &quot;completely separate&quot; &amp;mdash; just the handling of each of those media kinds follows a common //generic pattern// augmented with specialisations. Basically, it is //impossible to connect// media streams of different kind. Under some circumstances there may be the possibility of a //transformation// though. For example, a still image can be incorporated into video, sound may be visualized, MIDI may control a sound synthesizer.
-* Below the level of distinct kinds of media streams, within every kind we have an open ended collection of ''prototypes'', which, when compared directly may each be quite distinct and different, but which may be //rendered//&amp;nbsp; into each other. For example, we have stereoscopic (3D) video and we have the common flat video lacking depth information, we have several spatial audio systems (Ambisonics, Wave Field Synthesis), we have panorama simulating sound systems (5.1, 7.1,...), we have common stereophonic and monaural audio. It is considered important to retain some openness and configurability within this level of distinction, which means this classification should better be done by rules then by setting up a fixed property table. For example, it may be desirable for some production to distinguish between digitized film and video NTSC and PAL, while in another production everything is just &quot;video&quot; and can be converted mostly automatically. The most noticeable consequence of such a distinction is that any Bus or [[Pipe]] is always limited to a media stream of a single prototype. (&amp;rarr; [[more|StreamPrototype]])
-* Besides the distinction by prototypes, there are the various media ''implementation types''. This classification is not necessarily hierarchically related to the prototype classification, while in practice commonly there will be some sort of dependency. For example, both stereophonic and monaural audio may be implemented as 96kHz 24bit PCM with just a different number of channel streams, as well as we may have a dedicated stereo audio stream with two channels multiplexed into a single stream. For dealing with media streams of various implementation type, we need library routines, which also yield a type classification system. Most notably, for raw sound and video data we use the GAVL library, which defines a classification system for buffers and streams.
+* Below the level of distinct kinds of media streams, within every kind we have an open ended collection of ''prototypes'', which, when compared directly may each be quite distinct and different, but which may be //rendered//&amp;nbsp; into each other. For example, we have stereoscopic (3D) video and we have the common flat video lacking depth information, we have several spatial audio systems (Ambisonics, Wave Field Synthesis), we have panorama simulating sound systems (5.1, 7.1,...), we have common stereophonic and monaural audio. It is considered important to retain some openness and configurability within this level of distinction, which means this classification should better be done by rules then by setting up a fixed property table. For example, it may be desirable for some production to distinguish between digitized film and video NTSC and PAL, while in another production everything is just &quot;video&quot; and can be converted automatically. The most noticeable consequence of such a distinction is that any Bus or [[Pipe]] is always limited to a media stream of a single prototype. (&amp;rarr; [[more|StreamPrototype]])
+* Besides the distinction by prototypes, there are the various media ''implementation types''. This classification is not necessarily hierarchically related to the prototype classification, while in practice commonly there will be some sort of dependency. For example, both stereophonic and monaural audio may be implemented as 96kHz 24bit PCM with just a different number of channel streams, as well we may have a dedicated stereo audio stream with two channels multiplexed into a single stream. For dealing with media streams of various implementation type, we need //library// routines, which also yield a //type classification system.// Most notably, for raw sound and video data we use the GAVL library, which defines a classification system for buffers and streams.
 * Besides the type classification detailed thus far, we introduce an ''intention tag''. This is a synthetic classification owned by Lumiera and used for internal wiring decisions. Currently (8/08), we recognize the following intention tags: __Source__, __Raw__, __Intermediary__ and __Target__. Only media streams tagged as __Raw__ can be processed.
 
 !! Media handling requirements involving stream type classification