Ichthyostega
b556d2b770
Some sections of the Lumiera website document meeting minutes, discussion protocols and design proposals from the early days of the project; these pages were initially authored in the »Moin Moin Wiki« operated by Cehteh on pipapo.org at that time; this wiki backed the first publications of the »Cinelerra-3« initiative, which turned into the Lumiera project eventually. Some years later, those pages were transliterated into Asciidoc semi-automatically, resulting in a lot of broken markup and links. This is a long standing maintenance problem problem plaguing the Lumiera website, since those breakages cause a lot of warnings and flood the logs of any linkchecker run.
198 lines
8.9 KiB
Text
198 lines
8.9 KiB
Text
EDL's Are Meta-Clips
|
|
====================
|
|
|
|
[options="autowidth"]
|
|
|====================================
|
|
|*State* | _Final_
|
|
|*Date* | _2008-07-15_
|
|
|*Proposed by* | PercivalTiglao
|
|
|====================================
|
|
|
|
EDLs Are Meta-Clips
|
|
-------------------
|
|
One very useful property of EDLs is the ability to contain other EDLs and to
|
|
__treat these ``inner'' EDLs as an unit__. The most logical implementation of this
|
|
is to have EDLs themselves be able to be treated as an Clip-MObject. Recursion is
|
|
known to be a powerful feature that is relatively simple to understand. By
|
|
making EDLs recursive, some higher level features can be more easily
|
|
implemented by taking advantage of this fact.
|
|
|
|
|
|
Description
|
|
~~~~~~~~~~~
|
|
|
|
There is a class of problems that this sort of behavior would help with.
|
|
|
|
First, you can organize a movie recursively. For example, you can create a
|
|
large movie file and organize it into Introduction, Chapter1, Chapter2, Climax,
|
|
and Conclusion. From there, you can edit Introduction EDL, then the Chapter1
|
|
EDL, and so forth.
|
|
|
|
From a bottom-up perspective, you can build a collection of Stock Footage (for
|
|
example, transformation scenes, lip sync frames, or maybe running joke). You
|
|
can then use the Stock Footage even if it isn't finished, and you can re-edit
|
|
your stock footage later once you have a better idea of what you want. From
|
|
there, the edits in these other files will still be in sync in the final render
|
|
of the big project. Further, each instance of Stock Footage can be personalized
|
|
by added effects on the timeline. Finally, one can create Stock Footage without
|
|
being forced to render the file to disk first.
|
|
|
|
The usability benefits are obvious.
|
|
|
|
In all examples, rendering the main EDL implies that all of the ``inner EDLs''
|
|
have to be re-rendered if the inner EDL was modified. That is one of the only
|
|
requirements.
|
|
|
|
|
|
Tasks
|
|
^^^^^
|
|
* Consider usability issues from the current Cinelerra userbase.
|
|
* Have the EDL Object (or create a proxy class) that extends MObject, Clip,
|
|
AbstractMO, or some other class that would create this kind of behaviour.
|
|
* Consider and Detect infinite recursive cases. ie: File1 contains File2.
|
|
File2 contains File1. This might produce infinite recursion while attempting
|
|
to render the EDL.
|
|
* Implement higher level features in the GUI.
|
|
* Create ``Compound Tracks'' which contain multiple tracks within them.
|
|
* Create a GUI that can handle multiple open EDLs at the same time.
|
|
|
|
|
|
Pros
|
|
^^^^
|
|
* A low level feature that would greatly ease the creation of high level features.
|
|
* Multiple applications.
|
|
* Eases the use and maintenance of Stock Footage.
|
|
|
|
|
|
Cons
|
|
^^^^
|
|
* Possibly would have to rewrite a lot of code at the Engine level??
|
|
* Caching / Efficiency issues arise.
|
|
- Handling multiple instances of Lumiera running might be difficult. E.g.
|
|
File1 contains File2. Both File1 and File2 are open by two different
|
|
processes.
|
|
- Or maybe even multiple instances of Lumiera across computers that are
|
|
connected to the same Drive. File1 is opened in Computer1 and File2 is
|
|
opened in Computer2.
|
|
* A corrupted ``inner EDL'' or Stock Footage would ``poison'' the whole project.
|
|
|
|
|
|
Alternatives
|
|
~~~~~~~~~~~~
|
|
* Pre-Rendering Clips
|
|
- Unlike the current proposal, you would be unable to re-edit sock footage on
|
|
the mass scale and re-apply it to the whole project.
|
|
- Moreover, rendering either introduces a generation loss or requires huge
|
|
storage for raw (uncompressed) video.
|
|
* Loading the resources of the EDL -- This is an alternative way to load EDLs.
|
|
This should also be supported. It would be an expected feature from the old
|
|
Cinelerra-2 user base.
|
|
|
|
|
|
|
|
Comments
|
|
--------
|
|
|
|
I got the inspiration of this idea from an email discussion with _Rick777_
|
|
discussing the Saya Video Editor.
|
|
|
|
PercivalTiglao:: '2008-07-17T13:34:08Z'
|
|
|
|
Hi Percival, thanks for writing this proposal. This is indeed a feature which
|
|
was much discussed in the last months and I consider it to be included almost
|
|
for sure. We always used the term *meta-clip* for this feature, thus I
|
|
edited the headline (I hope you don't mind).
|
|
|
|
Regarding the implementation, I choose a slightly different approach for the
|
|
``proc layer'' (actually, it's not yet there, but planned right from start, as I
|
|
consider this meta-clip feature to be of uttermost importance): I'd prefer to
|
|
add it at the level of the media source which is used by a clip. The
|
|
rationale is, that at the level of the clip, there is no (or almost no)
|
|
different behaviour if a clip pulls from a media file, from an life input or
|
|
from another EDL. Thus, the implementation would be for a meta-clip to use a
|
|
special media asset, which represents the output of the other EDL.
|
|
|
|
Basically, the implementation is quite simple and doesn't necessitate much
|
|
additional code (the power of recursion at work!). Further, I don't see any
|
|
caching or efficiency problems. As you already pointed out, there are two
|
|
fundamental problems
|
|
|
|
- We need a cycle detector when building the low-level model. _But_ we
|
|
don't need it solely because of meta-clips, we also need such a facility
|
|
the moment we allow relatively free wiring of input-output connections
|
|
(which we do plan anyway). My proposal is to flag the respective MObjects
|
|
as erroneous, which should be visualized accordingly in the GUI
|
|
- We need a thoroughly complete handling for multichannel video and audio
|
|
throughout the whole application. We need to get rid of the distinction
|
|
into »video« and »audio« tracks. _But_ again, this is not due to
|
|
meta-clips solely, we should do so anyway because of multichannel spatial
|
|
audio, 3D video and other advanced media to come. Thus, when every media is
|
|
multichannel by default, and the builder can sort and handle connections
|
|
with multiple stream types (which he does, or more correctly, was planned
|
|
to do right from start), putting a meta-clip which pulls output from N
|
|
channels with various mixed stream types from another EDL is not really a
|
|
problem.
|
|
|
|
The other »cons« listed above actually aren't directly connected or due to
|
|
the existence of meta-clips, thus I wouldn't list them here.
|
|
|
|
- yes, it _is_ true, concurrent changes to the session files may screw up things.
|
|
But is this really an issue the Lumiera App should handle at all?
|
|
- yes, _any corrupted part_ of the serialized session can mess up things.
|
|
This is a real threat (see Cinelerra), but not limited to meta-clips. It is
|
|
especially important, as you can expect users to work for months or years
|
|
with a single session. Thus the integrity of the session is a value to be
|
|
protected. That's the rationale why I put up the constraint in the steam
|
|
layer that all important objects can only be created or re-created by some
|
|
specialized factory, which in turn has the responsibility of never creating
|
|
a corrupted object.
|
|
|
|
Ichthyostega:: '2008-07-27T22:15:01Z'
|
|
|
|
I'll think about closures around seralized artifacts, the serialized stream
|
|
can then be validated, unsupported or corrupted parts can be tagged as
|
|
erroneous (means they become virtually readonly but they must be preserved)
|
|
and circumvented. A lot of details have to be worked out here, iirc ichthyo
|
|
already planned support for `erroneous' nodes in the data model. I also think
|
|
about some debuggable plaintext dump format (maybe XML) then real corrupt
|
|
things can be fixed manually with some efforts. Otherwise we handle gigabytes
|
|
of video data and our most valuable resource is the few MB sized session
|
|
file. I really aim to make that as robust as possible. Adding backups and
|
|
redundancy there wont hurt.
|
|
|
|
ct:: '2008-07-30T16:03:04Z'
|
|
|
|
|
|
Conclusion
|
|
----------
|
|
This Design Entry deals with the question whether to include such a feature and
|
|
it discusses the general questions when doing so. Since we are determined to
|
|
include this kind of _meta-clip_ anyway, and will most likely do in a way
|
|
similar as described here, this can be considered __`final'__.
|
|
|
|
This conclusion was drawn at the
|
|
link:{ldoc}/devel/meeting_summary/2008-10-10.html#_edls_as_meta_clips[October.2008 developer meeting].
|
|
|
|
''''
|
|
|
|
[TIP]
|
|
===========
|
|
Terminology is somewhat in flux regarding this topic:
|
|
|
|
- »EDL« is a technical term from the Cinelerra-2 code base. The acronym actually
|
|
stands for **E**dit **D**ecision **L**ist, which is a term from traditional
|
|
film making and production organisation -- and does not really map properly
|
|
into the usage possible with digital technology. For that reason, the Lumiera
|
|
project _dropped_ this notion subsequently.
|
|
- close to the ideas presented in this text is the concept of a ``Sequence'',
|
|
which in Lumiera designates a ``Fork'' (tree of tracks) with an arrangement
|
|
of clips attached.
|
|
- as of 2025, we typically use the following terminology:
|
|
|
|
** a _Virtual Clip_ is how such a nested structure is integrated
|
|
** such a clip in turn uses a _Virtual Medium_
|
|
** which is based on the _Binding_ of a _Nested Sequence_
|
|
===========
|
|
|
|
''''
|
|
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]
|