Jerky Video On Milestone VMS

I've been having jerky video on a Milestone Enterprise 6.5d system only on a recently added Axis Q1604 camera. Recording is done motion based at a 7 fps. However, both live and recording video are jerky. However, I understood that the jerkiness/jumpy (infact frame losses) is related to pre-event/post-event video times (3 secs in m case). When this was increased to 15 secs more frames are lost and more jumpy.

It seems pre/post event buffers are not working properly. Wonder if anyone could shed some light on this to alleviate the issue. What happens with the video is; it plays a chunk of activity (abt 6-7 sec) then jump to current frame instead of next sequential frame where motion is still happening.

Where is this pre/post event buffers are maintained; at the VMS RAM or at the camera it self?

Is the problem due to motion based recording algorithm? (All other cameras are fine, this particular one is not; WDR is off, FOV is very wide - a ware house)


Have you spoken with Milestone first? If not, can you do so? If yes, what did they say?

This is the type of incident where it's useful to start first with the manufacturer and get their diagnosis. If that is not helpful or does not make sense, then we can look into alternative theories.

Hi John

Spoken to Milestone, they do not support the version anymore, nor is customer having a valid support agreement.

Any further input appreciated.

Thanks

Which Firmware is on that camera? Also, is the jerkiness observed when you access the camera via browser, or just via the VMS?

You mentioned all other cameras are fine - different models, or the same model?

What is the average CPU on the Recording server?

Milestone the VMS is the one that determines the pre/post (they actually pre-buffer all images from the camera, and if camera is set to motion only, any frames that are older than the pre motion buffer event are discarded and not recorded.

From their Knowledge base: "every image is recorded from each camera, but images older than the buffer length are discarded until the recording is triggered. This means that even though images might not be recorded for all cameras at the same time, the storage system should be designed to accommodate all cameras recording simultaneously."

Milestone representative responded that the "newly added camera overloaded the server (CPU) or disk." and recommended you contact the reseller or Milestone's Support for further assistance.

Sarit - the Milestone reps response doesn't make sense to me.... :( While a newly added camera can certainly overload the CPU or disk, would the symptoms be contained to just the last camera added? I think you nailed it with your initial words: camera firmware :) ...but I'd like to see some of the answers to your other questions as well.

UD#0612065 - "both live and recording video are jerky. However, I understood that the jerkiness/jumpy (infact frame losses) is related to pre-event/post-event video times (3 secs in m case). When this was increased to 15 secs more frames are lost and more jumpy."

Where does this understanding come from? The pre/post buffers on the recorder might be causing this one camera to appear 'jerky', but I'm inclined to think not. Are you only using pre/post buffers on this one camera and not the others?

Also, what doesn't Milestone support anymore? Enterprise 6.5d is still downloadable from their site.

Thanks for replies.

I could not find server being overloaded. CPU Utilization max around 25%, network Uti around 3%. Disk overloading - how could I confirm that (Stop other cameras and see what happens?).

Video on web page is perfect. I checked the RTSP stream seperately too to be perfect.

I'm using driver pack 6.6 and the camer's is using recommended firmware (5.sth.sth.2).

All other cameras are fine - different makes/models (axis, acti). All of them have pre/post event buffers.

When I increased pre/post buffers to 15 secs; jumpiness increased. When set to 0 jumpiness reduced but still visible.

When recording set to cotinuous, video quality is good.

Check the camera, client and server time- is there a big difference? different time zones?

I don't know what this means: (5.sth.sth.2) would you clarify for me?

Re: "Disk overloading - how could I confirm that (Stop other cameras and see what happens?)." set the rest of the cameras to Record always while leaving this one at Motion Only. btw- how many cameras on one server?

No time diffrence. In fact I tested on the server it self too.

Firmware used is 5.40.3.2 (Drive pack 6.6).

I actually set all the rest to continuous recording and tested, but did not improve.

Been thinking VMS does not change live stream received from camera, but seems VMS does change

Do you think size of the FOV has anything to do with this..motion detection algorithm can't cope with.

In total there's only 21 cameras. Most doing at 4CIF and rest 720p. Problem is only with this particular one. Currently there's there's little activity being a weekend. HDD I/O stable at 3.5 MBps.

I think it could be related to disk performance. Check this using the Windows Resource monitor, looking at disk queue length. If it is greater than 2, you will need a faster disk for recorded images. Note that the archive disk can be slower, since archiving is a background task. I have been using SATA 6 GB for smaller systems, and on larger systems I recommend SAS with 10k or 15k rpm.

If the disk queue is 1 or less, then take a look at RAM, since the pre- and post-recordings reside in memory before being committed to disk. Also take a look at the recorded video. Is it also jerky after recording? This would support the theory of frame loss due to insufficient RAM resources.

You didn't mention which codec you are using. JPEG cameras place a much greater demand on the system. Try converting some of the cameras to MJPEG or H.264 to reduce bandwidth and recording load on the system.

Appreciate your great answer.

I am using MPEG4 and H.264 throughout the server, this particular camera doing H.264.

It is incomprehensible all losses occuring only to this camera, because RTSP/web stream looked perfect so couldn't think of any connection issues.

However, after changing streaming from UDP to TCP problem dissapeared.

Intereseting, was the camera set to use the UDP transmission protocol as a default, or changed at some point? If so that would be independent of the VMS.

Camera was set to UDP by default (reckon many cameras default to UDP), and all my other cameras too.

Problem appeared right after commissioning the new camera (the problematic one).

Thanks for your input too. They gave me more points to hypothesize the issue.