One of my retirement hobbies has been shooting and editing videos, mostly of our bicycle adventures. When I was young, back in the middle of the 20th century, one of my uncles had a movie camera and projector, and I learned to splice broken film and edit clips together with razor blades and transparent tape. He moved away and I grew up, and the skill was filed away as just another data point in How The World Works.
Fast forward to the second decade of the 21st century, when I decided to strap a cheap digital camera to the handlebars of the bicycle. Digital editing requires software, a much less messy and more forgiving (i.e., non-destructive to the original “film”) process. Since we use Linux exclusively as our computing platform of choice, there were a number of choices for Open Source video editing projects, mostly attempts to clone commercial video editing software for Windows and Apple.
I looked at Cinelerra and Kdenlive, which are fairly complex tools with a steep learning curve, but settle on OpenShot, a simpler tool with a lot of attractive features and a cleaner, no frills user interface. Openshot 1 was essentially a one-man project, a user interface written in Python with the Tk graphical toolkit, built on the Unix principle of lots of little programs working together, using the multimedia command-line editor ffmpeg and associated libraries, the Inkscape vector graphics editor, and the Blender animation tools and libraries.
OpenShot made it possible to load up a project with multiple clips, arrange them on a timeline, trim the ends or snip out shorter clips, and add titles and audio tracks, like voice-over and musical scores, in multiple overlaid tracks, and turn video and audio on and off by track and clip. For several years, this worked fine. However, success is not always a good thing, and Openshot suffered from it. Not in the usual riches-to-rags story of an entrepreneur or rock star who descends into excess and loses his way, but in the attempt to seek wider appeal.
OpenShot was originally a purely Linux product, as mentioned. To port the project to Windows, it was necessary, for a project with limited manpower resources, to keep a common code base. Openshot attempts to keep a smoothly flowing user interface through parallel processing, using OpenMP. The Windows philosophy is based on a single-user, single-task model rather than the multi-user, multi-tasking model of Unix. When Windows evolved into a multi-tasking system, it used the pre-emptive model, which is relatively inefficient for the pipelined processing flow in the Unix cooperative model. So, Windows applications tend to be monolithic, with all resources loaded in one huge process. Parallel processing in Windows monolithic applications is accomplished largely through threads, rather the inter-process communication protocols. I’ve programmed with threads in Linux, which tends to be tricky at best, and takes a thorough knowledge of parallel processing and memory management to do successfully.
The move to Windows-compatible architecture necessitated rewriting a lot of the Unix-specific standard library code in C++, which introduces the danger of memory-management issues. Openshot began to get buggy, with newer versions crashing often. The developers claim it is the fault of unstable system libraries, but I’m not buying that explanation. Since the user interface was also getting a major overhaul, work on version 2 meant that no more bug fixes were forthcoming for the now-crippled version 1.4.3. Alas, initial releases of Version 2, with the back end still largely 1.4 code base, was also prone to crashing as well as presenting an unfamiliar user experience.
So, we stayed with version 1.4.3 for a while longer, with short auto-save intervals. Finally, with crashes and deadlocks rampant, we just had to try version 2 again. Yes, the crashes had been largely fixed, but the new version was a monolithic package wrapped in a “launcher,” (AppImage), apparently a type of container tool including all of the library dependencies, which rapidly ate up all available memory and much of the swap space, becoming so slow as to be indistinguishable from deadlock. Memory leaks come to mind when seeing this type of behavior. On top of that, some of our favorite tools for controlling video blanking and audio muting by track were missing, to be restored by popular demand in a future revision. Back to 1.4.3 .
The other alternative, kdenlive, based on the Konquerer Desktop Environment (kde, not native to Ubuntu, thus necessitating loading the complete KDE library support suite), is yet another learning curve, with many editing feature differences and rendering options. We did use this for one video, as the internal de-shaking algorithm is a bit more efficient than reprocessing the clips with command-line utilities, and we had a bad experience with a new camera mount that was sensitive to shaking. Kdenlive also crashes from time to time, lending some credence to the Openshot claim that the system libraries are at fault.
But, I continue on, putting up with slow response, freezes, and crashes, because I’m familiar with the features I like, and it produces acceptable videos. I may spend some time to learn kdenlive, but, hopefully, Openshot 2 will improve over time. The other alternative is to try to build a native Ubuntu version from source, which is a daunting task, since most open source software has a very specific support software version dependencies. Despite the woes with Openshot’s growing pains, it is still faster than writing command-line scripts to use the Linux multi-media-processing utilities ffmpeg or avconv to trim and assemble video clips and sound files. I use those command-line tools to assemble time-lapse videos from my home-built security camera system, but that is much simpler.