[Kdenlive-devel] Re: kino and next steps

[Rolf Dubitzky]

On Monday 13 January 2003 06:19 pm, Chris Clayton wrote:
> Yes, I have a BT878-based Pinnacle PCTV Studio/Rage. Thanks for the tip
> about Kino.

I think, letting cinellera aside, kino is our direct competitor. Most of the 
stuff I use I learned from kino. If the code wasn't so ugly, I wouldn't have 
started any project at all. I'm not particular a KDE or GNOME fan, but that's 
another story. The point is, that kino was supposed to be KDE app (hence the 
k) but Arne (the founder) could'n get KDevelop to run, so he used glade and 
kino became a gnome app. Unfortunately the code is a real mess. Those guys 
managed to poison each and every source file with gui dependecies. spread 
commandline options all over the place (even in libraries!).  Unfortunately 
piave is too late to become also the kino-engine (a goal I had), because the 
new devel team is starting to separate GUI and engine and also implement 
effects and transitions. The way it is done today is completely unusable, but 
they are aiming for release of the new stuff in the near future.
 When it comes to cutting and aranging clips, kden/piave is pretty up to paar. 
Kino has one big advantage up to now, that's the very usable grabbing 
environment (V4L iface and ieee1394 steering). A minor thing is export to 
(not read from) mpeg and other file formats. It works in principle (though I 
think they got the API and encapsulation wrong again), but as long as it is 
still much worse than mencoder, it doesn't count. Also, if you can't apply at 
least denoise and deinterlace filters to a DV file, the resulting MPEG4 or 
DivX or whatever, will just suck. So you have to use mencoder anyway.

So here is a question: 

I can think of two major things I can start working on:

1) reading other file formats. I looked into xine-lib, and it actually looks 
   pretty nice. clean, understandable code. Simpler than ffmpeg. They also got 
   a fmpeg plugin, amongst many others. They don't have encoding, but I think
   I might get aRts and video also video (replace SDL, reduce dependencies).
   Other than reported framerates and windows sizes, this should go pretty 
   unnoticed by the GUI.
2) implement ieee1394 support, so that you can grab video from your cam.
   This envolves a lot of GUI and communication stuff

It depends on the users. If the target is DV people, we need grabbing, if not, 
other people might prefere to be able to cut mpeg files. I am more interested 
in grabbing, but it migh be the case, that I am alone with this.
What do you think should go first? 

Cheers,
Rolf

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