Is the camera setting set up for h.264 on the primary stream for recording?, MJPEG would put a big load on the network.
Yes, try another camera. Good luck.
Troubleshooting poor image quality - frustrated.
- Thread starter Gilera
- Start date
Is the camera setting set up for h.264 on the primary stream for recording?, MJPEG would put a big load on the network.
Yes, try another camera. Good luck.
Only thing I have wondered in the past is that total power quota is 56w and user manual for cameras say each camera might need up to 23w (PoE+) but that is in cold environments to power the heater. It goes on to say that PoE is fine if temp maintains above 4degrees which it almost always is up here (tonight might test it!). Would have thought that power issue would not show up in this way though but who knows.
As far as ports go, I can unplug the router and plug laptop in directly it is not too far away. I'll try that as one last thing tomorrow. Have a longer Cat 5e cable somewhere. No data going to the recorder is going through router though - only Smart client or RDP to smart client. Will report back.
As far as ports go, I can unplug the router and plug laptop in directly it is not too far away. I'll try that as one last thing tomorrow. Have a longer Cat 5e cable somewhere. No data going to the recorder is going through router though - only Smart client or RDP to smart client. Will report back.
Currently H264 primary stream for live + record. Tried MJPEG in case an encoding/decoding issue but didn't help.
It is usually a good idea to diagnose possible network problems by repeatedly sending network pings to the camera to measure latency and packet loss. This is a tool which can make that easy: bp2008/pingtracer Use this or any other pinging tool to ping the camera and crank up the number of pings per second so you collect data faster. An ideal network will yield stable latency of around 2ms or less with no packet loss. Higher latency or packet loss is an indication of a problem.
Many posts, may have forgotten some info in them. Did you try setting the camera to output another stream format, like mjpeg or mpeg4? Both use far less CPU/GPU to render the video. You can also try turning down the resolution on the camera, again to lessen the load on the GPU/CPU.
Also might be worth trying to turn off Motion Detection in the camera settings for each camera in Milestone Management Client, to lessen the CPU/GPU load on the server.
Also might be worth trying to turn off Motion Detection in the camera settings for each camera in Milestone Management Client, to lessen the CPU/GPU load on the server.
Thanks. Tried MJPEG a while ago. Saw the bitrate go up to 40000! Will try again and count frames per second recorded. Am using software motion detection. Was reading that UDP protocol can sometimes improve performance where choppiness and jerkiness. Am using the default TCP. Anyone have experience in this?
I have tried pinging each camera for extended periods via command prompt and never had lost packets. Latency (on 32 bytes) <1ms always.
When there is no packet loss, TCP streaming is the same as UDP streaming, more or less. When there is packet loss, UDP streaming results in lots of corruption while TCP results in buffering and delay.
I tried UDP and it made a big difference to the steadiness of the FPS shown in the video overlay in the Smart Client. Went from swinging between 5 and 15 FPS (for setting of 10) to 9.8-10.2.
So do you think that the fact that it appears to have trouble maintaining a steady FPS with TCP is just the nature of TCP and not a sign of the system struggling due to the overheads involved in that protocol?
Having no experience with milestone's smart client myself, I can't really say. If the FPS swings around a lot with TCP that suggests to me you could have some minor network problems that cause retransmission to occur (which adds delay) and that the Smart Client isn't tuned to handle it very well. But these systems are really complex and sometimes it is hard to diagnose a problem correctly 
That would fit in with eveything else. Just can't track the bugger down. Behaviour is common to 3 cameras, so it has t be something in the cameras themselves or has to be from the switch back. Have run a query on the cameras (Linux) which showed CPU usage was only around 30% so don't think it is the camera capability limiting things. Switch is gigabit. CPU on server running at maximum of 20%. New WD purple hard drive.
Maybe disk I/O? Is it hard to assess this?
Maybe disk I/O? Is it hard to assess this?
Disk I/O can be seen in task manager. On the performance tab you can choose a disk and then see actual read and write speeds. However it is unlikely that your disks are a bottleneck. Most hard drives are capable of 100+ MB/s for sequential writing which is what a VMS does.
Did you connect your laptop (with the smart client) directly to the switch ?, you didn't confirm. In your diagram it goes via your router/modem.
Sorry, yes I did. It didn't seem to make a difference. I had it like that for a couple of days and then changed it back. I only have one ethernet port on it and also Windows doesn't seem to let you connect to connect to Wifi when a cable is plugged in so couldn't use the internet on that machine.
The issue occurs whether running Smart Client on the laptop or the server. Changing the stream setting to UDP in the recording server stream settings definitely seemed to have an impact. Counting the frames meant that it was consistently recording the right number of frames in within1 second with only a few thousandths of a second variance (is the timestamp really that accurate).
Is this setting actually changing the protocol between the cameras and the server? Looking at the supported protocols listed for my camera, UDP is not even listed. There are also no settings on the camera interface to adjust streaming protocol and I would have thought a change would be required there as it is the source of the stream.
Yeah, depending on the container the timestamps can be even more precise than that.
I'm not sure exactly which setting it is... could be affecting camera -> server streaming or it could just be server -> Smart Client streaming. Cameras can support RTSP over either TCP or UDP. Most don't provide an option and probably are just waiting to see how the client makes the request.