Sorry for bumping this thread, but would it be possible for someone to review and commit the little patch for this ticket : <a href="http://www.kdenlive.org/mantis/view.php?id=1489" target="_blank">http://www.kdenlive.org/mantis/view.php?id=1489</a> ?<br>
<br>Thanks.<br><br><div class="gmail_quote">2010/3/10 Hugh Tebby <span dir="ltr"><<a href="mailto:hugh.tebby@gmail.com">hugh.tebby@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="gmail_quote">2010/3/9 Dan Dennedy <span dir="ltr"><<a href="mailto:dan@dennedy.org" target="_blank">dan@dennedy.org</a>></span><div><div></div><div class="h5"><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2010/3/9 Hugh Tebby <<a href="mailto:hugh.tebby@gmail.com" target="_blank">hugh.tebby@gmail.com</a>>:<br>
<div>> Hi everyone,<br>
><br>
> I've been using Kdenlive and following closely it's development, and now at<br>
> last I've got myself a development environnement and I started tinkering<br>
> with the code.<br>
<br>
</div>Welcome! Prepare for the journey down the rabbit's hole. :)<br>
<div><br>
> To start simple I had a look at what little tweaking I coulf to in the<br>
> interface. I made a little patch that replaced the "render" and "generate<br>
> script" dropdoanw list by two separate buttons in order to make the<br>
> interface clearer and less error-prone. See here :<br>
> <a href="http://www.kdenlive.org/mantis/view.php?id=1489" target="_blank">http://www.kdenlive.org/mantis/view.php?id=1489</a><br>
<br>
</div>I know this has been irksome for many.<br>
<div><br>
> I attached the patch to this mail. Could you have a look to see if this<br>
> could be including in the trunk ?<br>
><br>
><br>
> I'm not a great coder. I have a little experience with c++ and contributed a<br>
> bit to Inkscape, but it's my first time with qt, and I'm mor a php developer<br>
> (and no really that good anyway). But even little contributions can help, so<br>
> here I am.<br>
><br>
> One area I could help would be the bug tracker management (cleaning up a<br>
> bit, removing old reports, checking out bugs etc.). Another place is the<br>
> user forums. There are still quite a lot of unanswered posts and there a big<br>
> problem with spam.<br>
><br>
> Would it be possible to have the rights to delete posts in the forum (to<br>
> remove spam) and to modify Mantis reports ? I could also contribute in the<br>
> documentation area, so if I can get the right for that too...<br>
<br>
</div>Isn't it all based on pre-0.7.x? If so, maybe we should just get rid<br>
of it for now and solicit updates for installing/downloading and<br>
common problems sections.<br></blockquote></div></div><div><br> 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.<br>
<br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> Concerning the code, I was thinking of starting of with interface<br>
> enhancements (maybe in the rendering area, to have an simpler access to<br>
> ffmpeg parameters instead of simply modifying the command lines, like what<br>
> Avidemux or Open Shot have).<br>
<br>
</div>good idea.<br></blockquote></div><div><br>I'll dig into that later this week, see if i can come up with anything. <br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> There are several other bugs/features I would like to help with, but I don't<br>
> think I'm anywhere near ready for that :<br>
><br>
> Proxy clips : like what Blender has for it's sequence. For each clip you can<br>
> generate a proxy clip (in a proxy subfolder), which is basically a lower<br>
> resolution/quality clip that will be used for editing and the original clips<br>
> will seamlessly be used for rendering. Changing resolution might be tricky<br>
> (problems with effects, maybe), but simply converting AVCHD to a different<br>
> codec, maybe 36 Mbit/s DNxHD would make HD edting a breeze. It's doable now<br>
> manually by converting all the clips, then modifying the .kdenlive file. A<br>
> simple script could do the job, so it shouldn't be toot difficult to<br>
> implement.<br>
<br>
</div>Resolution change might be doable if you scale positions or convert<br>
effects that use positions to percentages.<br></blockquote></div><div><br>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.<br>
<br><br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> Audio Fade-outs and volume effects bug :<br>
> <a href="http://www.kdenlive.org/mantis/view.php?id=1493" target="_blank">http://www.kdenlive.org/mantis/view.php?id=1493</a><br>
> This is probably more MLT than Kdenlive, and I suppose it is a little bit<br>
> tricky<br>
<br>
</div>I will try to take a closer look soon.<br>
<div><br>
> Automatically split audio and video clips :<br>
> <a href="http://www.kdenlive.org/mantis/view.php?id=1494" target="_blank">http://www.kdenlive.org/mantis/view.php?id=1494</a><br>
> This would use dvgrab I suppose, I don't know how difficult that would be,<br>
> but I suspect it's feasable.<br>
<br>
</div>You are confusing scene detection with separate video and audio clips<br>
on the timeline. Scene detection is going to be difficult to<br>
accomplish in the current architecture of things.<br></blockquote></div><div><br><br>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...<br><br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> Compositing : the composite transition is one of the features I really<br>
> dislike with Kdenlive. Because of this you can't for instance have a title<br>
> fade out over a clip, or have a title over a clip and have that clip fade<br>
<br>
</div>The composite transition has keyframable opacity to do a fade in/out<br>
of a title or whatever is on top.<br></blockquote></div><div><br>Yeah, it's doable, but that's really just a workaround, and it isn't that obvious.<br> </div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> out over another clip (can't have multiple transitions overlayed). Also all<br>
<br>
</div>Hmm, I believe I have done multiple transitions in the past, but I<br>
know there are some issues. </blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><br>
> transparency effects, like transparent pngs or blue screen effect, need a<br>
> composite transition, which is limiting and unintuitive. If compositing<br>
> could be simply enabled or disabled for all clips (enabled by default), and<br>
> if compositing was done with all tracks (so you can have a title over a<br>
> transparent png over a clip with blue screen effect over a background clip),<br>
> it would solve all problems.<br>
> I'm fairly sure OpenShot works that way, so it's possible with MLT. But<br>
> there it's really way beyond my knowledge of MLT and Kdenlive.<br>
<br>
</div>I believe the effects system in Kdenlive will need major rework to be<br>
less tightly coupled to MLT. Also, MLT can do things like masking to<br>
confine filters to regions defined by the alpha channel. Also, with a<br>
bit more work in MLT, all filters could be connected to the motion<br>
tracking ala AutoMask. Some filters can take a MLT producer (for<br>
example, to define its alpha channel), and that would be good to make<br>
possible. Maybe we plan while we wait until I get generic keyframing<br>
done in MLT? Maybe some people can experiment with better UI ideas as<br>
well like being to define rectangles directly on top of the preview<br>
monitor instead of the little red rectangle widget. Eventually, that<br>
could lead to shapes for defining masks.<br></blockquote></div><div><br>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.<br>
<br>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).<br>
<br>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.<br>
<br>I just hope that Kdenlive's internal structure is sound enough to enable it to continue developping more features.<br><br></div></div><br>
</blockquote></div><br>