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. )
In fact, the Pixel C only has a 4-core main CPU!
Now, the slight disadvantage that comes from this, is that certain apps will also make use of NEON, but not for real-time video playback. They will find there is no SIMD capability. One app which does this is ‘Kinemaster’, for the editing of videos. Kinemaster is normally able to handle multiple layers of creative content, and provides this ability under Android the same way ‘OpenShot’ or ‘Kdenlive’ supplies it under Linux.
In order for Kinemaster to perform all its functions flawlessly, it really requires NEON, and the application warns the user of this with a first-run message box. Kinemaster uses NEON in order to compute certain transitions.
But aside from that, my main worry was initially, that I am used to using certain video playback apps, and I questioned wither those apps can recognize the Hardware-Codecs which the Tegra X1 chip supplies, in order to make use of those.
My favorite app to use for video playback is MX Player Pro. This app requires some attention to install on every new tablet in my recollection, because we install a Codec alongside it, as a separate app from the app store, that corresponds to the best Codec for any one particular hardware-configuration. And unfortunately, when I download the configuration from an established tablet onto a newly-acquired one, the Codec package that was installed on the first, is automatically installed on the second by Google, regardless of whether that is actually the correct Codec for MX Player.
Because, unlike the other tablet, this tablet does not have NEON, it would be a mistake to install the NEON-based Codec that works with MX Player. In fact, the only Codec that makes any sense to my mind is the ARM v7 software-Codec, just to be sure that this player can play the maximum range of possible video-formats, if it ever needs to use software-decoding.
I needed to test whether this configuration works by recording a brief video of myself babbling in front of the tablet. Doing so with the built-in camera app obviously stores the video in one of the most common formats Google has to offer. And then, MX Player Pro was not only able to play back that video, but was indicating in the top-right corner of its information panel, that it was using Hardware to decode the video, without my having configured this in any deeper way.
If we go into the settings panel of MX Player Pro, there are options to software-decode the videos, or to use HW+ to decode them. And as far as I am concerned, those settings will override what the app chooses to do automatically, when they are checked off. So I think it best not to check any of those off. If MX Player runs into a video-format that has no system-provided Codecs to decode, I will assume that it will switch to software-decoding those, using the separate Codec I installed from the app store.
This has not happened to me yet, as of 14h24.
If the user selects HW+ as an available decoding option within MX Player Pro, then for every video format that this player can recognize as applicable, it will try to use a custom set of GPU instructions to decode. And while on the surface this might seem to have the same meaning as what Nividia has supplied us with, in reality it does not.
We have no reason to think, that the custom GPU-decoding suggested by this app, will be as efficient as the hardware-codecs that Nvidia has installed to the system, and which the app simply sees as available.
Therefore, to my mind it is also best to leave HW+ unchecked in the app settings.
(Edit 04/07/2017 : )
In order to make sure I have not given the reader any incorrect advice, I now needed to find some videos on my established computers, that have been stored in some weird format, which is unlikely to have a Hardware Codec, to decode those on the Tegra X1 GPU. This is an easy exercise for me, because I have plenty of things like that on file!
The two videos I tried next were:
- An MPEG-1 video, that according to my ‘MediaInfo’ Linux-application has a “custom matrix” (whatever that means).
- An OGV Theora video, which has not been modified in any way from the HTML5-version of OGG or OGV.
Both these videos play fine on my MX Player Pro, with both indicating in the upper-right corner of the screen, when the center of the screen is tapped during playback, Software playback.
What this implies, is that even though there will be an obvious performance penalty, the separately-chosen ARM v7 Codec runs fine on my ARM v8 64-bit, main CPU.
On the side I wanted to note, that the app “Paper Camera” is capable of running in motion-video mode on the Pixel C. I once had a device on which this app only worked in still-mode, because that device was lacking NEON.
My only explanation for why all of the Paper Camera features work on the Pixel C would be, that this app has been updated several times since, and that the current version does not absolutely require NEON anymore.
In fact, I know of a way in which this is theoretically possible. The app can turn on the device-camera in preview mode, which means that the physical camera is rendering into graphics memory. And from there, the GPU can apply effects to the image in real time using a Fragment Shader.
However, I would be overstating the extent of my own knowledge, if I said with certainty that this is how the devs of this app solved the problem.