Saya Video Editor
"Unsheathe your creativity"

Most existing GNU/Linux video editors face great problems when it comes to installing, the most significative of all is the dependency hell.

Python, wxPython

Some Video Editor projects are written in Python - wxPython to be more specific. In both Windows and GNU/Linux, we come to the problem that wxPython - the Python bindings for wxWidgets - doesn't have a stable API: It changes frequently and in an incompatible way. This leads to runtime errors when trying to run software that requires a PREVIOUS version of wxPython. The problem is aggravated when you don't get an error message, but a crash. Another problem is that some (poorly programmed) packages written in Python don't have the package management dependencies set right. In other words, with Python (or actually with some libraries written in Python) you lose all the advantages of using a package manager. Unfortunately, this includes libraries used by certain Video Editors.

Another problem is that perhaps a plugin or some Python library doesn't behave consistently with all Python versions.

Finally, Python developers suffer from what I call "the disconnection from the user": The user HAS to install Python, but the developer has forgotten the problems and frustrations that inexperienced users (who are NOT programmers) face when having to install Python (BEFORE trying to run the python software in question). A C++ package doesn't present this problem, since GCC is already included (or is easily installable) in most GNU/Linux distros.

Gstreamer plugins

Other projects were hardcoded to use the GStreamer framework. That doesn't pose a problem per-se. However, some GStreamer plugins have other dependencies. You're not only faced with installing the dependencies, but also the dependencies' dependencies ad nauseaum. And when your distro doesn't have those dependencies, you need to compile by hand. And I've seen some packages that when downloaded, have additional dependencies (not included in the rpm) before they can be compiled correctly.

Esoteric frameworks

Some frameworks (or their dependencies) are outright buggy in their official release version - or don't have an official release version for that matter - and you cannot download them from (insert your version control system here). For an end-user, this is unacceptable. Period.

To this date, I cannot install the MLT framework on my Linux distribution, which means I can't even try to install alternative video editors like Openshot. If I'm having these problems as a developer, imagine what an end-user has to go through.

Non-native user interfaces

For the GNU/Linux user, having GTK or QT installed in his system poses no problems. However, for the Windows user, having to install an external widget library becomes a burden, as heavy as the users' inexperience with installing software (note that this may change with QT4). Another problem is that projects that depend on GTK may not be as stable in Windows as they are in GNU/Linux. Personally, I have experienced crashes and/or hangs in GTK-dependant programs under Windows (well, either it's that, or all of them were horribly programmed).

Our solution

Our approach to solve the dependency problems consists in the following measures:

GNU C++ instead of Python

By writing the program in GNU C++, we get rid of the Python packages installation blues. Compatibility with Microsoft Windows is guaranteed with the MINGW port of GCC.

Including the required libraries in the source tree

To solve the problem of dependency hell, all multimedia libraries used will be included in the source package (If we create a shared object or DLL, it will be specific to the current version of the editor). This solves the problem of having to search for endless dependencies before even trying to install/compile the project. An advantage of GPL'ed code is that you can effectively copy whatever code you want and include it in your own code.

Using Qt as the UI Toolkit, and sigslot for the signals and slots architecture

At first we had decided to use wxWidgets, but this toolkit had been very difficult to work with, and the lack of popularity made it even harder to support.

By using the Qt 4.5+ library, we're guaranteed to use a consistent API for rendering the UI.
However, Qt has its own problems: The dreaded MOC precompiler, which forces us to limit our development strategies.

By adapting the sigslot library, we can get around source code precompilation and precompile generic widgets only once; These generic widgets will provide the signal handling to our new widgets which we can compile in 100% C++.

All software sooner or later faces crashes and / or hangs. This isn't a problem in itself - the problem comes when in the currently released version of a software, a poorly-designed default setting makes the program crash and/or hang at some stage of playback. Another problem with poorly-designed architectures is the difficulty to extend and adapt part of the program to make a fork. The lack of a solid and extensible architecture has already stalled at least one Video Editing project.

By applying the Multitier architecture and the Model-View-Controller pattern in the design (they're not mutually exclusive in my experience), we maximize the stability of the program, minimize the time invested in fixing bugs, and improve the programming efficiency of each developer. This also allows us to make the program extensible through the use of plugins or wrappers, and we are liberated from being tied to a specific multimedia framework - and hence, to predetermined video formats.

The separation of the user interface and the video editing framework will allow us to turn our Video Editor into a mere editor frontend, that other programmers can use for their own Video Editing projects.

Existing GNU/Linux Video Editors can only import clips in a limited range of formats. Others don't even warn you of unsupported file formats - they simply crash when you try to import a file with an unsupported format / codec. We will try to make sure that Saya can natively import video files in their native formats (i.e. DivX avis) without even having to recode the files first.

Note that some formats and codecs don't have a legal, open source implementation of the codec - unfortunately there's no way to get around this, but we'll try to make it easy for a third party to make a plugin that will be able to decode said formats.

Some video editor projects depend on their homebrew user interface, reinventing the wheel. This is the case for Cinelerra, whose file opening dialog poses (at least for me) several usability problems. Other video editors have an incomplete user interface, lacking some features that Windows users consider essential - including, but not limited to:

• tooltips
• Logical default settings
• Saving settings for the next session
• Context-sensitive help
• Meaningful Right-click menus
• Configurable shortcut keys

And that's without taking into account features expected in professional Video Editors, like multi-track, multi-sequence timelines, three-point video editing, markers, etc.

Saya is being developed with usability as its #1 priority. Also, several man hours have been invested in studying the user interfaces of professional video editors, such as:

• Canopus Edius
• Adobe Premiere
• Pinnacle Studio
• Final Cut Pro

For these, we have purchased manuals and downloaded hundreds of megabytes of screenshots, screencasts, tutorials, and webpages containing tips (and even rants of annoyed users) for the above editors. See the Research page for more details.

The following video editors fail at Microsoft Windows compatibility, as they were designed only for either GNU/Linux or posix-compatible operating systems:

• Cinelerra
• Diva (stalled)
• Kdenlive
• Kino
• LiVES
• Lumiera (in development)
• Open Movie Editor
• PiTiVi

Perhaps the GNU/Linux user can reply that "these days it's much easier to have Linux and Windows running on the same machine" at the same time. But this sidesteps the requirement of having to install GNU/Linux AND a Virtual Machine software in the first place. This clearly contradicts requirement #1: Ease of installation.

To solve this problem, we will use cross-platform libraries.

Ease of installation, a solid and extensible architecture, support for a wide variety of file formats and codecs, a user-friendly interface, and cross-platform compatibility are very important requirements for a good Video Editor. We consider that none of the existing open source Video Editors fulfill all of the above requirements - either because of the libraries/frameworks used, or because some decisions taken at design time.

The Saya-VE development team has nothing against the authors of these video editors. We fully appreciate their effort - we simply consider that there are inherent problems in the way they were designed / implemented. And for this reason the Saya Video Editor project was founded.

For this, we don't consider Saya-VE to be "yet another" video editor, but a completely different project. This is reflected in Saya-VE's recursive acronym: "Saya-VE ain't yet another Video Editor".

We are currently looking for volunteers. If you're interested, don't hesitate in contacting us.

Sincerely,
    The Saya-VE development team.