Cisco 6030 PTZ - camera instructions
I've recently added a Cisco 6030 PTZ ( CIVS-IPC-6030 ) camera to my mix, and nice in some ways, bad in others. It's actually kind of terrible from a software perspective. It has many, many flaws in the firmware but the hardware is amazingly nice - 10x optical zoom, 1920x1080 maximum resolution, heaters, rapid patrol, overall just a nice piece of equipment. It's a shame about the terrible code. So I think I've finally got it recording video, though there is still no PTZ control for Security Spy.
QUESTION FOR BEN: How would I get the PTZ recipe for this? I can give you access to the web UI for the camera with the PTZ and position controls and you can try to reverse-engineer with Charles. app or something like that.
For the record:
By experimenting (way too much) I have found that if I:
- turn off OnVIF
- disable session ID
- video standard: NTSC/60hz
- fixed quality (very high)
- turn down the resolution to around 704x480
- set video codec to "MJPEG"
- framerate to 6 frames per second
- sound to G.711-A
- nothing on channel 2 (deactivate channel2)
I can then set on Security Spy:
- manual configuration setting
- camera IP address
- no http port
- no rtsp port
- no ssl
- username (as set for admin)
- password (as set for admin)
- RTSP UDP (video and audio)
- Request set to: /StreamingSetting?version=1.0&action=getRTSPStream&ChannelID=1&ChannelName=Channel1
If I set things to TCP, I only get one or two frames and then things fail, so stick with UDP. I also found that I wasted several hours because SS became "corrupt" yesterday, meaning that some of my experiments put SS into a condition where nothing worked. I restarted SS for other reasons this morning and was astonished to see the camera instantly working where yesterday I was beating my head against a brick wall for quite a while after some limited success earlier.
It takes around 15 seconds for settings changes to take effect once you make them on the camera.
At the point where you've configured your camera as above, you have to find out what your network can handle. I've found that SS doesn't like losing packets or not being able to interpret packets, so I start with the framerate, image size, and quality turned down as low as possible to get things working, and then turn each up independently depending on what I want to accomplish until SS starts to have disconnection problems. Having the "patrol" option set on the camera causes lots of motion, and that causes SS to freak out pretty quickly with larger image sizes, so make sure you have a good network between SS and the camera.
Also: I've tried to set this to H.264, and that works more reliably as far as reducing the bandwidth of moving images BUT... this apparently is one of those H.264 instances that doesn't play well with SecuritySpy or Quicktime. The image starts to slur, and then eventually goes into grey completely, or a green screen. It resets every 20 or so seconds, but it's unusable.
I'll note that both the MJPEG and H.264 streams work perfectly when viewed with Safari and the VLC plugin. The UI says specifically not to use Quicktime, and sure enough, quicktime doesn't work when pointed at the camera as an RTSP feed.
The image quality is pretty crappy with SS, even though looking at the same streaming image next to it in Safari with the VLC plugin looks great. Not sure if this is a JPEG artifact issue or what. I've tried at various qualities, framerates, and sizes - it still looks awful on SS.
Anyway, hope this is useful to someone.
Example:
rtsp://10.1.3.4:554/StreamingSetting?version=1.0&action=getRTSPStream&ChannelID=1&ChannelName=Channel1
QUESTION FOR BEN: How would I get the PTZ recipe for this? I can give you access to the web UI for the camera with the PTZ and position controls and you can try to reverse-engineer with Charles. app or something like that.
For the record:
By experimenting (way too much) I have found that if I:
- turn off OnVIF
- disable session ID
- video standard: NTSC/60hz
- fixed quality (very high)
- turn down the resolution to around 704x480
- set video codec to "MJPEG"
- framerate to 6 frames per second
- sound to G.711-A
- nothing on channel 2 (deactivate channel2)
I can then set on Security Spy:
- manual configuration setting
- camera IP address
- no http port
- no rtsp port
- no ssl
- username (as set for admin)
- password (as set for admin)
- RTSP UDP (video and audio)
- Request set to: /StreamingSetting?version=1.0&action=getRTSPStream&ChannelID=1&ChannelName=Channel1
If I set things to TCP, I only get one or two frames and then things fail, so stick with UDP. I also found that I wasted several hours because SS became "corrupt" yesterday, meaning that some of my experiments put SS into a condition where nothing worked. I restarted SS for other reasons this morning and was astonished to see the camera instantly working where yesterday I was beating my head against a brick wall for quite a while after some limited success earlier.
It takes around 15 seconds for settings changes to take effect once you make them on the camera.
At the point where you've configured your camera as above, you have to find out what your network can handle. I've found that SS doesn't like losing packets or not being able to interpret packets, so I start with the framerate, image size, and quality turned down as low as possible to get things working, and then turn each up independently depending on what I want to accomplish until SS starts to have disconnection problems. Having the "patrol" option set on the camera causes lots of motion, and that causes SS to freak out pretty quickly with larger image sizes, so make sure you have a good network between SS and the camera.
Also: I've tried to set this to H.264, and that works more reliably as far as reducing the bandwidth of moving images BUT... this apparently is one of those H.264 instances that doesn't play well with SecuritySpy or Quicktime. The image starts to slur, and then eventually goes into grey completely, or a green screen. It resets every 20 or so seconds, but it's unusable.
I'll note that both the MJPEG and H.264 streams work perfectly when viewed with Safari and the VLC plugin. The UI says specifically not to use Quicktime, and sure enough, quicktime doesn't work when pointed at the camera as an RTSP feed.
The image quality is pretty crappy with SS, even though looking at the same streaming image next to it in Safari with the VLC plugin looks great. Not sure if this is a JPEG artifact issue or what. I've tried at various qualities, framerates, and sizes - it still looks awful on SS.
Anyway, hope this is useful to someone.
Example:
rtsp://10.1.3.4:554/StreamingSetting?version=1.0&action=getRTSPStream&ChannelID=1&ChannelName=Channel1
Comments
Thanks for posting this information, and your thorough testing! We haven't really had much experience or customer feedback about Cisco cameras so this is very useful.
Currently SecuritySpy does indeed use QuickTime for its video decompression (though we are planning to move to an alternative in the next major update), so this may explain what you are seeing with the corrupted H.264 video.
We'd certainly like to have a look ourselves, firstly to see if can find a way to improve the video streaming, and secondly to implement PTZ control. To allow us to do this, please put your camera online for us by setting up port forwarding in your router to the camera on its HTTP and RTSP ports (usually 80 and 554), and also its ONVIF port if this is different from the HTTP port. Then email us your public IP address or DDNS address (you can easily set up a DDNS address in SecuritySpy's Web Server Settings window if you have not done so already).