Allwinner processors aren’t the only ones getting an open source hardware video decoding / encoding support in Linux, as Maxim Jourdan recently submitted a patchset to Amlogic Linux mailing list adding a video decoder driver to some Amlogic processors.
The driver is written around the V4L2 M2M framework and currently supports MPEG 1/2/4, H.263, H.264, MJPEG, and (partially) HEVC 8-bit codecs. The driver has been tested with FFmpeg, GStreamer, and Kodi, and currently works on S905 (Meson GXBB), S905X/W/D (Meson GXL), and S912 (Meson GXM) processors.
Those processors also support HEVC 10-bit, VP9, and VC1 codecs, and while those are implemented yet, they should be in the future.
A separate commit adds support for “Overlay plane for video rendering” which support various YUV layouts and a non-alpha RGB32 layout, and will be useful for Kodi and LibreELEC ports.
I came to learn about those two patchsets thanks to Neil Armtrong (Bay Libre) who also mentioned he will talk about Amlogic open source video decoder and Kodi/LibreELEC ports during a session at Embedded Recipes 2018 taking place on September 24-25 in Paris, France.
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
author’s repo
https://github.com/Elyotna/linux/commits/4.18/amlogic-v4l2-m2m
I think most there chip manufacturer noted open source can make money for now
This code wasn’t released by Amlogic, Maxime Jourdan wrote it by using trial and error.
There’s no publicly available documentation of the video decoding unit.
U might clear things up for me . Now the video decoding unit is separate from thee Mali GPU correct ? what is this chip exactly called and what is the pros of opensourcing it
Video decoding was never done by Mali. So-called GPU Video Decoding applies only to PCs! In ARM SoCs there is a separate part of SoC which task is to decode and encode videos.
> Video decoding was never done by Mali.
How about Mali-Vnnn VPUs?
There’s virtually no info about Mali Vxxx in real SoCs. It seems that ARM asks too much for this IP so vendors like Amlogic and Allwinner prefer to design their own VPU solutions.
> There’s virtually no info about Mali Vxxx in real SoCs.
On Actions S500 at least Mali “vde driver” probed and loaded successfully:
…
[ 2.964416] #### insmod vde driver!
[ 2.968232] mali0 b0280000.vde: Probe vde device
[ 2.972851] info ic_type 0x5206
[ 2.976115] vde->irq =52
[ 2.978710] cputherm_register_notifier list 0
[ 2.986207] mali0 b0280000.vde: resource: iomem: [mem 0xb0280000-0xb0280107]2
…
(source: https://www.cnx-software.com/2015/10/14/linux-quick-start-guide-for-roseapple-pi-board-based-on-actions-semi-s500-processor/)
And it seems that “vde” in this case mean “video decoder”.
Yes, it has always been that way. Normally, the name of the VPU (Video Processing Unit) that handled decoding / encoding is not disclosed. The advantage of getting an open source version is that bugs are easier to fix, and you don’t have to rely on the manufacturer. For long term support project, that means even if the SoC manufacturer goes out of business, it would still be possible for third parties to implemented fixes.
Raspberry pi is somewhat closed but has provided years of good support.
What competitive advantage do manufacturers get in keeping the video decoder closed source?
Cheaper for them – less effort, less support, etc – just the bare minimum to actually claim their hardware has capability X (and only on the platforms they care about – Android)
They often buy third party IP, and are not allowed to distribute it’s details.
Also, they may have unintentionally violated someone else’s IP (happens all the time), but without available documentation, it’ll be hard to prove.