OS 14 has been released!
Version 14 is now available and the default for all new devices. The following information documented steps towards reaching that goal and improvements made since then.
Here’s a list of some improvements for the first Pi5 compatible release compared to the earlier ‘OS 13’ release. Additional improvements will follow in later posts:
-
Reworked the complete video output engine on the Pi4 to support both Pi4 and Pi5. It now uses KMS/DRM and is now future proof as it uses standard Linux mechanisms to do video decoding. Gone is the legacy MMAL API and the HEVC decoding hack.
-
Stable playback of HEVC video. The decoder can now also play multiple HEVC videos at the same time (assuming their combined size doesn’t exceed video reserved video memory for decoding). This makes HEVC a full replacement of H264 on Pi4 and Pi5. Of course H264 remains fully supported.
-
There is HDR support available on Pi4 and Pi5. Assuming the display indicates HDR support via EDID, info-beamer will try to switch the video output to a 10bit mode. This should allow playback of HDR encoded HEVC content.
-
Updated to the latest 6.6 Linux kernel series. This would normally mean that previously working GPIO scripts fail if they relied on /sys/class/gpio to access GPIOs. This is worked around within this release with the introduction of a special compatibility tool that allows continued use of the old mechanism.
-
Audio output via HDMI should now send audio to both connected HDMI displays.
-
CEC can now turn off both connected HDMI displays.
-
Various optimizations to work better on the original Pi1 and Pi Zero.
-
Updated bundled Pi4/Pi5 firmware release and reworked the update mechanism. Now on booting up the OS checks if the bundled version matches the one installed on the hardware. If not an attempt is made to flash the Pi.
-
Support for newer hardware release of the Edimax WiFi stick for older Pis without built-in WiFi support.
As usual: Feedback is welcome.
1 Like
Updated the testing
release. Improvements:
- Reworked HDMI screen blanking on Pi4/5. Now uses KMS blanking as
vcgencmd display_power
is no longer available.
- Amount of space reserved on an SD card now uses 10% of available space up to 512MB. This helps with smaller SD cards (in case you still have 1GB cards around )
- Added a way to transparently flip either one or both screens on Pi4/Pi5 devices with zero performance overhead. This helps with dual display setups if both displays are physically rotated differently. You can now also use the same setup on devices with different orientation. Flipping is by 180 degree only. Right now there is no way to easily configure this option on the dashboard. Stay tuned (or get in contact if you want to use this right now). EDIT: It’s actually possible to split this feature into horizontal and vertical flipping. So if you have a rear projector, the output can soon be flipped horizontally only. Stay tuned.
- Pi4/5 video decoder now properly handles single frame videos.
- Assigned video modes are now tested to ensure they work on the connected display. If not, the resolution is first reduced to 1920x1080 and finally to 640x480, so there is always at least some output.
1 Like
Updated testing
(now 240424-14917d
) again.
- Support for independently rotating/flipping one of both displays on Pi4/Pi5
- Support for overscan setting on Pi4/Pi5
- Support for ignoring HDR on Pi4/Pi5
- Updated kernel to 6.6.28 / FFmpeg to 5.1.4-rpi_24 / EEPROM to April 20th version
- Fixed some package properties (like streaming support) not getting activated properly
Updated testing
(now 240426-280b1b
):
-
Added support for content processes (allowing embedded browser content). See this very technical post. If you want to try it out on a Pi4 or Pi5, click this button to import the experimental package into your account. Be sure to update your testing release to the latest version (Device detail page > Manage > Activate testing channel). Do not use it in production please
Updated again to 240427-cb91f4
:
- Fixes content process code in info-beamer required to run the browser demo package linked in the previous post.
Updated to 240506-552176
:
- Fix EEPROM update condition on Pi4/Pi5
- Avoid briefly switching resolutions on info-beamer restart when changing setups.
- Fixed H264 playback on Pi4 (oops)
- Improved info-beamer to support both RGBA and BGRA pixel formats for future content process plugins
- Potentially improved rendering performance when using fully opaque textures
- Improved CEC handling. Might hopefully be more compatible with more displays?
Known issues:
- PoE hats don’t really automatically adjust fan RPM. Note sure yet why that doesn’t work: The necessary modules and overlays should all be there. See this other post.
Updated to 240515-125a8c
:
- Allow
YUVJ420P
and YUVJ422P
video frame format.
- Added a way to remotely show a small text overlay on demand. Could be used for another ‘second factor’ auth in the future or as a way to recover account access. This isn’t used yet.
Known issues:
- The PoE issue from above
- There’s still sometimes an annoying flickering of the last two frames when info-beamer is briefly stopped while switching setups. I’m not sure why that happens as nothing info-beamer is doing should cause that. It seems almost as if double buffering swaps between buffers while DRM/KMS is shut down. Odd.
Updated to 240712-b61773
and promoted to stable-0014
- Changing the device configuration now keeps the currently installed OS version
- Updated kernel to 6.6.33 and EEPROM to 2024-06-05
- Improved 270/90 degree rotation handling on Pi4/Pi5: No longer requires package specific workarounds
- Fixed a small memory leak when playing videos
- Updater process on the device can now install specific versions. This isn’t used yet but will help with future version migrations.
- Fixed flickering mentioned above.
Known issues:
- Some display names are not correctly detected. This will be fixed in a followup release soon.
2 Likes
Released testing 240821-01d6ef
:
- [Pi4/5] Fall back to FullHD (or potentially 640x480) if no display is connected and no video mode is configured.
- [Pi4/5] Support emulation for
hdmi_cvt
modes (see [Solved] I can't set custom resolutions)
- [Pi4/5] Added support for very old
/config/tvservice
config files.
- [Pi4/5] Video streaming improvements like an new
video:buffer()
call for video objects to query the buffer size in seconds as well as a more reliable start for RTP/UDP streams.
- [Pi5] Added support for power button press. Can be used by packages and also signals presses to the backend.
- Updated kernel to 6.6.45, EEPROM to 2024-07-30.
- Add overlays for more CM5 lite models.
1 Like
Released testing 240828-69d35d
:
- [Pi4/5] Potentially slightly faster boot time
- [Pi4/5] Reduce memory usage when playing more than one HEVC video.
- [Pi4/5] Reworked internal frame buffer handling. Prevents flickering in rare cases and fixes an incorrect API assumption regarding video textures: Turns out one has to use individual DMA handles per plane and not a single dumb buffer containing all planes, as that results in DMA file descriptors being closed too soon.
- [Pi4/5] info-beamer now supports non-blocking DRM commits as well as asynchronious snapshotting. But unused at the moment, but could be interesting. See this thread.
- [Pi5] Potential support for hardware sleeping: Powers down the Pi and wakes it up X seconds later. Could maybe be used to deep sleep if nothing is scheduled. But of course a Pi is then offline until the scheduled date and no amount of dashboard changes will wake it up before that.
- [Pi4] Reduce memory usage when playing H264 videos.
1 Like
Released testing 240904-80d628
:
- [Pi4/5] If no explicit video mode is set, a hotplug detection is now activated to monitor both HDMI ports. On change, the info-beamer process is restarted to readjust the resolution as necessary.
- [Pi4/5] When info-beamer tries to connect to (for now only) the embeddable browser process, the connection is reattempted if the browser isn’t running yet. This avoids having the browser sometimes not appear on first load if it’s too slow to start.
- Update Linux kernel to 6.6.47
Released testing 240914-8e59d0
:
- [Pi5] Added support for the Pi5 2GB model. Turns out there were quite a few tricky things missing: From a missing overlay without which booting was rudely interrupted by an instant kernel panic to changes required to Mesa that fixed GL output due to broken shaders.
- [Pi5] Optimized software decoding of H264 videos: Now avoids 180MB/s of memcpy calls per FullHD video or around 25% of the total video decoding CPU usage during playback of a H264 video.
- [Pi4/5] Reorganized DRM handling of 90/270 degree rotated videos. Moving between DRM and OpenGL rendering now no longer flickers for one frame, so videos can be rotated seamlessly at 60fps. This can potentially be used to transparently move video rendering between methods without visual changes to allow freeing up DRM resources if lots of videos play. This needs more testing…
- [Pi4/5] Explored the possibility of realtime capturing the screen output. Scaling down FullHD to 480x270 (so to ¼) can be captured as a 3mbit H264 video at 60fps already. Potentially better on the Pi4 with hardware H264 encoder. This feature isn’t usable yet…
- Updated Linux kernel to 6.6.51
- Updated EEPROM to 2024-09-10
Released testing 240917-381d3d
- [Pi4/5] Detection of disconnected displays. If a configured display isn’t detected for 10 seconds, a maintenance event is triggered and will soon show up in the dashboard.
- [Pi4/5] Process priority optimizations. The main info-beamer process now runs with the highest priority possible.
- [Pi4/5] Uses non-blocking DRM commits. Together with the previous item, this helps avoiding skipped output frames and achieves the perfect 60fps frame rate more consistently.
- [Pi3] In theory the Pi3 can also use the Pi4/5 version of info-beamer now. The only immediate issue is that taking screenshots crashes the process due to some unexplained “Out of space” error. Needs more investigating.
Released testing 240923-334ce8
:
- [Pi5] Optimized H264 software decoder yet again by only using a single pooled DMA buf per video frame.
- [Pi4/5] Provide executable name to content-process. This can be used to improve content process start up time by avoiding to load the content process into an overlay if configured in node.json.
- [Pi4/5] Prevent content process content from being drawn prior to being marked ready.
- [Pi4/5] Allow raw video players to transition to gl player. This can allow fancy transitions by switching from faster raw playback to gl during transitions like rotations.
- [Pi4/5] The same mechanism can now seamlessly mode rendering from DRM to GL and vice versa on demand or when required by how video layers are stacked. This can help render more videos at once without using too many DRM planes. This can also be used while taking screenshots to avoid having to double the active DRM planes as would be required without this feature.
- [Pi4/5] Reduce CPU usage by avoiding syncing of video frames if they are not being drawn.
- [Pi4/5] Use optimal DMA heap depending on Pi model: system heaps on Pi5, CMA on Pi4. This also means that there isn’t any real memory restriction on how many videos can be loaded on a Pi5.
- [Pi3] Fixed the screenshot problem from the previous release. The later Pi3 models should now also use the Pi4/Pi5 OS method of video rendering, including content process features like embedding a live browser. Get in contact if you’re interested in testing this.
Released testing 241002-d745a3
:
-
[Pi4/5] Improved overlap tests for video content. If multiple videos partially overlap, covered areas will not be drawn in most cases. This can greatly improve rendering performance.
-
Incompatible change in some very rare cases: Moved all rendering to premultiplied alpha blending. This is something that should have been done from the very start, but is necessary now due to how video rendering on the Pi4/5 works to ensure 90/270 degree rotated videos render correctly in all cases. In very rare cases when using custom fragment shaders in custom packages could this change result in incorrect visual output. If you have shader code like this:
gl_FragColor = vec4(1.0, 0.0, 0.5, alpha);
you must now use the following code if info-beamer uses premultiplied alpha, so the alpha value is multiplied to the RGB components:
gl_FragColor = vec4(1.0*alpha, 0.0, 0.5*alpha, alpha);
You can detect if this change is needed, in case you use a mix of old and new versions using:
if sys.provides "premultiplied-alpha" then
-- use new premultiplied-alpha shader
else
-- use old shader
end
info-beamer tries to automatically patch existing shader code used with resource.load_shader
based on a heuristic (which you can disable with node.set_flag "premultiplied-alpha"
, in which case premultiplied alpha use is assumed):
-
If there is a `uniform vec4 Color;" import in the shader, nothing is patched, as it is assumed that the color is multiplied with the result already like this:
gl_FragColor = the_shader_result * Color;
in which case it’s assumed that the primary alpha value is within Color
. As that’s already premultiplied, nothing needs to be done.
-
In all other cases, the following code is patched before the closing brace within the main
function:
gl_FragColor.rgb *= gl_FragColor.a;
If you have any questions about this, please get in contact!