Fix #29
open
Overview images coming from IP cameras sometimes do not send the frame number.
Added by Khaled Malhal Abbas about 2 months ago.
Updated 12 days ago.
Description
In the Scancar web interface, there is a parameter in the resulting JSON that cameraserver outputs that is called Ovw_XFrameSizeFps which sometimes is not set up. This often happens with RTSP images. It could or could not happen with the color camera.
I suspect that the merging of the images of the same line may have this issue. Since it has a buffer of 30 timestamps (correlated to the FPS of each camera) and when querying the closest Overview image for a certain OCR image, it is doing it wrongly.
I can probably replicate this issue by setting up the RTSP camera and the OCR at different FPS.
- Status changed from New to In Progress
- % Done changed from 0 to 40
I suspect that the cameraserver is getting overloaded with tasks to do, specially on the HUB ALPR with a Pico500 when IP cameras are involved.
For each instance of an IP camera being declared in the configuration file (/config/atenea/cameraserverd.ini), a GSTreamer pipeline is created, which adds to the load.
A good solution for this is to have a single pipeline for each IP camera and forward the images to the lines where they belong.
- % Done changed from 40 to 70
The IP cameras have a multicast configuration. We have enabled them.
Also, we have forced the GSTreamer pipelines to transport the RTP packets through UDP Multicast (commit).
This suggests that the bottleneck was not the cameraserverd's overload, but it was in fact the IP camera's overload.
I will set this ticket as Paused for now. Since I believe that the previous solution should be ideal for the cameraserverd and eliminate as many unnecessary tasks as possible.
- Status changed from In Progress to Paused
- Subject changed from Overview images coming from RTSP sometimes are not sent the frame number. to Overview images coming from IP cameras sometimes do not send the frame number.
Also available in: Atom
PDF