[Kdenlive-devel] kdenlive performance

[Dan Dennedy]

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-+