amirm

Thank you for posting your image. We can do a lot with that bit of information. Here are some observations: 1. You see how the diagonal lines in your driveway are jagged/rough? That is due to an interlace (normal TV) camera sensor. In presence of slightest camera/subject motion/vibrations, you lose half your vertical resolution resulting in kind of artifact you see here. The camera or DVR software can filter these but then you get a softer image, not a sharper one. Advanced de-interlacing like used in better built A/V equipment does a better job here but I have not seen evidence of it being used in CCTV market yet. The sensor in Mobotix is progressive and hence, has full 480 lines of vertical resolution. Note that this kind of artifact makes the video harder to compress. So all else being equal, you also get more compression artifacts at the same data rate as that of a progressive sensor. When picking an IP camera, it is super important to make sure it uses a progressive sensor. There is no reason (other than saving a couple of dollars in manufacturing) to use an interlaced sensor. I have noticed for example that some of the Acti IP cameras use interlace sensor (evidenced by the same artifact shown here in their demo material). 2. Cross-color/False-color visible in details. Look at the basketball net. You see the red/blue color bleeding there? That is an artifact of NTSC decoding not done right and/or fault of the NTSC format itself. same thing is visible in the bush branches near the mailbox. There, you see that artifact combined with problem #1, making a mess of that object. Analog comaras sending their NTSC signal over a single composite (coax) wire will have this sort of artifacts which reduces effective resolution of the image once more. As with #1, the extra "information" (false color) makes compression harder resulting in either larger files (if data rate is allowed to be higher) or more artifacts (if data rate is kept constant). Again, the progressive sensor in an IP camera is sending pure data and not subject to NTSC flaws that come from sending that signal over coax wire (as opposed to a fraction of an inch inside an IP camera). 3. I see more compression artifacts. For example, let's look at the camera captions. We see what we call "ringing." These are halos that get created at the edges of objects (the sharper the edge, the more you see them). On top of that, you also see problem #2 in them with false pink shades bleeding into them as the signal had to be modulated into NTSC and demodulated back in the DVR. This again makes them harder to compress. I see a lot of "blocking artifacts" in the cement driveway. These are square blocks that show up when that segment of the video is overcompressed. Another manifestation is image detail completley getting destroyed when these artifacts get too high. Look at the line at the intersection of the driveway and road. That line is barely visible. It is destroyed by combination of all three factors explanied here. Grass is very difficult to compress and here, we see them becoming a sea of little blocks/blurriness, taking away their nature texture. On this front, I would say your image was harder to compress so on this bit, I think the comparison is not quite fair. Partial olution for #3 would be to boost your data rate/quality setting. Set it way high for testing and you should at least eliminate problem #3, leaving you with #1 and #2. 4. NTSC signal sent over a coax wire CANNOT send 4CIF worth of horizontal resolution. The system is not cable of doing that, period. So your image has lower resolution than the sensor would indicate. Again, Mobotix doesn't use NTSC so it can send all the signals as it sees them. See my post in the middle of the page here: http://www.cctvforum.com/viewtopic.php?t=10415&start=45 (how do you link to single post here?). You are losing nearly 40% of your resolution this way! Net, net, this is a classic example of how well a progressive IP camera works relative to an analog TV. Unless you come and tell me your camera was also IP in which case, I have to make a visit at this company and teach them a thing or two about proper design .

The wiki doesn't say much unfortunately. Again, best advice is to go to a camera company web site and download both operational and SDK documentation. There you will find everything you are asking about, assuming you have decent knowledge of computers, networking and video. For now, here is a bit more on what I post: 1. Video format. The core compression is either MJPEG, MPEG-4 or H.264 (ala MPEG-4 AVC) with the latter being rather new. MJPEG is just JPEG repeated so many times per second (M stands for "Motion"). The other two are what the standards say they are. 2. The transport layer is what I described before. Let's say you just want to see JPEG images. There, you are using the web browser to talk to the integrated web browser in the camera which formats an HTML page for control and embeds the JPEG images. 3. Application layer. For more sophisticated control and/or to support propriatary formats, all the camera companies supply ActiveX controls (programs which run inside the browser). The program then is able to do specialized things like better control, playback of video using higher performance pipeline, etc. Some give you the SDK interface so that you can write your own application like these. 4. DVR software. This is a security management software. Some camera companies provide these, others rely on third-parties. Hope this gets you started....

Are you looking for a PC solution or dedicated box?

You are asking someone to write you a book . Here is a bit to get you started.... In the simplest form, the camera has a web browser and sends over its UI and images using HTTP (or https for secure connections). In another form, say in a Mobotix camera, it is able to open any Windows share (SMB) and write directly onto it. So this is SMB over TCP. Yet another way is using ftp. And there are schemes using streaming protocols such as RTSP. In other words, there is no single standard for shipping the bits over. It all depends on the camera and usage mode. I suggest going to the web site of the camera company and downloading their manuals. There, you see all the configuration parameters. Start with Axis, ACTi, Mobotix, Arecount. These are the ones that I know have manuals to download.

So much indeed. Yet, I am still looking for the one answer I asked about. What standard will be used to carry analog HD signal? We don't need a tutorial on camera technology again . Please tell us what analog HD signal supports > 2 megapixels. You put too much trust in Baluns and UTP. Video has very low signal to noise ratio. Unlike digital signals over twisted pair, an analog HD signal has no error correction. What comes out of a 100 foot of UTP is anything but "pure." Go ahead and test it. Send it a 1080p signal with on/off pixels and see if you can see the pixel seperation at the end of that signal on your TV. You will not. Let's put that aside. Can you explain how you get analog HD signal into your DVR prior to compression? Again, please no tutorial on unrelated topics. This is a simple question. Computers/DVRs can't deal with analog signals. You must digitize them prior to processing/compression. Please explain to me where you get a 16-channel analog HD capture. Sorry but 568B is not a video standard but how the wires are connected in a UTP configuration. I am asking how the video signal is transmitted. Examples in digital domain are CCIR 709 for HD video and CCIR 601 for SD. IP is a protocol. The transmission is Ethernet. I can put any protocol on it I want. Indeed, no magic is required where the distance between the CCD and A/D is only a fraction of an inch inside the camera. Bring that CCD signal out of the camera in analog domain and attempt to send it long distances and you have a ton of new problems, starting with the fact that there is no standard for > 1080p. Inside the camera, I can go any resolution I want since the other end is also inside the camera so no standard compliance is necessary. Such is not the case in the world you are describing. This is true but we are still trying to understand what you are poposing. If you don't have a solution which works, it doesn't matter how bad the alternative is today. This is partially true. Many new graphics controllers now have full hardware decoding to deal with Blu-ray playback. AVC (h.266), VC-1 (technology my group developed), and MPEG-2 are available even in $400 PCs today. ATI, Nvidia and Intel silicon already has this support. Admittedly, I am not sure if the camera software is smart enough to use it though but this is not a limitation of IP solutions. Again, IP is not a perfect solution. But you haven't shown anything else is possible. If I want 3 megapixel image, how do I get that in your solution? If you can't deliver that, then it doesn't matter what else is good about your proposal.

So much indeed. Yet, I am still looking for the one answer I asked about. What standard will be used to carry analog HD signal? We don't need a tutorial on camera technology again . Please tell us what analog HD signal supports > 2 megapixels. You put too much trust in Baluns and UTP. Video has very low signal to noise ratio. Unlike digital signals over twisted pair, an analog HD signal has no error correction. What comes out of a 100 foot of UTP is anything but "pure." Go ahead and test it. Send it a 1080p signal with on/off pixels and see if you can see the pixel seperation at the end of that signal on your TV. You will not. Let's put that aside. Can you explain how you get analog HD signal into your DVR prior to compression? Again, please no tutorial on unrelated topics. This is a simple question. Computers/DVRs can't deal with analog signals. You must digitize them prior to processing/compression. Please explain to me where you get a 16-channel analog HD capture. Sorry but 568B is not a video standard but how the wires are connected in a UTP configuration. I am asking how the video signal is transmitted. Examples in digital domain are CCIR 709 for HD video and CCIR 601 for SD. IP is a protocol. The transmission is Ethernet. I can put any protocol on it I want. Indeed, no magic is required where the distance between the CCD and A/D is only a fraction of an inch inside the camera. Bring that CCD signal out of the camera in analog domain and attempt to send it long distances and you have a ton of new problems, starting with the fact that there is no standard for > 1080p. Inside the camera, I can go any resolution I want since the other end is also inside the camera so no standard compliance is necessary. Such is not the case in the world you are describing. This is true but we are still trying to understand what you are poposing. If you don't have a solution which works, it doesn't matter how bad the alternative is today. This is partially true. Many new graphics controllers now have full hardware decoding to deal with Blu-ray playback. AVC (h.266), VC-1 (technology my group developed), and MPEG-2 are available even in $400 PCs today. ATI, Nvidia and Intel silicon already has this support. Admittedly, I am not sure if the camera software is smart enough to use it though but this is not a limitation of IP solutions. Again, IP is not a perfect solution. But you haven't shown anything else is possible. If I want 3 megapixel image, how do I get that in your solution? If you can't deliver that, then it doesn't matter what else is good about your proposal.

So much indeed. Yet, I am still looking for the one answer I asked about. What standard will be used to carry analog HD signal? We don't need a tutorial on camera technology again . Please tell us what analog HD signal supports > 2 megapixels. You put too much trust in Baluns and UTP. Video has very low signal to noise ratio. Unlike digital signals over twisted pair, an analog HD signal has no error correction. What comes out of a 100 foot of UTP is anything but "pure." Go ahead and test it. Send it a 1080p signal with on/off pixels and see if you can see the pixel seperation at the end of that signal on your TV. You will not. Let's put that aside. Can you explain how you get analog HD signal into your DVR prior to compression? Again, please no tutorial on unrelated topics. This is a simple question. Computers/DVRs can't deal with analog signals. You must digitize them prior to processing/compression. Please explain to me where you get a 16-channel analog HD capture. Sorry but 568B is not a video standard but how the wires are connected in a UTP configuration. I am asking how the video signal is transmitted. Examples in digital domain are CCIR 709 for HD video and CCIR 601 for SD. IP is a protocol. The transmission is Ethernet. I can put any protocol on it I want. Indeed, no magic is required where the distance between the CCD and A/D is only a fraction of an inch and can be any design one wants. Bring that CCD signal out of the camera in analog domain and attempt to send it long distances and you have a ton of new problems, starting with the fact that there is no standard for > 1080p. Inside the camera, I can go any resolution I want since the other end is also inside the camera so no standard compliance is necessary. Such is not the case in the world you are describing. This is true but we are still trying to understand what you are poposing. If you don't have a solution which works, it doesn't matter how bad the alternative is today. This is partially true. Many new graphics controllers now have full hardware decoding to deal with Blu-ray playback. AVC (h.266), VC-1 (technology my group developed), and MPEG-2 are available even in $400 PCs today. ATI, Nvidia and Intel silicon already has this support. Admittedly, I am not sure if the camera software is smart enough to use it though but this is not a limitation of IP solutions. Again, IP is not a perfect solution. But you haven't shown anything else is possible. If I want 3 megapixel image, how do I get that in your solution? If you can't deliver that, then it doesn't matter what else is good about your proposal.

You could indeed use Baluns but then you are spending even more money and the link is still analog and subject to noise and resolution loss. HDMI would be digital so can't be what is talking about . For long distance digital, HD-SDI is used in broadcast world.....

I wouldn't be . First, what he is saying already exists in the from of Axis Q1755. http://www.axis.com/products/cam_q1755/index.htm The Axis is a hybrid camera with H.264/JPEG compression over Ethernet and component analog HD. So you could hook up the analog feed to a standard HDTV and have real-time viewing yet have the compressed IP stream for capture. They rightly do not advertize that you use the HD analog feed and use that for capture. But for zero delay viewing in short distances it solves one of the problems he states with IP. He says that you want to capture the analog HD at the DVR. I say good luck finding ways of cheaply digitizing and then compressing analog HD. NTSC analog capture costs nothing. HD capture does. And of course, any analog transmission is liable to lose fidelity as you ship it long distances as it picks up noise and loses high frequency data (fine detail). And with signals like component, you can get color shift if the three cables are not identical in characteristics.

Then please answer the specific question I asked. What is the interface specifications for "analog HD?" I listed the only one I know: component video requiring three coax cables. Are people prepared to run three coax now or are you saying there is a new video standard being cooked up in private by CCTV world (as there is none in broadcast where these usually come from). It shouldn't be hard to asnwer the above if products are only 6 months from introduction as they would have to use silicon already designed. Hence the question above. Hope we all agree that if the "analog HD" is not one in the SMPTE book, then you are cooking something that is far worse than IP transmission if I need to use new cables and interfaces at the DVR side just to capture the bits. And please articulate how you go above 1080p (1920x1080) which the current broadcast standards support.

I am not seeing anything in your post backing the claim that analog HD transmission to a DVR is the way to go. This is what we were responding to. You say that there are PCs with hardware H.264 encoders but don't say why the same cannot be in the camera. Net, net, for anything greater than NTSC/PAL resolution, the world is going to be IP with encoding in camera. I am not seeing any logic or economics driving people to send gigabits/sec signals from camera to the source when megabits/sec would do. This doesn't make IP cameras perfect. But does indicate the way the industry has to go, as opposed to analog HD which was stated.

I am not sure I fully understand your set-up. But if you are asking if a S-Video (S-VHS as you call it) can be replaced with coax, the answer is yes. But you need two of them. One carries the black and white signal and the other color. If you only have one coax, you can use that but you lose color.

Are you saying there is a new standard for analog transmission of HD signals for CCTV? If so, what is the format? I am not aware of single cable analog HD schemes. We have component video but that requires three coax cables and is essentially obsolete format. Current uncompressed broadcast standard is HD-SDI (i.e. digital, not analog). They do but per above, it is digital, not analog. Axis has a new camera with HDMI output but that link cannot travel long distances (50 feet is probably the limit). Unless you can cite specifics, I don't see any reason why CCTV world would migrate toward analog HD or HD-SDI. But then what? What do you do with it after you watch it on a TV? How do you record it? Convert to digital? Well, do that first in the camera! I can't see having a nice HD signal and then sending it over long wires and causing it to degrade. Why would this improve if you send the signal over analog link rather than digital/compressed? This is not a problem with "IP cameras" but rather, the limiation of the encoder used in them. A better encoder can give you any frame rate you want. Besides, what will you do with your analog encoder? How do you get high frame rates with say, 8 to 32 cameras? Have that many full frame rate H.264 encoders? That gets expensive, no? And if you have that kind of budget, no doubt people can create cameras for you with full frame rate encoders. You get that with either scenario. Assuming there is a monitor which can show your hypothetical analog signal, then you have an advantage here. Encoders in the cameras need to look ahead a few frames in order to gain efficiency. So that much latency is introduced. M-JPEG and MXPEG don't have this limitation. Well, you have the biggest compatibility with the propriatary analog signal for your camera . How is that? Gigabit switches cost nothing these days. And 100 mbit/sec can give you superb video (Blu-ray disc video runs at 48 mbit/sec). Their market share is no doubt due to high costs. Agree that they are not perfect. But we are probably 18 to 24 months away from superb solutions on the encoding side. CMOS sensor in professional SLR cameras run at full frame rate and have very wide exposure lattitude. So I see no limitation to how far IP cameras can go. I simply do not see any reason to go to analog transmission over coax.

Right... Battery isolates (of different designs) are also very common in boating/marine world. So if you have a west marine or Boater's world near you, they also carry them. Both also have web sites and the former has pretty educational documents on the subject. I wonder how well an IP camera with embedded SD slot would work as far as power consumption. I suspect it will work better than an external DVR. Panasonic makes some low cost units but power consumption is not so low (6-7 watts): http://www2.panasonic.com/consumer-electronics/shop/Computers-Networking/Network-Cameras/Network-Cameras/model.BB-HCM531A.S_11002_7000000000000005702#tabsection

There is no cheap or easy solution to what you are looking for. 2 miles is a long, long distance when it comes to pushing bits or video. The cost will certainly be more than whatever is getting damaged. If the car is next to the business why not use the business as a bridge? You could put a wireless router there, put a wireless camera in the car and feed the latter from the car battery if you are sure to drive the car everyday. Then you can monitor everything from your house, by connecting to the work computer/server.

Actually they have a shorter life. NAND Flash memory has limitted write cycles. There are algorithms to spread the load to every cell (load levelling) but even with that, life expectancy in this application is going to be short. More expensive SLC Flash (as opposed to MLC) tends to have longer life but it also costs a lot more.

My background is both in the broadcast industry and computer/IT/signal processing. My group at Microsoft led the development of MPEG-4 AVC (H.264) and its competitor, VC-1. My team also had extensive experience in optimizing encoders to run fast both on PC and non-PC environment. This is me if you want to read more http://www.microsoft.com/presspass/exec/amirm/default.mspx You are correct that encoders in cameras cheat a lot to reduce computational requirement of encoding video. H.264 is especially CPU intensive. It takes a cluster of PCs to approach real-time encoding for production of Blu-ray High Definition discs. VC-1, is about twice as fast but still, both take a lot more CPU than MPEG-2 and far more than MJPEG. So it is not enough to hear that some encoder is H.264. What is important is what features of the standard it uses. At the extreme, H.264 is only 10 to 30% more efficient than MPEG-2 which is not a whole lot. To get 2X or higher, the encoder must support more advanced features like multiple reference frames, "CABAC," etc all of which take considerably more CPU. How do you provde which library (encoder) was used? Encoders do not leave a trace to prove which software or hardware was used. So the hash is not going to be strong evidence. Now you could argue that the same is true of the in-camera encoder . I suspect though human evidence of what was used is easier to come by in the case of a camera output going directly to disc as compared to some system with ever changing software recompressing things. At the end though, maybe we are splitting hairs here. I don't know .

Can you provide some specifics? In the world of digital video where I come from, encoding in HD at 1080p (2 megapixels) is barely doable with the latest quad core CPUs at 24fps. And that is a single stream. Increase resolution up to 3 or more and the job becomes even more difficult. Sure, you can take shortcuts and produce compliant streams but quality will not be there. I can see both sides of this argument. One may want to optimize the data rate for example for the camera in use. A night camera with a lot of noise may need to be encoded at higher bitrate as opposed to one with plenty of light. And of course, if the cameras are not identical, then the settings will not be either. I would imagine in either case you need to show that manipulation is difficult. I think most people would agree that modifying a camera's encoder is much harder than some PC software performing the same function.

Also in reference to motion detection mentioned in the article and here: http://ipvideomarket.info/report/video_analytics_greatest_value__storage_reduction, I was surprised to see that this is a misnomer. In the one camera design where the algorithm was disclosed (I forget the brand), there is no real motion detection. But rather, the frame brightness is compared to previous one and if there is sufficienty change, then the camera declares that it has seen "motion." Needless to say, this will generate false positives in that if the light levels change, you wind up recording things when nothing of significance has occured in the image. Now maybe it doesn't matter in grand scheme of things. But as a guy coming from signal processing/compression, it is kind of bothersome to see the wrong terminology used here.

What would be cool would be powering them all up, point them at the same scene and let us compare!

First, let me say that I enjoy reading your articles. They are short and to the point . On this front though, I think the poster "CameraMan" hit the right note. If you buy a NAS (or PC solution) with room to grow, then the incremental costs are what he stated. Namely, a 1.5 TB Seagate drive cost $130 to add, not $750 to $1000. Your answer to him that you need a new enclosure only holds if you blow past the capacity of the box you bought. Amortized over the cost of say, 4 drives, the cost of the base engine is well below your estimate anyway. Having said this, as I look at my own application with 8 cameras, with half at megapixel resolution, the amount does add up. Or else, you don't get to hold the video for as many days. The advent of MPEG-4 AVC (H.264) over MJPEG and simple MPEG-4 implementation is also significant in saving some storage costs. This of course assumes that they are using a proper AVC encoder and not just something that is compliant with the bitstream but lacks the "tools" to provide full efficiency.

That's using M-JPEG. Using their proprietary MxPEG they get 10 fps. Before you say it, wish they used an open standard instead .

I have an explanation purely from reading their specs/documentation. They took out H.264 encoding and only support motion-JPEG! I suspect in low quantities an H.264 encoder costs $35 to $40. Add some extra logic such as memory and such, and material cost difference is in $50 range. Mark that up by the time it gets to retail and it explains the differnce. Still, not a bad option to have if cost is more important than storage/transmission costs. Clever way of quickly differentiating products...

True. Best to look at the size of the sensor as to *some* indication of its light gathering abilities. A larger sensor will have less noise. Less noise means a clearer image but more imporantly, one that compresses better! I assume you mean an analog TV. A digital TV goes up to 1920 now. And computer monitors even higher. That is the vertical resolution and is fixed by NTSC for all cameras (the actual visible lines is 486). The more important number is the horizontal resolution we have been talking about. Correct and progressive scan also helps. Long topic to get into . For now, here is a tidbit from the photography world. All else being equal, a telephoto lens performs better than a wide angle one. In addition to better resolution, there is also less (geometric) distortion in a telephoto lens. Now, the CCTV sensors are tiny so it is not clear how much the above applies to them. But thought folks may want to keep that in mind as they evaluate different cameras. Perhaps it becomes a factor as we climb above 2 megapixels.... I am trying .

You forgot someone trying to hand draw the image using crayons! Seriously, as I mentioned, there is debate about what is the right Kell factor to use. But it is important to note, as Kell did, that we are not attempting to take a picture of a static image with 100% stationary camera (i.e. no movement or vibration). But if this is bothersome still, folks can simply use Nyquist rule and assume that you need 2X the sample rate to achieve X amount of detail. It would be a conservative estimate but defensible.