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.
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?
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.
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.
Gautham, very helpful, thanks!
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.
Milestone's confirmed and reiterated the advice Aaron cited above - use MJPEG for live stream and H.264 for recorded.
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.
IPVMU Certified | 05/18/13 12:36am
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.
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.
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.