[Kdenlive-devel] Interested new developer and little patch

[Hugh Tebby]

2010/3/9 Dan Dennedy <dan at dennedy.org>

> 2010/3/9 Hugh Tebby <hugh.tebby at gmail.com>:
> > Hi everyone,
> >
> > I've been using Kdenlive and following closely it's development, and now
> at
> > last I've got myself a development environnement and I started tinkering
> > with the code.
>
> Welcome! Prepare for the journey down the rabbit's hole. :)
>
> > To start simple I had a look at what little tweaking I coulf to in the
> > interface. I made a little patch that replaced the "render" and "generate
> > script"  dropdoanw list by two separate buttons in order to make the
> > interface clearer and less error-prone. See here :
> > http://www.kdenlive.org/mantis/view.php?id=1489
>
> I know this has been irksome for many.
>
> > I attached the patch to this mail. Could you have a look to see if this
> > could be including in the trunk ?
> >
> >
> > I'm not a great coder. I have a little experience with c++ and
> contributed a
> > bit to Inkscape, but it's my first time with qt, and I'm mor a php
> developer
> > (and no really that good anyway). But even little contributions can help,
> so
> > here I am.
> >
> > One area I could help would be the bug tracker management (cleaning up a
> > bit, removing old reports, checking out bugs etc.). Another place is the
> > user forums. There are still quite a lot of unanswered posts and there a
> big
> > problem with spam.
> >
> > Would it be possible to have the rights to delete posts in the forum (to
> > remove spam) and to modify Mantis reports ? I could also contribute in
> the
> > documentation area, so if I can get the right for that too...
>
> Isn't it all based on pre-0.7.x?  If so, maybe we should just get rid
> of it for now and solicit updates for installing/downloading and
> common problems sections.
>

 I've been going around asking people in the forums and in recent bug
reports to update to 0.7.7.1. Maybe it could be made more obvious on the
front page of the site that 0.7.5 and previous releases are no longer
officially supported.


> > Concerning the code, I was thinking of starting of with interface
> > enhancements (maybe in the rendering area, to have an simpler access to
> > ffmpeg parameters instead of simply modifying the command lines, like
> what
> > Avidemux or Open Shot have).
>
> good idea.
>

I'll dig into that later this week, see if i can come up with anything.

>
> > There are several other bugs/features I would like to help with, but I
> don't
> > think I'm anywhere near ready for that :
> >
> > Proxy clips : like what Blender has for it's sequence. For each clip you
> can
> > generate a proxy clip (in a proxy subfolder), which is basically a lower
> > resolution/quality clip that will be used for editing and the original
> clips
> > will seamlessly be used for rendering. Changing resolution might be
> tricky
> > (problems with effects, maybe), but simply converting AVCHD to a
> different
> > codec, maybe 36 Mbit/s DNxHD would make HD edting a breeze. It's doable
> now
> > manually by converting all the clips, then modifying the .kdenlive file.
> A
> > simple script could do the job, so it shouldn't be toot difficult to
> > implement.
>
> Resolution change might be doable if you scale positions or convert
> effects that use positions to percentages.
>

That's what I was thinking. Maybe doing a first iteration with same
resolution clips, and then later adding down scale. Anyway I tested on my
computer (it is a quad core, mind you...) and full HD in any other codec
than AVCHD is perfectly usable and only uses 20% or so of CPU when editing.
It might be a bit tough fo a Pentium 4, but any more recent processor should
be allright. So downscaling doesn't seem to be a priority.



> > Audio Fade-outs and volume effects bug :
> > http://www.kdenlive.org/mantis/view.php?id=1493
> > This is probably more MLT than Kdenlive, and I suppose it is a little bit
> > tricky
>
> I will try to take a closer look soon.
>
> > Automatically split audio and video clips :
> > http://www.kdenlive.org/mantis/view.php?id=1494
> > This would use dvgrab I suppose, I don't know how difficult that would
> be,
> > but I suspect it's feasable.
>
> You are confusing scene detection with separate video and audio clips
> on the timeline. Scene detection is going to be difficult to
> accomplish in the current architecture of things.
>


Indeed, I somehow got mixed up between automatically separating audio /
video and doing scene detection on import. I actually wanted to mention
both... I don't think I could do much about the scene detection, but
automatic audio/video splitting sounds doable...


> > Compositing : the composite transition is one of the features I really
> > dislike with Kdenlive. Because of this you can't for instance have a
> title
> > fade out over a clip, or have a title over a clip and have that clip fade
>
> The composite transition has keyframable opacity to do a fade in/out
> of a title or whatever is on top.
>

Yeah, it's doable, but that's really just a workaround, and it isn't that
obvious.


>
> > out over another clip (can't have multiple transitions overlayed). Also
> all
>
> Hmm, I believe I have done multiple transitions in the past, but I
> know there are some issues.


> > transparency effects, like transparent pngs or blue screen effect, need a
> > composite transition, which is limiting and unintuitive. If compositing
> > could be simply enabled or disabled for all clips (enabled by default),
> and
> > if compositing was done with all tracks (so you can have a title over a
> > transparent png over a clip with blue screen effect over a background
> clip),
> > it would solve all problems.
> > I'm fairly sure OpenShot works that way, so it's possible with MLT. But
> > there it's really way beyond my knowledge of MLT and Kdenlive.
>
> I believe the effects system in Kdenlive will need major rework to be
> less tightly coupled to MLT. Also, MLT can do things like masking to
> confine filters to regions defined by the alpha channel. Also, with a
> bit more work in MLT, all filters could be connected to the motion
> tracking ala AutoMask. Some filters can take a MLT producer (for
> example, to define its alpha channel), and that would be good to make
> possible. Maybe we plan while we wait until I get generic keyframing
> done in MLT? Maybe some people can experiment with better UI ideas as
> well like being to define rectangles directly on top of the preview
> monitor instead of the little red rectangle widget. Eventually, that
> could lead to shapes for defining masks.
>

That sounds like quite a bit of work. Do you expect that to be feasable in a
reasonably near future ? (maybe one year ?) I'd be glad to help, but more
for grunt work at the moment.

I must admit I had a hard time choosing between Kdenlive and OpenShot.
Kdenlive is quite a lot more advanced at the moment, and has a much nicer
and cleaner interface (thanks for qt4 !), but OpenShot is growing at an
incredible rate, has some very powerful features (better compositing for
instance) and is coded in Python (I'll choose Python over C anytime).

I chose to look into Kdenlive mainly because I prefer it's interface, by
far, and having used is quite a bit I already had a few ideas for
enhancements. Also OpenShot seems to aim for "simple and easy editing for
anyone" whereas Kdenlive seems to aim for more advanced editing, so I feel
more attracted to Kdenlive at the moment.

I just hope that Kdenlive's internal structure is sound enough to enable it
to continue developping more features.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20100310/e23b4095/attachment.html>