[Kdenlive-devel] Export timeline progress dialog box...

[Rolf Dubitzky]

On Wednesday 25 June 2003 17:48, jasonwood at blueyonder.co.uk wrote:
> > > Ina any of the mentioned cases (except 3) we need to define a common
> > > picture format so that kdenlive can understand what piave is saying.
> >
> > PNG for 3 points :
> >
> > - free and GPL.
> > - easily usable with Qt.
> > - fast and not really big for video size.
>
> I would be tempted by png as well. There are two or three points to
> consider as to which will be fastest :
>
> 1. Compression/decompression time. It doesn't matter if the files are
> reduced to almost zero length, if it takes five minutes to decode the
> result, we'll have poor performance.

0 sec for RGB.

> 2. Quality. Lossless is best, but we could get away with a lossy
> compression format.
>
> 3. Transfer time. How long it takes to transfer across the network/save and
> read from a file/ copy from one memory location to another.

Ok, I checked shemem (the Sys V style) and FIFO/UnixSockets. I think we can do 
with a FIFO fo now. When it comes to network, I really don't care at this 
point.

> I think that we should start by trying images across TCP - this will be the
> "slow but always works, even across a network" solution. From then on, we
> find out exactly how slow it is, and then we can optimise with local
> solutions :-)

Let me add, that going from a FIFO based solution to a TCP based solution is 
not a big deal, only that FIFO is easier/faster in the first place.I really 
don't see why we should go for the very unlikely case where you really have 
_all_ the renderers running on host A and kdenlive on host B. In this case 
you can still use plain X and start kdenlive on host A and let it be 
displayed on host B. X is very well designed for exactly this and is 
optimized in latency. At home I connect my laptop via eth1394 to my desktop 
and X works like a charm at 200mb/s. I don't see why we should go for the 
option which will be slow in 95% of the cases (where main renderer and gui 
are on different hosts) and not for the option that will be faster and 
simpler.
Having the batch rendering option over TCP, once the editing is done and you 
just need a bunch of slaves to do the full quallity rendering of the whole 
thing is a completely different issue.
Controlling your DV cam, connected to A, with a gui running on B, doesn't make 
any sense anyway.

Cheers,
Rolf

***************************************************************
 Rolf Dubitzky          http://hep.phy.tu-dresden.de/~dubitzky
 e-mail:         Rolf.Dubitzky at Physik dot TU-Dresden dot de
***************************************************************