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

Continue reading VDPAU Playback Issue (Problem Solved).

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.