jharrell

The only other bullet I have seen with Wifi is the Y-Cam bullet: http://www.y-cam.com/y-cam-bullet-hd/. Nobody mentions Y-cam much on here, I have a few of their indoor cameras and they are great, and one of the few where audio works on iPhones, they all have built in mics too, which might not be good for outside surveillance because of the wiretap laws. Big downside with Y-cams is they are fixed focal length, but their picture is pretty decent. BTW anxiously awaiting that Acti TCM-7811 review, I think that might be the one for outdoor surveillance at my home.

Haven't done much direct SIP calling without a PBX, but shouldn't be very difficult, the Grandstream phone I have setup before didn't need much besides a valid IP to receive a call directly on the same LAN. I would recommend setting up a PBX though. 3CX has a free one for windows that should be enough to setup a test system, I think it will provision the Grandstream for you. http://www.3cx.com I would like to know how those two work together, its tempting to spend the money on a Mobotix because of using them with a video phone like that.

Hollywood has all the best stuff:

ZodTTD got his Streamer app approved for the app store today. It is based on VLC and supports RTSP streams so you can finally watch a mpeg4 IP cam with audio on an iPhone! I can confirm it is working with a Y-cam including audio from the mic. It is free but has ads, says he is going to add landscape support soon. Here it is:http://www.zodttd.com/blog.php?b=27

The key to displaying analog video properly on a digital display is proper deinterlacing and scaling. This issue became obvious to folks over in the AVSForum years ago when everyone was originally trying to use a PC for home theater use on large DLP projectors and then plasmas and now LCD's. If you had money you bought Farjouda video scalers, but the PC guys knew a modern PC, even back then could do it, so they developed a program called DScaler. It's still around today, and you should try it with an analog cam on a PC just to see how far you can take picture quality on a LCD display. It will require a very specific chipset video capture card, a bt8x8 series, which should be extremely cheap. DScaler will probably out perform any analog-digital video scaler you can find, at least it used to. Now of course this doesn't help very much, as it probably wouldn't be practical to use DScaler for large scale monitoring, but it gives perspective on the problem, simply put the video scalers and deinterlacers built in to most LCD's and HDTV's is horrible, but there is no drive it improve it since it's mostly unnecessary with an HDTV feed. I still say an IP cam manufacturer needs to add a low to no compression low latency mode, where you may only be able to stuff one megapixel cam on a single gigabit link, but would get under down around 10ms latency.

Keep in mind it's not IP that contributes significantly to latency, most of it comes from the compression/decompression process. SDI sends uncompressed video consuming 270 MBps for NTSC and 1.5 GBps for 1080i HD! HDMI used on HDTV's is similar running at over 3Gbps uncompressed video for 1080p. There is technically no reason an IP camera couldn't be made that uses no compression or perhaps a very low overhead compression such as Huffyuv to improve latency at the expense of bandwidth. I would imagine some cameras woulds improve significantly just by dropping back to JPEG instead of MPEG4/H.264. Of course the issue is you would quickly saturate a gigabit ethernet network backbone with even one uncompressed HD cam, but the situtation is similar an analog setup, you don't use a single backbone for multiple cams, instead you would need basically a point to point connection between your cam and your monitoring station, with perhaps only a switch in between. I am surprised this isn't more of a focus for ip cam manufacturers, they all seemed to be wrapped up in H.264 for low bandwidth and disk space but don't seem to let you trade that out for low latency when the situation calls for it. As an aside if you have any packet loss at all on a LAN that is an unacceptable situation and should be resolved, if cameras are dropping packets they are broken in some way.

I have been waiting to hear what ACTi's h.264 offering will be, do you have any more info on them? Also one feature that I cannot seem to confirm is whether ACTi ip cams have a static jpg url to access a current still image, Axis does this. I know it will do mjpeg over raw tcp but I really want a ip cam that does a static jpg over http as a fallback for access from just about any browser(mac,iphone etc).

With this kind of attitude no wonder we are stuck with the horror known as ActiveX.

Thanks for reviewing these cameras, I was wondering if the 540X was worth the extra $ and it seems so to me. Justin

Do you mean the Hikvision SDK is expensive? Because I downloaded it for free from here: http://www.hikvision.com/en_Service_list2.aspx?classid=81 Justin

MJPEG and MPEG are video compression formats, they specify how video is to be encoded into binary form they do not however specify how those bytes go over IP in any way. Which port? What application layer protocol http,rtp,raw udp? See the issue, NTSC pretty much guarantees a working connection over a cable to a recording/viewing device, IP cams have no end to end standard every manufacturer is different but seems to be moving toward H.264 over IP using RTP(maybe). Look at HDTV at least they standardized on ATSC which is MPEG2 encoded over radio using 8PSK modulation, and a cable standard(cablecard) which is mpeg2 over coax using QAM modulation. So I agree with CollinR CCTV needs a full layer 5 standard and it should include compression formats and PTZ as well, look at the PTZ inconsistenices with analog now since NTSC has no concept of PTZ control built in. Justin

Ah well too bad, though they might be sealed PC's but still have standard ports on them for monitor etc. Well most likely if you crack one open there will be a VGA or DVI connection in there between the montior and the motherboard but I would imagine your client wouldn't want to get into that Seems pretty hackish to point a camera at a monitor, kinda like having a printer feed into a scanner but you gotta do what you gotta do, good luck. Justin

Yeah they are pretty useful devices, many are usb based now for mouse but also support making your local cd drive or thumb drive show as drive on the remote box through the usb. Also you can put one in front of a normal KVM as we do at the office, as we already had a 8 port standard KVM, so just got a single port IP KVM and use the special keystokes to tell the 8 port to switch inputs. On a side note if your buying Dell servers now for say a NVR or something for about $250(I think) they offer a DRAC(Dell remote access card) which is basically a IP KVM built in to the server, lets you do CD drive emulation (I even installed Windows server remotely through it) and power up/down the box all through IE activex, worth it IMO and no need for a external IP KVM or to install VNC or the likes. BTW most IP KVM's are just embedded linux boxes and use VNC as the protocol including the DRAC so you can just use your preferred VNC client if you don like thier client. Justin

I know you said no networking the machines but have you looked into using a IP KVM instead? You can get them relatively cheap now and they will allow remote control of the pc without touching the pc hardware just looks like monitor,keyboard and mouse to it and usually still has local outputs for the real stuff on the desk. Another approach would be a VGA to composite converter and capture the montior output just like a camera, but an IP Kvm will give much better results as it can handle megapixel VGA resolution instead of downsampling to NTSC. Justin

Yes very good discussion, I wholeheartedly agree full NTSC D1 is lacking in many ways for CCTV purposes but much better than CIF at 6fps . The lengths you have to go through to deinterlace properly are extensive when you could have simply taken the progressive digital signal right from the CCD imager and sent it to compression without a D/A->cable->A/D situation you have now. Hence IP cameras superiority in many ways. Have any of you guys ever looked into DScaler? I know you mentioned VidCap with BT cards, DScaler was started by some guys on the AVScience forum years ago that talked to the BT8x8 cards directly with some very CPU intensive but high quality deinterlacing algorithms. They found that even the cheap BT8x8 chip could deliver full raw 720x576 in 4:2:2 sampling higher than necessary to resolve all TVL and that it was software mostly holding it back. Many used DScaler with thier DVD players through SVideo as a cheap PC outperformed very expensive video processors up until DVD software surpassed it since it had digital access to the mpeg2 bits on the disk avoiding the A/D altogether. I would imagine Megapixel cameras will force some form of digital transmission since it would be impractical to use say component video from the camera to a DVR, but IP will require compression at least for the time being since a raw digital transmission in megapixel range would require DVI/HDMI like bandwidth which starts at 1.2Gbps per channel! I would think now that the dust has settled in Blu-Ray vs HDDVD and it seems H.264 is going to be THE compression format for video disks and most internet streaming formats and even now supplanting mpeg2 in the broadcast industry(Direct TV) that CCTV will settle into H.264 IP cams as the cost of H.264 encoder chips is dropping quickly and there many advantages when all your video archives are in the same compression format, instead of the mjpeg/mpeg4 mixed situation you have now. Currently for me though the best bang for the buck still seems to be analog NTSC cameras with a DVR since the IP cams really haven't seemed to settle on a solid standard and if full D1 30fps recording your basically at the wall of whats possible with NTSC. Although I would like nothing better than a nice set of indoor/outdoor H.264 megapixel cams with POE and a DVR to go with them for a reasonable price . Justin

It's a very flawed test if they are trying to measure the ability to transmit motion video as a static B/W test pattern such as they where using could be HIGHLY compressed yet still resolve perfectly using mpeg4. They could have run it at 1Mbps instead of 4 Mbps and got the same results. It is an elementary mistake to measure compression quality using static test images with highly compressable repeating patterns unless you are simply trying to examine the analog to digital conversion components in your system (which it looks like all they where doing) as the compression algorithms won't even break a sweat on that material and with VBR the bitrate might actually drop almost to 0 since nothing is changing over time. I would imagine all current DVR's contain A/D chips that can resolve 540TVL from the analog NTSC input probably in 4:4:4. So they are all starting out with 720x480 in 24bit color on the digital side of things, then it handed off to the compression engine which may or may not be able to handle D1. You can research more if you like but this bottom line there is no simple objective mathematical way to measure how good a lossy compression system is since by nature it is based on human perception. There are some trying though, Google lossy compression and Mean Opinion Score or MOS.

What would you measure with the equipment? If you run D1 video through a codec like h.264 at any quality/bitrate you will get D1 video on the other side, it will have 720x480 pixels in 24bit color however as with any lossy format those pixels will have different values then the original, how noticable those difference are is subjective to the viewer, it would be difficult to measure other than opinion polling, which is in fact a big part of how they develop and tune lossy codecs.

Bottom line all the compression formats we are talking about are lossy, the colorspace compression is only the first step then on to quantization throwing away high frequency differences and in mpeg encoding only the differences between frames over time. They all throw away information from the original raw RGB 720x480 frames coming from the ADC's in the DVR none of them really internally hold on to the original pixels instead they recreate an approximation of the original frame through a series of mathematical steps while trying to achieve as little "perceptual" loss as possible which is simply a way of saying so we humans don't notice what was thrown away based on the way our eye works and our brains. So how could you even standardize on TVL that would basically mean sticking only to a mathematically lossless compression format(like zip files) of which you might get 4:1 from the raw video at best and that would fill up any hard drive fast at what would that be about 62Mbs per channel. I am surpsied some DVR's don't offer this or perhaps a raw record option for those who want the uber quality of no loss/raw video while sacrificing the space, although the raw number of bits would probably overwhelm your average DVR's disk bandwidth with 4 channels let alone 8 or 16. It is funny in a way it's starting to sound like the audiophile guys who complain about mp3 compression vs raw PCM comming from CD's or worse yet vinyl, please don't start saying that h.264 lacks the warmth or depth of analog VHS CCTV . Justin

This is surprising to me as at a technical level I know h.264 to be superior to mpeg4 and mjpeg, where these h.264 DVR's set to the same bitrate as the the others, as it sounds like they where tuned to a much lower bitrate to conserve space or network bandwidth? The only other cause would be these h.264 DVR where simply of lower quality perhaps cutting corners on the analog to digital conversion side of things causing a poorer quality result on the output, as all thing being equal mpeg4 part 10 (h.264) is simply a better way to compress video than mjpeg or mpeg4(part 2) but a DVR is much more than just the codec. Justin

If you check q-see's website you can see they are also offering the same Hikvision DVR as the QSF2648008 model that records in 4CIF. What would you consider superior to h.264? Remember this is the same codec used to compress video on Blu-Ray and probably the most advanced temporal video compression method available today, surpassing mjpeg and mpeg2 in almost every way. Now granted D1 compressed in h.264 at 1Mbps will not look as good as MPEG2 at 8Mbps, but compare apples to apples, that is bitrate to bitrate and h.264 will win every single time and give a equivalent picture in less bits. Justin

So for outdoor use for a residence would the P540X be worth the extra over the 400HPT ? Some comparison images would be neat to see between the two. Justin

The unit seems to be made by Hikvision and sold under Intellicam and Q-See. It seems to me that the D1 model does infact do 30fps at D1 per channel where as the lower model does 12fps at D1. Also it supports a secondary lower bitrate stream for live network streaming. So that you can record Full D1 30fps yet stream in say CIF at 6fps if you access it through a slow inet connection. Looks like you can choose which stream from the client so a lan computer can still connnect to the full D1 stream, nice. I am quite interested in this DVR as price and features seem good although I don't do this for a living. Another nice thing is they provide both a windows and linux SDK for the unit so that if you know how to code in C you could write your own client for whatever purpose. I haven't found this very easy to come by on any other DVR only the ip cams. I am contemplating developing an iPhone interface to this unit as no one seems to be supporting that device yet it is an ideal WiFi based video viewer. Justin