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

Now, the Samsung Tablets tend to have as feature, 2 CPUs, each of them a quad-core, one a low-power, base-band CPU, and the other the high-power CPU. But the way I’ve found this to work in practice, the second, low-power CPU remains invisible to many Android apps, which simply report 4 cores (belonging to the high-power CPU). So my Linux-arrangement on that tablet, also cannot make use of the full 8 cores either, ‘which it does not see’.

screenshot_2017-10-07-22-18-36-e

Further, I’m using the Android app ‘XSDL’, to provide my Linux guest-system with an X-server. This app maxes out 1/4 high-powered cores for itself, leaving ‘GNURoot’ with only 3, to run Linux applications on.

(Edit 10/08/2017 :

One aspect to this problem which I did notice in the past, in another user’s experiences with Linux, might be relevant to this question.

Often, if the motherboard of a real Linux computer has 2 CPUs, each Linux kernel only has access to 1 CPU. Hence, in the case of my compatriot, he actually needed to have 2 kernels running, in order to be able to use 2 CPUs.

Rather than this issue being due to Android per se, it could just as easily be due to a behavior of the Linux guest-system… )

I suppose that the project could be redefined, that rather than using a non-linear video editor, we’d just like to run a Linux-application, on the tablet, that offers the option to concatenate shorter video-clips into one longer video-clip. And if this is what we’re looking for, then ‘mkvtoolnix-gui’ would be the package that provides it, and which should run just fine. But even if we’re using that, we’ll just need to give it however-much time it needs, to render its output. Rendering the output could again be slow, for the reason I’ve outlined.


 

Also, when we use an Android app to perform non-linear video-editing, such as ‘KineMaster‘, then this app will want for the tablet to posses a ‘NEON co-processor‘, which is an SIMD Extension that some ARM CPUs have. Because the ARM CPUs are otherwise RISC-Chips, even the suitable Android app could be handicapped at doing this sort of thing.

(Edit 10/08/2017 :

And, when the Debian packages were cross-compiled, I would expect this was not done in a way, that made use of the NEON instruction-set, because Linux philosophy is often, to keep the hardware-requirements to a minimum, and hope that the software will run on the oldest hardware-architecture still in use. )

(Edit 10/09/2017 : )

Another observation strikes me as relevant. Using the Android app ‘XSDL’ as my virtual, Linux-apparent X-server, I am provided with an optional library to preload, so that the Linux application ‘sees’ Android shared memory in place of Linux-shared-memory, and so that some applications can use this shared memory, for the familiar X-server extension, to output video.

One problem with this simple library is likely to be, that it won’t work with all Linux programming. For example, I would never try to preload it to my entire desktop-session, even though the ‘LD_PRELOAD’ variable, like all Linux environment variables, is inherited by child-processes from their parent-processes.

This causes a shared library to be used preferentially, to provide specific functions by name, presumably having to do with shared memory in this case, each time a new process is launched.

Since this add-on has limited complexity, and since OpenShot has been programmed with the Python interpreter as its core-process, there can be an issue affecting OpenShot.

The Python interpreter itself never uses shared memory. And then the way individual Python modules load is likely such, that each of them stays ‘dynamically linked, but statically-aware,’ of the shared (core) libraries which would provide shared-memory natively to Linux, thereby bypassing the preloaded library…

In which case another explanation has been provided, as to why OpenShot stammers and stutters, under Android. We’d be better off not to use the preloadable library at all then.

Dirk

 

Print Friendly, PDF & Email

Leave a Reply

Your email address will not be published. Required fields are marked *

Please Prove You Are Not A Robot *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>