-----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
