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

Rolf Dubitzky dubitzky at pktw06.phy.tu-dresden.de
Mon Oct 28 10:29:36 UTC 2002


On Friday 25 October 2002 08:36 pm, Christian Berger wrote:
> > 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.

Yes, I completely understand, since I thougt about this topic for quite while. 
The only idea I had just very recently is, if both applications, the GUI and 
the cutter as well, are GStreamer apps. In that case the cutter can be 
implemented as a GStreamer plugin and thus can render into a gst-queue. The 
GUI can build any gst-pipe it wants, eg. pipe to a file or display in a 
widget. In the end you _will_ need an Interface between cutter and GUI, this 
could be something selfmade, or something which is already there. If the KDE 
guys could live with GSteamer becomming part of KDE, this would even be 
Desktop independent. I have already coded something like a wrapper which 
makes my complete engine something like a super plugin, i.e. a single 
gst-element with as many input pads as there are video streams to merge and a 
single output pad. There is one problem though with gst-dv plugin, As far as 
I can see, it decodes every frame it passes to the pipe, concidering the bad 
quality and performance of linux-libdv-codec, this is not acceptable. My 
render tree is smart enough, to only decode a frame if it is really 
necessary, i.e. if the image data is not touched it will be written to the 
output file without beeing de-en-coded.

Unfortunately I don't have a copy of Adobe Premiere, I don't know how it 
works.

> 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.

sure, and "2 screens" don't mean really two widgets on the desktop next to 
each other, but displaying a preview of the video and displaying  single 
frame in which I want to adjust text or other video with the mouse are two 
very different tasks, which will need different wirdgets.

> Yes, but we can maybe define somekind of "meta-format", which contains the
> "common denominator" but is dynamically extensible.

Something like this has already been done, I think, do you know SMIL? In the 
beginning, I thought about using a subset of SMIL, but I think it is overkill 
and is not very well suitable to persist my kind of rendertree.

> 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.

As I said, I would be happy to share the code if you are interested. My 
'engine' is not ready by any means. I would say it is in a prove of principle 
state. I mean cutting a movie in plain C++ is not a pleasure, I need a GUI.

Cheers,
Rolf

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






More information about the Kdenlive mailing list