<?xml version="1.0" encoding="utf-8"?>
<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Disqus - Latest Comments for GHurenkamp</title><link>http://disqus.com/by/GHurenkamp/</link><description></description><atom:link href="http://disqus.com/GHurenkamp/comments.rss" rel="self"></atom:link><language>en</language><lastBuildDate>Fri, 19 Jun 2009 13:07:02 -0000</lastBuildDate><item><title>Re: HDcctv Alliance Competitive Analysis</title><link>http://ipvm.com/review/show/371#comment-11455543</link><description>&lt;p&gt;Why apologize for the “science lesson”?  The physics pan out and it was a well crafted explanation of some of the background of the technology.  The only comment I have is that the assumption of -25dB  loss characteristic for RG-59 is a bit optimistic for existing CCTV installations.  The typical RG-59 cable used in this industry is different than the one used for CATV applications and has 10-20db higher loss characteristics.  I would be very interested to learn what distances you believe can be achieved on copper / copper video cable.  &lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gerrit Hurenkamp</dc:creator><pubDate>Fri, 19 Jun 2009 13:07:02 -0000</pubDate></item><item><title>Re: HDcctv Alliance Competitive Analysis</title><link>http://ipvm.com/review/show/371#comment-11455113</link><description>&lt;p&gt;You post an article in which you eloquently and succinctly introduce a new concept in video security: HDcctv.  You are not the first to do so but you provide an unusually complete picture compared to some of the republishing of marketing information that has been going on elsewhere.  In this article you include a section with the heading “Technical Details”.  These are your words, not mine.  That heading does suggest a certain precision, as this is where you are supposed to present the actual technical data on the product.  In this section, you write the following: “HDcctv is targeting up to 170 meters over RG-59 for 720p resolution video. Contras this to analog video, where the maximum distance is 300 meters.”  Again, these are your words, not mine.  It’s a quote from the premium section, which I usually try to avoid for the obvious reasons but you leave me little choice.&lt;/p&gt;&lt;p&gt;I did (and do) take exception to that statement.  The numbers simply do not add up.  As a result, I decided to do some research on actual specifications, using your link to Gennum’s 7600 chip set as a starting point (one paragraph before the one I quoted).  The specifications on the receiver section can be found here: &lt;a href="http://www.gennum.com/video/products/gv7605" rel="nofollow noopener" target="_blank" title="http://www.gennum.com/video/products/gv7605"&gt;http://www.gennum.com/video...&lt;/a&gt;.  It lists the following: “Receives HD at 1.485 Gb/s video over 140m of 75Ω coaxial cable (RG6 or equivalent) when used with GV8501 cable equalizer”.  I will give them the benefit of the doubt and will assume that the equalizer is build-in for the HDcctv application.  However, to get close to the 170 meter distance that you chose to contrast with the 300m analog distance, I need to use RG6 cable.  That is not at all common in the CCTV word, as you, Carl and I all pointed out, but it is needed just to get close to the 170m you started with for comparison to analog.  If you wanted to contrast with 300m analog on RG-59, you should have used the 100m number.  Labeling my calling this out as “misleading”, is a little ironic.&lt;/p&gt;&lt;p&gt;However, it is my belief that you missed the real point of my post.  Carl got it right away as can be seen from his reference to “RG-59 copper/copper video cable”.  What he is referring to is the fact that the video security industry uses a very specific RG-59 cable, one that uses an all-copper center conductor with all copper braided shield with 95% braid coverage.  For decades, every professional installer has been using this type of cable, explaining (and sometimes demonstrating) to customers and less professional colleagues why TV coax would not work.  The installed base therefore consists of a very specific subset of RG-59 cables, a subset that has 700MHz loss characteristic of 35-45dB, rather than the 25dB mentioned in Gareth Heywood’s post.&lt;/p&gt;&lt;p&gt;Gareth’s numbers absolutely do add up and I am confident that the distances he lists can be achieved with RG-59 cable optimized for CATV but that is not the cable installed in most CCTV installations and the discussion originated with the ability to use existing cabling as a driver for acceptance of the technology.  Make no mistake about it, the video quality that I have seen demonstrated with HDcctv is very impressive (vibrant colors, no compression artifacts and very low latency) and will drive IP camera manufacturers to improve the image quality of their products.  However, this was a discussion about leveraging existing coaxial cable.  &lt;br&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gerrit Hurenkamp</dc:creator><pubDate>Fri, 19 Jun 2009 12:57:37 -0000</pubDate></item><item><title>Re: HDcctv Alliance Competitive Analysis</title><link>http://ipvm.com/review/show/371#comment-11109061</link><description>&lt;p&gt;The concept of HDcctv is an interesting one but the discussion on the probability of success seems to lack foundation.  The reuse of CCTV cable is presented as a major plus of this concept but it is?  The Gennum receiver chip, at the heart of this concept, is rated to receive 720p video at 1.485 Gb/s "over 140m of 75Ω coaxial cable (RG6 or equivalent)".  That begs two questions.&lt;/p&gt;&lt;p&gt;What percentage of existing CCTV installations uses RG6 as the minimum cable specification?&lt;/p&gt;&lt;p&gt;What type of RG6 is this?  The one used in CCTV installations, optimized for video transmission at 8-10MHz bandwidth and typically rated at 9-14 dB loss per 100ft at 1,000 MHz or the RG6 that is intended for UHF frequencies and typically rated at 5-6 dB loss per 100ft.  Every 3dB more halves the maximum cable length.&lt;/p&gt;&lt;p&gt;Carl mentioned some concerns regarding the 720p initial capability.  They seem justified.   &lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gerrit Hurenkamp</dc:creator><pubDate>Thu, 18 Jun 2009 14:20:18 -0000</pubDate></item><item><title>Re: Do Megapixel Cameras Provide Better Image Quality?</title><link>http://ipvm.com/review/show/353#comment-9609727</link><description>&lt;p&gt;Your comments make perfect sense.  In various articles, you have pointed out a number of interesting “issues” with HD that the typical customer may not think about but that are important to realize.  I refer to discussions on lacking optical resolution in so-called HD lenses and the use of frame integration to obtain better sensitivity numbers.  You have now mentioned another aspect.&lt;/p&gt;&lt;p&gt;With analog cameras, users would be less interested in the imager size in pixels than in the actual capability of the image to resolve detail, which was typically expressed using a TVL number.  The two – horizontal number of pixels and TVL – were related through the Kell factor but that only established a best case relationship.  The quality of the electronic amplifiers used in the camera – or the lack thereof – could reduce the actual ability to resolve detail to a lower number than the Kell factor would indicate.  As a result, discerning customers were looking for TVL numbers – preferably independently verified –to get an idea of what level of image quality could be expected.&lt;/p&gt;&lt;p&gt;This concept has been completely abandoned in the IP camera arena.  Very few IP camera suppliers are publishing TVL numbers and for a very good reason.  Compared to analog cameras, these numbers do not look good.  Not only can electronic amplifiers negatively affect the ability to resolve detail but now A-to-D converters and compression are also playing a part to reduce the achievable TVL number.&lt;/p&gt;&lt;p&gt;There are typically two aspects:&lt;/p&gt;&lt;p&gt;The better the quality of the electronic amplifiers, A-to-D converters and compression chips in an IP camera, the closer the TVL number is to the achievable TVL number. Using the TVL number gives a better idea of the camera’s capability to resolve details than just the raw pixel size of the imager. To truly compare camera performance, we need to use a resolution chart.&lt;/p&gt;&lt;p&gt;Because of the smaller physical size of a pixel in an HD camera compared to an SD camera, less light can reach the pixel thus reducing the signal level at the pixel.  However, the noise level is relatively constant and the SNR for low light images would thus be reduced considerably.  This would result in an undesirable high bandwidth (noise does not compress well).  A method to reduce noise is to group pixels together and to treat these groups as “super pixels”.  This process is known as binning.  As a result, signal levels go up, noise levels are still constant and the picture has a better SNR.  Of course, the imager now has less “super pixels” than it had pixels and the effective resolution has gone down.  To still meet the required “output resolution”, the onboard DSP “up converts” the image “resolution” back to the required setting.  This additional “resolution” – of course – does not add any useful data but does take up additional bandwidth and storage space.&lt;/p&gt;&lt;p&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gerrit Hurenkamp</dc:creator><pubDate>Wed, 20 May 2009 22:12:30 -0000</pubDate></item><item><title>Re: Storage Manufacturers Becoming NVR Providers</title><link>http://ipvm.com/review/show/351#comment-9608564</link><description>&lt;p&gt;Carl lists many solutions to reduce file system fragmentation.  They all work and they have almost all been designed to reduce fragmentation of generic data storage.  There typically are three approaches.  XFS and the Mac file system use delayed allocation to slow down fragmentation.  This approach works by combining many small changes into a single update operation.  This reduces the number of write operations and therefore the rate of fragmentation.  Unfortunately, an update in video recording means a complete replacement of data, not just a modification of data.  There is thus little to combine.  The blocks are so large that they mostly completely fill the delayed write buffer, negating its effect.&lt;/p&gt;&lt;p&gt;A second approach is to use idle cycles to aggregate free space so that new data can be written in a single block.  This works really well when there is idle time and when there actually are blocks of free space.  In a continuous video recording system, there is little idle time and free space does not exist as the disk is constantly filled to capacity.&lt;/p&gt;&lt;p&gt;The third approach is to use a journaling file system (Linux) that builds a journal of changes before committing these to the file system.  This is really intended to avoid file system corruption in case of an unexpected shutdown but reduces the fragmentation as well, as fewer writes are needed. Unfortunately, the amount of new data being written is so large with video recording applications that this almost immediately fills up the journal, regardless of mode it is being used in, thus effectively requiring two write operations for each data block and negatively affecting write performance.&lt;/p&gt;&lt;p&gt;The ring buffer solution however is a very effective implementation of the “very large files” concept and works particularly well if the size of the buffer is matched to the block size of the underlying file system.  This is used by several large DVR manufacturers and, as we have seen, by at least one NVR manufacturer.  Pelco also uses a variant of this approach for its Endura Enterprise NVR.&lt;br&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gerrit Hurenkamp</dc:creator><pubDate>Wed, 20 May 2009 21:14:45 -0000</pubDate></item><item><title>Re: Storage Manufacturers Becoming NVR Providers</title><link>http://ipvm.com/review/show/351#comment-9377802</link><description>&lt;p&gt;This is an interesting write-up with a good overview in the premium section of why a combination of storage array and build-in server might make a good choice.  There is an additional benefit as well: having both devices in a single unit has the advantage that the power-up sequence is pre-determined as not all servers do well with not having a storage array available at startup.  The integration of server and storage array thus eliminates the need for power sequencers for powering up and powering down systems.&lt;/p&gt;&lt;p&gt;What remains to be seen is whether or not these devices are simply standard servers in standard storage arrays or optimized video storage solutions.  This matters for a number of reasons.&lt;/p&gt;&lt;p&gt;While generic storage arrays process 95% reads and 5% writes, video storage servers do almost exactly the opposite.  As a result of the much more frequent writes, performance reduction due to disk fragmentation happens much faster and disk defragmentation is required much more frequently.  While generic arrays can do this defragmentation during periods of low transaction volume, the continuous nature of video does not present many defragmentation opportunities.  The net result is often a gradually declining performance that requires manual intervention to restore the system.  While it is possible to optimize storage systems for video data recording, that solution, while common in high-end DVRs, are still relatively rare in NVRs.&lt;/p&gt;&lt;p&gt;A second major difference is that generic storage arrays are optimized for transactional processing with time distributed read and write operations on small data packets.  Video storage systems typically use large sequential blocks.  The requirement for the underlying file system is therefore quite different.  Splitting a large video data block over many small disk segments is hardly efficient and creates a throughput bottleneck.&lt;/p&gt;&lt;p&gt;Both concerns give the DVR manufacturers an edge in this space as they have already solved these issues.  In addition, new compression technology developed for the broadcast market (think H.264 for low cost set-top boxes) will allow DVR manufacturers to introduce new, more cost effective hybrid models that will address the cost concerns.&lt;/p&gt;&lt;p&gt;We have some interesting times ahead and we have not even touched upon video storage as a service.&lt;br&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gerrit Hurenkamp</dc:creator><pubDate>Fri, 15 May 2009 19:50:06 -0000</pubDate></item><item><title>Re: The Danger of Pre-Announcing Products</title><link>http://ipvm.com/review/show/322#comment-7683956</link><description>&lt;p&gt;Some customers visit a show to find the latest products for immediate use, whereas others intend to understand what level of performance will be available a year from now.  It all depends on the timing of the project that is being considered.  Typically, the larger the project, the longer the planning cycle.  When planning far out, it often makes sense to visit a couple of shows during the year, just to make sure that the promised performance is actually on track.  An alpha version at ISC West should have morphed into a much more solid product by ASIS.&lt;/p&gt;&lt;p&gt;Communication is key.  Don't just assume a product is a production version but ask questions.  If the sales person does not have any details, it is not likely a shipping product.  Specification sheets are often released less than a few weeks before release to production.  No specification sheet, no production version.  Is the product a "one off" or does it fit a strategy?  A product that is core to a strategy will get a lot of resources and has a high probability of being delivered on time and with the features originally promised.  In my experience, many customers understand this concept very well.  Specifiers spent a substantial amount of time at every show asking us about what’s “in store”.   The better ones engage in discussions on the likelihood of the development being on time based on feedback from other manufacturers that are dealing with similar technological challenges.&lt;/p&gt;&lt;p&gt;How are specifiers going to justify the completion of a project for a customer using storage with MPEG-4 compression when H.264 compression is shipping at the time the project is completed?  Unless this specifier has advanced information, his customer is not going to be happy and his reputation suffers.  He has a vested interest in pre-announcements and thoroughly understanding them.    Manufacturers should not hide the fact that a product is a concept or an alpha unit and customers should ask what the status of a product is.  At the end of the day, it is a balance act.  Some pre-announcement is needed but “vapor ware” hurts more than it helps.&lt;/p&gt;&lt;p&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gerrit Hurenkamp</dc:creator><pubDate>Tue, 31 Mar 2009 15:29:12 -0000</pubDate></item><item><title>Re: Confusion over Megapixel Lenses</title><link>http://ipvm.com/review/show/289#comment-6630716</link><description>&lt;p&gt;Hi John,&lt;/p&gt;&lt;p&gt;There are a couple of companies that have recognized the focal issues and are doing something about it (including Pelco).  Most others have not yet seen this as an installation problem.  That will probably change when megapixel imagers are being released in fixed dome configurations by more manufacturers.&lt;/p&gt;&lt;p&gt;With the imagers that we use in our Sarix line, we needed 100 lp/mm to ensure that the lens and the 3MP imager are balanced in terms of optical resolution, i.e. the lens is not restricting the imager performance but is also not unnecessarily expensive.  We have done some serious testing in our optical lab to ensure that the two are matched.&lt;/p&gt;&lt;p&gt;In Pelco's case, you would have been correct on the overkill classification for 1.3MP imagers.  However, while the 100 lp/mm is more than needed in this case, the lens would only be slightly less expensive if it were optimized for the 1.3MP imager.  That small advantage is then completely lost once you factor in twice the NRE costs and the costs of carrying two (or more) lines.  Currently, the volumes for these cameras and lenses are too low to justify two megapixel lens lines.  I would be surprised if other manufacturers would not come to the same conclusion.&lt;/p&gt;&lt;p&gt;This picture changes radically when going to 5MP or higher resolution lenses because lens costs are not linear with optical resolution.  The jump from 3MP to 5MP is much higher than the jump from 1.3MP to 3MP.  Currently, this is not an issue for us as our current megapixel cameras only go up to 3MP.&lt;/p&gt;&lt;p&gt;For this range concept to work, most manufacturers would have to select a megapixel lens with 100 lp/mm or better.  A 60 or 80 lp/mm lens will likely not work over the entire 1.3MP - 3MP range as our industry uses relatively small imagers.  I have no doubt that there will be companies that do select that 60 lp/mm model and then use it across the entire 1.3MP - 3MP range for cost reasons and I see absolutely no problem with you keeping an eye on that practice.&lt;/p&gt;&lt;p&gt;By the way, interesting to read your write-up on mega-pixel cameras.  You list Arecont as the only supplier of H.264 megapixel cameras.  Have you looked at our Sarix camera line?  Megapixel and H.264.  Even if you would not want to use our Endura system, a Sarix camera would work nicely with Milestone software in H.264 mode.  It's not my product but Sara Scroggins, our product marketing manager for this camera, would be happy to get you some information for the next version of the report...  :-)&lt;/p&gt;&lt;p&gt;Best regards,&lt;/p&gt;&lt;p&gt;Gerrit&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gerrit Hurenkamp</dc:creator><pubDate>Wed, 25 Feb 2009 22:12:14 -0000</pubDate></item><item><title>Re: Confusion over Megapixel Lenses</title><link>http://ipvm.com/review/show/289#comment-6586093</link><description>&lt;p&gt;John,&lt;/p&gt;&lt;p&gt;A clearly written article, as usual.  It is good to see that this important aspect is getting some unbiased attention.  Working for a manufacturer (Pelco), I do not entirely share your opinion that manufacturers intentionally hide the technical details.  We do list lp/mm numbers for those interested but, as you have already explained in your article, finding the right lens is not trivial and there are many customers that prefer to simply select a "megapixel lens" and rely on the manufacturer to ensure that the lens does not become the limiting factor for image quality.  We need to ensure that we serve these customers as well, hence the "megapixel" classification for these lenses.  We have selected them so that they are suitable for all our current megapixel cameras.&lt;/p&gt;&lt;p&gt;In addition to what you wrote, selecting a lens that is not only color corrected but also IR corrected is important for those customers that would like to use their megapixel camera at night provided their camera has adequate sensitivity and a day / night mode with IR cut filter removal.&lt;/p&gt;&lt;p&gt;A further issue is focusing a lens on a megapixel camera which is of a different magnitude than focusing a lens for standard definition cameras.  A much finer focus control is required to get the lens to focus optimally and the lens is also much more susceptible to vibration, as the slightest shift in focal position is immediately visible with a megapixel camera.  If the camera is mounted in a dome shaped enclosure, an additional problem occurs.  While the focus shift that occurs when the bubble is placed on the dome after installation is almost imperceptible on standard definition cameras, it is clearly noticeable on megapixel cameras and thus makes focusing such cameras in a dome enclosure difficult.&lt;/p&gt;&lt;p&gt;As to Vlado's comments on auto iris, this is definitely true for one type of AI lenses: video drive lenses.  There are, however, several megapixel cameras available that support direct drive megapixel auto iris lenses.  This is a good alternative that extends the advantages of auto iris functionality mentioned by Vlado to megapixel cameras.&lt;/p&gt;&lt;p&gt;Best regards,&lt;/p&gt;&lt;p&gt;Gerrit&lt;br&gt;&lt;/p&gt;</description><dc:creator xmlns:dc="http://purl.org/dc/elements/1.1/">Gerrit Hurenkamp</dc:creator><pubDate>Tue, 24 Feb 2009 21:25:30 -0000</pubDate></item></channel></rss>