-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Sami Kallinen schrieb:
hi all,
a few questions and thoughts re cin3, (partially already answered):
Hi Sami,
I'll pick just some of the topics you mentioned; Richard gave already
some answers to other issues
first off: as far as i can see in terms of f(l)oss we have only
playback, 3d and compression pretty well covered at the moment. with
cin3 the ambition is to also cover nles. but that still leaves pro
level
grading and compositing not available to my knowledge. would cin3
architecture be a good base for developing such solutions? either
inside
cin3 or as standalone using the same backend/rendering engine? could
imagine such solutions might need different kind of emphasis,
although
hope not.
since the ambition is to build a professional app, will the
architecture
allow for following features down the line:
One of my primary goals to get the architecture open enough to be able
to handle such advanced / pro stuff. Which sometimes means not to
settle
down at seemingly "obvious" things. My favorate example is "come on,
a clip has simply a video stream and a stereo or mono audio".
That's wrong, for example I am a big fan of stereoscopy, and 3D video
has 2 video tracks which need to be treated in conjunction. Or you may
want to add an overdubbed dialogue track to the existing camera sound.
Not a real problem if the core is prepared for such right from start,
but a major hassle if you try to implement it after the fact by some
macro hackery.
So for most of the following points my answer is for now:
"basically yes,
we want to be prepared, but specifically no, as long as no one
cares to
work out the specific details to handle it..."
1. selectable precision in processing, including floating point
for both
in RGB and YUV (or Y'CrCb)?
as far as i understood from cehteh this should not be a problem
yes, agreed
4. eventual support for professional and other output devices such as
bmg design etc for calibrated monitoring or output purposes? this is
crucial for any proper workflow:
- cehteh said that no plans currently for these, but the plug in
architecture will allow such to be implemented later.
I'll add the following here. I want to utilized a rule based system
for handling configuration. When building the render nodes network,
the Proc-Layer (middle layer) issues queries, e.g. "need a default
input chain for a media file with stream type XYZ". The result will
be a "processing pattern" which is simply a sequence of effects/nodes
to be added at the source end, e.g. a demuxer, a decoder and a
"camera"
node (doing some scaling or cropping).
The effect of such an approach is that much of the complexity and
know-how is separated from the actual low-level processing and form
the organisation of the core. Rather, this sort of setup will be
contained in the rule base.
Back to your question: you would have to
- - add the necessary color correction nodes
- - augment the rules to add these nodes either at the source and
or the output end (or both). These rules could trigger on
specific tags which the user would need to add to his media
assets...
5. multiple format timelines working seamlessly?
We don't want to have a single "global format", if that's what
your question is about. We don't want the whole session to "run
with 25fps". Rather you could pull 25fps output from a session.
This will cause the processing pipelines to pull data with this
frame rate too, until some way down in the pipeline we hit a point
where we need to map or quantize a destination (output) source
window (=1/25sec) onto an existing grid of source frames (e.g.
a 30fps source).
playback without rendering (while editing).
Up to now we didn't distinguish between playback and rendering.
But we'll have different quality settings.
If you want any sort of output, you'll have to pull it from
some processing pipe. But this doesn't mean it has to be calculated
every time, because we want to build a very elaborated cache into
the backend. And you could use low res proxy footage for normal
playback while editing, and the full res source for a final render.
I say "you could" -- meaning that all these details need to be
worked out, and we need people helping with this....
7. flexbility regarding framerates, pulldowns and cadences to another
and back? solutions for working on projects that have mixed sources?
(this is mostly an issue for ntsc country people but not
exclusively).
see above.
For building the node network, I plan to have "connection requests".
At this point, the Builder will issue a configuration query (see
above)
to find out if he can make the connection and what transformation
nodes
he needs to insert.
Again, lots and lots of details just pushed out of the builder and
into the confguration rules.
8. distributed processing?
- (just double checking, isnt this a working feature already?)
The current Cinelerra-2 codebase implements a "render farm".
The general understanding is that we will keep/implement such a
feature
too, but no one cared to plan any details for now.
9. precise and user friendly time remap, optical flow manipulation
possibilities in all directions on specific portions of an open
timeline
without messing the rest. could also be necessary for filters that do
format conversions.
Excuse me, I don't understand what you mean her. Could you explain?
10. multiclip editing?
Handling any sort of compound and multichannel media is an important
objective. In the design and implementation I started for the Proc-
Layer
I treat every clip as possibly a compound of several different media
and multiple streams. I deliberately don't use "video tracks" and
"audio tracks" as the current Cinelerra has.
I didn't plan to use special multichannel clips. Rather every clip
* can contain multichannel audio
* can contain additional audio tracks
* supports stereoscopic (3D) video
* could supports additional view angles (multi camera setups)
* could carry additional MIDI data (if we implement handling of
MIDI data)
It's just a question how the underlying media asset is configured
The usual example being:
You start to edit footage of a dialogue scene.
Later on there is work done on the soundtrack, e.g. dubbing
or you add a spot miked track /after/ you already started editing.
-You add such additional tracks to the underlying media assets
-then you are immediately able to use the additional tracks in
all clips that are already in the timeline
To actually handle this complexity, the core feature in my design
(and started implementation) of the Proc-Layer are the "Placements".
This is the point where I put together the objects (having various
kinds of objects in the timeline) and the rule based approach:
Each object is "put" into the timeline by a Placement object, which
internally maintains a chain of conditions describing how this object
has to be placed. This is a very open concept, because "to place"
can mean various different things:
- put it on a specific track
- anchor it at a fixed, absolute time position
- anchor it relative to another object (clip, label,....)
- anchor it relative to a fixed position within the source material
of another clip (e.g. good old clapperboard for sound sync)
- place it on a fixed output layer
- place it on a layer relative to the layer of another clip (e.g.
"above clip Y")
- place it at a fixed sound pan position
- "place" (rather plug) it into some output bus.
Advanced Ideas (for later):
- a patterned placement which places clones of the basic object
controlled
by an fractal pattern...
Every "media object" is controlled and placed by this placement
system,
including clips, effects, transitions, automation data sets, lables,
even whole tracks. Any placement can provide "excess information"
or overconstrain the position. That's not a problem, because only
the information needed is used.
When building, the Placement of an object is queried for the basic
properties: temporal position, output port, pan, layer.
The placement queries down the chain of internal conditions to find a
solution. I plan to query into the context too, which means
especially,
if the local Placement can't resolve some property, the track is
queried,
than the parent track, and so on, and finally the defaults manager is
queried.
Well, that's my planning. I have implemented the basic Placement
framework,
but all of this querying, resolution and all details of Placement
handling
still need to be targeted.
i realise that most and hopefully all of these are
solvable/implementable and/or (non?)issues for later but wanted to
raise
them now to be sure as i many of them to be critical future features.
Sami, many thanks for bringing up all those issues. It's the right
time
to care to have the necessary flexibility. I consider all of the
points
in your list as being relevant for a professional application...
cheers,
Hermann V.
(aka Ichthyo)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFHt70tZbZrB6HelLIRAorRAKCK9ebqDVgiVInDhtnzDv/hYFXdvQCdGdeR
j2rk5DoSz7SRi9Ze+R9ZD5s=
=Z92H
-----END PGP SIGNATURE-----
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
