(Or "Why we chose to make yet another video editor instead of helping develop the current ones")
by Rick Garcia - lead developer
The goal for our project is to make a Video Editor software with the following characteristics:
- Ease of installation
- Solid, extensible architecture
- Support for a wide variety of file formats and codecs
- Well-thought, user-friendly interface
- Cross-platform compatibility (and that includes Microsoft Windows(TM)!)
We'll talk more about them below.
Why making another Video Editor, when there's (insert your favorite GNU/Linux video editor here)?
According to my experience and research, current attempts at making a decent video editor for GNU/Linux systems have failed in one or more of the above-mentioned areas (as an example you can read this ubuntuforums post). These problems are inherent to these editors' designs. In other words, it's much easier to start a project from scratch than try to fix the shortcomings in the existing GNU/Linux video editors.
1. Ease of installation
Most existing GNU/Linux video editors face great problems when it comes to installing, the most significative of all is the dependency hell.
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.
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.
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 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++.
2. Solid, extensible architecture
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.