From 737da9c8687ad93fb00ffeecea7ca0a1426c4667 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Tue, 4 Sep 2007 05:09:08 +0200 Subject: [PATCH] continued wishful thinking in Test form --- src/proc/assetmanager.hpp | 1 - .../components/proc/asset/createassettest.cpp | 56 +++++++++++++++++++ uml/cinelerra3/128133 | 2 +- uml/cinelerra3/130309.diagram | 2 +- uml/cinelerra3/5.session | 9 ++- wiki/renderengine.html | 54 +++++++++++++++--- 6 files changed, 110 insertions(+), 14 deletions(-) diff --git a/src/proc/assetmanager.hpp b/src/proc/assetmanager.hpp index b85113bbb..f63f90e0d 100644 --- a/src/proc/assetmanager.hpp +++ b/src/proc/assetmanager.hpp @@ -40,7 +40,6 @@ namespace proc_interface */ class AssetManager { - int bla; public: /** registers an asset object in the internal DB, providing its unique key */ diff --git a/tests/components/proc/asset/createassettest.cpp b/tests/components/proc/asset/createassettest.cpp index 2fab0a9d3..d08589821 100644 --- a/tests/components/proc/asset/createassettest.cpp +++ b/tests/components/proc/asset/createassettest.cpp @@ -25,6 +25,9 @@ //#include "common/factory.hpp" //#include "common/util.hpp" +#include "proc/assetmanager.hpp" +#include "proc/asset/media.hpp" + //#include #include @@ -49,7 +52,60 @@ namespace asset { virtual void run(Arg arg) { + createMedia(); } + + void createMedia() + { + Category cat(VIDEO,"bin1"); + Asset::Ident key("Name-1", cat, "ichthyo", 5); + P mm1 = asset::Media::create(key,"testfile.mov"); + P mm2 = asset::Media::create(key); + P mm3 = asset::Media::create("testfile2.mov",Category::VIDEO); + + // Assets have been registered and can be retrieved by ID + ASSERT (AssetManager::getAsset (mm1.id) == mm1); + ASSERT (AssetManager::getAsset (mm2.id) == mm2); + ASSERT (AssetManager::getAsset (mm3.id) == mm3); + + ASSERT (AssetManager::getAsset (mm1.id) != mm2); + + PAsset aa1 = AssetManager::getAsset (mm1.id); + ASSERT (aa1 == mm1); + P mX1 = AssetManager::getAsset (mm1.id, Category::VIDEO); + ASSERT (mX1 == mm1); + ASSERT (mX1 == aa1); + try + { // can't be found if the Category is wrong.... + AssetManager::getAsset (mm1.id, Category::AUDIO); + NOTREACHED; + } + catch (cinelerra::error::Invalid) { } + + + // checking the Ident-Fields + ASSERT (mm1->ident.name == "Name-1"); + ASSERT (mm2->ident.name == "Name-1"); + ASSERT (mm3->ident.name == "testfile2"); + + ASSERT (cat == Category (VIDEO,"bin1")); + ASSERT (mm1->ident.category == Category (VIDEO,"bin1")); + ASSERT (mm2->ident.category == Category (VIDEO,"bin1")); + ASSERT (mm3->ident.category == Category (VIDEO,"")); + + ASSERT (mm1->ident.org == "ichthyo"); + ASSERT (mm2->ident.org == "ichthyo"); + ASSERT (mm3->ident.org == "cin3"); + + ASSERT (mm1->ident.version == 5); + ASSERT (mm2->ident.version == 5); + ASSERT (mm3->ident.version == 1); + + ASSERT (mm1->getFilename() == "testfile.mov"); + ASSERT (isnil (mm2.getFilename()); + ASSERT (mm3->getFilename() == "testfile2.mov"); + + } }; diff --git a/uml/cinelerra3/128133 b/uml/cinelerra3/128133 index b457bbab8..8a0a4ec3b 100644 --- a/uml/cinelerra3/128133 +++ b/uml/cinelerra3/128133 @@ -1,6 +1,6 @@ format 40 "AssetManager" // ProcessingLayer::AssetManager - revision 4 + revision 5 modified_by 5 "hiv" // class settings //class diagram settings diff --git a/uml/cinelerra3/130309.diagram b/uml/cinelerra3/130309.diagram index d1300390d..3979c49c4 100644 --- a/uml/cinelerra3/130309.diagram +++ b/uml/cinelerra3/130309.diagram @@ -6,7 +6,7 @@ classcanvas 128005 class_ref 136453 // Asset end classcanvas 128133 class_ref 136581 // AssetManager draw_all_relations default hide_attributes default hide_operations default show_members_full_definition default show_members_visibility default show_members_stereotype default show_parameter_dir default show_parameter_name default package_name_in_tab default class_drawing_mode class drawing_language default show_context_mode default auto_label_position default show_infonote default shadow default - xyz 289 26 2000 + xyz 289 26 2005 end packagecanvas 128517 package_ref 128133 // AssetManager diff --git a/uml/cinelerra3/5.session b/uml/cinelerra3/5.session index b106f468a..f33ed26db 100644 --- a/uml/cinelerra3/5.session +++ b/uml/cinelerra3/5.session @@ -1,14 +1,19 @@ window_sizes 1140 783 270 860 584 120 diagrams active classdiagram_ref 130309 // Asset Kinds - 860 584 100 4 0 0 + 860 584 100 4 60 0 end show_stereotypes selected package_ref 129 // cinelerra3 open + deploymentview_ref 128517 // gen + deploymentview_ref 128645 // gen + deploymentview_ref 128773 // gen + deploymentview_ref 128901 // gen + deploymentview_ref 129029 // gen -package_ref 128005 // design +package_ref 130309 // engine class_ref 136453 // Asset class_ref 136581 // AssetManager class_ref 136709 // Media diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 224f4c324..67e3684f6 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -514,12 +514,13 @@ ColorPalette SiteUrl -
+
Asset management is a subsystem on its own. Assets are "things" that can be loaded into a session, like Media, Clips, Effects, Transitions. It is the "bookkeeping view", while the EDL is the "manipulation and process view". Some Assets can be //loaded// and a collection of Assets is saved with eatch Session. Besides, there is a collection of basic Assets allways available by default.
 
-The Assets are important reference points holding the information needed to access external resources. For example, an Clip asset can reference a Media asset, which in turn holds the external filename from which to get the media stream. For Effects, the situatin is similar. Assets thus serve two quite distinct purposes. One is to load, list, group serarch and browse them, and to provide an entry point to create new or get at existing MObjects in the EDL, while the other purpose is to provide attribute and property informations to the inner parts of the engine, while at the same time isolating and decoupling them from environmental details. 
+The Assets are important reference points holding the information needed to access external resources. For example, an Clip asset can reference a Media asset, which in turn holds the external filename from which to get the media stream. For Effects, the situation is similar. Assets thus serve two quite distinct purposes. One is to load, list, group search and browse them, and to provide an entry point to create new or get at existing MObjects in the EDL, while the other purpose is to provide attribute and property informations to the inner parts of the engine, while at the same time isolating and decoupling them from environmental details. 
 
 We can distinguish several different Kinds of Assets, each one with specific properties. While all these Kinds of Assets implement the basic Asset interface, they themselfs are the __key abstractions__ of the asset management view. Mostly, their interfaces will be used directly, because they are quite different in behaviour. Thus it is common to see asset related operations being templated on the Asset Kind. 
+→ see also [[Creating and registering Assets|AssetCreation]]
 [img[Asset Classess|uml/fig130309.png]]
 
 !Media Asset
@@ -547,9 +548,16 @@ Some additional, virtual facilities created in the course of the editing process
 → MetaAsset {{red{to be defined}}}
 
 !!!!still to be worked out..
-is how to implement the relationship between [[MObject]]s and Assets. Do we use direct pointers, or do we prefer an ID + central registry approach? And how to handle the removal of an Asset (→ see also [[analysis of mem management|ManagementAssetRelation]])
+is how to implement the relationship between [[MObject]]s and Assets. Do we use direct pointers, or do we prefer an ID + central registry approach? And how to handle the removal of an Asset 
+→ see also [[analysis of mem management|ManagementAssetRelation]]
+→ see also [[Creating Objects|ObjectCreation]], especially [[Assets|AssetCreation]]
+
+
Assets are created by a Factories returning smart pointers; the Asset creation is bound to specific use cases and //only available// for these specific situations. There is no generic Asset Factory.
+
+For every Asset we generate a __Ident tuple__ and a long ID (hash) derived from this Ident tuple. The constructor of the abstract base class {{{Asset}}} takes care of this step and automatically registeres the new Asset object with the AssetManager. Typically, the factory methods for concrete Asset classes provide some shortcuts providing sensible default values for some of the Ident tuple data fields. They may take additional parameters — for example the factory method for creating {{{asset::Media}}} takes a filename (and may at some point in the future aply "magic" based on examination of the file)
+
Automation is treated as a function over time. It is always tied to a specific Parameter (which can thus be variable over the course of the timeline). All details //how// this function is defined are completely abstracted away. The Parameter uses a ParamProvider to get the value for a given Time (point). Typically, this will use linear or bezier interpolation over a set of keyframes internally. Parameters can be configured to have different value ranges and distribution types (on-off, stepped, continuous, bounded)
 
@@ -940,11 +948,13 @@ For this Cinelerra3 design, we could consider making GOP just another raw media
 →see in [[Wikipedia|http://en.wikipedia.org/wiki/Group_of_pictures]]
-
+
This wiki page is the entry point to detail notes covering some technical decisions, details and problems encountered in the course of the implementation of the Cinelerra Renderengine, the Builder and the related parts.
 
 * [[Packages, Interfaces and Namespaces|InterfaceNamespaces]]
 * [[Memory Management Issues|MemoryManagement]]
+* [[Creating and registering Assets|AssetCreation]]
+* [[Creating new Objects|ObjectCreation]]
@@ -1298,8 +1308,8 @@ From experiences with other middle scale projects, I prefer having the test code * {{red{and what else?}}}
-
-
The MObjects Subsystem contains everything related to the [[EDL]] and the various Media Objects placed within it. Examples for [[MObjects|MObject]] being:
+

+
The ~MObjects Subsystem contains everything related to the [[EDL]] and the various Media Objects placed within. It is complemented by the Asset Management (see → [[Asset]]). Examples for [[MObjects|MObject]] being:
 * audio/video clips
 * effects and plugins
 * special facilities like mask and projector
@@ -1377,6 +1387,27 @@ For the case in question this seems to be the ''resource allocation is construct
 And, last but not least, doing all actual allocations is the job of the backend. Exceptions being long-lived objects, like the Session or the EDL, which are created once and don't bear the danger of causing memory pressure. Besides that, the ProcLayer code shouldn't issue "new" and "delete", rather it should use some central [[Factories]] for all allocation and freeing, so we can redirect these calls down to the backend, which may use pooling or special placement allocators or the like. The rationale is, for modern hardware/architectures, care has to be taken with heap allocations, esp. with many small objects and irregular usage patterns.
 

 

+

+
We have to consider carefully how to handle the Creation of new class instances. Because, when done naively, it can defeat all efforts of separating subsystems, or — the other extreme — lead to a //switch-on-typeID//  programming style. We strive at a solution somewhere in the middle by utilizing __Abstract Factories__ on Interface or key abstraction classes, but providing specialized overloads for the different use cases. So in each use case we have to decide if we want to create a representant of some general concept (Interface), or if we have a direct colaboration and thus need the Factory to provide
+a more specific sub-Interface or even a concrete type.
+
+!Object creation use cases
+!![[Assets|Asset]]
+|!Action|>|!creates |
+|loading a media file|asset::Media, asset::Codec| |
+|viewing media|asset::Clip| for the whole Media, if not already existant|
+|mark selection as clip|asset::Clip| doesn't add to EDL|
+|loading Plugin|asset::Effect| usually at program startup|
+|create Session|asset::Track, asset::OutPort| |
+→ [[Creating and registering Assets|AssetCreation]]
+
+!![[MObjects|MObject]]
+|add media to EDL|asset::Clip, session::Clip, FixedPlacement| creating whole-media clip on-the-fly |
+|add Clip|session::Clip, FixedPlacement| |
+|attach Effect|session::Effect, RelativePlacement| |
+|start using Automation|session::Auto, asset::Dataset, RelativePlacement| |
+

+

 

 
Cinelerra2 introduced OpenGL support for rendering previews. I must admit, I am very unhappy with this, because
 * it just supports some hardware
@@ -1392,8 +1423,9 @@ But because I know the opinions on this topc are varying (users tend to be delig
 My proposed aproach is to treat OpenGL as a separate video raw data type, requiring separete and specialized [[Processing Nodes|ProcNode]] for all calculations. Thus the Builder could connect OpenGL nodes if it is possible to cover the whole render path for preview and fall back to the normal ~ProcNodes for all relevant renders
 

 

-

-
[img[Block Diagram|uml/fig128005.png]]
+

+
The Cinelerra-3 Processing Layer is comprised of various subsystems and can be separated into a low-level and a high-level part. At the low-level end is the [[Render Engine|OverviewRenderEngine]] which basically is a network of render nodes cooperating closely with the Backend Layer in order to carry out the actual playback and media transforming calculations. Whereas on the high-level side we find several different [[Media Objects|MObjects]] that can be placed into the [[EDL]], edited and manipulated. This is complemented by the [[Asset Management|Asset]], which is the "bookkeeping view" of all the different "things" within each Session.
+[img[Block Diagram|uml/fig128005.png]]
 

 

 

@@ -2344,7 +2376,7 @@ Instead, we should try to just connect the various subsystems via Interfaces and
 * to shield the rendering code of all complexities of thread communication and synchronization, we use the StateProxy
 

 

-

+

 
/*{{{*/
 /* a contrasting background so I can see where one tiddler ends and the other begins */
 body {
@@ -2509,6 +2541,10 @@ h1,h2,h3,h4,h5,h6 {
 	color: #ff2210;
 	padding: 0px 0.8ex;
 }
+
+.viewer th {
+        background: #91a6af;
+}
 /*}}}*/