benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

brainstorming (continued). MediaImplLib

Browse source 
considering how to snap in the actual implementation
This commit is contained in:
Fischlurch 2008-09-22 06:42:10 +02:00
parent 2885b41895
commit 578178a937
7 changed files with 247 additions and 10 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
src/common/streamtype.hpp
View file

@ -92,11 +92,6 @@ namespace lumiera {
/**
* placeholder definition for the contents of a data buffer
*/
struct DataBuffer { };
/**
* A (more or less) concrete implementation type, wired up
@ -107,6 +102,13 @@ namespace lumiera {
public:
Symbol libraryID;
/** placeholder definition for implementation specific type information */
struct TypeTag { };
/** placeholder definition for the contents of a data buffer */
struct DataBuffer { };
virtual bool operator== (ImplFacade const& other) const =0;
virtual bool operator== (StreamType const& other) const =0;
@ -148,6 +150,8 @@ namespace lumiera {
* Create a new framebuffer of the resutling type */
virtual DataBuffer* createFrame (ImplConstraint const& furtherConstraints) const =0;
//TODO: do we need functions to represent and describe this constraint?
};

58
src/lib/external/libgavl.cpp vendored Normal file
View file

@ -0,0 +1,58 @@
/*
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/lumiera.hpp"
#include "lib/external/libgavl.hpp"
extern "C" {
#include <gavl/gavl.h>
}
namespace lib {
namespace external {
namespace { // implementation internals
}
/**
* Use an type information struct, which actually has to be
* a GAVL frametype (TODO), to wire up an ImplFacade such
* as to deal with GAVL data frames of this type.
* @todo fill in the acutal GAVL frame type
* @todo how to distinguish the audio and the video case?
*/
ImplFacadeGAVL const&
LibGavl::getImplFacade (TypeTag*)
{
TODO ("any chance to verify that the TypeTag actually points to a GAVL frame type descriptor?");
UNIMPLEMENTED ("wire up an impl facade with the correct GAVL lib functions for the data type in question");
}
} // namespace external
} // namespace lib

89
src/lib/external/libgavl.hpp vendored Normal file
View file

@ -0,0 +1,89 @@
/*
LILBGAVL.hpp - facade for integrating the GAVL media handling library
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 LIB_EXTERN_LIBGAVL_H
#define LIB_EXTERN_LIBGAVL_H
#include "proc/control/mediaimpllib.hpp"
namespace lib {
namespace external {
using lumiera::Symbol;
using lumiera::StreamType;
typedef StreamType::ImplFacade ImplFacade;
typedef StreamType::ImplFacade::TypeTag TypeTag;
class LibGavl;
/**
* Concrete media lib implementation facade
* allowing to work with GAVL data frames and types
* in an implementation agnostic way
*/
class ImplFacadeGAVL
: public ImplFacade
{
protected:
ImplFacadeGAVL()
: ImplFacade("GAVL")
{ }
friend class LibGavl;
public:
virtual bool operator== (ImplFacade const& other) const;
virtual bool operator== (StreamType const& other) const;
virtual bool canConvert (ImplFacade const& other) const;
virtual bool canConvert (StreamType const& other) const;
virtual DataBuffer* createFrame () const;
};
class LibGavl
: public control::MediaImplLib
{
protected:
public:
virtual Symbol getLibID() const { return "GAVL"; }
virtual ImplFacadeGAVL const& getImplFacade (TypeTag*);
};
////////////////////////////////////TODO: dafür sorgen, daß sich das beim Systemstart in den control::STypeManger einklinkt!!!!!!!!
} // namespace external
} // namespace lib
#endif

54
src/proc/control/mediaimpllib.hpp Normal file
View file

@ -0,0 +1,54 @@
/*
MEDIAIMPLLIB.hpp - interface providing a facade to an media handling library
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 CONTROL_MEDIAIMPLLIB_H
#define CONTROL_MEDIAIMPLLIB_H
#include "common/streamtype.hpp"
namespace control {
using lumiera::Symbol;
class MediaImplLib
{
protected:
virtual ~MediaImplLib() {};
typedef lumiera::StreamType::ImplFacade ImplFacade;
typedef lumiera::StreamType::ImplFacade::TypeTag TypeTag;
typedef lumiera::StreamType::ImplFacade::DataBuffer DataBuffer;
public:
virtual Symbol getLibID() const =0;
virtual ImplFacade const& getImplFacade (TypeTag*) =0;
};
} // namespace control
#endif

3
src/proc/control/stypemanager.hpp
View file

@ -42,6 +42,9 @@ namespace control {
public:
lumiera::StreamType const& getType (Symbol sTypeID) ;
////////////////TODO: Mechanismus erfinden, mit dem sich MediaImplLib-Instanzen einklinken können....
};

2
src/proc/engine/buffhandle.hpp
View file

@ -53,7 +53,7 @@ namespace engine {
*/
struct BuffHandle
{
typedef lumiera::DataBuffer Buff;
typedef lumiera::StreamType::ImplFacade::DataBuffer Buff;
typedef Buff* PBuff;//////TODO define the Buffer type(s)
PBuff

37
wiki/renderengine.html
View file

@ -1320,6 +1320,11 @@ Slider.prototype.stop = function()
}
//}}}</pre>
</div>
<div title="GAVL" modifier="Ichthyostega" created="200809220251" tags="def" changecount="1">
<pre>The ''Gmerlin Audio Video Library''. &amp;rarr; see [[homepage|http://gmerlin.sourceforge.net/gavl.html]]
Used within Lumiera as a foundation for working with raw video and audio media data
</pre>
</div>
<div title="GOPs" modifier="Ichthyostega" modified="200706220333" created="200706220301" tags="def" changecount="2">
<pre>__G__roup __of__ __P__ictures: several compressed video formats don't encode single frames. Normally, such formats are considered mere //delivery formates// but it was one of the key strenghts of Cinelrra from start to be able to do real non linear editing on such formats (like the ~MPEG2-ts unsed in HDV video). The problem of course is that the data backend needs to decode the whole GOP to be serve single raw video frames.
@ -1832,6 +1837,21 @@ __5/2008__: the allocation mechanism can surely be improved later, but for now I
&amp;rarr; see also LoadingMedia
</pre>
</div>
<div title="MediaImplLib" modifier="Ichthyostega" modified="200809220309" created="200809220304" tags="def spec" changecount="2">
<pre>The Proc-Layer is designed such as to avoid unnecessary assumptions regarding the properties of the media data and streams. Thus, for anything which is not completely generic, we rely on an abstract [[type description|StreamTypeDescriptor]], which provides a ''Facade'' to an actual library implementation. This way, the fundamental operations can be invoked, like allocating a buffer to hold media data.
In the context of Lumiera and especially in the Proc-Layer, __media implementation library__ means
* a subsystem which allows to work with media data of a specific kind
* such as to provide the minimal set of operations
** allocating a frame buffer
** describing the type of the data within such a buffer
* and this subsystem or external library has been integrated to be used by Lumiera by writing adaptation code for accessing these basic operations through the [[implementation facade interface|StreamTypeImplFacade]]
* such a link to an type implementation is registered and maintained by the [[stream type manager|STypeManager]]
!Problem of the implementation data types
Because we deliberately won't make any asumptions about the implementation library (besides the ones imposed indirectly by the facade interface), we can't integrate the data types of the library first class into the type system. All we can do is to use marker types and rely on the builder to have checked the compatibility of the actual data beforehand.
</pre>
</div>
<div title="MemoryManagement" modifier="Ichthyostega" modified="200808110208" created="200708100225" tags="impl decision discuss" changecount="14">
<pre>Of course: Cinelerra currently leaks memory and crashes regularilly. For the newly written code, besides retaining the same level of performance, a main goal is to use methods and techniques known to support the writing of quality code. So, besides the MultithreadConsiderations, a solid strategy for managing the ownership of allocated memory blocks is necessary right from start.
@ -3196,6 +3216,9 @@ __see also__
Rendering can be seen as a passive service available to the Backend, which remains in charge what to render and when. Render processes may be running in parallel without any limitations. All of the storage and data management falls into the realm of the Backend. The render nodes themselves are ''completely stateless'' &amp;mdash; if some state is necessary for carrying out the calculations, the backend will provide a //state frame// in addition to the data frames.</pre>
</div>
<div title="STypeManager" modifier="Ichthyostega" created="200809220230" changecount="1">
<pre>A facility allowing the Proc-Layer to work with abstracted [[media stream types|StreamType]], linking (abstract or opaque) [[type tags|StreamTypeDescriptor]] to an [[library|MediaImplLib]], which provides functionality for acutally dealing with data of this media stream type. Thus, the stream type manager is a kind of registry of all the external libraries which can be bridged and accessed by Lumiera (for working with media data, that is). The most basic set of libraries is instelled here automatically at application start, most notably the [[GAVL]] library for working with uncompressed video and audio data. //Later on, when plugins will introduce further external libraries, these need to be registered here too.//</pre>
</div>
<div title="Session" modifier="Ichthyostega" modified="200712100526" created="200712100525" tags="def" changecount="3">
<pre>The Session contains all informations, state and objects to be edited by the User. From a users view, the Session is synonymous to the //current Project//. It can be saved and loaded. The individual Objects within the Session, i.e. Clips, Media, Effects, are contained in one (or several) collections within the Session, which we call [[EDL (Edit Decision List)|EDL]]. &amp;rarr; [[Session design overview|SessionOverview]]
@ -3372,6 +3395,12 @@ Within the Proc-Layer, media streams are treated largely in a similar manner. Bu
<div title="StreamTypeID" modifier="Ichthyostega" created="200808151510" tags="def" changecount="1">
<pre>This ID is an symbolic key linked to a StreamTypeDescriptor. The predicate {{{stream(ID)}}} specifies a media stream with the StreamType as detailed by the corresponding descriptor (which may contain complete or partial data defining the type).</pre>
</div>
<div title="StreamTypeImplConstraint" modifier="Ichthyostega" created="200809220248" tags="def" changecount="1">
<pre>A special kind of media stream [[implementation type|StreamTypeImplFacade]], which is not fully specified. As such, it is supposed there //actually is// an concrete implementation type, while only caring for some part or detail of this implementation to exhibit a specific property. For example, using an type constraint we can express the requirement of the actual implementation of a video stream to be based on RGB-float, or to enforce a fixed frame size in pixels.
An implementation constraint can //stand-in// for a completely specified implementation type (meaning it's a sub interface of the latter). But actually using it in this way may cause a call to the [[defaults manager|DefaultsImplementation]] to fill in any missing information. An example would be to call {{{createFrame()}}} on the type constraint object, which means being able to allocate memory to hold a data frame, with properties in compliance with the given type constraint. Of cousre, then we need to know all the properties of this stream type, which is where the defaults manager is queried. This allows session customisation to kick in, but may fail under certain cicumstances.
</pre>
</div>
<div title="StreamTypeImplFacade" modifier="Ichthyostega" modified="200808151818" created="200808151520" tags="def" changecount="6">
<pre>Common interface for dealing with the implementation of media stream data. From a high level perspective, the various kinds of media ({{{VIDEO, IMAGE, AUDIO, MIDI,...}}}) exhibit similar behaviour, while on the implementation level not even the common classification can be settled down to a complete general and useful scheme. Thus, we need separate library implementations for deailing with the various sorts of media data, all providing at least a set of basic operations:
* set up a buffer
@ -3382,7 +3411,7 @@ Within the Proc-Layer, media streams are treated largely in a similar manner. Bu
&amp;rarr; see also &amp;raquo;[[Stream Type|StreamType]]&amp;laquo;
</pre>
</div>
<div title="StreamTypeUse" modifier="Ichthyostega" modified="200809170107" created="200809130312" tags="draft discuss dynamic" changecount="13">
<div title="StreamTypeUse" modifier="Ichthyostega" modified="200809220249" created="200809130312" tags="draft discuss dynamic" changecount="16">
<pre>Questions regarding the use of StreamType within the Proc-Layer.
* what is the relation between Buffer and Frame?
@ -3414,17 +3443,17 @@ Thus, //constraints may be viewed as type constructing functors.//
* describing the properties of an processor plugin
!! pulling data from a media file
To open the file, we need //type discovery code,// resulting in a handle to some library module for accessing the contents, which is in compliance with the Lumiera application. Thus, we can determine the possible return values of this type discovery code and provide code which wires up a corresponding StreamTypeImpleFacade. Further, the {{{control::STypeManager}}} has the ability to build a complete or partial StreamType from
To open the file, we need //type discovery code,// resulting in a handle to some library module for accessing the contents, which is in compliance with the Lumiera application. Thus, we can determine the possible return values of this type discovery code and provide code which wires up a corresponding StreamTypeImplFacade. Further, the {{{control::STypeManager}}} has the ability to build a complete or partial StreamType from
* an ~ImplFacade
* a Prototype
* maybe even from some generic textual IDs?
* maybe even from some generic textual ~IDs?
!! wiring problems
When deciding if a connection can be made, we can build up the type information starting out from the source. (this requires some work, but it's //possible,// generally speaking.). Thus, we can allways get an ~ImplType for the &quot;lower end&quot; of the connection, and at least a Prototype for the &quot;output side&quot; &amp;mdash; which should be enough to use the query functions provided by the stream type interfaces
!! describing properties
{{red{currently difficult to define}}} as of 9/2008, because the property description of plugins is not planned yet.
My Idea was to use [[type implementation constraints|StreanTyoeImplConstraint]] for this, which are a special kind of ~ImplType
My Idea was to use [[type implementation constraints|StreamTypeImplConstraint]] for this, which are a special kind of ~ImplType
</pre>
</div>
<div title="StrongSeparation" modifier="MichaelPloujnikov" modified="200706271504" created="200706220452" tags="design" changecount="5">