Once upon a time, while deploying a solution based on Viinex Foundation 1.4, we faced the situation where an uncommon logic was required to control the rail car numbers recognition. Namely, there was a weight bridge with two poles at both sides of it, — and Viinex Foundation 1.4 was supposed to detect from which side the train approached the weigh bridge, switch rail car number recognition to process the video streams from the pair of cameras installed at respective pole, and the recognition process should be controlled according to the optical sensor installed on that pole. The video streams and signals from sensor on the other pole should be ignored until the whole train has passed. After that the system should get back to a waiting state to be ready for a train to come from either side of a weigh bridge again.
For this depolyment, we decided to combine the video analytics in Viinex Foundation 1.4 and the features from Viinex 2.0. First of all, we’ve implemented the support for Modbus TCP protocol in Viinex 2.0. Now devices compatible with Modbus TCP (like Moxa ioLogic family) can be used as event sources in Viinex 2.0. The events coming from such devices look just like events from IP cameras (they have “DigitalInput” in their “topic” field). There is a new object with type “modbus” appeared in Viinex 2.0 which implements the communication with Modbus TCP controllers.
We had the plan to implement the whole logic in a script which can take the events from GPIO controller with an Ethernet interface, process such events, and control the “Server Side Video Renderer” to switch its output.
As for controlling the layout of viewports on a video renderer – we implemented this approach, there was a logic for controlling a video renderer from a script, and it did work pretty well, – this logic was displaying two cameras aside (from the “left” and “right” pole) when there was no train approaching the railweigh bridge, and showing the video from the “leading” pole when the train appeared.
However video renderer performs video decoding and video encoding. These steps are taking computational resources which are scarce in the railcar identification number recognition system. To save resources, we decided to implement a lightweight object which can just take several input streams and switch between them to produce one output stream. This does not require video stream encoding and decoding. The output stream looks just like a normal video source in Viinex 2.0, — that is, it can be translated via RTSP or HLS, written to a video archive, and so on. An object which implements this functionality is called “streamswitch”.
It also turned out that the most convenient way to actually control the recognition process in Viinex Foundation 1.4, – was to do this from an external process (the “process” object) interfacing with Viinex 2.0 and receiving events from our main controlling script. Why an external process? because it should also interface Viinex Foundation 1.4, using its specific native interface, which we do not want to appear in Viinex 2.0. An external process facility in Viinex 2.0 represents a versatile means for an event-driven integration with virtually any external subsystem.
For the reference and for illustrative purposes, we’ve published the configuration and the controlling script for respective Viinex 2.0 objects in a public repository on the github.