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>
