Intro
My relationship with the Raspberry Pi has been ambiguous for the last nine years. On the one hand, I think it could be the perfect low-cost digital signage player. But the devil is in the details. And he enjoys fooling people's expectations. In 2019, I even wrote a big article for my company advising against a Raspberry Pi for serious digital signage. Seven years later I published a tutorial on how to do exactly that. This is the story of what happened in between.
Since 2017 I have been trying to bring my garlic-player to the Raspberry Pi, and I failed constantly until now.
The Pi3 Story
On the Pi 3, FFmpeg accelerated the codec in hardware via the MMAL API, but there was no acceleration for video output. In particular: The Qt lib made the player platform independent. It also had no zero-copy path for display output. The result was crackling video even at 30% CPU load.
A solution in 2017 was to tinker with Omxplayer. This software decoded completely on the GPU and it worked well for the H.264 codec. A guy named Luca Carlon managed to create a backend which uses parts of FFmpeg and Omxplayer to render videos directly in QML scenes. He named the project POT - PiOmxTextures.
The first problem: in 2017 garlic-player was based on a QWidget interface, while PoT was QML. It was necessary to split my app in a lib and a player component. Then I coded a QML player as a second option next to the QWidget player part. Days of refactoring just for one video codec. Fortunately, QML was required for Android multimedia anyway.
In 2018, I managed to stick everything together and got perfectly smooth HD video playback even on a Raspberry Pi Zero. But then another rock hit. For a reason I never found out, it was no longer possible to open a webview component while using PiOmxTextures in QMultimedia. No error. No log. Just nothing.
Videos now worked great in fullscreen, but HTML5 Widgets and websites failed. Multi-zone layouts also became a problem. That meant two garlic-player features which made it different from other free solutions were killed.
After a few weeks I closed the branch and did not touch it again. The mistake was aiming for perfection. Many companies instead released their Raspberry Pi software and communicated known problems and restrictions. Just to have the marketing line: It runs on a Pi.
I do not like this style, but that does not mean it did not work.
The Pi4 story
In 2019 the new Pi 4 came out, and I wanted one immediately. Since I lived in Greece at that time, I even asked an expat friend from Munich, who was already in the middle of his travel preparations, to buy a device asap and bring it to Corfu.
The Pi 4 again came without eMMC flash, but with a new GPU, a much faster CPU and something almost unique for IoT: two HDMI ports.
The first attempts were promising, as 1080p videos now played without crackling via FFmpeg, but acceleration was available only on the 32-bit OS. The 64-bit Raspbian, which was more interesting for garlic-player, seemed to become an eternal beta, and on top of that without any acceleration. Pick one: modern OS or hardware decoding. Even Luca's solution did not work anymore, as MMAL became deprecated.
One more disappointment on top: 4K videos worked only in fullscreen in VLC player and only for one specific H.265 profile. No support for 4K with the H.264 codec. 4K in a window and in garlic-player resulted in ugly stuttering, because the hardware overlays were efficient but could not be embedded in complex surfaces like Qt widgets. Garlic-player used FFmpeg via QtAv and additional Qt Multimedia as its multimedia backends at that time. I even added a libvlc implementation as a third backend. It crashed in ways I could not reproduce.
I soon became frustrated again. On the one hand I was impressed by playing four videos in parallel in the 64-bit beta, but this was software decoding only. Nothing for a serious digital signage project that has to be rolled out on hundreds of remotely maintained screens. A demo is not a product.
The machine I technically considered a perfect low-cost 4K digital signage player turned out to be a minefield of pitfalls, "almosts" and "buts".
In the following years I focused on Android and built the garlic-launcher, because my partner had more and more project requests based on Android hardware.
The Comeback Years Later
In 2022, I realized for the first time that something had changed significantly. There were some optimization, Wayland, labwc, many small performance enhancements and a V4L2-M2M decoder at least for VLC. I bought a Pi 400, and in 2023 it finally played a surprisingly smooth 4K H.265 video, even in a window. It was not perfect, but it gave me some hope for the next incarnations.
The Pi5 Story
In 2023 Raspberry Pi 5 was released. Although again without eMMC Flash it got at least a battery-buffered real time clock and a PCIe interface. An RTC is crucial for digital signage. After a crash or reboot the player starts with the correct date and time. Playlists now play time-scheduled content correctly even when the player is offline. With the wrong time, TLS certs can fail and the CMS will refuse connections. A two dollar battery fixes all of that.
But again there were some weird technical decisions: higher energy consumption, which required a fan, and a big slap in the face for digital signage applications, namely hardware acceleration for H.265 only. Everything else was deprecated and decoded on the CPU. The Pi 4 still accelerated h264, the Pi 3 even more. Three generations, and the codec support went down. I realized that the Raspberry Pi would never be the perfect solution for huge digital signage networks, so I lowered my expectations.
Then Qt5 QWebView started crashing on Raspberry Pi OS based on Debian 12 (Bookworm). The moment you wanted to display a website or an HTML5 widget: crash. No information and no real bug reports, just a recommendation to use Qt6. As far as I know, nobody knows why to this day. So again I was stuck with problems I could not solve for a serious release.
Qt6 was not an option for me. The migration alone would have been a huge amount of work, and QXmlPatterns was removed in Qt6. The problem is that garlic-player needs XPath 2.0 functions. The only open source C++ library that supports it is XQilla, unmaintained since 2016, badly documented, and dragging in Xerces-C as a second dependency on every platform. Replacing a working XML engine with a dead one plus extra build complexity made no sense. There are other ways to solve this, but not as a side project while chasing a WebView bug.
I tried to offer experimental images based on pi-gen for the Pi 4, but pi-gen is suboptimal and complex, and after a while it started to produce 32-bit binaries instead of the configured 64-bit ones. At that point I was too annoyed to invest a significant amount of time in finding out why.
Finally the surprise
In 2026, 3 years after the last stable of garlic-player, which is another story of silly perfectionism claims, I tried again on Bookworm and Trixie. This time with a self compiled version of the last Qt5 lib (5.1.5.19) and surprisingly everything worked. Everything. On the first try. So I decided to release a 1.0 version of garlic-player and offer an official AppImage for the Raspberry Pi. It seems there were some fixes in Qt WebEngine and in Raspberry Pi OS which makes everything working.
So what changed after all these years?
Garlic-player on Linux ARM now uses libvlc as its multimedia backend instead of FFmpeg and QMultimedia. That was one of the keys. The setup runs on a Pi 4 and a Pi 5 with a plain SD card. 4K and HD video playback runs smoothly on both devices. And the problem which killed my motivation back in 2018 is gone: multizone with video and webviews at the same time simply works now. The libvlc solved the video part, the Qt fixes solved the webview part.
See the result in this Raspberry Pi Digital Signage Setup Tutorial, the final conclusion of a journey full of disappointments that I never really gave up on.
There are known limitations. Libvlc needs X11/xcb, so it only runs in an XWayland context, and there is currently no control daemon for remote restarts or reboots. Both are on the list, but at some point you have to stop nitpicking and ship something that works.
My biggest lesson was to stop waiting for the perfect version of anything. The obsession with perfection kills ideas, motivation and energy. But as I wrote above, that is another story.
The Pros and Cons of Using a Raspberry Pi for Digital Signage
The Pros
- Stable production for years and not permanent new hardware every couple of months like many cheap Android media player overflowing the marketplaces
- A company behind it with a real open source mindset, constantly supporting and updating drivers and the operating system to current versions
- An engaged maker community has created an amazing ecosystem around this device
The Cons
- Slow hardware and interfaces
- Sometimes poor strategic company decisions
- Lack of eMMC flash
- Poor video acceleration in FFmpeg
- No battery-buffered real time clock until the Pi 5
What does the Nine Year Older Niko recommend now?
In summary, the difference to my old article from 2019 is not that big. Yes for small installations, no for big ones.
Yes, if:
If you are low on budget, you are able to handle Linux and need to manage a modest number of devices over a network, you can use a Raspberry Pi 4, or better a 5, without any hesitation. Go for it. Especially, as long as you can easily get to the location and fix errors.
I would say it is even a much better choice than many Android HDMI sticks or the overhyped Amazon Fire Stick. In many HDMI stick projects I have seen overheating problems or Wi-Fi dropouts. My personal opinion, especially about the Amazon stick: they just label a consumer device as digital signage and advertise it as a technical enhancement. Probably some modern Midas touch. Overall it is a black box without easy control over updates and remote maintenance. A Raspberry Pi at least has transparent driver support and continuous updates, proven for over a decade.
No, if:
For bigger installations, especially with several far away locations, the risk is too high. In the end, the Raspberry Pi is a tinkering system created for prototyping and makers. Of course, it is usable, but for a big network you need rock solid stability. That is not the place for a tinkering device.
You should consider serious and proven hardware manufacturers which do not compete just with price. Every buck you obsessively try to save can cost you a multiple of it later, at least when a support team has to travel to the location for a fix. One service trip eats ten Raspberry Pis.
The Raspberry Pi did not become the perfect digital signage player. I just stopped waiting for it. Finally, after all these years, I still like this little machine.
Top comments (0)