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

[Christian Berger]

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/