VDPAU Playback Issue (Problem Solved).

One of the facts which apply to Linux computing is, that NVIDIA created an API, which allows for certain video-streams to be played back in a way accelerated by the GPU, instead of all the video decoding taking place on the CPU. And, users don’t necessarily need to have an NVIDIA graphics card, in order for certain graphics drivers to offer this feature, which is called ‘VDPAU’, an acronym that stands for “Video Decode and Playback API for Unix”. Simultaneously, what some Linux users can do, is to experiment with shell-scripts that allow us to click on a specific Application Window, in order to perform screen-capture on that Window for a specified number of seconds, ad then to compress the resulting stream into MP4, AVI, or MPG -Files, once the screen-capture has finished. This latter piece of magic can be performed using elaborate ‘ffmpeg’ commands, which would need to be a part of the script in question. And in recent days, I’ve been tweaking such scripts.

But then an odd behaviour crept up. My NVIDIA graphics card supports the real-time playback of MPEG-1, MPEG-2, DIVX and H.264 -encoded streams, with GPU-acceleration. Yet, when I clicked on the resulting animations, depending on which player I chose to play those with, I’d either obtain the video stream, or I’d just obtain a grey rectangle, replacing the captured video stream. And what I do know, is that which of these results I obtain, depends on whether I’m playing back the video stream using a software decoder purely, or whether I’m choosing to have the stream played back with GPU-acceleration.

I’ve run in to the same problem before, but this time, the cause was elsewhere.

Basically, this result will often mean that the player application first asks the graphics card, whether the latter can decode the stream in question, and when the VDPAU API responds ‘Yes’, hands over the relevant processing to the GPU, but for some unknown reason, the GPU fails to decode the stream. This result can sometimes have a different meaning, but I knew I needed to focus my attention on this interpretation.

Linux users will often need to have some sort of file-format, in which they can store arbitrary video-clips, that do not need to conform to strict broadcasting and distribution standards, even when the goal is ‘just to monkey around with video clips’.

I finally found what the culprit was…

(Updated 8/15/2019, 22h15 … )

All my desktop and laptop computers are Linux-based, more specifically, being Debian-based, but I enjoy having some of the simplifications which Windows offers, including either to notify me of pending updates, so that I can use point-and-click methods to install those, or even, in some cases, to install updates automatically. The package which I use, to install updates automatically, as I sleep, is called ‘unattended-upgrades’, which is a package which cannot simply be installed and forgotten. If the user has installed this package, he or she must also configure it. And the following Web-article explains, how to do so under Debian:

A situation I was having for some time was, that ‘unattended-upgrades’ was installed and working fine, on my Debian / Jessie – aka Debian 8 computer named ‘Phoenix’, but that even though I had followed all the instructions for how to install and configure it on my Debian / Stretch – aka Debian 9 computer named ‘Phosphene’, the same package did not seem to work on that one. I had often found that if there did exist updates which the automated process was supposed to install, then the log file on ‘Phosphene’ would break off, just before indicating which packages were going to be installed, and no updates would take place. This would happen every time that some updates were to be installed, and required each time, that I install the updates in question manually. Also, the ‘normal’ logging output did not include any error messages; it would simply stop in mid-process.

What I finally needed to do in order to troubleshoot this process, was to wait until there were going to be pending updates, and then, instead of installing those manually, to run the following command from the command-line, as root, and to observe the output:





Running this command when there were no updates pending was rather useless, because the malfunction would not take place, unless there were updates pending. Also, this process should not be interrupted if it’s in the middle of installing updates, because doing so can and will cause package-corruption and / or software corruption. If the process is going to install multiple packages, the user needs to wait until that process has finished, before doing anything else from the same command-line. What I finally found was, that the article linked to above omits a very important piece of information.

How to patch ‘kdeconnect’ to work under Debian / Stretch.

There exists an Android app named ‘kdeconnect’, which, when paired with the Debian / Stretch / Plasma 5.8 desktop widget by the same name, allows users to sync various features between their Linux desktop, and their Android device. The versions I’m presently using are:

• Android app: 1.12.9
• Linux package: 1.0.3~bpo9+0

Besides syncing certain basic messages, such as phone Notifications to the widget, this app allows for the desktop computer to browse directories on the Android device, which the user has authorized from his Android device – as long as the Linux desktop widget software has been patched! Below is another shot, of what this looks like when it’s working:

The main observation about this is the fact, that it does not work out of the box. The reason for this is the fact that the Linux widget is out-of-date, as a backport. The Linux-based software tries to use an SSH-FS Mount, that specifies ‘DSA’ as its crypto-algorithm. DSA is an outdated, insecure protocol, for which reason the application framework of Android no longer supports it! Android will demand that RSA be used as a minimum.

And so, due to this initial incompatibility, the SSH-FS Mount, which creates a virtual file system in the user’s home directory, in a hidden sub-directory, fails, with an error message to the user that doesn’t seem helpful. This error message simply complains that certain files and folders could not be found, that are supposed to exist remotely, from the Android device.

And so at first glance it might seem like an unsolvable problem. But as it happens, with this exact version of the Linux package, there is a fix, which I’ve been using for months. In the past I wanted to keep this patch to myself, out of fear that my readers might botch this delicate surgery. But I’ve had a change of heart, in that I want everybody to benefit from this app, even if they are using an outdated version of the Linux software. If the reader has the courage to perform this surgery, then the following is for you:

Installing Snap under Debian

The traditional way of installing software under Linux, specifically under Debian, has been, to use a package manager which accesses global repositories of software, and sometimes, to use a graphical front-end to the same package manager.

Thus, under Debian the package-manager command-line to install <somepackage> would be:

apt-get install <somepackage>

But, if we have “Synaptic” installed, that is a graphical front-end for the same set of commands, that I’ve come to like and trust. If we do not have Synaptic installed but wish to, then the way to install it from the command-line would be:

apt-get install synaptic

But what has happened in the Linux world is that this method of installing packages has become ‘boring’. There exists software which is not listed in the package repositories, and which Synaptic will therefore also not find in response to explicit searches, but which users will want to install, simply due to the evolution of software. One reason for which this software is not listed could be, that it would be tedious for package maintainers to compile, but another could be, the fact that some software is proprietary in nature, or at least partially so, so that to include it in the open-source repositories may in some cases be illegal.

And so, even Linux users will sometimes seek other ways of installing specific software, which they already know exists. And another way to do so has traditionally been, to compile this additional software from source code. But, sometimes the out-of-tree software we wish to install needs to come in the form of binaries. A recent development in this field has been, the emergence of a software-management system called “Snapcraft“. It’s based on the ‘Snappy’ package manager, that was developed by Canonical.

I’m going to assume for the moment that the reader already understands the existence of security implications, in installing binaries from anywhere except the package manager, together with the official repositories, even when those binaries are to be sandboxed. And I’m not going to explain those in this posting.

One reason for which Snappy exists, is the fact that some of the more-traditional installation scripts, for out-of-tree binaries, needed to make arbitrary assumptions about the organization of the Linux computer, and there are many different versions of Linux, which eventually lead to incompatibilities with the binary software. Their developers have had to make assumptions about how the customer’s computer was configured, and those assumptions will eventually be wrong for some versions of Linux. Snappy can circumvent this limitation, or so its developers claim. Whether it truly can or not remains to be seen, as Snappy is still in its infancy as I’m writing this. It could be that I just jumped in with a fashion trend, which may turn out just to have been a fad, as seen several years or decades in the future.

But this posting will continue on the assumption that the reader has a Debian Linux computer, but that he wishes to install Snappy anyway. Snappy was designed more with Ubuntu in mind, but is also available for Debian Linux.

(Updated 6/15/2019, 14h20 … )