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 : )

Whether to Refer to PHP Extensions or to PHP Libraries

In This Earlier Posting, I wrote that the PHP5 packages I have installed, include extensions that allow the PHP Scripts to act as a MySQL Client.

I suppose that one picky question to ask might be, ‘Should those not be referred to as PHP Libraries?’ Unfortunately, the answer is not as cut-and-dry as that might sound.

The way these files work is similar to how ‘Java Native Includes’ work. It has frequently been possible to do ‘Multi-Language Programming’, in which some subroutines are programmed in C or in C++, but are made visible to the interpreted language – that being Java, Python, PHP, etc., so that they can be called from that parent context.

But AFAIK, the way JNIs are usually linked, it is that actual File belonging to the Java installation, that receives the object code, from what started out as C or C++ source code. Therefore, this File would correctly be the Library.

A regular Library would just be an .SO File in Linux, or a .DLL File under Windows, which contains this compiled code, that resulted from C or C++.

The hesitation that I see, before referring to PHP Libraries, is twofold:

1. The Modules were not themselves written in PHP.
2. The File in question depends on the .SO File, but does not contain the actual object code, which has been linked into that .SO File. Therefore, the actual package ‘php5-mysql‘ depends on the additional package ‘libmysqlclient18‘, but contains the files


/usr/lib/php5/20131226/mysql.so
/usr/lib/php5/20131226/mysqli.so
/usr/lib/php5/20131226/pdo_mysql.so

/usr/share/php5
/usr/share/php5/mysql
/usr/share/php5/mysql/mysql.ini
/usr/share/php5/mysql/mysqli.ini
/usr/share/php5/mysql/pdo_mysql.ini



OTOH, The package ‘libmysqlclient18‘ contains the files


/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
/usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
/usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18
/usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18.0.0



What this means is that although the Files that actually belong to the PHP Package are linked as .SO Library Files, they merely act as a Wrapper for the files that do the work, and which were in the MySQL Clients Library Package, without which the PHP components could not work.

And so we do refer to these as “Bindings”, and I prefer to call them ‘Extensions’. The package manager refers to it as a “Module”.

Dirk