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.

  • Apologies if this is a stupid question but will this make things better for S912 devices that had no fbdev Mali libraries released?

  • 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.

  • In the end it all depends on a users needs and what they will want going forward, especially in regards to refreshing cheap hardware every 2 to 3 years.

    S912 hardware will be perfectly fine for LE CE 9.x and Kodi Leia v18 and that is where currently the road will end due to the the valid reasons chewitt listed above.

    By the time that happens I will have had approx. three years usage out of current S912 hardware which is an eternity in Tech and it will still do all HD Audio and up to 422,10bit or 444,10bit HDR.

  • 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 Vorke v1 is a reasonably priced x86 alternative. However it has to be realised even the x86 has issues with some UHD content due to lack of a suitable intel driver.