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

start planning towards how to describe the type of frames and buffers

Browse source
This commit is contained in:
Fischlurch 2008-08-06 05:29:29 +02:00
parent c0d7ae1aa2
commit 8803d86e27
1 changed files with 29 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
wiki/renderengine.html
View file

@ -1279,7 +1279,7 @@ For this Lumiera design, we could consider making GOP just another raw media dat
→see in [[Wikipedia|http://en.wikipedia.org/wiki/Group_of_pictures]]
</pre>
</div>
<div title="ImplementationDetails" modifier="Ichthyostega" modified="200804070244" created="200708080322" tags="overview" changecount="22">
<div title="ImplementationDetails" modifier="Ichthyostega" modified="200808060229" created="200708080322" tags="overview" changecount="25">
<pre>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 Lumiera Renderengine, the Builder and the related parts.
* [[Packages, Interfaces and Namespaces|InterfaceNamespaces]]
@ -1296,6 +1296,8 @@ For this Lumiera design, we could consider making GOP just another raw media dat
* [[integrating the Config Query system|ConfigQueryIntegration]]
* [[identifying the basic Builder operations|BasicBuildingOperations]] and [[planning the Implementation|PlanningNodeCreatorTool]]
* [[how to handle »attached placement«|AttachedPlacementProblem]]
* working out the [[basic building situations|BuilderPrimitives]] and [[mechanics of rendering|RenderMechanics]]
* how to classify and [[describe media stream types|StreamTypeDescr]]
</pre>
</div>
<div title="ImplementationGuidelines" modifier="Ichthyostega" modified="200711210542" created="200711210531" tags="discuss draft" changecount="7">
@ -3066,6 +3068,32 @@ if (oldText.indexOf(&quot;SplashScreen&quot;)==-1)
* moreover, it contains methods to communicate with other state relevant parts of the system, thereby shielding the rendering code from any complexities of Thread communication if necessary. (thus the name Proxy)
</pre>
</div>
<div title="StreamTypeDescr" modifier="Ichthyostega" modified="200808060322" created="200808060244" tags="spec discuss draft" changecount="3">
<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''.
! Terminology
* __Media__ is comprised of a set of streams or channels
* __Stream__ denotes a homogeneous flow of media data of a single kind
* __Channel__ denotes a elementary stream, which can't be further separated in the given context
* all of these are delivered and processed in a smallest unit called __Frame__. Each frame corresponds to a //time interval.//
* a __Buffer__ is a data structure capable of holding a Frame of media data.
* the __~Stream-Type__ describes the kind of media data contained in the stream
! Problem of Stream Type Description
Media types vary largely and exhibit a large number of different properties, which can't be subsumed under a single classification scheme. But on the other hand, we want to deal with media objects in a uniform and generic manner, because on the large all kinds of media behave somewhat similar. The problem is, these similarities disappear when describing media with logical precision. Thus we are forced into specialized handling and operations for each kind of media, while we want to implement a generic handling concept.
! Handling Stream Type Description
!! Identification
A stream type is denoted by a ~StreamID, which is an identifier, acting as an unique key for accessing information related to the stream type.
!! Requirements
* set up a buffer and be able to create/retrieve frames of media data.
* determine if sources and sinks for media data can be connected, and how.
* determine and enumerate the internal structure of a stream.
* discover processing facilities
</pre>
</div>
<div title="StrongSeparation" modifier="MichaelPloujnikov" modified="200706271504" created="200706220452" tags="design" changecount="5">
<pre>This design lays great emphasis on separating all those components and subsystems, which are considered not to have a //natural link// of their underlying concepts. This often means putting some additional constraints on the implementation, so basically we need to rely on the actual implementation to live up to this goal. In many cases it may seem to be more natural to &quot;just access the necessary information&quot;. But on the long run this coupling of not-directly related components makes the whole codebase monolithic and introduces lots of //accidental complexity.//