On Sun, Sep 13, 2009 at 4:00 PM, Ryan Peters <sloshy45 at sbcglobal.net> wrote: > There has been lots of talk about new features for future releases of
There has? Do not confuse the brainstorm forum with the developer's intentions. In fact, there is a distinct lack of discussion about features among the developers. Well, maybe in IRC there is, but I avoid IRC. I will go ahead and admit the OS X support I worked on recently for selfish reasons - it was so close to working and I use OS X daily on my laptop. > kdenlive, but I was wondering if in the near future there could be a > release dedicated to making sure that kdenlive as a whole has less bugs, I am only a kdenlive contributor, but from my perspective stability and bug fixes has been a primary focus of all releases since 0.7.0 despite what I consider minor feature additions. There have been a number of feature adjustments, which are sometimes considered bug fixes. > works faster and more efficiently, etc. I've been wanting to create Well, that is a tougher one. Since the last MLT release, I have made some major changes to address performance when combining multiple effects. Unfortunately, I believe this will lead to some regressions in corner cases despite my best effort and testing. In addition, I am looking at adding a frame cache inside MLT (special cases) and a thread-per-track in the near future. Again, we might see some regression when those are added. Beyond that, I do not see any significant improvement to be made without major efforts to use NVIDIA VDPAU as well as SSE and multi-core parallelism technologies for image processing routines. Oh, there is some work one can put into kdenlive to better take advantage of the existing multi-threaded FFmpeg codecs. I do not believe the Decoding Threads field in the Clip Properties dialog is enough. It could use a default setting in Preferences, and the Render dialog ought to add a threads field. > videos using linux for a while now, and with each update, even though > there's more and more features, I'm noticing that kdenlive is getting > increasingly unstable and buggy. This is why I'm proposing this, because OK, this is good feedback because, like most FOSS projects, we lack a dedicated, formal Quality Assurance process, team, and lab. We rely upon community feedback to give an overall progress indicator. Your post is very similar to this one: http://www.kdenlive.org/forum/kdenlive-crashes-most-operations-0 We did not know 0.7.5 was a "beta" - meaning worse overall than 0.7.3 or 0.7.4. > before too long we'll have another "Cinelerra", a full-featured video > editor that crashes so often and has so many weird bugs that it's > unusable to the average user (such as myself). If there is already a > release such as this one planned, sorry for being redundant. > > ? ?- Ryan Peters, kdenlive user For reasons I do not fully understand, it often seems a lot of strange problems are reported when using binary packages. Now that there is an increase in the number of available binary packages, more people are using them. Over my many years supporting Kino and MLT, there have been countless times when people reported strange, unreproducible problems only to report back that it works after manually compiling or building a source package. Finally, there are always little problems coming and going in FFmpeg. You often hear about how strict the commit policy is in the FFmpeg project, and that is part of their QA process. Fortunately, they have quite a bit of talent and eyeballs. We have certainly received a lot more eyeballs on the surface over the past 3/4 year, but not enough new talent and eyeballs on the code. -- +-DRD-+