normicgander 0 Posted April 12, 2008 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. It's not hard at all with the right test equipment. It's standard in the broadcast world. Even VCRs in CCTV had rating of 240 color and 300TVL (not scan lines) B&W. Of course lossy compression is necessary, that's not my point. Share this post Link to post Share on other sites
jharrell 0 Posted April 12, 2008 It's not hard at all with the right test equipment. It's standard in the broadcast world. Even VCRs in CCTV had rating of 240 color and 300TVL (not scan lines) B&W. Of course lossy compression is necessary, that's not my point. 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. Share this post Link to post Share on other sites
normicgander 0 Posted April 12, 2008 http://www.indigovision.com/whitepapers_resolutionandtvl.php This is interesting... Share this post Link to post Share on other sites
normicgander 0 Posted April 12, 2008 I've heard very good things about this company Indigo Vision. From their white paper, this is what I've been whining about: Today in the digital world we have become accustomed to using terms such as 4SIF and mega-pixels to specify resolution as the number of pixels samples used per image. Unfortunately this is both helpful and misleading. The number of pixel samples used only governs the theoretical upper limit of usable resolution. The actual usable resolution of a system cannot be directly inferred from the number of pixels. Usable resolution is important to CCTV operators as it determines the level of fine detail that they will be able to see. A higher usable resolution will enable an operator to: Read a car number plate from a greater distance. Identify a face more clearly. Examine a portion of video in more detail. Share this post Link to post Share on other sites
jharrell 0 Posted April 12, 2008 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. Share this post Link to post Share on other sites
normicgander 0 Posted April 12, 2008 Of cousre there is dynamic and static scenes for which the total surveillance/transmission chain or system must handle. Even before A/D process performed in DVRs/IP encoders, one could argue that the odd/even field based NTSC compatible or EIA-170A video compostie signal is flawed for video surveillance applications. Perhaps cost and simplicity were factors. The developers of the NTSC systems never intended or anticipated that someone would want to "Freeze" a frame of video with two temporally different fields, 1/60th of second apart (just hope the subject stands still). Their reason for using odd/even fields was reduce the bandwith of the NTSC RF spectrum (analog compression ). So, with respect to "D1" and most DVRs, this can be a problem with recordings involving targets of interest moving within the capture video. I only mention this because there are issues even before the D/A process. This is why the use of progressive scan imagers for higher quality images are the future IMO (hopefully there will be options to UDP/TCP network transmission). As for testing methods to obtain an objective figure of quality, the method used in broadcast, such as testing cameras also uses static test charts and signals. I'm sure they too are aware that TV content involves movings objects and scene lighting etc. But, you have to start somewhere. I agree MPEG transmission is an issue, but the applied compression will effect the ability to discern detail even in static scenes also. Once the bits are gone due to compression, so goes the image detail. There is the need for an objective measurement stanard for digital systems, to include dynamic and static conditions. That's the reality in the field. Perhaps IEEE will address this issue for the CCTV industry. Good discussion.. Share this post Link to post Share on other sites
jharrell 0 Posted April 13, 2008 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 Share this post Link to post Share on other sites