Subscriber Discussion

RTSP Huge Delay With Bosch Camera

VG
Vlad Georgescu
Feb 04, 2016

We are license plate recognition software so we traditionally use mjpeg over http streams.

But in one project the integrator really really wants to use Bosch (Dinion Starlight 5000) which hast only rtsp and has a huge latency whih makes it unusable for open/close barrier.

Any ideas on how we can reduce the delay on rtsp ?

Thank you

(1)
U
Undisclosed #1
Feb 04, 2016
IPVMU Certified

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.

JH
John Honovich
Feb 04, 2016
IPVM

Bosch asks:

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?

(1)
VG
Vlad Georgescu
Feb 04, 2016

NBN-80052-BA, DINION IP starlight 8000 MP (CPP6)

http://93.113.6.37:91/view.htm?mode=l

(1)
U
Undisclosed #1
Feb 04, 2016
IPVMU Certified

That is a HTTP URL, not an RTSP URL.

Ispyconnect is listing two RTSP URL's for Bosch dinion HD cameras:
rtsp:<ip_address>:554/rtsp_tunnel

rtsp:<ip_address>:554/h264

(1)
VG
Vlad Georgescu
Feb 04, 2016

yup, that's the one we're using :

rtsp:<ip_address>:554/rtsp_tunnel.

The url above is the camera interface, John requested it.

I'll try a firmware upgrade (i now noticed we have 6.11 and there's 6.20 available)

Dont the firmware upgrade, no change

Forgot to mention : we're the only connected client to it, it does not record or integrated into vms, we're not using the sdk, getting the stream directly

(1)
U
Undisclosed #1
Feb 04, 2016
IPVMU Certified

Sometimes there will be an ONVIF URL that can perform differently, (often worse). You can use ONVIF DM to uncover this, if ONVIF is enabled on the camera.

You should try the "h264" URL as well, call me old fashioned but anything involving a "tunnel" makes me think traffic jam.

U
Undisclosed #1
Feb 04, 2016
IPVMU Certified

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?

VG
Vlad Georgescu
Feb 04, 2016

We do the lpr , not the camera :)

The stream from the camera gets into the computer (on same switch, ping 100%) extract the plate in our software.

Same behaviour in vlc.

U
Undisclosed #1
Feb 04, 2016
IPVMU Certified

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.

http://IPADDRESS/snap.jpg?JpegSize=M

(1)
VG
Vlad Georgescu
Feb 04, 2016

hmmm..the snapshot gets it right(no delay) .

U
Undisclosed #1
Feb 04, 2016
IPVMU Certified

See what the shortest interval between snapshots that the camera is capable of.

Some wont give you a new snap for a whole second, other ones can manage 15 fps.

its easy enough to script it if it supports a frame rate that is acceptable.

VG
Vlad Georgescu
Feb 04, 2016

umm, we don't need snapshots, we need video stream...lowering the resolution reduced the delay to ~1,5 seconds..

U
Undisclosed #1
Feb 04, 2016
IPVMU Certified

An mjpeg 'stream' is nothing more than a series of snapshots.

VG
Vlad Georgescu
Feb 04, 2016

Indeed it is, but we expect to get it from rtsp, http not reading from a directory. Changing the way the software works for everyone else(axis, sony, dahua, hik, vivotek) just for bosch it does not make sense.

If we cannot find a solution(here or with bosch) , the customer must accept the delay. Or change the camera to one that has no delay .

(1)
U
Undisclosed #1
Feb 04, 2016
IPVMU Certified

agree, not worth changing just for bosch.

btw, no need to read a directory, just put the GET in a loop and call the same routine that processes the individual jpeg frames when you are extracting from the mjpeg stream.

is the resolution downgrade affecting the LPR performance? Either way a pity.

Also, the spec says that the camera does support mjpeg.

U
Undisclosed #1
Feb 04, 2016
IPVMU Certified

From a BOSCH tech note:

Another alternative would be to request JPEG Streaming for the RTSP connection.

This would require the URL: RTSP://160.10.0.1/?h26x=0

Avatar
Brad Eck
Feb 05, 2016
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.eck@us.bosch.com Please pass on yours. Brad
VG
Vlad Georgescu
Feb 05, 2016

Thank you Brad, you got mail.

U
Undisclosed #1
Feb 05, 2016
IPVMU Certified

Hey Cristian, were you able to try the URL:

RTSP://<ipaddress>/?h26x=0

Avatar
Brad Eck
Feb 05, 2016

Cristian, I haven't seen an email from you this morning. Can you check and resend? Brad.eck@us.bosch.com

U
Undisclosed #1
Feb 13, 2016
IPVMU Certified

Brad, in the end, was the rtsp_tunnel URL the correct URL?

EP
Eddie Perry
Feb 05, 2016

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.

(1)
U
Undisclosed #1
Feb 05, 2016
IPVMU Certified

"none of my suggestions are meant to help you not insult you"

Quick Eddie, grab the edit button before it's too late! ;)

(1)
EP
Eddie Perry
Feb 05, 2016
to late it should be some instead of none
VG
Vlad Georgescu
Feb 09, 2016

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

(3)
U
Undisclosed #1
Feb 09, 2016
IPVMU Certified

Great! So same rtsp_tunnel URL? What was the tweak, disable h.264?

New discussion

Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.

Newest discussions