[Kdenlive-devel] Interested new developer and little patch

Hugh Tebby hugh.tebby at gmail.com
Tue Mar 30 11:53:20 UTC 2010


Sorry for bumping this thread, but would it be possible for someone to
review and commit the little patch for this ticket :
http://www.kdenlive.org/mantis/view.php?id=1489 ?

Thanks.

2010/3/10 Hugh Tebby <hugh.tebby at gmail.com>

> 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/20100330/d79eebd7/attachment.html>


More information about the Kdenlive mailing list