(This post is somewhat inspired by a blog post of another Pi company in the market, but seems like a great opportunity to reflect on how info-beamer approaches things)
info-beamer for the Pi’s first line of code was written in January of 2013 while porting the original PC version of info-beamer to the Pi 1. It quickly got obvious that no one could run this raw info-beamer software on a Raspbian based OS as too much Linux knowledge was required. Also it just wasn’t fun. So development of info-beamer hosted (the software-as-a-service solution) started 10 month later in November 2013 with the goal to make it easy to use without any special knowledge.
It was clear that the dashboard and cloud backend had to work together with the operating system running on each Pi. Just taking the default Raspbian OS wasn’t an option as it was both too big and missing certain key features required to make the playback software work reliably. And as the service doesn’t ship preinstalled hardware, the OS installation had to be so easy that it can be installed by really anyone with even minimal computer knowledge. So info-beamer OS was born.
One other vital aspect when designing the combination of content player (the “info-beamer pi” software) and the custom operating system was to maximize control over the complete software stack and to not be too reliant on other software for core features. Not only does this allow the tight integration info-beamer hosted now offers, but it also ensures that info-beamer works across all Pi models with maximum performance. Other services in the market often reuse the stock Raspberry Pi OS (as Raspbian is now called) and just add a thin layer of their own software on top. They then often rely on exiting software like omxplayer (may it rest in peace) or VLC for video playback. The former is now obsolete as it no longer works on the Pi 5 and the latter is nice, but still makes it difficult to get completely gapless playback of content, maximum performance when mixing video output with other content or accelerated playback across two displays.
With regards to the operating system, info-beamer OS is special in that it is both really tiny (just around 60MB total), yet works on all existing Pi models. It is designed from the core to be as robust as possible with atomic version updates (so either the update is completely applied of nothing changes), automatic rollback, self-checks and more. And trivial to install by unzipping a single ZIP file. All of those features are difficult or impossible when relying on Raspberry Pi OS. Thanks for the custom OS, a Pi set up almost 10 years ago will still receive the latest OS update today. All without touching the Pis SD card once after setting it up the first time. No Pi is left behind!
Similarly info-beamer pi (the content player running at the core of that OS) is completely built from scratch. In the early Pi days up to the Pi 3 it relied on proprietary broadcom APIs like their GL driver, dispmanx and OMX/mmal APIs for controlling video resolution, placing content on the screen or decoding videos. Those APIs worked fine, but it was clear to not become too reliant on them.
When the Pi 4 was introduced, a lot changed. The old GL driver was gone and MESA, an open source GL implementation, was used instead. Similarly dispmanx was already partially deprecated and KMS was used to select video modes. info-beamer OS version 13, released for the Pi 4, used a weird mix of both broadcom and standard linux APIs (the “Fake-KMS” mode). While that worked (and was recommended at the time), the writing was on the wall (and on the Pi forum) that this most likely won’t work with future Pi models.
Once the Pi 5 was finally released it became clear quickly that a complete redesign of core components of the player software was required: Controlling video resolution was now exclusively handled by the standard KMS (kernel mode setting) API. Controlling placement of videos and other content on the screen now only uses DRM (Direct Rendering Manager) APIs. Both work together nicely and getting it all working wasn’t too difficult as a bit or exploratory work was already done for the Pi 4 version. One other very welcome change was video decoding. Previously it relied on OMX or mmal, but those APIs were always poorly documented and somewhat limited in the ability to debug problems. info-beamer on the Pi 5 now uses a slightly modified FFmpeg library version. It allows fully accelerated HEVC decoding on Pi 4 and 5, as well as accelerated H264 decoding on Pi 4 and software decoding on Pi 5. The Pi 5 no longer has a hardware decoder for H264, but videos up to FullHD@60 can be decoded in software without losing frames as the Pi 5 is more than fast enough.
Using DRM for composing the HDMI output means that everything is as fast as possible which is helpful for smooth animations but essential when doing 4K video playback. Using zero-copy is the only way to get 60FPS: It means that the output of the HEVC video decoding process in FFMpeg is directly placed on one or two displays without any of the video pixel data having to be modified in between. info-beamer on the Pi 4 and 5 do exactly that and playback is perfectly smooth and reliable. Similarly on older Pi models the previous method is still used. The tight control over the player software means that these differences are not important to the actual code responsible for controlling what’s on the screen: Almost all info-beamer packages run unmodified across all Pi models. This would be impossible without controlling the complete stack all the way to the underlying Linux version.
Additional benefits are unique features not seen in any other software on the market: For example dual display support including video playback. Without explicit support and control over layout and video placement and tight integration with the part that sets up the video mode, this just isn’t possible.
One other unexpected feature requiring a rework is taking screenshots of what’s on the display(s). In the Pi 3 days, the dispmanx API supported creating a snapshot of what had placed on the screen. This didn’t require any coordination between the player software and the software taking the snapshot. This is no longer possible on the Pi 5 as dispmanx is no longer supported and DRM must be used. DRM doesn’t allow arbitrary processes to freely mess up each other’s state and instead a single process is in control. Taking screenshots has thus moved into the player software itself which temporarily sets up a “writeback” connector, essentially a virtual screen, and instructs the hardware to not only render to HDMI but also into this virtual screen, which can then be compressed and sent to the dashboard on request. Again without the tight integration this would not be possible without degrading performance.
The Pi 5 was a necessary wake up call to finally move everything to standard APIs and the path forward looks promising as FFmpeg, MESA, KMS and DRM are unlikely to get deprecated anytime soon as they are the reasonable default on Linux (if you own a SteamDeck handheld gaming console: they use that too). The Pi 5 is now fully supported with the latest OS release. info-beamer is ready for the future!