IP vs. Analog

[Soundy 1]

Therein lies the other problem: how long will it take this technology to get to market? Not prototypes or demos or brochures, but to actually be available for purchase at a reasonable cost?

 

BTW, if you "don't have space" for IP infrastructure, I don't see how this would be any better. Storage systems won't take any less physical space - you still need a ****load of drives. Cabling certainly won't take less space; in fact, it would probably take more cabling as everything would have to be home-run. The only additional equipment needed for IP is the switch(es)... 24 ports in 1U is pretty compact. Make it a PoE switch and you don't even need a separate power supply for the cameras.

[amirm 0]

We can have this discussion in 6 months when analog HD cameras hit the market

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.

 

and oh by the way remember that the market for HD cameras is 1% - so we come back to 99% of the world still wants a basic non proprietary camera and if you think that is IP when there is a legacy world out there I have nothing more to say on the subject.

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.

[amirm 0]

OK, I'm hooked.

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.

[Soundy 1]

We can have this discussion in 6 months when analog HD cameras hit the market

 

Until then, the whole concept is "RSN", isn't it? One can make grandiose promises of what's "just around the corner" until the proverbial cows come home... don't mean squat in the real world until it's actually available for purchase.

 

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).

 

Well, you can run component over Cat-5e with baluns... or you could put HDMI outputs into your cameras, but your distance would be pretty limited without expensive extenders.

 

and oh by the way remember that the market for HD cameras is 1% - so we come back to 99% of the world still wants a basic non proprietary camera and if you think that is IP when there is a legacy world out there I have nothing more to say on the subject.

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.

 

That's my main concern as well.

[amirm 0]

Well, you can run component over Cat-5e with baluns... or you could put HDMI outputs into your cameras, but your distance would be pretty limited without expensive extenders.

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.....

[jisaac 0]

I did not read all the reply's. So excuse me if I repeat some information.

 

When you are wanting to put your entire system on the network there are many things you need to do first.

First you need to find out exactly what you can partition of for the video system. In terms of bandwith what do you have available? 1G? 100M, 10M, 100K? Ok maybe that last one was a stretch but you get the point.

Buying all the nicest cameras in the world does not do you a bit of good if you do not have the means to transport the video.

Once you get an idea of the amount of bandwith you have available you can start to figure out exactly what that means in terms of # of cameras, resolution, frame rate, and so on and so forth.

You also need to get some kind of threshold of what type of quality that you need at a minimum to get the results that you are looking for. That way you start to make out a system level synthesis and operational scenarios.

 

Hope that gives you a starting point

t.

[jisaac 0]

I did not read all the reply's. So excuse me if I repeat some information.

 

When you are wanting to put your entire system on the network there are many things you need to do first.

First you need to find out exactly what you can partition of for the video system. In terms of bandwith what do you have available? 1G? 100M, 10M, 100K? Ok maybe that last one was a stretch but you get the point.

Buying all the nicest cameras in the world does not do you a bit of good if you do not have the means to transport the video.

Once you get an idea of the amount of bandwith you have available you can start to figure out exactly what that means in terms of # of cameras, resolution, frame rate, and so on and so forth.

You also need to get some kind of threshold of what type of quality that you need at a minimum to get the results that you are looking for. That way you start to make out a system level synthesis and operational scenarios.

 

Hope that gives you a starting point

 

 

 

Hope that gives you a starting point

t.

[cctvexpert 0]

so many things to answer

 

First, all cameras start out as analog - again CCD or CMOS but analog image sensors its all in the A/D and D/A conversion.

 

Baluns well balun stands for balance unbalanced and in fact want noise. Baluns and UTP have interference rejection and crosstalk immunity.

 

I can take 16 cameras and run then across cat5 using baluns and a balun hub and not compress the video and have a pure signal. This is all done passive. I can punch down to a patch panel or anything passive with up to 10 cuts and follow 568B standards. Perfect image uncompressed live video no latency.

 

If i take 16 IP cameras and encode there is automatically latency and no live image. It is all active, loss of the network, viruses, bandwidth congestion, and on and on. Oh yea and i am going to pay more.

 

IP is a transmission method thats it.

 

All the megapixel cameras start out as analog is what you forget. You are converting it to digital. So in order to make the megapixel camera HD you just put in line a D/A converter, there is no magic.

 

As far as transmitting the HD there is no difference in the architecture and methodololgy. If you are running megapixel and using PoE that is Cat5 cable. Can go into a novel about transmitting video both analog and digital over UTP.

 

My question to anyone is why are you going to pay more and get less. FYI, the IP cameras in the market do not use open standards. While the codec may be H264 or MPEG4 or whatever they are proprietary if they werent then you could simply run them on any windows media player which you cannot.

 

If you have 16 different IP cameras from a half dozen manufacturers you have to hope your NVR solution supports them. If the NVR gets upgraded you have to hope the upgrade supports them.

 

Last but not least you cannot software decode megapixel cameras without maxing out the CPU, its a fact of life. You can fight about IP cameras all day long but they have limited use and the real pros know this. Axis and others can spend zillions on advertising but they cannot reinvent math and science. Latency will always be a problem of math and physics and there is no fault tolerance.

 

There is also the issue of what each of the IP cameras support in their SDK. One camera may have some basic functionality and not have others and similarly some IP cameras well the point is there is no consistency. Even within Axis or any of the others one company and a zillion different SDK's. Not only do you not have a single SDK for the entire codec family but it varies from manufacturer to manufacturer and from model to model.

From the programmatic aspects there is no way to build in proper software testing. If everytime you add a feature to an NVR you have to test 100 models, it is impossible to regression test or have any proper quality control in the testing aspects.

 

I can show you 100 casinos running hundreds and thousands of cameras running on analog platforms with virtually no downtime. Show me how many enterprise IP camera systems are out there and show me one with any fault tolerance.

 

Much to the chagrin of the IP manufacturers it is the opposite of their BS. the further you scale the more complicated it becomes and the less value it has because of having to try to transmit and manage.

[amirm 0]

so many things to answer

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.

 

Baluns well balun stands for balance unbalanced and in fact want noise. Baluns and UTP have interference rejection and crosstalk immunity. I can take 16 cameras and run then across cat5 using baluns and a balun hub and not compress the video and have a pure signal.

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.

 

This is all done passive. I can punch down to a patch panel or anything passive with up to 10 cuts and follow 568B standards. Perfect image uncompressed live video no latency.

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 transmission method thats it.

IP is a protocol. The transmission is Ethernet. I can put any protocol on it I want.

 

All the megapixel cameras start out as analog is what you forget. You are converting it to digital. So in order to make the megapixel camera HD you just put in line a D/A converter, there is no magic.

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.

 

If you have 16 different IP cameras from a half dozen manufacturers you have to hope your NVR solution supports them. If the NVR gets upgraded you have to hope the upgrade supports them.

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.

 

Last but not least you cannot software decode megapixel cameras without maxing out the CPU, its a fact of life.

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.

 

Much to the chagrin of the IP manufacturers it is the opposite of their BS. the further you scale the more complicated it becomes and the less value it has because of having to try to transmit and manage.

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.

[amirm 0]

so many things to answer

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.

 

Baluns well balun stands for balance unbalanced and in fact want noise. Baluns and UTP have interference rejection and crosstalk immunity. I can take 16 cameras and run then across cat5 using baluns and a balun hub and not compress the video and have a pure signal.

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.

 

This is all done passive. I can punch down to a patch panel or anything passive with up to 10 cuts and follow 568B standards. Perfect image uncompressed live video no latency.

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 transmission method thats it.

IP is a protocol. The transmission is Ethernet. I can put any protocol on it I want.

 

All the megapixel cameras start out as analog is what you forget. You are converting it to digital. So in order to make the megapixel camera HD you just put in line a D/A converter, there is no magic.

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.

 

If you have 16 different IP cameras from a half dozen manufacturers you have to hope your NVR solution supports them. If the NVR gets upgraded you have to hope the upgrade supports them.

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.

 

Last but not least you cannot software decode megapixel cameras without maxing out the CPU, its a fact of life.

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.

 

Much to the chagrin of the IP manufacturers it is the opposite of their BS. the further you scale the more complicated it becomes and the less value it has because of having to try to transmit and manage.

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.

[amirm 0]

so many things to answer

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.

 

Baluns well balun stands for balance unbalanced and in fact want noise. Baluns and UTP have interference rejection and crosstalk immunity. I can take 16 cameras and run then across cat5 using baluns and a balun hub and not compress the video and have a pure signal.

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.

 

This is all done passive. I can punch down to a patch panel or anything passive with up to 10 cuts and follow 568B standards. Perfect image uncompressed live video no latency.

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 transmission method thats it.

IP is a protocol. The transmission is Ethernet. I can put any protocol on it I want.

 

All the megapixel cameras start out as analog is what you forget. You are converting it to digital. So in order to make the megapixel camera HD you just put in line a D/A converter, there is no magic.

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.

 

If you have 16 different IP cameras from a half dozen manufacturers you have to hope your NVR solution supports them. If the NVR gets upgraded you have to hope the upgrade supports them.

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.

 

Last but not least you cannot software decode megapixel cameras without maxing out the CPU, its a fact of life.

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.

 

Much to the chagrin of the IP manufacturers it is the opposite of their BS. the further you scale the more complicated it becomes and the less value it has because of having to try to transmit and manage.

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.

[ak357 0]

so many things to answer

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.

 

 

I dont think u will get answer from "cctvexpert"

I asked the ??? 2 times on jan 4

still waiting for answer

[survtech 0]

BTW, if you "don't have space" for IP infrastructure, I don't see how this would be any better. Storage systems won't take any less physical space - you still need a ****load of drives. Cabling certainly won't take less space; in fact, it would probably take more cabling as everything would have to be home-run. The only additional equipment needed for IP is the switch(es)... 24 ports in 1U is pretty compact. Make it a PoE switch and you don't even need a separate power supply for the cameras.

It's not the storage or recording systems we don't have the space for, it's the distribution system. Space for IDF closets is nonexistent and making the room for them would encroach on the gaming floor - something that would be a difficult "sell" to the casino.

 

Keep in mind that we would have to follow ethernet best practices. That means 100 meters maximum distance from camera to switch and from switch to recording system. The existing system is a mix of RG-59 coax and analog twisted-pair with runs that go from each camera directly back to the Surveillance Room for RG-59. For twisted-pair, the runs are all CAT-5 - 4-pair from the camera to 66 punchdown blocks to 25-pair backbones to 66 punchdown blocks to 4-pair to our recording system. Each camera run is approximately 50 ft. to approximately 700 ft. with no break except for the non-IP-ready 66 punchdown blocks.

 

Although network switches are only 1U, we still have to put them somewhere with power and cooling. Switches would need to be in secure, air conditioned rooms and the power would have to be UPS'd because we can't afford to have multiple cameras go out if someone kicks off a circuit breaker or we have a power failure. Remember, we have over 1000 cameras; most too far away to home-run ethernet cables. Many are too far to get back with one "jump", so they would either have to come back on fiber or go two "jumps"; with the added latency.

[jisaac 0]

so many things to answer

 

First, all cameras start out as analog - again CCD or CMOS but analog image sensors its all in the A/D and D/A conversion.

 

Baluns well balun stands for balance unbalanced and in fact want noise. Baluns and UTP have interference rejection and crosstalk immunity.

 

I can take 16 cameras and run then across cat5 using baluns and a balun hub and not compress the video and have a pure signal. This is all done passive. I can punch down to a patch panel or anything passive with up to 10 cuts and follow 568B standards. Perfect image uncompressed live video no latency.

 

If i take 16 IP cameras and encode there is automatically latency and no live image. It is all active, loss of the network, viruses, bandwidth congestion, and on and on. Oh yea and i am going to pay more.

 

IP is a transmission method thats it.

 

All the megapixel cameras start out as analog is what you forget. You are converting it to digital. So in order to make the megapixel camera HD you just put in line a D/A converter, there is no magic.

 

As far as transmitting the HD there is no difference in the architecture and methodololgy. If you are running megapixel and using PoE that is Cat5 cable. Can go into a novel about transmitting video both analog and digital over UTP.

 

My question to anyone is why are you going to pay more and get less. FYI, the IP cameras in the market do not use open standards. While the codec may be H264 or MPEG4 or whatever they are proprietary if they werent then you could simply run them on any windows media player which you cannot.

 

If you have 16 different IP cameras from a half dozen manufacturers you have to hope your NVR solution supports them. If the NVR gets upgraded you have to hope the upgrade supports them.

 

Last but not least you cannot software decode megapixel cameras without maxing out the CPU, its a fact of life. You can fight about IP cameras all day long but they have limited use and the real pros know this. Axis and others can spend zillions on advertising but they cannot reinvent math and science. Latency will always be a problem of math and physics and there is no fault tolerance.

 

There is also the issue of what each of the IP cameras support in their SDK. One camera may have some basic functionality and not have others and similarly some IP cameras well the point is there is no consistency. Even within Axis or any of the others one company and a zillion different SDK's. Not only do you not have a single SDK for the entire codec family but it varies from manufacturer to manufacturer and from model to model.

From the programmatic aspects there is no way to build in proper software testing. If everytime you add a feature to an NVR you have to test 100 models, it is impossible to regression test or have any proper quality control in the testing aspects.

 

I can show you 100 casinos running hundreds and thousands of cameras running on analog platforms with virtually no downtime. Show me how many enterprise IP camera systems are out there and show me one with any fault tolerance.

 

Much to the chagrin of the IP manufacturers it is the opposite of their BS. the further you scale the more complicated it becomes and the less value it has because of having to try to transmit and manage.

 

 

Jesus christ! Some of what you said is true but most is your opinion. Latency is not that bad. Hell I on a daily basis work with a client that is one of the largest electrical companies in the US and I have to Remote Desktop in to a computer at their headquarters to get access to the video at the substations and it is not that bad. We are talking milliseconds.

 

Second you can get better overall quality if you have the capacity on your network with IP megapixel cameras. End of story.

 

I have yet to see any HD analog cameras. Not saying there is not any just have not seen any.

 

And if all cameras are analog andrt all the analog ca just being converted to digital why would someone not just convert all the cameras at the head end to "convert" to megapixel.

Its because the mechanism used to capture the image is yes analog however the processing of the image at that point is digital and not just converted.

 

Isaac

Systems Engineer II

[survtech 0]

Latency is not that bad.

Latency is a problem on PTZ cameras. Try following a moving vehicle or a running person at 200-300 feet with 300ms or more of latency.

[Rebco 0]

I am still on the fence on this subject, As i see it there are great things coming from the IP megapixel market but like there analog brothers there is no standard for anything. One company can make 20 different models with 20 different software versions. With the economy the way it is alot of companies are looking to cut there spending and 1 in 20 will really have the budget to do an all IP solution, and thats reality. Most medium sized businesses I am giving them more of a hybrid system then anything else. And lets not get started on the small business that are just looking to cut spending period.

 

The biggest problem I've found with most companies are the IT department, IT personel are very protective of there network and I can't blame them. When we start telling them we need to test there network and this and that before we could give you an answer on whether we can put an IP system on and existing infrastructure they don't seem to like any outside person telling them what to do on the Network. I think everything has a place and the way things are the economy dictates my solutions...

[Soundy 1]

I am still on the fence on this subject, As i see it there are great things coming from the IP megapixel market but like there analog brothers there is no standard for anything. One company can make 20 different models with 20 different software versions.

 

That's a bit misleading, really. There are plenty of standard in use - 10/100 ethernet, video codecs, video streams - it's mostly just the individual interfaces and communication "languages" that differ. Those would be very easy for the manufacturers to standardize, if they wanted to.

 

With the economy the way it is alot of companies are looking to cut there spending and 1 in 20 will really have the budget to do an all IP solution, and thats reality.

 

I'm sure a lot of companies have that perception, but the reality is, the TOTAL cost isn't that much more. IP cameras have dropped to the point they're only about twice the cost of a *comparable* analog camera, while one IP camera can easily provide the same coverage as two or even three *comparable* analog cameras for many uses. Right there, the cameras alone are the same price or LESS than using analog... it only SEEMS like it would be more expensive if you're doing a direct 1:1 swap-in of analog for IP.

 

Factor in that an NVR is (or should be) typically less expensive than a *comparable* DVR or hybrid system, because it doesn't require additional capture hardware. Some cameras even include basic recording software.

 

Most medium sized businesses I am giving them more of a hybrid system then anything else. And lets not get started on the small business that are just looking to cut spending period.

 

There's just no hope for some, analog or IP. The ones that are concerned more with cost will go with a $500 all-inclusive camera/DVR package from Costco, because they're more concerned with simply having cameras, than having usable video. There's no point trying to sell anything to them, be it IP, or simply high-quality analog.

 

The biggest problem I've found with most companies are the IT department, IT personel are very protective of there network and I can't blame them. When we start telling them we need to test there network and this and that before we could give you an answer on whether we can put an IP system on and existing infrastructure they don't seem to like any outside person telling them what to do on the Network.

 

They REALLY don't like it when you prove you know more than they do

 

I think everything has a place and the way things are the economy dictates my solutions...

 

Sure it does, but it's also in how you sell it. As noted above, an all-IP-based system can be more cost-effective in a lot of cases, if done properly. "Look, I can give you this system with a $1500 DVR and 8 cameras... or this system with a $600 NVR that only requires 4 cameras." And in my experience, megapixel cameras sell themselves with a lot of customers - you just have to show them a few still shots. Everyone I've ever shown them to is blown away and wants to know when I can upgrade ALL their cameras... sites where I install even one, they almost immediately want the rest done as well. Unfortunately, most of them don't actually make the purchasing decisions, but still, nobody seems to complain about the massive jump in image quality.

[survtech 0]

There are plenty of standard in use - 10/100 ethernet, video codecs, video streams - it's mostly just the individual interfaces and communication "languages" that differ. Those would be very easy for the manufacturers to standardize, if they wanted to.

But the big question is: do they really want to? Although the ONVIF (Open Network Video Interface Forum), which includes Axis, Sony and Bosch, is working on some standards, in reality they are fighting an uphill battle against the many smaller manufacturers; especially the Chinese, who want their own set of standards. I wouldn't hold my breath for real standards any time soon.

 

 

I'm sure a lot of companies have that perception, but the reality is, the TOTAL cost isn't that much more. IP cameras have dropped to the point they're only about twice the cost of a *comparable* analog camera, while one IP camera can easily provide the same coverage as two or even three *comparable* analog cameras for many uses. Right there, the cameras alone are the same price or LESS than using analog... it only SEEMS like it would be more expensive if you're doing a direct 1:1 swap-in of analog for IP.

The assumption that IP cameras can fill in for two or three analog cameras is quite a stretch. That is only in some specific cases and only when you are using megapixel cameras. 640x480 IP cameras have no better resolution than their analog equivalents and would require a 1:1 swap. Even with megapixel cameras, their supposed increased efficiency depends entirely on what they are watching. I can think of a number of applications where megapixel IP cameras would not give any better coverage than analog.

 

Then we have network infrastructure problems. I'll grant that there are instances, especially with small-to-medium size systems, where you can place IP cameras on existing networks and save quite a bit on cabling. But what do you propose to do in a casino with an existing analog system? When you have over 1000 cameras, you can forget about riding along on the existing network. The video data streams would swamp the system.

 

Then you have the problem of network security. You can't just allow anyone to tap in to sensitive video streams. You can't trust the IT personnel to manage the system. And you don't have enough space for the switches, patch panels and other infrastructure necessary to distribute the video data.

 

To top that off, very few IP cameras are small enough to mount in many existing domes, requiring another huge investment.

 

The point is that the costs to convert from a 1000+ camera analog system would be far greater than you claim. In our case, many millions.

[Soundy 1]

There are plenty of standard in use - 10/100 ethernet, video codecs, video streams - it's mostly just the individual interfaces and communication "languages" that differ. Those would be very easy for the manufacturers to standardize, if they wanted to.

But the big question is: do they really want to? Although the ONVIF (Open Network Video Interface Forum), which includes Axis, Sony and Bosch, is working on some standards, in reality they are fighting an uphill battle against the many smaller manufacturers; especially the Chinese, who want their own set of standards. I wouldn't hold my breath for real standards any time soon.

 

Alas, that's an issue with just about anything... and the only thing that will make them change their minds is consumer pressure. If an analog camera manufacturer decided they didn't want their cameras to output using NTSC or PAL, they'd have a very limited market indeed. Likewise an IP camera maker who decided to use something other than 10/100base-T for their connectivity - say, 10base-2, token-ring, or even something proprietary for their IP transport - would find little interest in their products.

 

Consumer demand for a standard is the only thing that will interest them... if Axis/Sony/Bosch can get something going, it will probably make all three much more attractive to the market, and others will have to fall in line to compete. Of course, they also ALL need to realize that the lack of cross-compatibility is one of the last things holding their market back.

 

I'm sure a lot of companies have that perception, but the reality is, the TOTAL cost isn't that much more. IP cameras have dropped to the point they're only about twice the cost of a *comparable* analog camera, while one IP camera can easily provide the same coverage as two or even three *comparable* analog cameras for many uses. Right there, the cameras alone are the same price or LESS than using analog... it only SEEMS like it would be more expensive if you're doing a direct 1:1 swap-in of analog for IP.

The assumption that IP cameras can fill in for two or three analog cameras is quite a stretch. That is only in some specific cases and only when you are using megapixel cameras. 640x480 IP cameras have no better resolution than their analog equivalents and would require a 1:1 swap.

 

Yes, poor wording on my part, using "IP" and "megapixel" interchangeably.

 

Even with megapixel cameras, their supposed increased efficiency depends entirely on what they are watching. I can think of a number of applications where megapixel IP cameras would not give any better coverage than analog.

 

That's why I said, "in MANY cases". I work mainly with retail - fuel services (pump and c-store cameras), restaurants, pubs, liquor stores. There are very VERY few instances I've found where megapixel cameras don't provide at least a 2:1 benefit over analog. It used to be a harder sell when the cameras were $1500 vs. about $250 for a good-quality analog camera, but now that those same 1.3MP cams can be had for $500-$600 (our cost), it's getting a lot more cost-effective, especially since the price of the same analog cameras has changed little if any. Megapixel/IP technology is only going to get better and cheaper, very quickly.

[cctvexpert 0]

rather then getting into a long winded discussion wait a few months and see. Analog is analog all cameras start out as analog. You say you can't transmit analog over twisted pair then what can I say - it is being done. It doesn't need a protocol - it is analog. The only thing right now waiting is the encoder at the DVR end to be able to compress the HD signal and there are a number of DSP's already on the roadmap.

 

Rather than talk to me ask Micron and TI about the chips, Hitachi and Sony Broadcast about the transmission maybe you will believe them.

[Soundy 1]

So after all your longwinded technical bafflegab, you can't even answer some basic technical questions about the technology being used?

 

Of course you need a "protocol". Even analog video has to conform to signal and transmission standards of some sort - you can't just take the electric impulses coming off the sensor and send them over long distances to a waiting DVR. NTSC and PAL are the two most common examples of analog video "protocols", but they're limited to available resolution. This is the stumbling block: existing common analog-HD standards are still resolution-limited... so what is the new standard being used?

 

BTW, you claim that megapixel IP cameras "can't" be used in casinos... maybe you should tell IQ about that, as they don't seem to be aware of what their cameras "can't" do...

[survtech 0]

BTW, you claim that megapixel IP cameras "can't" be used in casinos... maybe you should tell IQ about that, as they don't seem to be aware of what their cameras "can't" do...

I tend to agree with cctvexpert on this. The reliability of IP cameras has yet to be proven. In our experiments with them, we have seen many problems with cameras dropping off the network randomly. While they do reappear, that alone makes them unsuitable for our purposes.

 

The other aspect is redundancy. Analog camera distribution systems don't require it. After all, what can go wrong with a piece of coax or analog twisted-pair? Computer networks are far less reliable and one major issue we would have to address when incorporating IP would be how to assure the reliability of the camera signals.

 

The frame rate limitations of every megapixel camera we have seen makes them unusable for what we want to use them for: table games where the suit of the cards can determine the outcome of the game, the faces of wide area slot machines, cash handling and counting areas, etc.

 

The thing is that our NVR system is limited as to which brands of IP cameras we can use. All the ones we tried were unable to give us more than 15fps. Our MICS (minimum internal control standards) requires 30fps.

 

Other limitations include latency of IP PTZ systems, low light problems with many existing IP cameras and, the biggest factor, the cost to add the infrastructure for IP.

[Soundy 1]

BTW, you claim that megapixel IP cameras "can't" be used in casinos... maybe you should tell IQ about that, as they don't seem to be aware of what their cameras "can't" do...

Where did he say that?

 

Last but not least there is a reason that no gaming commission in the united states allows IP camera for casinos.

 

http://www.cctvforum.com/viewtopic.php?t=14855&start=43

 

If anyone did, it would be me and I never claimed megapixel cameras couldn't be used in casinos, I just said that the frame rate limitations of every megapixel camera we have seen makes them unusable for what we want to use them for: table games where the suit of the cards can determine the outcome of the game, the faces of wide area slot machines, cash handling and counting areas, etc.

 

That's all fine and well... saying that the ones YOU'VE seen are not suitable for YOUR NEEDS is perfectly valid, but there's a big difference between saying that, and someone making blanket statements that something isn't suitable for ANYONE in a similar situation, especially when it's clear others ARE using them for those purposes.

 

The thing is that our NVR system is limited as to which brands of IP cameras we can use. All the ones we tried were unable to give us more than 15fps. Our MICS (minimum internal control standards) requires 30fps.

 

Well, I can suggest looking at the IQ "Pro" series cameras, if your NVR supports them... the Sentinel and 700/750 series cameras state they'll do 30fps @ 1.3MP.

 

I don't work for IQ, BTW, but I use their cameras regularly and have been pretty happy with their performance.

 

Other limitations include latency of IP PTZ systems, low light problems with many existing IP cameras and, the biggest factor, the cost to add the infrastructure for IP.

 

In addition, the reliability of IP megapixel cameras has yet to be proven. In our experiments with them, we have seen many problems with cameras dropping off the network randomly. While they do reappear, that alone makes them unsuitable for our purposes.

 

And like I say, that's perfectly valid. But you're not the one making the blanket statements and wild claims without being able to back them up.

 

And FWIW, the only times I've seen our IQ cameras drop off, I've eventually traced it back to network issues, either a cheap switch or router choking from the traffic, or sketchy wiring. Sketchy wiring will cause problems with ANY camera system.

[survtech 0]

Please re-read my reply since I edited it. As far as the network is concerned, for our experiments we are hooking the IP cameras directly up to our Cisco 4507R core switch - a $60,000 piece of equipment that far exceeds the capabilities of your normal network switch.

[Soundy 1]

My answer doesn't change: if YOU have found the technology isn't sufficient for YOUR needs, that's all fine and good.... but you're not trying to tell everyone else that it won't be sufficient for THEIR needs either.