[Kdenlive-devel] moved here from kde-multimedia (was Re: Multimedia Frameworks)

[Christian Berger]

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/