info-beamer hosted 15 released

The info-beamer hosted operating system gets a release. All existing Pi models, back to even the Pi 1 are still fully supported.

New Features

Improved video/rendering engine

On Pi models up to the Pi4, rendering output to the display could be achieved in two different modes. The legacy mode is using dispmanx and OMX. It was using proprietary libraries back from the days when the Pi's hardware was still showing its set-top box roots. It allowed composing the output on the screen using multiple layers in a way specific to the Pi. It did everything needed, was mostly reliable and pretty fast.

With the Pi4 and now the Pi5, the Pi people rightfully transitioned to using a more standard Linux approach of controlling video output by using DRM (direct rendering manager) and KMS (kernel-mode setting). For video decoding, FFmpeg is using standard Video4Linux decoding devices wrapping the decoder hardware. Gone are the days of just sending video data to a library in the hopes a decoded video frame falls out on the other side. Now everything allows precise control over the complete decoding process.

Unfortunately this also comes with a few caveats: Rendering a video rotated by 90 or 270 degree isn't something that's immedately available. Previous info-beamer releases worked around this by rotating via OpenGL in that case. This works well enough on Pi4 and Pi5, but results in quite a slowdown on older Pi3 models. Clearly that's not acceptable :)

Investigating with help from the Pi forum resulted in a workaround that almost completely restores previous performance on the Pi3 and improves performance on the Pi4. It's pretty technical and the linked forum post and community forums post goes into a lot of the details. This mechanism is now used on the Pi3 and Pi4. For the Pi5 this isn't usable, but also not required as it's fast enough to do the rotation in OpenGL.

NUMA on Pi4/Pi5

A workaround for how memory is accessed on Pi4/Pi5 can increase performance on those. It has to do with how the physical memory is accessed. NUMA (Non-uniform memory access) is a mechanism of organizing memory usage based on their access time. It allows giving hints to the OS about which memory to prefer to achieve the best performance possible. For systems with a lot of CPUs, accessing local memory could be a lot faster than accessing memory co-located with other CPUs.

It turns out that these mechanisms can help with performance even if no complicated memory layout is used. While the Pi has one single physical memory chip, accessing it with no special rules caused some contention and slowdowns. It turns out using NUMA to simulate a more complicated memory layout avoids this and results in quite a speedup in some cases. This wasn't enabled in the previous OS release as there still were some issues, but they are fixed now and the fake NUMA feature is now enabled on Pi4 and Pi5.

Following upstream versions

info-beamer OS update a few components to be up-to-date with the latest developments:

• Kernel is now 6.12.28
• FFmpeg is using the latest 7.1 version and the latest HEVC decoder.
• Mesa (the OpenGL driver) is updated to 24.2.8
• EEPROM version 2025-05-08

Other improvements and fixes

• RTSP video stream playback would not start properly in some streaming setups. This is now fixed and streams should start as expected.
• Sometimes the fan on PoE hats wouldn't rotate. This is now fixed.
• Improvements to the rendering engine also fixed potential flickering on 90/270 degree rotated videos.
• Auto repair of partition layout randomly introduced when the SD card is opened on a Windows machine.

The last one is a bug that still isn't fully explored yet. The current theory is that users sometimes put the SD card into a Window machine after finishing setting up their Pi, potentially to change some of the config files. It seems Windows sometimes then rewrites the partition table on that SD card either automatically (!?) or as a "repair" step. Doing so messes with the expected partition layout which then prevents the info-beamer OS from doing any upgrades or remote config changes in the future. This can be fixed remotely, but it's still annoying. This case is now detected and the OS self-repairs in that case to work around this.

Updating to the latest release

As usual, you don't have to do anything manually. Within the next months, your devices will be gradually upgraded automatically. Please get in contact with support if you have any questions.

If you want to upgrade manually, you can click on the Activate stable channel option in the Manage menu on the device page of the device you want to upgrade. This will install the new version and reboot the device once. Alternatively you can preinstall the update: Go to the device page, click on Manage and Toolbox.. and select "Trigger deferred update to 'stable'". This will install the update but won't reboot. This is especially useful if you're currently running the testing version of the OS.

Fetching the new version, upgrading the OS all happens in the background and only a reboot that should not take longer than 20-30 seconds interrupts playback briefly.

Questions/Feedback?

Head over to the community forums for questions or feedback regarding this release.