Amlogic open source VPU decoder released

Things are in motion for Amlogic. I'd say let's get it working properly first, and deal with "less cpu consumption" later. If things work properly, the GPU will have to deal with most of the effort, while the CPU automatically can take the proverbial rest.

Maxime is an independent developer (not working for Bootlin) and we've been helping him find bugs in the decoder for 4-5 months already and as part of our long-term effort to bring Amlogic into the modern world with a mainline Linux kernel partnered with the next-generation Kodi (on Linux) video pipeline.

It won't make any difference to CPU consumption because it's a hardware (not software) decoder. I'm not aware of CPU usage being an issue with Amlogic hardware; other than some Amlogic SoC's being cost engineered and a little slower and weaker than others.

At the current time there is still no clear forward path for Kodi support on a mainline kernel (which is required to use Maxime's open-source V4L2 decoder) for S912 hardware. Future options (listed in order of probability and time) might include:

a) Using the swrast mesa driver to provide a fake software OpenGL environment. This is something we'll test soon (once developers stop being on vacation) but Kodi makes extensive use of GL animations in the GUI which will need lots of CPU to recreate and the S912 probably doesn't have the grunt needed. Disabling animations in the skin might help, and even if the GUI isn't perfect actual video can still be hardware decoded so playback should be okay (OSD performance issues are likely though). Armbian has done some experiments with software rendering under X11 (which is not a technical direction LE is interested in pursuing) that give an idea on performance.

b) Using libhybris (as the 3.14 kernel does). This approach could still work, but libybris needs to have Android kernel support that's broadly equivalent to the Linux kernel you're running and Android 8.0 support in libhybris is still in early stages. Android 8.0 uses an entirely new hwcomposer API for rendering and support for that needs all-new code and progress on this appears to be slow.

c) Using the panfrost open-source reverse engineered alternative to mali blobs. We've been tracking panfrost for a while and the lead developers are aware of LibreELEC and that we'd love to use it with Kodi to solve the lack of native libs. The main developers have some RK3399 hardware that uses T860 which is in the same family to the T820 used by Amlogic, but little time to work on support at the current time due to a range of other personal commitments. If and when there's some panfrost code to poke in the future, we'll be all over it.

In summary: unless Amlogic has a sudden change of heart on licensing (which is extremely unlikely based on past and recent conversations with management people and some knowledge of the $$ sums involved) the best-case scenario for S912 in the foreseeable future will be some kind of compromise. Our advice is still that people should avoid purchases of S912 hardware because there's a ton of "maybe" and zero guarantees in the above ideas.

To update:

a) After some basic investigation we found that swrast currently has hard requirements for X11, and our long-term plan (LE10) will see us drop all support for X11 (AMD and Intel move from X11/GL to a KMS/GBM + VAAPI (GLES) back end, and nVidia is probably discontinued) so we're not interested in pursuing that option much further.

b) No visible changes in Libhybris status, and this direction is still firmly seen as a hack by LE staff and Kodi staff.

c) The mesa driver is now capable of rendering on T860 hardware (used with the RK3399 boards and very similar to T820) in addition to T760 (used on RK3268) but the corresponding kernel driver is still at the earliest stages of being written. Great momentum building but a mountain of code to climb before we have anything useable.

In summary.. don't hold your breath for S912 mainline support.

The upstream vdec supports H264 and VP9 currently. HEVC is still work in progress so it will be software decoded. Other (older) codecs like MPEG4 and MPEG2 are a low priority for hardware support as even lowly S905 can software decode everything fine. You S912 nox should be able to handle 1080p media in the current state, but not 4K (as most 4K media is HEVC). The kernel stateful API changed in the semi-recent past and this broke seeking .. we're still trying to figure out what and where things need to be changed to make it work again.