Вопрос: ПО для реализация показа рекламы в транспорте?

Лучший ответ: У нас в городе (Белгород) в автобусах стоят такие моники. Там картинка в картинке. В нижней части прогресс-бар сближайшими остановками, указана следующая.
В верхней части крутится плейлист из рекламы, всяких прикольных видосиков, новостей.
Этот же телевизор, если не ошибаюсь, говорит какая остановка, какая следующая, и напоминает, что нужно присматривать за подозрительными оставленными вещами и уступать место бабушкам и дедушкам.
Контекстной рекламы, как вы упомянули, мест, которые проезжаем нет, думаю пока нет. Мониторы появились недавно, локальные рекламодетели не вкурили еще потенциальных плюшек от такой рекламы. А можно, ведь, сделать её очень интерактивной. Можно фигачить QR-коды со скидками, делать конкурсы, викторины и заманивать прям людей толпами.

Технически вашу задачку я бы делал, особенно если на скорую руку, так:

Бэкенд
Сервер телеметрии - Rest API на AsyncIO с хендлерами для приёма статусов, событий и треков от фронта.
Контент-сервер - я бы его сделал вообще каталогом с синхронизацией через rsync на фронтовые машины. Для каждого маршрута свой каталог, причем в нескольких ревизиях, чтобы можно было поправить видеоряд и настройки, а потом откатав на тестовом стенде и пробной машине переключить на всех. Возможно, что на маршрутах окажется немного разное оборудование, и какое-то не будет тянуть, скажем, видео в хай-рес, а на каком-то, возможно сломался GPS и нужно временно крутить там контент без привязки к геоданным. Просто делаются отдельные ревизии для таких клиентов.

Фронтенд
На бортовом компе (какой нибудь Raspbery или Orange Pi) крутится "локальный бэкенд" и развёрнутый на весь экран браузер, смотрящий на локалхост.
"Локальный бэкенд" тривиальный, на Flask или чем-то таком. Нужен для упрощения и стандартизации доступа к контенту. Своего рода слой изоляции. Один из хендлеров - веб-сокет, читающий очередь гео-событий и предоставляющий данные гео-виджету. Можно и аяксом, кстат, без всяких веб-сокетов обновлять навигационный виджет. Тут как быстрее в рамках MVP.
Rsync демон - синхронизирует каталог с ресурсами маршрута. Можно по ssh даже. Его задача держать все ревизии контентных папок идентичными серверу.
Сервис телеметрии - подключается к северу телеметрии на бэкенде и шлёт туда текущие куски трека, кидает в локальную очередь гео-события для бэкенда.
Сервис обновления - по расписанию проверяет хеш-сумму контентных каталогов, отправляет уведомление на API бэка о статусе загрузки новой ревизии контента. Получает в ответ сигнал о переключении на новую ревизию и перезапускает локальный бэкенд из нового каталога.
Фронтенд - просто хромиум или любой другой браузер, развёрнутый на полный экран и подключенный к веб-серверу на локалхосте.
На бэке крутится маленький локальный сайт с медиаплеером, навигационным виджетом и чем угодно вообще. Это лучше нативного прилжения, поскольку программистов и дизайнеров для веба кругом навалом, js-программистов тоже, всё это отлаженные и понятные технологии. Куда лучше, чем пилить свою балалайку со своим рендером контента. К тому же это более-менее изолированная повторяемая среда, показ можно тестировать на десктопе.


Не сказал про плейлист.
Все ролики-то у нас лежат в локальном доступе на БК. В связи с этим можно избавиться от локального "бэкенда" просто открывая браузером статику. Локальный веб-сервис нужен разве что для подачи данных навигационному виджету, но если будет поджимать время, то в рамках МВП можно и через статические файлы прокидывать гео-события. Маршрутка летит не со скоростью света - интерактивности хватит. Если жалко флешку убивать перезаписями, можно примонтировать маленький рам-драйв под это дело.
Плейлист - это json-файл, в котором фактически расписание аудио и видеоряда по времени старта и остановки. Можно сделать прогрев кэша браузера вперёд по плейлисту, чтобы не фризило, но то, что можно смонтировать в монолитные ролики - нужно монтировать. Тем более браузерный плеер отлично понимает когда ему говорят откуда что играть и слушается команд из js.

Худший ответ: Реализовать монитор с LAN и удаленным управлением сложно - если брать стандартный ТВ с DLNA - не подойдет, DLNA требует внешнего управления и не может сам начать воспроизведение. Следовательно должно быть устройство которое само будет воспроизводить. Возможно управление воспроизведением с БК - а на самом устройстве запускается VLC с плейлистом по умолчанию, возможно скрипт создает этот плейлист при включении в зависимости от времени и местаположения. Местоположение и управление воспроизведением по алгоритму осуществляет БК - нет смысла пихать GPS в каждый рекламный модуль, в БК должен быть GPS для трекинга и навигации. Связь по LAN, управление VLC по http.

Возможно использовать и Медиаплееры на Android - но тут придется возиться с автозапуском воспроизведения. Самое простое OrangePi+Linux(Armbian)+VLC. Основной софт будет в БК. Сервер управления - тупой сайт с которым БК связывается, можно хоть через группы вк реализовать.