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

Christian Berger einStein at donau.de
Mon Oct 28 15:56:54 UTC 2002


Am Montag, 28. Oktober 2002 11:29 schrieben Sie:

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

Well it should be completely desktop independant, even independand of X 
(the cutter should be able to just do the cutting without any display.
The reencoding might be a problem, but only in later persons.

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

Ohh I see, althought inserting text would be an effect with a video input 
as well as a text and other parameters.

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

No I've heared of SMIL, but never read much about it. Our current proposal 
is extemely simple and versitale. We just have sceenes and each scene has 
it's own render tree. Each scene can be rendered individually, maybe even 
on different computers.

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

But the cutter should be completely independand of GUI, it should get it's 
cutlist and simply cut the video somewhere far away from the table the 
editor is sitting on.

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




More information about the Kdenlive mailing list