Record without encoding


#1

I have a dbpower c754 cam that provide a stream at 1080p in h.264 (add cam only with custom rtps url, onvif not run).

Is it possible to record the original cam stream?

thanks


#2

Hi!
Yes you can do that. The camera delivers a stream in the format h.264 for the 1080p resolution.
In NCS add the camera using the Custom URL like:

  • set stream type to rtsp_tcp
  • set the URL to rtsp://username:password@ipnumber;554/live/ch0

This should give you the video stream from that camera.
Good luck and you know where to find me if problems ;).
-Henrik


#3

Thank you for this answer but my question was to record the cam native stream without reencoding and compressing.

How can i set ncs to do this?


#4

Hi,
NCS is designed and optimized to be a surveillance system. The native stream from the camera is in avi fomat and imediately encoded to mp4. So in principal the answer is no. However, there is an option under recording where stream is saved in native format and then encoded to mp4. The plan was to use the cpu ‘free time’ for the encoding to mp4, but the cpu never has that so it did not work as planned so reencoding on the fly is much more efficient ;). If you enable that you will have an avi file in the folder so you can grab that with another software before it is deleted. That feature will probably be romoved in some future release. The internal format in NCS is mp4 so avi will not work.


#5

Ok, very good.

I have last version of NCS and I didn’t find the option under recording. Furthermore the cam stream is a mp4 not avi.
Anyway I believe that are very useful allow to save the original format (if it is in mp4 format) also to avoid losing image definition.

Is there a workaround for enable this feature? I would want to try.

Thanks.


#6

If the stream is already in mp4 NCS will not touch it. Here is the option

-Henrik


#7

I did some tests (rec/enc/dec with default configuration) and I noticed that with Background Encoding enabled NCS saves an AVI file with a bit rate at 89.6 Mb/s , which is then converted into an mp4 at 20.4 MB/s.

With Background Encoding disabled is saved directly an mp4 file with an bit rate equal to 8418 Kb/s .

The initial stream is an mp4 at 1080p with a bit rate of 3072 Kb/s.

How can I optimize this conversion? These bit rate are excessive.

Enable Background Encoding has not solved my initial problem.

Thanks.


#8

Thanks fort the info. Really interesting with these bit rates. How this really works and also with the ffmpg I do not know. I am not completely against the possibility to save in original format, but then I need some more arguments when this might be of interest to convince the developers. If this is difficult to solve or not I do not know. Maybe, just a click in a checkbox ;). A new version of NCS is under testing for release in a couple of weeks so maybe in a release after that.
Thanks,
Henrik


#9

I think current version no longer has the option to switch background encoding and it seems the encoding is forced by default.
Does it mean now there is no way to save the native h264 stream from the camera? Why does netcam need to reencode the stream? The encoding process is very cpu intensive task and since the camera hardware already does that for us, why we just waste it and force the encoding once again on local machine?

Is it only because of logo bar and the time stamp? If I get the paid license and disable the logo, would I then be able to save the native h264 stream from the camera?

I am asking because I use a rather budget PC and with 2 sources I have a lot of dropped frames and need to change the settings to the ultra fast which is not good for image quality. I wonder what are cpu requirements if there would be 6 or 8 cameras where all streams would need to be reencoded live.

I bet those cheap 4 or even 8 channel stand alone network NVRs do not recode but simply grab the camera stream and save to disk. Then there is almost no cpu processing power needed.

Still I think it would be good to have an option to choose either the original stream or to reencode locally (for whatever reason).


#10

Hi Robert,
Background encoding was removed for several versions ago. The purpose was to reduce the peaks of the CPU load by letting the encoding process run when cpu load was low. However, it worked in the other way where the cpu load increased and a delay in encoding. The software do all this very efficient as it is and therefore it was removed. It also used up a lot of disk space which was unfortunate.

You can read about the requirements for NCS here http://netcamstudio.com/ . Since the resolution of cameras has drastically increased during the last years what cpu is needed depends very much on the cameras, FPS and the recorded FPS. Cameras of vga, HD or even higher resolution demands much more cpu power. A standard cpu is today an Intel i5 which covers very well a “normal” system, but as I mentioned high resolution increase the need for a faster system a lot. Therefore, it is rather important to think about what is really needed. In one of my systems I have a laptop with an i3 processor that is probably 5-6 years old which works fine with 5 vga cameras and default settings. I have a system with 22 cams with vga to 1080p that need an i7 quad core with default settings so it varies a lot.

In your case, what is the cpu load? Maybe you can decrease the recorded FPS to 10 which I use a lot. Dropped frames can also be caused by communication problems with cameras using wifi.

-Henrik


#11

Thank you for comprehensive reply.

My CPU load during monitoring (no recording, but motion detection on) stays at 15-17%. During actual recording (which involves real-time recoding as I understand) increases to 35% as measured by Process Explorer for total system usage, where Netcam is practically the only CPU consuming program (this PC has no other tasks).

Now my recording settings are:
Quality: CRF 30
Preset: SuperFast
FPS: 10

There is now 1 IP camera (Wifi) with 720p stream over RTSP (Escam Q6 button camera). Most of the time the recording is quite smooth (10fps) but still ocasionaly there is a freeze frame for 1 or 2 seconds, typically at the beginning of each new video file. Earlier with higher encoding Preset, like Fast (or higher), it could barely make 1 fps on each recording.

The CPU is Intel Atom Z3735F. I am well aware it is no performance demon, that’s why I feel that the camera’s hardware potential of delivering the already encoded H264 stream is wasted. But the Windows system runs pretty well on it.

I will take a look at the CMS software provided by Escam, because I think it will simply retrieve and save the original H264 stream from the camera.

By the way, now when I look at it, spending few hundreds bucks for a PC based NVR (to make it a Core i5 or so) seems unreasonable when compared to getting a hardware based NVR for 30 USD with embeded Linux and software (adding a 500GB HDD for another 50 USD, which still puts me under $100) - it can do 8 channel 720p recording.
Unless I am missing something out?


#12

A 720p camera is a lot of calculations. The CPU load is not much, but as you say when changing preset Faster or higher it goes down to less than 1 fps it is clear a processor problem. That camera can deliver surely 30fps with no problems, but the computer can handle 10 fps. So as you say the Intel Atom is really not for this as discussed.
-Henrik