-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martin Ellison schrieb: > Where should Cinelerra go next? Several comments: > > * the first components to focus on should be > o the renderer -- renders from the Edit Decision List and the > assets to a codec, taking however long it requires > o the previwer -- renders to a screen window, taking at most > 17ms so it can do 60f/s
> Hi all, just filling in some more details... Christian and Herman R. already pointed out core features of "cin3" we plan (and already code). > * the renderer needs to be made up of components that might > o apply an effect frame-by-frame (each frame independently eg > chromakey) > o change the number of frames (eg pulldown) > o combine several clips (transitions, compositing) We want to do the rendering exactly in the same manner as in current Cinelerra: Pull frames from the output side and propagate this pulling down until it reaches some source reader. This subsumes the case of an effect capable of working only synchronous (1 frame in 1 frame out), but is more powerful. > * the edit decision list would then be a graph of component nodes Personally, I concentrate on this part and I don't want to do it exactly this way. Maybe this is because I myself have quite some experiences with editing shorts and even some feature film editing. While the "EDL is a graph of nodes" approach shines when you want to do animations and maybe even compositing work, editing work would be bogged down by doing things this way. Try to imagine to have 40 hours of footage, maybe 50 different scene setups, various sound tracks, and the core of the work consists of deciding and trimming 500 - 800 edits, working against a tough deadline, while being focused on the artistic aspects, storytelling, not imaging or sound or software technology. Because, on the other hand, we are dedicated to use and even extend the "everything is a node" approach, the challenge is to get this manageable. Thus we treat the EDL and the resulting node graph as separate things and build the latter from the former. This is nothing new -- Cinelerra-2 does the same, but there it's buried and tangled deep down in the implementation code, and not made explicit at the "interfaces level". Generally, I think here it isn't necessary to invent something brand new and completely different, it is sufficient to critically question some of the terms we use always the same way (clip, track, channel) and implement them in a somewhat more configurable manner. The "things" within the EDL (clips, effects, transitions, markers) can be seen more like building instructions and rules. To begin with, these will be configured such that the whole system behaves pretty much conventional, i.e. the user sees some "tracks" and places simple clips with 1 video and 1 audio "track". But it should be possible to change these rules on a project/session base. For example, I want it to be possible to setup a project, where the video is 3D (2 channels), maybe even on several screens, sound is handled within an elaborate spatial sound system (Ambisonics or wave field synthesis), while the handling for the editor stays the same: he places some clip like objects within the EDL, just the /way of placement/ has been reconfigured to fit the much more elaborate setup. The editor will tag the material with some additional markers (simple ids defined by convention within the project) and, when building the render nodes graph, the system will do the necessary connections and adjustments semi-automatically. (And btw., this is not K.I. and SciFi, but using existing technology, I did similar things in my work job in financial business context several times in the last years). > > * free/open source projects work by dividing the code base into > modules that can be worked on independently, replaced by better > alternatives, and reused on other projects. > * therefore the important thing is to define the interface between > components. Not only open source projects work this way ;-) For "cin3", we employ sort of a self-chosen diet: We restrain from desiging cool UI features and thus avoid the danger of tangling and messing up the architecture in order to "get the features working, at least provisorily". We know the basic working tools an editor needs, and we build starting from the technological core necessary to support them. We use test-driven development extensively: we don't have any usable executable, but we have already a large pile of running tests, some working, some failing. Every mayor feature or component is defined and documented by one or several tests. When we reach the point where to start a GUI or try to wire to some GUI draft done in parallel, we will have a self contained and completely scriptable system to work with. > Also, look at Blender. This contains a video editor with similar > functionality to Cinelerra but a less-usable user interface. However, it > would be good if both projects could address the same interface to allow > reuse of components. Regarding "reuse", there was quite some sobering in the last years. In most cases, there can't be as much reuse as you might think there can be at first sight. A good deal of reuse is possible for small low-level components. For example utilizing GStreamer plugins. Or, have a look at: http://gmerlin.sourceforge.net/gavl.html GAVL will probably play an important role within "cin3". IMHO, the most viable kind of reuse is to look at (and copy code form) the source of competing projects and exchange ideas with the people behind those projects. Cheers, Hermann V (aka "ichthyo") -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHmKHvZbZrB6HelLIRAr0xAJ0eDCYQIPsUDhE9/HGBruapUkjuFACgqdgn LsqpOdFnlPlD/UdCRSxenMs= =Q3Yj -----END PGP SIGNATURE----- _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
