Девять лет «почти»: почему Raspberry Pi так и не стал идеальным плеером для цифровых вывесок

Разработчик медиаплеера garlic-player потратил девять лет, пытаясь превратить Raspberry Pi в надёжный плеер для цифровых вывесок. Его путь — наглядная иллюстрация того, как инженерные компромиссы в «малиновой» платформе ломали даже простые сценарии.

Raspberry Pi не стал идеальным плеером для цифровых вывесок — разработчик просто перестал этого ждать.

Raspberry Pi уже давно позиционируется как универсальная недорогая платформа для всего: от учебных проектов до промышленной автоматизации. Одно из популярных направлений — цифровые вывески (digital signage): экраны в торговых залах, аэропортах, ресторанах, которые показывают расписания, рекламу, информационные виджеты. По идее, компактный компьютер за 35–80 долларов с поддержкой HDMI и видеовыхода должен идеально подходить для этой задачи. На практике всё оказалось гораздо сложнее.

Разработчик Нико Сагиадино опубликовал подробный технический разбор своего девятилетнего опыта работы с Raspberry Pi в контексте цифровых вывесок. Его плеер garlic-player — open-source проект с открытым исходным кодом, ориентированный на воспроизведение мультимедиа в составе информационных экранов. Путь от Pi 3 до Pi 5, который он описал, полезен не только энтузиастам вывесок, но и всем, кто планирует использовать «малину» для задач с видеовоспроизведением.

Pi 3: аппаратное декодирование есть, но вывод не ускорен

В 2017 году, на этапе Raspberry Pi 3, основная проблема была в архитектуре видеоподсистемы. Аппаратный декодер через API MMAL (Multimedia Abstraction Layer от Broadcom) позволял ускорять декодирование H.264 на уровне GPU. Однако ускорения видеовыхода — то есть передачи декодированного кадра на экран — не было. Qt-фреймворк, который использовал garlic-player для кроссплатформенности, не имел zero-copy пути (механизма, при котором декодированный кадр передаётся напрямую в буфер дисплея без копирования в оперативную память и обратно). Результат — рваное воспроизведение даже при загрузке процессора всего на 30%.

Частичным решением стал проект PiOmxTextures (PoT) от разработчика Луки Карлона. Он использовал части FFmpeg и Omxplayer для рендеринга видео напрямую в QML-сценах. На Pi Zero удавалось получить плавное воспроизведение HD-видео. Но появилась другая проблема: при использовании PoT переставал работать компонент webview — то есть встраивание веб-страниц и HTML5-виджетов. Без ошибок, без логов — просто не открывался.

Это убивало два ключевых отличия garlic-player от конкурентов: мультизональные раскладки (несколько зон с разным контентом на одном экране) и отображение веб-виджетов. Ветка разработки была закрыта.

Интересно, что другие коммерческие решения в то время выпускали ПО для Pi и просто декларировали «работает на Raspberry Pi», документируя известные ограничения. Подход автора garlic-player — добиться полной корректности — оказался контрпродуктивным с точки зрения сроков, но позволил честно оценить платформу.

Pi 4: обещания 4K и реальность 64-битной ОС

Raspberry Pi 4 появился в 2019 году с новым GPU VideoCore VI, значительно более быстрым процессором ARM Cortex-A72 и двумя портами HDMI. Для digital signage это выглядело прорывом: два экрана от одного устройства, потенциальная поддержка 4K.

Реальность снова внесла коррективы. Аппаратное ускорение видеодекодирования через FFmpeg работало только на 32-битной версии Raspberry Pi OS. 64-битная сборка, которая была более актуальна для приложений вроде garlic-player, оставалась в состоянии перманентной беты — и без аппаратного ускорения вовсе. Приходилось выбирать: современная 64-битная ОС или аппаратное декодирование видео.

Что касается 4K: воспроизведение работало только в полноэкранном режиме через VLC и только для одного конкретного профиля H.265. Поддержки 4K для H.264 не было вообще. Попытки воспроизводить 4K в оконном режиме приводили к сильным фризам, потому что аппаратные оверлеи (аппаратные слои наложения) не могли встраиваться в сложные Qt-поверхности.

Предыдущее решение через PoT тоже перестало работать — MMAL был объявлен устаревшим. Разработчик пробовал три разных мультимедийных бэкенда (QtAv, Qt Multimedia, libvlc), но каждый приносил свои проблемы, включая некорректные краши в libvlc.

Pi 5: шаг вперёд, два шага в сторону

Вышедший в 2023 году Raspberry Pi 5 наконец получил два важных для промышленного применения компонента: часы реального времени с батарейным питанием (RTC) и интерфейс PCIe. RTC критичен для цифровых вывесок: после отключения питания или ребута устройство должно знать текущее время, иначе расписания воспроизведения ломаются, TLS-сертификаты не проходят валидацию, а система управления контентом (CMS) отказывается соединяться с плеером. Решение — монетная батарейка CR2032 за пару долларов.

Но стратегия Broadcom по поддержке кодеков вызвала вопросы. На Pi 5 аппаратное ускорение есть только для H.265. Всё остальное, включая повсеместный H.264, декодируется программно на процессоре. Для справки: Pi 4 ускорял H.264, Pi 3 — ещё больше кодеков. За три поколения количество аппаратно поддерживаемых форматов сократилось. Это инженерный компромисс, связанный с переходом на новый видеоблок, но для интеграторов он означает дополнительную нагрузку на CPU и повышенное энергопотребление.

Последний удар пришёл со стороны Qt. На Raspberry Pi OS на базе Debian 12 (Bookworm) компонент Qt5 QWebView начал падать при попытке отобразить веб-страницу. Без ошибок, без полезных логов. Переход на Qt6, который мог бы решить проблему, требовал масштабного рефакторинга: из Qt6 была удалена библиотека QXmlPatterns, необходимая для работы garlic-player с XPath 2.0. Единственный open-source аналог — библиотека XQilla — не поддерживается с 2016 года и тянет за собой зависимость от Xerces-C. Замена работающего XML-движка на заброшенный ради исправления одного бага в webview не имела смысла.

Что изменилось к 2026 году

В 2026 году, спустя три года после последней стабильной версии garlic-player, разработчик снова попробовал — и всё заработало. Ключевых изменений было два.

Во-первых, мультимедийный бэкенд был заменён с FFmpeg/QMultimedia на libvlc. VLC имеет собственную систему декодирования и вывода, которая оказалась значительно стабильнее в контексте ARM-устройств.

Во-вторых, исправления в Qt WebEngine и в самом Raspberry Pi OS устранили проблемы с webview.

На Pi 4 и Pi 5 с обычной SD-карты плавно воспроизводится и 4K, и HD-видео. Мультизональные раскладки с одновременным показом видео и веб-контента работают корректно. Известные ограничения остаются: libvlc требует X11/xcb, поэтому работает только в контексте XWayland (совместимость X11 поверх Wayland). Нет также демона для удалённого перезапуска. Но это уже детали доработки, а не фундаментальные проблемы.

Плюсы и минусы Raspberry Pi для digital signage

Ретроспектива Сагиадино позволяет сформулировать объективный список сильных и слабых сторон платформы для данного сценария.

В пользу Raspberry Pi:

• Стабильность линейки — производитель не меняет hardware каждые полгода, как это часто бывает с дешёвыми Android-медиаплеерами.
• Компания с реальной open-source культурой — регулярные обновления драйверов и ОС на протяжении более десяти лет.
• Огромное сообщество и экосистема вокруг устройства.

Против Raspberry Pi:

• Ограниченная производительность и медленные интерфейсы.
• Отсутствие eMMC-флеша — SD-карты менее надёжны для промышленного применения.
• Непоследовательная стратегия поддержки аппаратных кодеков.
• Слабое аппаратное ускорение видео в FFmpeg, особенно на свежих моделях.
• RTC появился только в пятом поколении.

Практические выводы

Рекомендация, к которой пришёл автор после девяти лет экспериментов, реалистична и заслуживает внимания.

Raspberry Pi подходит для небольших инсталляций цифровых вывесок — когда устройств немного, они находятся в пределах досягаемости для обслуживания, а бюджет ограничен. В этом сценарии Pi 4 или Pi 5 значительно лучше многих Android HDMI-стиков и Amazon Fire Stick, которые страдают от перегрева, потерь Wi-Fi и закрытой архитектуры без прозрачного механизма обновлений.

Для крупных распределённых сетей с сотнями экранов на удалённых площадках Raspberry Pi остаётся слишком рискованным выбором. Каждый выезд технической поддержки на место обходится дороже, чем десятки плат. Для таких задач существуют промышленные решения от специализированных производителей с гарантией стабильности и удалённого администрирования.

История garlic-player — хороший пример того, как «почти работающее» решение может тормозить разработку годами. Платформа эволюционировала, но каждый шаг вперёд сопровождался регрессами в других компонентах. Ирония в том, что окончательное решение пришло не благодаря прорыву в «железе», а благодаря смене программного стека: замена FFmpeg на libvlc решила проблемы, которые аппаратные улучшения Broadcom не могли закрыть на протяжении трёх поколений.