I'll stick with what I know for sure in this reply. 1. All my raw video clips are AVCHD, 1920x1080p 50fps. Kdenlive automatically generates proxies, and all my editing is done on that. No trans-coding necessary.
2. Proxies are generated with ffmpeg, and if you are running kdenlive in gdb, the current proxy will continue to generate even if kdenlive crashes. 3. Rendering is done with mlt, and that is closely integrated with kdenlive. To change this would just introduce a lot of new bugs. 4. Every time kdenlive has crashed on me in the middle of a project the automatic recovery feature recovered my work up to a few minutes ago. The current git of kdenlive & mlt is absolutely awesome, with quite a lot of improvements, and quite a lot more stable than the latest released version. If you are running the last released version of kdenlive, I highly recommend that you try to get the latest git version installed. You will find that most of your issues here have been addressed already. Kind regards, -Evert Vorster- 2012/1/20 Stefan Naumann <snaumann2912 at yahoo.de>: > What about saving the project for example one time per 5 minutes or so. But > then the project size is too big for it to be saved within a short period if > time, so that the user can edit the project without trouble. Maybe, there > should just be a little hint on the bottom if that happens. When KDEnlive > crashes the project can then be recovered. If KDEnlive crashes while saving: > have more than just one file. lets say 5. If the last one can't be loaded, > the second can. I guess. Adobe Premiere has so small projects - why can't > KDEnlive have this small projects? > > Running stuff as seperate process would be nice, for example the transcoding > dialog, if KDEnlive crashes, the dialog should still be present and > untouched and ffmpeg should render the videos further. Most of the crashes I > encountered where due to SegFaults. (is there another way to crash a > program?). Finding them is a bit difficult (maybe because I'm still a novice > in programming). So, of course - if a user can recover their project easily > it's nice, but it's even better for them not having to recover them. > > Another thing: why is AVCHD not supported? Or let's say badly. Editing it - > there should be proxy clips (I like the ffmpeg way - so if you'll have more > presets: do not remove the ffmpeg-way), and when the project is rendered - > why should the renderer care about it being AVCHD or not? When in doubt: run > ffmpeg over it with that high bitrates, that there can't be a loss of > quality. > > Regards Stefan. > > ---------- Waren Sie schon auf: www.oettinger-games.net.tf . Helfen Sie mit. > ________________________________ > Von: Dan Dennedy <dan at dennedy.org> > An: For kdenlive developers <kdenlive-devel at lists.sourceforge.net> > Gesendet: 5:38 Freitag, 20.Januar 2012 > Betreff: Re: [Kdenlive-devel] KDEnlive Bugs I encountered > > On Thu, Jan 19, 2012 at 2:01 PM, el jefe delito <eljefedelito at gmail.com> > wrote: >> I am talking out of my backside here, as a non-programmer, but... >>> How can you handle a crash in a nice way? An application shouldn't >>> crash, but when it crashes it's too late. >> >> How does an app crash and not bring down the whole OS? ?How does Adobe >> Flash crash often but not bring down Chromium? ?How does the Desktop Capture >> crash and not bring down KDEnlive? ?Is there a way to do something similar >> in other parts of KDEnlive, and allow these parts to be restarted? >> > > These occur through process isolation. Web browsers like Chromium run > each tab and plugins in separate processes from the browser shell. > Kdenlive already spawns separate processes for screen capture, > transcoding, and rendering thereby protecting the editing project. > > Kdenlive could potentially run the bulk of its editor in a separate > process and leave only the window and perhaps a dialog upon crash - > something like Firefox does as Brian mentioned. That would only add > minor user experience sugar over simply using the desktop environment > to restart kdenlive. > > Now, the more extreme approach that would require serious engineering > is to run the majority of MLT in a separate process. To do this > strictly from MLT to Kdenlive would get messy due to things like GUI > toolkit and the way XVideo is being used today for better performance. > We may be able to add around something around MLT that runs the main > object graph in separate process and uses shared memory to transfer > the audio and image to a parent process using the MLT output plugins. > But that will also require the addition of a complete IPC layer over > the MLT API so the Kdenlive logic can still manipulate the object > model of the composition. And in the end, all that buys you is MLT > isolation, and crashing bugs within Kdenlive code still leaves > Kdenlive vulnerable. > > -- > +-DRD-+ > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Kdenlive-devel mailing list > Kdenlive-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Kdenlive-devel mailing list > Kdenlive-devel at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/kdenlive-devel > -- Those who do not understand UNIX are doomed to reinvent it, poorly.
