Netcam Studio 1.3.6

Here is a brand new version for you to play with.

It should address 2 important points which are often reported or requested:

  1. Some ONVIF devices are not being detected
  2. CPU Usage while recording

Regading ONVIF, I have spent hours of analyzing network traffic while using OnvifDM and comparing with the previous partial implementation. Indeed some things were different, I have finally been able to understand those differences and now it seems to behave stricly in the same way for all my 5 ONVIF cameras. Please give it a try in case you had some ONVIF cameras not detected (but detected in OnvifDM)

Regarding Recording, I have attempted to re-do what has been done since many years in webcamXP which is to record in real-time in MJPEG and then re-encode in MPEG-4 in the background, 1 file at time in order to spare the CPU time especially when recording multiple sources at time.

To use this, you’ll have to enable the option (Background encoding) in the Recording settings. Please also report if you notice a difference but it should divide by 2 the overhead caused by recording and therefore allow recording on more sources simultanously.

There are other smaller changes which will be detailed in the official release note when this version will be available to public.

Thanks to @Henrik it also includes about 10 new network camera templates which have been requested recently. On the other end I also had to upgrade a few libraries therefore It requires some testing / validation, this is also why i’m not 100% comfortable releasing this update officially right now.



These are excellent updates. Especially, the onvif detection system. Many of the new Chinese 3,4, 5 MP cams have onvif, but it is very difficult to find out how to connect. My 5 five onvif cams were detected in a vif. Better that onvifDM.

CPU load I am not so sure that I agree when dividing the process into recording and re-encode when times is. Someone can probably do a statistical calculation when this is optimal. I mean it really depends on the situation. If there are many cams that seldom record the separation will probably give a lower time average CPU load. If there are many cams that detect/record often the question is when it is a good time for re-encoding? The re-encoding process will take some CPU load and the question is if the sum of the two separate processes will be larger than the old system? I am probably wrong so explain for me, please. I tested with 8 cams, VGA to 1080p, and maybe if I think positive I could see a small decrease. There is a bigger difference between Super-fast and Ultra-fast. I tested the 32-bit version on an HP netbook where a separation of the processes really would have been valuable, but actually no difference.

The templates I could test works. But, for all “my” templates the button Test connection is grayed out?

The old template for the Edimax named IC-IC3116W is still there. The correct one, IC-3116W, is there also.

More to look for?


There is no test button for RTSP. It’s only available for JPEG / MJPEG presets.

As for the CPU load, i didn’t make very deep evaluation but mainly followed up the cpu usage of Netcam Studio to compare both modes.

On my dev and test computers recording would consume about 4-6% when encoding in real-time, with the MJPEG recording (which more intensively uses HDD btw) it’s around 1-3%. Then of course the background encoding is intensive but usually quick (it will take 1-2 seconds for 30 seconds video again on my main 2 computers I used to evaluate).

The big interest is when recording multiple cameras. You may have ended up in situation when you need 80% of your CPU to record and encode 4-5 sources at time, now at least it will only encode 1 video at time. The encoding process has a low priority so it should not much too penalize Netcam Studio if it requires power to record but anyway it requires some testing and benchmarking to really have confirmation that it’s more efficient. To me It seems to be more efficient in all cases but maybe i’m wrong…

For the time it’s an option and it’s disabled by default… Anyway the real-time encoding is still required for streaming (the Live mode) which is the exact same module than the real-time encoding for recording so there is no reason to remove it and making this an option seemed logical.

I really hope I am wrong since I and most likely many others should benefit from this. When version 136 is public released I will update a 131 system with intense recording with many cams to 136. The current cpu load of 90-95% and it would be very nice to lower that a lot not to add more cameras, bu to have a better video recording.
Is the test 4-6% and decrease to 1-3% based on 1 camera?

It’s based on 1 source at time but from different cameras or test streams (special sources) which are more stable in term of cpu consumption of their own.


Thanks for adding my DBPower camera profile! That was fast.


I hope it works. Also add the cam using the onvif tab.

Unfortunately, it didn’t detect on the onvif tab. :frowning: so, just used the profile.

Are your ONVIF cameras detected by OnvifDM ?

Updated which may normally support AAC audio :slight_smile:

Excellent! Unfortunately, I do not have an AAC cam on location, but maybe someone else have! This “normally” worries me a bit ;).

I didn’t try with AAC camera actually, I have used local files with AAC encoded audio for all my tests.

I have somewhere an Axis 1031 which allows chosing between g726 or AAC but was not motivated to go to those boxes full of electronics in my cave :slight_smile:

Please let me know if you notice anything special in your recordings with today’s build such as changes in smoothness or in CPU…

My testing environment is not the best right now; two 1080p cams in motion detection running on HP Netbook with 32bit Intel Atom 1,67 GHz, 1 GB RAM, Win10. However, it is interesting since it really use available resources!

  • smoothness I cannot say anything.
  • in general the cpu load seems to be lower. When I do other things on the computer it responds faster. If i check the CPU load in the Task Manager it do not saturate at 100% anymore. If I check the new box with separated processes, well the cpu load to at least not increase.

So, in general it is better. However, sorry for the not so scientific evaluation process ;). I´d really like to switch from 131 to this 1365 on my production system because there I will hopefully see a lot of change. Is it any problems going directly from 131 to 1365?


I’ve never tried so I don’t know…

I suppose it will soon be official because It should really address the most important complains and remarks that we have got and that were left in my list of things to improve and apparently I did not too bad :blush:

What is the criteria for starting the process of conversion from avi to mp4? In the same computer as above it never starts since it is quite occupied all the time. When I turn of recording on both cams it start to convert after an additional 30 minutes.

it starts right away (as soon as a recording ends) however now the non-background mode seems also much smoother.

Well, I am not so sure about this ;). In my case it never started, well it took 30 min after closing the cams recording.

you can check if you have a ffmpeg.exe process running, it should start right after.

Yes, the ffmpeg is running. The problem is that “something” is to slow. The generation of avi files are much faster than the process to decode to mp4 can handle and it escalates. There are 25 more videos in the pipeline.