Martin Ellison wrote:
> 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
only one renderer which maybe has diffrent code paths (software, gpu,
...) controled by quality/resolution/profiling parameters.
Have a scheduler where we can assert frame pulls "I need frame 2 at
quality level N in 17ms, and btw i am playing forward, if possible
prepare me frame 2 and following as well". This Scheduler can the report
immediately "Yes sounds doable" or "No way, I wont even try, drop this".
As well as some extra hints like "give me the nearest frame to frame 40
within X ms" or adaptive quality/resolution while scrubbing one sees low
res/low quality preview and when stopping scrubbing the exact frame
where it stopped is rendered in (maybe incremental) better quality/res.
This needs also a sophisticated caching system which maximize and
monitor memory usage and ensures that frames which are expensive to
render and/or often reused (mpeg keyframes for scrubbing) are readily
availabe and dont need to be re-rendered. Perhaps with some profiles to
determine the cost benefit of caching or rendering for a given thing.
> * 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)
> * the edit decision list would then be a graph of component nodes
> * 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.
For cin3 everything will be entered in a big graph including decoders
and encoders, mixers, effects, ... what you see in a compositor is
basically only a tap on one of this nodes (yes it would be possible to
have multiple compositor windows and attach them at diffrent points in
the graph).
We define a module/plugin system based on C interfaces so that anyone
can write plugins in different languages.
take a look at the cin3 design docs.
>
>
> 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.
Blender is only one of many which defines its interfaces in its own way.
We plan to define our own interfaces which exacltly meet our goals and
then use wraper plugins which can adapt to foreign interfaces/plugins
(blender, frei0r, gstreamer, effectv, ....)
Christian
_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
