Member Discussion

Integrating Old IP Cameras Into Newer VMS

We have ran into a new issue that we aren't sure how to solve. We have a client with a bunch of older Axis IP cams that our VMS of choice (DW Spectrum/Nx Witness) does not support. One example is the Axis 211. It is from circa 2008, per the datasheet on the Axis site. It is MPEG-4/M-JPEG only. The VMS doesn't support it via SDK and the camera is older than ONVIF, so our question is, is there any other way to integrate this camera into our VMS?

The way I see it, the client is going to have to replace the camera with something newer.

My first question is whether you've tried to add the camera via the Axis driver. A lot of times even if it's not supported it's still using the same SDK. The basics of the Axis VAPIX SDK don't seem to have changed all that much. I'd at least give it a go. I've added Axis cameras from that era which are installed in this building to modern VMSes without issue.

If that fails, the 211 should have RTSP out: rtsp://user:pass@ipaddress/mpeg4/media.amp -- I believe you should be able to run server side motion on that using NO/DWS, as well.

Can you pull video in via RTSP? On the 211, the RTSP stream should be rtsp://ip_address/mpeg4/media.amp. Just a thought, I was able to do this with some Cisco cameras and a VMS in the past.

Ha! Great minds think (almost) alike!

How do I get a substream for motion detection for NO/DWS when using RTSP?

[IPVM Note: Poster is from Network Optix]


I'm involved in this software developement, so you can trust me:-)
The software natively do not support Axis cameras with old 4.x firmware.

However there are a couple of ways to work around.

Simple one: use generic RTSP/HTTP link

1)You can right click on the server in the tree->Add Cameras ..
2) in the camera address put something like http://<IP address>/axis-cgi/jpg/image.cgi?resolution=320x240 Do not forget to provide proper credentials.

This way server will take MJPEG stream from the camera. The good news is that if resolution is less than 720xsomething motion detection is supported anyway( server does software MD). Max resolution of this camera is 640x480, so MD will work.

Downside is that if you will have 30 fps, it will be a bit CPU consuming( but likely not much ).
Another downside - it's MJPEG( storage consumption).

Other way:
Use our simple SDK to integrate this model. I not sure if this is good option unless you have a huge amount of this cameras.

Let me know if it was helpful. And let me know id you have more questions.
If you want to talk privately and have other questions/feedbacks about the software - more than welcome as well.


Thanks for your help. I have given you one "Informative" upvote above!

This client has about 20-25 existing Axis M-JPEG only era cameras (211, 216FD, 221, 225FD, 233D) that we were hoping to integrate into a new VMS server (DWS). They are currently using Axis Camera Station, which isn't easy enough for their security staff to use. They also have about 60 analog cameras on various DVRs that we will be moving to encoders and integrating into DWS as well. Those are a much easier process, as are the 10-12 H.264 based Axis IP cams.

Can you tell me the risks of using the SDK? That would not be something I am familiar with, so I am unaware of what I would be getting myself into at that point. Is there concerns for version upgrades in the future breaking SDK integration, etc?

I saw you registered on our developer portal. Sending you sdk shortly..

By using SDK you'll be able to use mpeg4 streams instead of MJPEG.


May be it's not enough for you to go that way.
There are no risks except time consumption.

Just in case, if you need MD only and willing to go with MJPEG you do not need to do anything.

and there is no versions issue with sdk.
our intention is to make it painless for developers:-)

I would rather default to record always if we cannot do the dual stream, low stream always/high stream on motion. We usually do a D1 sub stream always recorded with a full res (1080/3mp/etc) motion stream.

I look forward to giving the SDK an effort. If it ends up taking more time than I have to give, we will just force the customer to upgrade the cams.

I just curious...
Is it cheaper to upgrafe the cameras or add a bit extra storage ?

It's less about the cost of storage and more about the ability to have both:

1-Constant recording

2-Motion events

The ability to use the motion search is a great selling feature of the VMS. The simplicity of it is what probably will land us the project. If it were simply recording space, hard drives are cheap. An extra $200 USD would take care of that, no problem.


You will have motion events and motion search even if you use constant recording.
recording on motion just minimizes storage usage.

With constant recording all motion features are still available.

Well don't I feel stupid now? I had no idea that motion search was possible if I only recorded continuous. That should be stated somewhere prominently! (Probably is in the manual right?)

:-) Glad it was helpful.
You know server does MD all the time.
If you use MD only recording mode, it puts data on HDD only in case of motion. This is the only diff between motion and continuous recording. The rest is the same.

Good feedback. Id did not know it's not obvious. If you have suggestions on how/where do we promote this - would be nice:-)

And yes, we have it manual, but who cares :-)?

We were led to believe from the v1.2 version announcement, where full ONVIF support was added for server side motion detection, that it required a dual stream camera for the motion detection. Reading that press release again, it's still somewhat vague.


Get in touch with us so we can test and certify your cameras into HD Witness Video Management Platform for full and deep feature integration. Our Onvif integration takes advantage of Onvif compliant dual streaming capability. In doing so, all dual-streaming Onvif cameras can now utilize our advanced server-side motion detection and motion smart search system as well as efficiently operating within our enterprise bandwidth optimization engine.

In HD Witness V1.2 we have made major upgrades to that above mentioned server-side software motion search and sensitivity masking system. In our previous release we had introduced its capabilities only with Axis cameras. Now in V1.2 it is available on all Onvif dual streaming cameras. We made significant improvements to the sensitivity and zone settings and we further optimized the already minimal processor utilization algorithm.

well, after that we decided, why do not we do MD if there is only one stream with not too big resolution?

In fact we did it exactly because of the cases like yours ( sometimes due to lack of integration with legacy devices people use generic rtsp/hhtp links and still need to have MD and smart serach ).

Just to clarify. Using devices that only support ONVIF integration and server-side motion, if I have a single RTSP stream or if I have a camera such as a D-Link camera that only has a single stream output, will motion events still be tracked? According to the manuals I have read in the past, dual stream cameras are required when doing either continuous recording or motion-only/motion+low-res recording because the motion stream is tracked from the 2nd stream. The last time I recorded an RTSP stream motion events weren't tracked. When I used the "integration" with the DVR from DW, motion events weren't tracked in spectrum.

If motion events can be tracked when only a single stream is recorded continuously, then yes, this should be more prominently stated.

Also for clarification, if an encoder supports h.264 for the main stream and the second stream is mjpeg, will the VMS track the motion events using the mjpeg stream?


Just checked the manual you are right. There is a wrong info in it.

Here is how it works:
MD( and smart motion search) works if at least ones stream ( primary or secondary ) has resolution smaller than some threshold value( I believe 720xXXX). Second stream is not necessarily needed. It does not matter if it's H.264 or MJPEG. Only resolution matters.

... and oue server shoud record video ( not any DVR we integrated with ). We do not pull MD data out of DVRs...

Thanks so much. So the 2nd stream is essentially only required if you have a camera with a resolution higher than the threshold to prevent the server from becoming overloaded. Thus, if you had a 3MP camera with only one stream, you would need to set the stream to D1 or possibly 720P to be able to track motion events.

Does your camera calculator take into account server-side motion? I was curious how much that becomes a factor when selecting server specs.

sometimes it's good to have second stream even if the first stream is 720 or less.

first stream is 720p@30 fps
secondary stream is 480x320 7 fps also it has much lower quality.
In this case it's not only helps to unload CPU doing MD with secondary stream but also helps with playback experience trough low bandwidth channel ( software automatically switches between primary and secondary stream ).

Calculator takes into account server side motion detection with tha assumption that second stream is 480x320@7fps( and you know in this case CPU consumption is very low - we do MD very efficiency).

The worst case scenario is when stream has 720p size and 30 fps. In this case MD is very CPU consuming. And our calculator does NOT take that into account.

And some more hints. MD CPU consumption is mostly proportional to the pixels per second. For example 640x480@30fps stream takes ~8 times more CPU than 640x480@30 fps for MD. ( it does not mean that over all server CPU usage will be 8 times more ).

sorry "8 times more than 480x320@7fps."

Software automatically configures cameras to produce such stream by default. But you can go to camera expert page and change it.

Any Axis camera with a model number not starting with a letter is old enough to be likely network vulnerable and should be replaced, regardless of the vendor's capability to support it. Not saying they were bad cameras, but bugs have been seen and vendor updates have stopped on those models.

This is a good point but how vulnerable are they on a secure network when they don't have direct access to the Internet and first go through a VMS? Due to the limited budget that would be on this project, replacing the cameras isn't really a viable option.

With the proper network security, this isn't an issue, as Kyle said.