Help - Codec with Overall IP delay less than 75 ms

[steven 0]

Would greatly appreciate your help..

 

We are required to provide a CCTV system that where latency shall be less than 75 ms. The Cameras are analog and therefore Codecs with very limited delay is required? Please help

[Soundy 1]

What sort of "delay" are you talking about? Live local viewing? Live remote viewing?

 

If you use a hardware overlay DVR card (like a Hikvision, GeoVision, etc.), there is no delay; local live display is instantaneous. Remote latency will be more a factor of the connection bandwidth than the codec used.

 

It would be easier to recommend something if we had a better idea of just what you're trying to do...

[steven 0]

Thank you for your response.

 

We are to design a large CCTV system that will monitor multiple sites to a central control building.

 

The cameras used are PTZ analog type. The requirements states that when designing the system care should be taken when choosing the Codec. The network end to end delay shall be less than 75 ms. i.e. When an operator use the joystick to move a camera there shall be no noticeable delay.

 

Therefore there are actually few questions / arguments:

 

1. Strictly based on what is stated above, as CCTV experts do you inturpet the 75 ms to be the total latency i.e. from sender to receiver and back to the operator, or jut one way and then total latency maybe around 150 ms?

 

2. Also with reference to point 1: Does the industry have a definition that is accepted by all for what "Network END TO END latency " really means?

 

2. From reading around, it seems no noticeable delay maybe achieved with latency less than 200 ms. What is your opinion?

 

3. If 75ms end to end means total delay from operator to PTZ and bac to operator, then we must find a codec that will not contribute to such delays, the minimum we see in the market are easily above 120ms. Keeping in mind that this system requires large bandwidth?

 

Your thoughts please. Thank you all.

[Soundy 1]

"From operator to camera" control signals are not a function of the codec, and since it's a relatively small amount of data, its contribution to overall latency should be negligible. Your only real concern is from the camera back to the viewer/operator.

 

There are a number of considerations here. To get the fastest transfer time, you want to compress the video as much as possible... however, that causes a loss of quality, and the more you compress it, typically the more processing is required, which will also add to the overall delay. Beyond just lag time, you should see if the client has a requirement for quality vs. compression level - you could sample at CIF and crush it in compression and have almost no data to stream... but have a really bad image.

 

Generally, the most space-efficient commonly-available codec is H.264, which will compress fairly quickly at the sending end... but remember that you have to decode at the viewer's end as well, and decoding H.264 can be processor-intensive, which could slow things down if you have several streams going.

 

However, I believe you'll find that network latency itself will be the biggest issue, unless everything is on a gigabit LAN. If you have to go over internet connections at all, unless you have dedicated high-capacity business connections between sites, you'll potentially see ping times in the range of 100ms or more.

 

Your client needs to define their requirements a little more inclusively than just "75ms end to end", because there's too much involved that I'm guessing is beyond your control.