Software for displaying ads in transport?

Question

Electronics

Good afternoon, colleagues! I ask for help, there is a project for the implementation of displaying advertising on transport. What would it have and hardware components:
1. Remote server
2. On-board computer on Linux
3. Monitor with LAN connection to the bookmaker

Advise software or are ready to consider the possibility of working together
1. The server has software for its task
a. Choice of route
b. send to all vehicles along the route a certain playlist with data
c. get a report on the receipt of the data download
2. On the bookmaker
a. get and save data in a folder
b. create a playlist (it is possible to include some videos based on GPS data - we are passing, for example, dentistry)
in. Reduce the volume or turn off the video and show the name of the stop
d. It is possible to overlay some data on the video (for example, drive to a stop so much ) e. automatically
start the video when power is supplied (no need to press anything)
f. automatically restart when the power is temporarily turned off
g. automatic repeat of the entire playlist
h. playback from SD, USB flash cards, and hard drives j
. decoding of DivX, XviD, AVI, DVD VOB, MPEG1-4 formats
e. does not show titles like PLAY, VIDEO when turned on, and between clips

Answer 1

In our city (Belgorod) there are such Monicas on buses. It's a picture in a picture. At the bottom of the progress bar are the nearest stops, the next one is indicated.
At the top, a playlist of advertisements, all sorts of cool videos, news is spinning.
The same TV, if I'm not mistaken, says which stop, which is next, and reminds you to look after suspicious left things and give way to grandparents.
Contextual advertising, as you mentioned, there are no places that we pass, I think not yet. Monitors have appeared recently, local advertisers have not yet tasted the potential benefits of such advertising. And you can, after all, make it very interactive. You can cheat QR codes with discounts, make contests, quizzes and lure people in crowds.
Technically, I would do your task, especially if in a hurry, like this:

• Backend
  
  • Telemetry server - Rest API on AsyncIO with handlers for receiving statuses, events and tracks from the front.
    
  • Content server - I would make it generally a directory with synchronization via rsync to front-line machines. Each route has its own catalog, and in several revisions, so that you can correct the video sequence and settings, and then, after rolling it back on the test bench and test machine, switch to all. It is possible that there will be slightly different equipment on the routes, and some will not pull, say, video in high-res, but on some, GPS may have broken and you need to temporarily rotate content there without reference to geodata. Just separate revisions are made for such clients.
    
  
  
• Frontend
  
  • On the on-board computer (some kind of Raspbery or Orange Pi), a "local backend" is spinning and a browser deployed to full screen, looking at the localhost.
    
  • The "local backend" is trivial, in Flask or something. Needed to simplify and standardize access to content. A kind of insulation layer. One of the handlers is a web socket that reads the geo-event queue and provides data to the geo-widget. You can also update the navigation widget with Ajax, by the way, without any web sockets. Here is how faster within the MVP.
    
  • Rsync daemon - Synchronizes a directory with route resources. It is possible on ssh even. Its task is to keep all revisions of the content folders identical to the server.
    
  • Telemetry service - connects to the telemetry north on the backend and sends the current pieces of the track there, throws geo-events for the backend into the local queue.
    
  • Update service - according to the schedule, checks the hash sum of content directories, sends a notification to the back API about the status of loading a new content revision. Receives a signal in response to switch to a new revision and restarts the local backend from the new directory.
    
  • Frontend - just chromium or any other browser deployed to full screen and connected to a web server on localhost.
    
  • On the back is a small local site with a media player, a navigation widget, and anything else in general. This is better than a native application, since there are a lot of programmers and designers for the web, js programmers too, all these are well-established and understandable technologies. Much better than sawing your own balalaika with your own content rendering. In addition, this is a more or less isolated repeatable environment, the show can be tested on the desktop.
    
  
  

Didn't say playlist.
All the videos we have are in local access on the BC. In this regard, you can get rid of the local "backend" simply by opening the static browser. A local web service is needed only to supply data to the navigation widget, but if it is running out of time, then within the framework of the MVP it is possible to pass geo-events through static files. The minibus does not fly at the speed of light - there is enough interactivity. If it's a pity to kill a flash drive with overwrites, you can mount a small ram drive for this case.
A playlist is a json file that actually contains a schedule of audio and video sequences based on start and stop times. You can make the browser cache warm up forward in the playlist so that it doesn’t freeze, but what can be mounted into monolithic videos needs to be mounted. Moreover, the browser player perfectly understands when he is told where to play and listens to commands from js.

Answer 2

It is difficult to implement a monitor with LAN and remote control - if you take a standard TV with DLNA, it will not work, DLNA requires external control and cannot start playback itself. Therefore, there must be a device that will play itself. It is possible to control playback from the BC - and on the device itself VLC is launched with a default playlist, perhaps the script creates this playlist when it is turned on, depending on the time and location. Location and playback control according to the algorithm is carried out by the BC - it makes no sense to shove GPS into each advertising module, the BC should have GPS for tracking and navigation. LAN communication, VLC control via http.
It is also possible to use Media Players on Android - but here you have to mess around with autoplay playback. The simplest is OrangePi+Linux(Armbian)+VLC. The main software will be in the BC. The control server is a stupid site with which the BC communicates, you can at least implement it through the VK groups.