## OpenShot-Qt Now Cooperates With Wayland Compositing.

One of the subjects which I blogged about before was, that the Debian version of OpenShot at the time, would simply freeze with desktop compositing on. That was the default, GTK version of OpenShot. Further, I can’t vouch for OpenShot under Windows because I think that the way it installs itself is botched. Yet, I am always keen to have such non-linear, 2D video editing applications available.

Well in the present, I have an up-to-date version of OpenShot installed, which is explicitly the Qt-version, installed as the package ‘openshot-qt’ on a Debian / Stretch computer. The main reason fw I have this version working, is the fact that I subscribed the computer I name ‘Phosphene’ to the Debian Multimedia Repository. Without access to this repository, Linux users can sometimes be hosed. In other cases, having its libraries installed can break dependencies with other software.

But this latest Debian Repository version of OpenShot-Qt (2.3.4), for Debian / Stretch, impresses me. Actually, when we first install it, the run-time won’t run, because of a missing library, that being ‘urllib’. This is due to the application package failing to state a dependency. This dependency can be resolved by installing ‘python-requests’ and ‘python3-requests’, which I believe also pulls in ‘python-urllib3′ and ‘python3-urllib3′. After this has been installed, ‘OpenShot-Qt’ runs.

When the developers upgraded their main build of OpenShot to version 2 (+), they needed to rewrite the source code for all the effects of the editor. And for this reason, the up-to-date version only seems to have 7 actual effects, that run over the duration that they’re applied for:

Such Effects can be applied to a clip, by dragging them onto the clip.

In contrast, because of the flexible way in which this editor defines Transitions – as grey-scale images, it still seems to have an almost unlimited supply of those, that transfer the foreground from one video clip to another (not shown).

But one way in which OpenShot makes up for its small library of 2D /time effects, is by giving its user a very powerful Title Editor, which actually invokes Blender, in order to create renderings of Titles with 3D effects:

(Updated 2/27/2019, 5h50 … )

## Why OpenShot will Not Run on my Linux Tablet

In This earlier posting, I had written, that although I had already deemed it improbable that the sort of Linux application will run on my Linux tablet, I would nevertheless try, and see if I could get such a thing to run. And as I wrote, I had considerable problems with ‘LiVES’, where, even if I had gotten the stuttering preview-playback under control, I could not have put LiVES into multi-tracking mode, thereby rendering the effort futile. I had also written that on my actual Linux laptop, LiVES just runs ~perfectly~.

And so a natural question which might come next would be, ‘Could OpenShot be made to run in that configuration?’ And the short answer is No.

‘OpenShot’, as well as ‘KDEnlive’, use a media library named ‘mlt’, but which is also referred to as ‘MeLT’, to perform their video compositing actions. I think that the main problem with my Linux tablet, when asked to run such applications, is that it is only a 32-bit quad-core, and an ARM CPU at that. The ARM CPUs are designed in such a way, that they are optimal when running Dalvik Bytecode, which I just learned has been succeeded by ART, through the interpreter and compiler that Android provides, and in certain cases, at running Codecs in native code, which are specialized. They do not have ‘MMX’ extensions etc., because they are RISC-Chips.

When we try to run CPU-intensive applications on an ARM CPU that have been compiled in native code, we suffer from an additional performance penalty.

The entire ‘mlt’ library is already famous, for requiring a high amount of CPU usage, in order to be versatile in applying effects to video time-lines. There have been stuttering issues, when trying to get it to run on ‘real Linux computers’, though not mine. My Linux laptop is a 64-bit quad-core, AMD-Family CPU, with many extensions. That CPU can handle what I throw at it.

What I also observe when trying to run OpenShot on my Linux tablet, is that if I right-click on an imported video-clip, and then left-click on Preview, the CPU usage is what it is, and I already get some mild stuttering / crackling of the audio. But if I then drag that clip onto a time-line, and ask the application to preview the time-line, the CPU usage is double what it would otherwise be, and I get severe playback-slowdown, as well as audio-stuttering.

In itself, this result ‘makes sense’, because even if we have not elected to put many effects into the time-line, the processing that takes place, when we preview it, is as it would be, if we had put an arbitrary number of effects. I.e., the processing is inherently slow, for the eventuality that we’d put many effects. So slow, that the application doesn’t run on a 32-bit, ARM-quad-core, when compiled in native code.

(Updated 10/09/2017 : )

## Lessening my Criticism of OpenShot

In this earlier posting, I criticized a non-linear video editor named “OpenShot”, stating that it was unstable. I think I need to both lessen, and pinpoint my criticism of this software.

At the time I was mainly having problems with the Windows version of OpenShot, which its developer worked long and hard to port to Windows. But the actual problem with OpenShot under Windows has to do with an environment variable named ‘QT_HOME’. When we install certain Linux-centric software under Windows, we are often instructed to set our ‘PATH’ variable to point to it. But with Qt-libraries, there is an additional variable named ‘QT_HOME’, which states what folders the Qt-libraries are to be found in. This is a global variable under Windows, even though we may have different examples of software installed, that use different versions of the Qt-libraries.

The way it is with me, I have ‘Kleopatra’ installed, which is also a Qt-based application which has been ported to Windows. Normally, a Windows executable will look in its own folder first, for an .DLL Files it needs, before looking in other directories.

But OpenShot is an application that comes with many Qt-library-files, located in its own directory or directories. And so to point the executable to these libraries, the OpenShot installer sets this environment variable.

The problem becomes, that when I next try to run Kleopatra, its Qt-executable respects this variable, and starts to try loading the Qt-libraries that shipped with OpenShot. Kleopatra does this, even though the developers of Qt have apparently forgotten that this variable exists because its observance is built-in to Qt.

The problem here is not strictly the fault of OpenShot developers. With Qt applications, the slightest mismatch between the Qt version the application was linked against, from the shared libraries it will ink to again, when it is run, will cause typical error messages. This problem has already happened to many users, who install Qt-based applications under Linux, that were not compiled and linked in-stream with the packaged version of Qt. In fact, when we install certain Qt-based applications that are out-of-tree in this way, we often need to do something like this:


rm -f libQt*.so*




In the folder of the software in question, to force that software to link to the Qt-libraries we have installed globally, instead of linking to its own version of these libraries, before the software will run.

So in my case, when the time came for Kleopatra to ask me for my passphrases, in order to unlock my private keys, this library-mismatch prevented the software from working. At first this might sound like some sort of malware-problem, but is really just a library-incompatibility-problem.

And so the only way I was able to clean up this problem on my Windows 7 machine ‘Mithral’, was to uninstall the Windows version of OpenShot, which its authors provided so carefully, and to delete this environment variable as well. Apparently, if this variable is set and the folder empty – or nonexistent – this is not enough to convince a Qt-application to link to its own Qt-libraries. In my case I needed to delete this variable as well, before Kleopatra became stable again.

Now, if a user only feels that he will be running software on his Windows computer, that uses one, global Qt-version, this could all look very different. But in my usage-scenario,

• The way I set up my Windows machine is different, and
• I have access to OpenShot on my Linux machines, for which reason I do not need this software under Windows.

I think that I had the additional problem on the machine I name ‘Phoenix’, that OpenShot once crashed my X-server, when instructed to play back a corrupted video file, in its preview window, but at full quality. Yet, I have already learned that ‘Phoenix’ has a weak, fragile instance of the X-server running… So this may also not strictly be the fault of OpenShot developers.

Dirk

## One disadvantage Kdenlive has, after OpenShot

On built-up Linux computers, we have two important nonlinear video editing applications available from the package manager: “Kdenlive” and “OpenShot”. As the naming would suggest, Kdenlive is centered on the K-Desktop-Manager, while OpenShot is not. Both use the Melt video processing library as their back-end.

(Edit: I goofed, first when I attempted to transcode the video using Kdenlive, and then again, when I wrote this posting about it.

What I had expected to find in the Project Settings of Kdenlive, was that the two “NTSC” formats be grouped together somehow, similarly to they are with OpenShot, starting with “NTSC”. Instead, Kdenlive has a long drop-down list, which is alphabetized by the software itself – not the programmers.

It has the setting simply named “NTSC”, which refers to the older, 4:3 version. But then, when the user wants to find the 16:9 version, he must scroll way up along the drop-down list, until he gets past the “HD” entries, all the way to the entry “DV/DVD Widescreen NTSC”. And then that setting will perform as expected.

Kdenlive therefore does not have this weakness, but my mistaken choice of output formats, was in fact the true reason for the malformed video file that resulted. )

There is a specific feature in Kdenlive, which does not work properly. To understand what is expected of this feature, the reader must first of all understand something about the background of analog video.

Back in those days, the NTSC, PAL or SECAM signal format assumed a 4:3 aspect ratio, which was later translated into a digital equivalent, which in turn simplified the resemblance to analog, by assuming a pixel aspect of 1:1. This first resulted in the VGA format. In other words, in order for a rectangle of square pixels to have a ratio of 4:3, it would have needed to be a 640×480 resolution image. Because of the way analog signals were processed in practice however, an analog video signal could never really distinguish anywhere near 640 lines of horizontal resolution. 483 vertical scan-lines were smeared horizontally by the filters, to result in maximally 480 horizontal points in the case of NTSC, and that would have been, assuming a comb-filter was used, which was also not available in the early days of TV. In reality, when the signal-format was adapted to DVDs, a strict NTSC format was defined, that consisted of 486 vertical scan-lines, but which had 720 points horizontally, a pixel-aspect of 8:9, and the frame-rate was kept consistent with the 29.97 Hz the analog signal had. This latter deal may in fact be important in video editing, because if an incorrect frame-rate is combined with correct sound-compression from today, an eventual loss of synchronization may result, after longer intervals of play.

At some point in time, picture-aspects of 16:9 started to become popular with DVDs, and their format was adapted to this, by making the pixel-aspect 32:27, and maintaining 720 horizontal points. The question follows, how this change in aspect-ratios was sent along to an analog TV, and the answer would lie in the fact that analog TVs had several modes with which to display a 4:3 signal on their 16:9 physical screens, one of which was to letter-box, another of which was to oversize, and another was just ‘to stretch to make it fit’. Viewers would simply observe that this last option sometimes produced distorted results and sometimes not.

I.e., Nothing was done to communicate the meta-data; the picture was simply stretched to 16:9 on-demand, by the viewer settings.

The sad fact about Kdenlive, is that somehow, it does not work with this notion correctly. As many video-editing applications may do, Kdenlive has a set of presets which the project is formatted to, as possible output-formats, and one of them is the Strict NTSC. This setting assigns some number of pixels, but still assumes an aspect ratio of 4:3, even when the user wants 16:9.

OTOH, OpenShot has a clear setting for NTSC, but in 16:9 instead of in 4:3. I have not tried them with PAL.

This failure of Kdenlive to process its meta-data correctly, has already slowed down one of my projects recently. I had a number of arbitrarily-formatted MP4 videos, and felt at first that the easiest way to transcode those into NTSC – 16:9, would have been just to open each in Kdenlive, but to set the output format to Strict NTSC. And the results were MPEG-2 -compressed streams which other, external player-applications could not play back.

Under the circumstances this was not a major setback, because I found an appropriate set of ‘ffmpeg’ command-line-recipes, which transcoded everything as I needed it. But a full-featured video-editing application needs to be able to make this format one of its targets.