All RTSP URL's don't necessarily perform the same. You may be able to find one that is better than 3 seconds.
If you are using this camera with a VMS, test the latency with to the VMS, if it's quick enough, then use Wireshark to find the URL it uses.
Or sniff any h.264 client, like one that may have come with the camera, that is fast enough.
Figure out what it is using.
What is the exact camera being used? Because our starlight family is either in 7000 or 8000 series. 5000 series is a different architecture.
Can you provide the RTSP URL you are using so we can see if that’s correct or not?
NBN-80052-BA, DINION IP starlight 8000 MP (CPP6)
just a thought...
Maybe the latency has nothing to do with the stream, since the camera does LPR all on its own, couldn't that be the cause of the delay?
Can you disable for testing purposes all analytical processes?
just to be sure have you tried other clients?
One thing to try would be to use the snapshot url and see what the latency is there.
umm, we don't need snapshots, we need video stream...lowering the resolution reduced the delay to ~1,5 seconds..
Hey y'all! This is Brad Eck with Bosch - Integration Manager here in North America. I would like to request a direct discussion to get bit more details, we typically can resolve concerns like this via our support lines as well as through my team. Having not seen an issue like this come through of late, I would be glad to engage this conversation in a place where we can capture exact details about integration (phone, etc) and to understand the whole picture (I.e camera, FW, network, etc). Having said that, please know this is not a normal issue and we need to dig to determine why you are seeing what you are seeing. As you can imagine, this type of latency would not be acceptable by anyone. In fact, our cameras have less than a 200ms latency themselves and our FW developers work to provide the market with the best quality video while considering all of the normal concerns we would have in the space - such as latency, etc. Of course there are many variables to consider (inclusive of image size, encoding format, etc) and thus why I recommend we connect directly. Please feel free to contact me and we will engage both our tech support people as well as my team to address the concern. There is an answer - we just need to work through all the variables to address it. Thanks in advance - looking forward to talking with you tomorrow. BTW here is the link to the data sheet for this camera: http://resource.boschsecurity.com/documents/NBN_80052_Data_sheet_enUS_13616032779.pdf My contact info: Brad.email@example.com Please pass on yours. Brad
I would like to preface my response with this "none of my suggestions are meant to help you not insult you"
form what you have said in your original post and subsequent replies I can narrow it down to three areas that could be responsible for what you are seeing.
One is your software, when you create your parameters for LPR you try to use a standard that is based a certain spec of camera. for example Panasonic face recognition is set to only process MJPEG images of 1280x960 @ 5FPS only. it doesn't matter if its a 4K 5FPS Panasonic camera the software is not going to work unless it has a stream with those parameters. I am not familiar with bosch but if it is a beefier camera stream than your software can handle, then to me that is not the camera manufacturer's fault but a limitation of your software, the camera is preforming as it is designed to.
the second is hardware, if your software is hardware limited ( as long as it has the hardware it can process anything.) and you are using 4K MJPEG images form the bosch camera and 720P MPJPEG from all the others you know that work it will take far more hardware to do so. So unless you are absolutely sure that the bosch camera is putting out MJPEG images as close as possible to your "known working cameras from other brands" then it could be that your hardware cant handle the extra work load.
the last is is of course human error, earlier you said you were trying to get a rtsp stream from the camera but gave a http URL. there is a huge differnce between a HTTP stream and a RTSP stream and how they are processed. HTTP streams will not drop packets and normally software will wait until all the packets have arrived and are sorted till they are processed. This will cause huge latency problems if you are using large amounts of packets ( like in 1,2,3+ MP camera streams) due to waiting for all of the packets to arrived and be sorted then processed not to mention that if any thing does get lost another request has to be made. A RTSP stream works similar but with one difference it transmits extra data along with the video, so if something goes missing it can drop those packets related to it so there is no bottleneck. there will be losses but that is preferred ( for live streaming video and voice/sound) over huge latency waiting for every packet to show up and get in order and then be processed.
but seems like bosch is willing to help you out i would take it as it can be a pain to shift though hundred of Dev pages for information sometimes to find what you are looking for.
Problem solved! Thank you to outstanding sport from Bosch Tech team which contacted over phone mail etc and tweaked the camera
Note to self: the MJPEG mode has less priority than H264 in Bosch cameras