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