Subscriber Discussion

2 Second Latency For An Axis PTZ On Milestone?

AA
Aaron Auseth
May 09, 2013

I have an Axis Q6035-E camera. Overall I like the camera but the PTZ response time with Milestone SmartClient is about 2 seconds (it takes 2 seconds after I click the mouse before the camera pans or zooms). Using the web interface to the camera (bypassing Milestone) the PTZ response time is about .25 seconds.

I have an older JVC camera and it's PTZ response time is about .25 seconds.

From a usability point of view the .25 seconds is fine. The 2 second delay makes it difficult to follow a suspect. I'm not sure if there is an industry standard or target response time for an IP camera using PTZ control. If not perhaps IPVM should rate and try to set one.

I realize that the Milestone Client will buffer several frames to make the video appear smoother. I tried lowering it to 1/4 second and raising it to 2 seconds, didn't seem to make much difference. My server is running 30-50% CPU utilization. So I'm not sure where the problem is. I suspect using Milestone as the inbetween is just adding some delay. I haven't researched any possible issues with the various Milestone's device pack (camera driver) versions yet.

I'd appreciate any insights into this issue. Is my experience typical, thus I just have to live with it. Or do you think there is a technical issue with the Axis camera or Milestone VMS system?

AA
Aaron Auseth
May 09, 2013

Well I found a forum article that stated:

For best performance, it is recommended to use MJPEG with PTZ cameras. If the camera supports dual streaming it is also possible to configure MJPEG for live streaming and MPEG4/H264 for recording. This will result in increased bandwidth requirements but less storage space.

Even though it allows for a smoother image in live view, live video buffering—if configured in your XProtect® Smart Client views—could also result in PTZ movement latency.
So I reconfigured the Q6035 camera to use MJPEG in Milestone. It is MUCH more responsive using the Milestone client. Apparently the issue was with the H264 compression. My bandwith might suffer, but at least I have usable PTZ controls now.
JH
John Honovich
May 09, 2013
IPVM

Aaron, you say, "I have an older JVC camera and it's PTZ response time is about .25 seconds."

Is that decreased latency with Milestone as well? And is that camera streaming MJPEG?

AA
Aaron Auseth
May 09, 2013

The older JVC camera only supports MJPEG. After changing the Q6035 to MJPEG (was H264), now both have a 1/4 second delay using the Milestone client.

JH
John Honovich
May 09, 2013
IPVM

Aaron, let me run this by Axis and Milestone and see what they recommend. I am sure some members have practical experience with this combo as both products are frequently used.

GG
Gautham Gopalakrishna
May 12, 2013

By default RTSP sessions have 1200ms of caching latency, which might be the reason why you're seeing the delay in case of H.264 video. This is also mentioned in Axis user manuals about streaming H.264/MPEG4 on RTSP.

Just to verify open a VLC player, go to Open Network Stream & type the URL rtsp://user:password@<ip>/axis-media/media.amp?codec=h264 & check the Show more options - & set the latency to say 300ms. Now when you do your PTZ operations (from your client), at least on VLC player you should see quicker response for H.264 stream.

If milestone provides a way to set this caching latency - use it & it should reflect the same. For MJPEG, this delay is not seen as it follows a different streaming mechanism.

JH
John Honovich
May 12, 2013
IPVM

Gautham, very helpful, thanks!

BS
Bernat Solyom
May 13, 2013

We maintain an existing Pelco Endura system that has been expanded with new Spectra IP domes (H.264 TXB-N boards, although we used them in MPEG4). The same happened, we had a latency at around 1-2sec. Pelco replaced all encoders to TXB-IP (MPEG4) boards and it worked well.

With Milestone I had an issue couple of years ago with latency and live viewing. The Milestone Server (it was just a demo) was connected to a 10/100Mpbs port which resulted the same. We wanted to find out the reason so replaced the switch which had gigabit ports. Using the Milestone on a 10/100/1000Mbps port solved the problem. Still the cameras had 10/100Mbps PoE ports.

JH
John Honovich
May 13, 2013
IPVM

Milestone's confirmed and reiterated the advice Aaron cited above - use MJPEG for live stream and H.264 for recorded.

JH
John Honovich
May 15, 2013
IPVM

More feedback from Milestone, with another recommendation:

"We have many installations which use this exact camera with very minimal latency. In fact, we have several casino’s which are using this model Axis camera and their standards for latency tolerance are very restrictive.

One thing that is quite easy to check are the client side buffering settings in the camera view. If this is set abnormally high then it will give the appearance of latency.

An often helpful troubleshooting step would be to open both the web page and the Smart Client simultaneously, execute the commands from the Smart Client and note what happens in the web view. By doing this we can determine if the latency is in the PTZ command execution, the video or both.

They will also want to make sure they have updated to the most current device pack."

Aaron, can you try the experiment of opening up the Smart Client and camera web client (making sure it's set to H.264)? From what you have already, it appears that you have checked the client side buffer settings?

Overall, I still think it's abnormal to have to use MJPEG to avoid massive latency with IP PTZs.

AA
Aaron Auseth
May 15, 2013

Using the recommended MPJEG live view settings for the PTZ camera is working great for me!

Just for fun I decided to run the test you suggested. I opened the SmartClient live video (H264) and Web Client (H264) side by side. When I use the Milestone client to pan the camera the Web Client shows the movement about 1 second before the Milestone client. The Milestone Xprotect Smart Client 7.0b (64-bit) is using the default Video buffer (2 frames I believe). I don't see any way to remove buffering all together.

I set the web client for H.264 and it has about a 1 second delay. Using the web client with MJPEG also has about a 1 second delay. Interestingly enough the H264 pans quite smoothly, the MJPEG is a bit jerky.

Avatar
Jon Swatzell
May 18, 2013
IPVMU Certified

I expect the MJPEG jerkey panning is potentially related to the camera using dedicated hardware for the H. compression and non-dedicated processor component for the MJPEG codec. Especially pushing HD MJPEG while panning. Although the Q6035 is built like a workhorse, with signifigantly better hardware than many HD PTZs, so there could be another explanation.

GG
Gautham Gopalakrishna
May 20, 2013

Hi Aaron

Did you try using VLC by playing H.264 stream from Axis camera? You should see a reduced latency when you set "caching latency" to 300 ms.

JG
John Grocke
May 20, 2013

I have watched surveillenace workstations crash due to trying to decode 16 or 32 simultaneous H.264 streams, you need a lot of processor to decode especially with a high resoltion camera like the Q6035.

My laptop crashes trying to decode more than 2 H.264 strams at a time, yeah I need a new laptop. :)

I find its best practice to record with H.264 and live view in MJPEG. Most VMS's allow you this flexibility as long as the cameras support multiple streams, which most newer ones do. I think all the current Axis cameras support multiple streams.

New discussion

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

Newest discussions