Am Mittwoch, 23. Oktober 2002 14:48 schrieben Sie: > Hi Jason, hi Christian, > > > On Wednesday 23 Oct 2002 10:14 am, Peter.Q at gmx.net wrote in thread: > > http://lists.kde.org/?l=kde-multimedia&m=103537308631406&w=2 > > > > Essentially my idea has always been based upon the GUI and engine > > running in seperate processes and communicating between each other. > > BUT before everyone starts wailing and nashing teeth at how slow > > chucking video from one process to another would be; the plan I have > > is that the engine will display it's own video window, which will then > > be embedded into the GUI. So no video will be passed from GUI to > > engine. > > Ok, that is a must. You cannot pass any video data arround.
Well but the problem is the cutter should be as little dependend of the rest of the system as possible. Well OK X can do something here, but I don't want to let the cutter become a GUI application like Adobe Premiere, which makes automatisation almoust impossible. > > timeline and moving them around at least one at a time, and in some > > cases multiple selections at a time (the code just needs finishing off > > to make it work in all cases). As I mentioned above though, I was > > thinking that for > > seperation it makes > > > better sense to put the KVideoWidget into a simple window in the > > engine, > > Well, I think this is one of the points I meant, when I said that you > will not be able to separate engine and GUI 100%. Putting a KVideoWidget > into the engine is clearly not what I want. But that is not a real > problem. Any two parts need a inteface layer. This layer will > necessaryly depend on a specific GUI and on a specific render engine. I > think that such a layer will not ruin a nice design. And btw you will > need at leas two video windows. Ony in which you see the curent frame, > maybe rendered in preview quality, maybe even with low quality, but HW > accelerated versions of the effects, and another kind of window to > preview subscenes that have already been rendered. My engine will be > capable (not yet working) of using idle time to prerender parts of the > production so that they can be quickly displayed. Well the 2 screen-paradigm is just one idea, there are many programs without. The timeline images surely could be passed from one application to another. > > and to then control it remotely. The most difficult bit of this will > > be actually settling on the actual format of the communication. > > This communication will very much depend on the capabilities of the > engine. E.g. I don't use a serial timeline. It's more like a tree. This > is extremely efficient and easy to manage, but not vary convenient to > visualize. Same is true for effects and transitions, actuall, in my > engine there is not even a difference between the two. I use dynamic > path effects, which can appear like transitions, or something else. It's > a very nice concept I think. I just mention it to make clear, that the > path nodes have to be visualized in the timeline which means, that it > will be difficult to write a generic gui and a generic engine with a > generic interface. > On the other hand, you are right, there are a number of things > basically every engine and every gui will have in common, but you > probably don't want to restrict yourself to this common denominator. Yes, but we can maybe define somekind of "meta-format", which contains the "common denominator" but is dynamically extensible. > And then, may I ask about Christian Berger's engine? In which state is > it? Are you two working closely together? I work together with a friend > of mine who is doing the GUI stuff, I would like to try and convince him > that we all work together, but I am not sure that'll work. He is not > eager to work with Qt. Ohh my engine is currently still non-existant. It'll be based on lavpipe which enables us to at least have a working cutter for a start. > Cheers > > P.S. Don't be puzzled about the e-mail. 'Peter' is a nick and an old > alias, I use when mailing from home. Servus Casandro > *************************************************************** > Rolf Dubitzky > e-mail: Rolf.Dubitzky at Physik.TU-Dresden.de > s-mail see http://hep.phy.tu-dresden.de/~dubitzky/ > *************************************************************** > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en > _______________________________________________ > Kdenlive-devel mailing list > Kdenlive-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel -- Warning! (this is no commercial ad) This e-mail probably will be read by secret services. Therefore please get pgp or gnupg and send me your public key so we e-mail encryptedly. http://www.gnupg.org/
