Performance problems
The 0.13.4 release brought videomixing/compositing, which is a required component for being able to do transitions, effects, transparency, etc.
However, some significant performance problems have appeared. These problems may not affect you if you have a machine with a very fast processor (ex: Core Duo, Core 2 Quad, ...). This will affect netbook users more significantly than users with powerful machines, although even with a fast processor, there can be a noticeable performance difference with older pitivi releases.
We are aware of these issues. This page is an attempt at listing those problems, the potential solutions, and our progress in fixing them. It is also a request for help from external contributors. If you would like to get involved in pitivi's core or are interested in optimization, this is where you can make a difference and rock the world.
Contents |
The two main problems
Poor playback performance when project resolution doesn't match the clip resolution
As part of implementing transitions, we needed to implement scaling. Due to various issues, it is currently done in software, instead of hardware-accelerated scaling. See bug 613416.
Playback performance is slower than before
In addition to the previously mentioned "scaling" problem, playback is generally slower than in pitivi 0.13.2 or 0.13.1. This is because of videomixing (ie: being able to make videos transparent, for example). Currently, it is done in software and negatively impacts performance. (todo: need a better explanation)
Others?
There might be bugs we don't know about, or other generic performance bugs not specific to the 0.13.4 release. See the current list of performance bugs.
The proposed solutions/paths of investigation
(todo: please make a bulleted list of all the stuff you want to optimize, with the status, and ideally an estimate of how long it would take, and if it's assigned to someone)
- videomixer: when it only has one input stream, it should be smart enough to just passthrough (i.e take 0% cpu).
- smartvideoscale (videoscale+videobox): The problem here is that we've decided to pick the project settings regardless of the current configuration (i.e. how many sources are mixed, are we previewing/rendering,...). We should only have to scale if needed. If not needed, videoscale/videobox should also act passthrough. Forcing the width/height/framerate of the various gnlcomposition is not needed when previewing, only when rendering.
- We should move the smartvideoscale into the smartvideomixer and use it only if needed, based on caps and number of inputs. That way:
- if previewing AND only one stream => smartvideoscale with no limitations => passthrough
- if previewing AND multiple streams => choose a smart common size (biggest ? smallest ?) in a capsfilter *after* videomixer => only one stream gets resized
- We should move the smartvideoscale into the smartvideomixer and use it only if needed, based on caps and number of inputs. That way:
- alpha: It would be great if we could do passthrough on any caps when alpha==1.0, which would be most of the cases. That would avoid us having to convert to AYUV that early, but only when needed.
- ffmpegcolorspace : We use it for converting to/from AYUV. We should not force unconditionally that common colorspace (which is forced in the input to videomixer with a capsfilter). In this use-case we should have been able to do I420 all the way to the sink. This is related to problems with videomixer not being good at caps negotiation.
- GNonLin: a lot of issues are related to caps negotiation. The problem is that due to the nature of how a gnlcomposition is built (source preroll before they're linked) we need to specify restrictions/capsfilter in various places.
- Edward has started implementing some features in gnonlin that will help solve this issue (basically use the caps property of the gnlobject, propagate it down from composition to its childs, and have the various gnlobject use the caps property to make smarter decisions). One place where this could be used is when a videomixer sees that it has more
than one input it could *then* specify a common set of caps to be used by the gnlobjects connected to it.
Note : alpha and video positioning/scaling of each video streams will be a *lot* more efficient when we have buffer metadata implemented in GStreamer, since we'll be able to delay the actual processing as downstream as possible (like in videomixer or even the sinks): http://cgit.freedesktop.org/gstreamer/gstreamer/tree/docs/design/draft-buffer2.txt
