We’re running into issues with a browser based app running in the browser block when connected to a 4k display. Our browser based app plays videos and when playing HD 1080p video when connected to a 1080p display the performance is great. As soon as we connect the exact same raspberry pi4 with same content to a 4k display the performance is very bad. There is tearing in the video playback and the frame rate for the videos drops to a few frames per second. We’ve set the ENABLE_GPU environment variable to 1 for the browser block and it seems to make no difference. We have also tried the WPE block and while there is no tearing in the video playback on WPE it also has an extremely low framerate connected to the 4k display while the performance is great when connected to a 1080p display.
Additionally, we are unable to play any actual 4k content when connected to the 4k display. When we attempt to the playback fails and the screen just goes black. We have tried h264 and h265 videos and neither have worked. Not sure if these two issues are related.
Welcome to the boards @xogodev
I am sorry, but regardless of the settings, you will probably never get 4k playing smoothly on the RPi 4.
Sadly I cannot find the official reference at the moment, but in the back of mind I still got the info that the RPi 4 GPUs hardware accelerator for video decoding is limited to Full HD video size (and h.264 - not h.265 or HVEC or better). That means that 4k videos are decoded on CPU which results in horrific performance. So If you need to use a “big display”, the only possibility would be to downscale the display resolution to FullHD and recode the video to FullHD to get smooth playback. Otherwise you need to buy a more powerful platform like an Intel NUC.
Hello, @nmaas87, @xogodev
Actually h265 4kp60 should be hardware decodeable on pi4 ( cf specs )
Thanks edwin, yeah looks like you’re right. There is no 4k hw decode for h.264, but for h.265, also the RPi forums does acknowledge this limitation: Future module Based on bcm2711: Question about H264 decoding spec - Raspberry Pi Forums
Version 1 of the browser block used to have a raspbian base image (for Pi devices) with extra drivers for the GPU. However, the raspbian sources for chromium were really behind (when we moved to V2 I think Chromium was at v90 but the raspbian sources were at ~v73 or similar) and we were getting a lot of support threads about issues with the block which were down to the Chromium version. For version 2, we wanted to add the API to allow controlling the browser programmatically, but at the same time we also tried moving to a debian base image which had a much more up-to-date version of Chromium. It also reduced our maintenance burden, since all device types were now built from the same source. During our testing we found that there was no significant performance difference between browser block V1 (raspbian) and V2 (debian). We tested WebGL content (doesn’t render with GPU disabled, renders with it enabled) to prove the GPU support was working on V2 and that the framerates were comparable. And we tested that video content performance was the same.
However, our testing wasn’t exhaustive, and we didn’t test any resolutions above 1080p - so it’s conceivable that there is a performance loss by moving to debian, that we didn’t find.
Please could you try the following image for the browser block, which is pinned at the old V1 raspbian build?
Thanks for this additional info. I’ve tried deploying using “balenablocks/browser:V1” but it looks like the browser container just keeps crashing and restarting. Here’s what I see in the logs repeatedly:
Restarting service 'browser sha256:7c151f4803463a069c92927cd43f399d6763a82809fcd07a4bf9e00e8374e5ec'
browser Running balena base image entrypoint...
browser setting xserver-xorg-legacy/xwrapper/allowed_users from configuration file
browser Using default chromium flags
browser Enabling GPU acceleration
browser Adding user settings directory
browser Using fullscreen: 1920,1080
browser Using default window position
browser Enabling kiosk mode
browser Disabling cursor
Service exited 'browser sha256:7c151f4803463a069c92927cd43f399d6763a82809fcd07a4bf9e00e8374e5ec'
Does anything about the config for that block need to be different from what we were using for the newer block? Here is what we currently have for env vars:
While we wait to hear back from @phil-d-wilson (European timezone), I wanted to try to break this out a bit so that I make sure the testing thusfar is easy to follow:
- You have a browser-based application
- You need to run content on both 1080p and 4K displays
- You need the ability to run both 1080p and 4K content, scaled appropriately to the various displays
- You are running this content from a RaspberryPi 4
TEST 1: balena browserBlock
- used balena’s own browserBlock
- playing 1080p content to a 1080p display works as expected
- playing 1080p content to a 4K display results in tearing of video playback and frame rate dropping a few frames per second
- setting the ENABLE_GPU=1 environment variable doesn’t improve the experience
TEST 2: Igalia WPE WebKit
- used Igalia’s project which is based on WPE WebKit
- playing 1080p content to a 1080p display works as expected
- playing 1080p content to a 4K display has no tearing, but has an extremely low frame rate
TEST 3: older browserBlock version
- per Phil’s suggestion, tested
balenablocks/browser:V1, based on Raspbian / older Chromium version instead of Debian
- browser container crash loops so can’t yet test content
My colleague @jakogut mentioned that he has shared that he has several 2160p monitors and his Pi 4 is uses them at their native resolution, so I feel like this is possible at a hardware level (as Edwin pointed out, the RPi4 specs indicate support for H.265 at 4kp60 support). Maybe understanding the difference in these two setups can be of help.
I had a chance to catch up with Joseph and learned the following:
- decoding video is a very CPU intensive task
- 4k even more so, since it is quadruple the pixel count and bitrate of FHD / 1080p, all else being equal
- a lot is dependent both on the decoder and the software
His thoughts about your specific use-case were along the following lines:
- your content will need to be encoded in a format that the Pi4 can decode in hardware, like H.265/HEVC
- your player will need to be able to utilize that hardware decoder (NOTE: this probably won’t be Chromium based; the Raspbian browser supported hardware decoding by carrying patches which specifically enabled it, which is probably why their browser was (and maybe still is) a bit older - porting and maintaining those patches is complex and time-intensive)
- if he were in your shoes, he would try to find out what players will use the RPi4 hardware decoder and go from there; if you can find a player that meets your performance expectations, you can probably use (or write) a compositor to present it however you want
- alternatively, amazing 4k video playback would probably be easier to achieve (cheaper / less development and easier to do) on a NUC rather than an RPi4
What I gather from the conversation is that if you do indeed want to stay with the Raspberry Pi 4, you will definitely need to find a player that can utilize that hardware to accommodate 4k, or build one / have one built. This isn’t a simple driver limitation.
I hope that helps.
I’m seeing some interesting player options in this thread, btw. I wonder if one of those could be tested for performance and then balena-ified?
If it works fine with 1080p screens, something worth trying is to force the HDMI output to 1080p while connected to the 4k monitor. As the monitor should be able to switch to that resolution just fine. If the video you’re displaying is 1080p anyway, it shouldn’t make any visible difference.
There’s a table with the right codes and parameters in the Raspberry Pi Documentation
You can tweak those parameters at fleet or device level (in the
I would try those combination :
HDMI Group = 1
HDMI Group = 1
HDMI Group = 2
If you know the
HDMI output group, select the ones that match, or just try different combination.
hdmi_group command defines the HDMI output group to be either
CEA (Consumer Electronics Association, the standard typically used by TVs) or
DMT (Display Monitor Timings, the standard typically used by monitors). This setting should be used in conjunction with