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.
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.
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.
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.
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.
Milestone's confirmed and reiterated the advice Aaron cited above - use MJPEG for live stream and H.264 for recorded.
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.
Gautham, very helpful, thanks!
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.
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.
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.
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?
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.