The Sort Of Software that will Not Run, on my Linux Tablet

In this posting I wrote, that I had installed Linux in a chroot-environment, on my old Samsung Galaxy Tab S, First Generation tablet, which remains an Android-based tablet. I did this specifically using the apps from the Google play store, named ‘GNURoot’ and ‘XSDL’, which do not require root.

Here, I gave a compendium of Linux-applications which do run in the resulting Linux guest-system.

I think that I need to point out a broad category of Linux applications that will always remain poor choices:

  • Audio Editors,
  • Video Editors.

The problem with any Audio Editor, is that it will eventually need to input and output Audio – not just edit sound files – and any Video Editor, needs to give a preview of all its video-clips – not just edit video files. This seems like a silly thing to write, but is non-trivial in my present context.

I have taken a Linux engine – GNURoot – and connected it to an externally-supplied X-server emulation – XSDL. The pipeline between these two Android apps is very narrow. It consists of X-server protocol – which is excellent and rendering text and GUIs, of shared memory at its maximum, and of a PulseAudio server, visible on the Linux side as such, but collectively running on the Android side as an SDL client.

I have no way to provide OpenGL or SDL on the Linux-side. What this means, is that virtually any non-linear video editor will want to see both installed on the Linux side, while neither is provided.

Continue reading The Sort Of Software that will Not Run, on my Linux Tablet

Google Pixel C does not have NEON.

I have been thoroughly enjoying my Google Pixel C, which I ordered only recently, and which I ordered because the actual tablet I have been using before, was only a first-generation Samsung Galaxy Tab S.

Sometimes we obtain many new features, but also at the expense of losing some feature. Because the ARM CPU is a RISC-Chip, the manufacturers of Android devices have sometimes made up for this by including a coprocessor called NEON. NEON is an SIMD – a Single-Instruction, Multiple-Data – coprocessor – aka a Vector-Processor, which is often useful to allow the decoding of high-definition video streams in real-time, without placing the burden of doing so on the main CPU.

(Edit 04/08/2017 : I have given my own definition of what “Hardware Acceleration” means, Here. )

What has happened with the Pixel C, is that Google has decided to put a Tegra X1 CPU into it, which is an SoC that also has a big coprocessor – its mighty GPU. With this tablet, real-time video-decoding is meant to be performed by the GPU, which advertizes several system-installed Codecs. Therefore, watching videos in high definition should not require a NEON coprocessor, and the Tegra X1 does not have one. (And, when I scroll further down the list of Codecs, that list includes two of the corresponding Encoders, from Nvidia, not only the Decoders. )

foxy_149159474357

In fact, the Pixel C only has a 4-core main CPU!

Continue reading Google Pixel C does not have NEON.

One disadvantage Kdenlive has, after OpenShot

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

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

What I had expected to find in the Project Settings of , was that the two “NTSC” formats be grouped together somehow, similarly to they are with , starting with “NTSC”. Instead, 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.

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 , 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 , is that somehow, it does not work with this notion correctly. As many video-editing applications may do, 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, 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 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 , 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 ‘‘ 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.

Continue reading One disadvantage Kdenlive has, after OpenShot