In a world where a new single board computer (SBC) comes out every month it has become impossible to maintain all the proprietary methods that are used with the boards. A movement towards a unified windowing method and unified decoding methods has started. For Kodi version 18 a Direct Rendering Manager / Kernel Mode Setting (DRM/KMS) windowing method has been implemented. This allows any device that has a Linux kernel DRM driver to run kodi. The next step is video decoding, where each SBC has it's own specific decoder and software to run it. The Linux kernel implements a Video4Linux2 (V4L2) subsystem where drivers can register a decoder to be used under a common API. Kodi needs to be able to use a zero-copy path in order to display these decoded frames on the screen. For this to happen we need to use DRM-PRIME buffer sharing and specific EGL extensions to present the frames. All this together will allow Kodi 18 to run on a vast variety of SBCs that have DRM driver and a V4L2 driver available.
In order for Kodi to present decoded frames along with the GUI multiple hardware planes are needed. To use multiple planes we will make use of the DRM subsystem. Atomic DRM allows control over each page flip and what is presented by each plane within one atomic commit. In Kodi this allows showing the Kodi GUI in the overlay plane and the decoded video frames in the primary plane. The decoded video frames exit the decoder in a semi-planar YUV format called NV12 (other formats may be possible as well). These NV12 frames can be presented directly in the primary plane and the DRM subsystem handles the scaling and rotation.
Presenting directly to a DRM plane has some downsides that need to be addressed. Depending on the DRM driver things like scaling and deinterlacing may not be supported. In these cases a separate rendering method has to be used. This other rendering method is entirely done in OpenGLES using the EGL extension EGL_EXT_image_dma_buf_import. This method allows directly importing the NV12 video frame into OpenGLES and manipulation can be done from there via GLSL shaders. Kodi already implements shaders that do the YUV to RGB conversion needed to output the image to the display. These shaders also implement scaling via various methods (lanczos, spline36, etc) and deinterlacing via bobbing.
All this together will allow SBCs such as NXP i.MX6, Allwinner H3, Rockchip 3288 and 3328, Qualcomm Dragonboard 410c, and many more to work with Kodi without implementing any new methods. This work is underway is largely merged into Kodi master already.
