Am Montag, 28. Oktober 2002 12:15 schrieben Sie: > > Well, I don't know, but any professional video editor uses the same > approach AFIK. This aproach is: > 1) Have single frame preview window. Selecting a frame in the timeline > will render/display this frame with decent (highes?) quality. > 2) Have _large_ buffers on HD and render the movie in preview quality to > the buffers. If you wnat to previe a scene, it will be taken from the > buffers. > > For 2) if you have a smart engine, the engine will be able to use the > offscreen capabilities of the grafics hardware and/or use hardware to > render ind preview quality if the selected scene has not yet been > prerendered. It is possible, to have different implementations of the > same effect/transistion. e.g. high or production quality, which just > renders everything by hand as good as possible, and then low/preview > quality which tries to use hardware acelleration. The effect might then > not look 100% perfect or fonts maybe not antialiased, color gradients > maybe reduced, etc, etc... > > The real problem is not 1). Doing it perfect is not that big a deal, but > 2) doing it almost perfect in realtime to preview.. that's the > challenge.
Well since our format is based on scenes and so simple, rendering a single frame might be efficiently possible. If it's not possible, we can still render a whole scene, which usually shouldn't be to long. > > > However, if we were to copy data from the Cutter to the GUI, then > > > the problems that arise are due to context-switching. We would have > > > to consider looking at the Cutter as a seperate thread rather than > > > as a seperate process. > > > > Well this wouldn't probably work without integrating the cutter a lot > > more tightly. > > Making the cutter a gst-plugin, this is for free, the GUI can wrap it in > gst-thread, or not. Using gst-launch I guess the plugin can become a > real process, too.. I'm not sure though. Well the problem is, it's vital for the cutter to be able to run on a box somewhere hidden in the closet where it doesn't disturb anyone. As well as the cutter should be able to just consist of a small programm controlling 3 VTRs and a video switch. > > Ok, I don't want to get envolved with multiple computers too much, > because that's my major. But if we want to test this on a 500+ PC > cluster at some point I can do it. But using a PC cluster to render a > movie is trivial. The task is intrinsicly parallel if you can make the > cutter read a XML file and launch it with gst-launch. You just have to > tell everybody which frames to render and have a seriealizer in the end. > That's what I do all day ;-) Well we probably do this scene-wise. > > Well first of all if we programm propperly, the cutter won't crash. > > ;-) Seriously, my programms didn't even crash when I still was programming commercially at HIW. > > However that's why I was suggesting the cutter to anounce it's > > posibilities. If the cutter completely runs over network it might only > > offer the frames or might even just display frames on a seperate > > display. > > Ok, you are talking about interactive work on a cluster? Nope, I'm talking about things like cutting with VTRs. I doubt computer editing will ever surpass the quality of a good analog HDTV VTR. > Cheers, > Rolf 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 email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > 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/
