平臺的選擇很多時候和系統選擇的算法是相關的，所以如果要提高架構，平臺的設計能力，得不斷提高自身的算法設計，復雜度評估能力，帶寬分析能力。

    常用的主處理器芯片有：單片機，ASIC，RISC(DEC Alpha、ARC、ARM、MIPS、PowerPC、SPARC和SuperH )，DSP和FPGA等，這些處理器的比較在網上有很多的文章，在這里不老生常談了，這里只提1個典型的主處理器選型案例。

    比如市場上現在有很多百萬高清網絡攝像機（HD-IPNC）的設計需求，而IPNC的解決方案也層出不窮，TI的解決方案有DM355、DM365、DM368等，海思提供的方案則有Hi3512、Hi3515、Hi3520等，NXP提供的方案有PNX1700、PNX1005等。

    對于HD-IPNC的主處理芯片，有幾個主要的技術指標：視頻分辨率，視頻編碼器算法，最高支持的圖像抓拍分辨率，CMOS的圖像預處理能力，以及網絡協議棧的開發平臺。Hi3512單芯片實現720P30 H.264編解碼能力，滿足高清IP Camera應用, Hi3515可實現1080P30的編解碼能力，持續提升高清IP Camera的性能。

    DM355單芯片實現720P30 MPEG4編解碼能力，DM365單芯片實現720P30 H.264編解碼能力, DM368單芯片實現1080P30 H.264編解碼能力。

    DM355是2007 Q3推出的，DM365是2009 Q1推出的，DM368是2010 Q2推出的。海思的同檔次解決方案也基本上與之同時出現。 海思和TI的解決方案都是基于linux，對于網絡協議棧的開發而言，開源社區的資源是沒有區別的，區別的只在于芯片供應商提供的SDK開發包，兩家公司的SDK離產品都有一定的距離，但是linux的網絡開發并不是一個技術難點，所以并不影響百萬高清網絡攝像機的推廣。

    作為IPNC的解決方案，在720P時代，海思的解決方案相對于TI的解決方案，其優勢是支持了H.264編解碼算法，而TI只支持了MPEG4的編解碼算法。雖然在2008年初，MPEG4的劣勢在市場上已經開始體現出來，但在當時這似乎并不影響DM355的推廣。

    對于最高支持的圖像抓拍分辨率，海思的解決方案可以支持支持JPEG抓拍3M Pixels@5fps，DM355最高可以支持5M Pixels，雖然當時沒有成功的開發成5M Pixel的抓拍（內存分配得有點兒問題，后來就不折騰了），但是至少4M Pixel的抓拍是實現了的，而且有幾個朋友已經實現了2560x1920這個接近5M Pixel的抓拍，所以在這一點上DM355稍微勝出。

    因為在高清分辨率下，CCD傳感器非常昂貴，而CMOS傳感器像原尺寸又做不大，導致本身在低照度下就性能欠佳的CMOS傳感器的成像質量在高分辨率時變差，于是TI在DM355處理器內部集成了一個叫做ISP的圖像預處理模塊，它由CCDC，IPIPE，IPIPEIF和H3A模塊組成，能幫助實現把CMOS的RAW DATA（一般是指Bayer格式數據）轉成YCbCr數據，同時實現包括白平衡調節，直方圖統計，自動曝光，自動聚焦等采用CMOS解決方案所必須的功能，故DM355處理器就可以無縫的對接各種圖像傳感器了。而海思的解決方案對于CMOS的選擇就有局限性，它只能用OVT一些解決方案，因為OVT的部分Sensor集成了圖像預處理功能。但是DM355不僅可以接OVT的解決方案，還可接很多其他廠家CMOS sensor，比如Aptina的MT9P031。所以在圖像預處理能力方面，DM355繼續勝出。

    在IPNC這個領域，只要每臺掙1個美金就可以開始跑量，所以在那個時代，很少有人會去死摳H.264和MPEG4的性能差異，而且TI已經給了市場一個很好的預期，支持H.264的DM365很快就會面世。所以IPNC這個方案而言，當時很多企業都選擇了DM355的方案。有些朋友現在已經從DM355成功過渡到DM365、DM368，雖然你有時候會罵TI，為什么技術不搞得厲害點，在當年就一步到位，浪費了多少生產力。但是技術就是一點一點積累起來，對于個人來不得半點含糊，對于大企業，他們也無法大躍進。DM355的CMOS預處理技術也有很多Bug，SDK也有很多bug，有時會讓你又愛又恨，但是技術這東西總是沒有十全十美的，能在特定的歷史條件下，滿足市場需求，那就是個好東西。

    本文來自www.hm-jh.cn