視頻監(jiān)控圖像處理

視頻監(jiān)控及視頻圖像分析基礎(chǔ)知識(shí)視頻監(jiān)控定義利用視頻技術(shù)探測(cè)、監(jiān)視設(shè)防區(qū)域，實(shí)時(shí)顯示、統(tǒng)計(jì)現(xiàn)場(chǎng)圖像，檢索和顯示歷史圖像電子系統(tǒng)或網(wǎng)絡(luò)系統(tǒng)視頻監(jiān)控系統(tǒng)是安全技術(shù)防范一個(gè)子系統(tǒng)視頻監(jiān)控技術(shù)是安全防范技術(shù)一部分它包含模擬視頻監(jiān)控系統(tǒng)、網(wǎng)絡(luò)視頻監(jiān)控系統(tǒng)。模擬視頻監(jiān)控圖1模擬視頻監(jiān)控基本結(jié)構(gòu)網(wǎng)絡(luò)視頻監(jiān)控圖2網(wǎng)絡(luò)視頻監(jiān)控基本結(jié)構(gòu)技術(shù)：主要是視頻編解碼技術(shù)、嵌入式技術(shù)組成：硬盤(pán)錄像機(jī)、攝像機(jī)、監(jiān)視器等功效：監(jiān)視（監(jiān)聽(tīng)）、控制、錄像、回放、對(duì)講等線纜：視頻電纜、485控制線主要應(yīng)用：金融、樓宇、小區(qū)等網(wǎng)絡(luò)視頻監(jiān)控優(yōu)點(diǎn)可經(jīng)過(guò)網(wǎng)絡(luò)組建低成本跨區(qū)域監(jiān)控系統(tǒng)一機(jī)多路，使用大容量硬盤(pán)可長(zhǎng)久存放數(shù)字信號(hào)長(zhǎng)久保留信號(hào)不失真采取智能檢索，檢索與錄像可同時(shí)進(jìn)行循環(huán)錄像方式，節(jié)約人力基本概念圖像（Image）像素（Pixel）分辨率（Resolution）水平：Width垂直：Height視頻（Video）時(shí)間上連續(xù)圖像組成視頻：Image→Video視頻中某一幅圖像稱(chēng)為一幀（Frame）幀率（FrameRate）FPS→每秒幀數(shù)碼流（BitStream）將圖像壓縮后形成數(shù)據(jù)碼率（BitRate）bps/Bps→對(duì)碼流進(jìn)行量化碼率類(lèi)型：定碼率（CBR）、變碼率（VBR）碼流類(lèi)型：視頻流、音頻流、復(fù)合流掃描方式隔行掃描（Interlaced）和逐行掃描（Progressive）都是在顯示設(shè)備表示運(yùn)動(dòng)圖像方法，隔行掃描方式是每一幀被分割為兩場(chǎng)畫(huà)面交替顯示，逐行掃描方式是將每幀全部畫(huà)面同時(shí)顯示。通常液晶電視顯示畫(huà)面掃描方法都是從左到右從上到下，每秒鐘掃描固定幀數(shù)。隔行掃描(Interlacing）隔行掃描就是每一幀被分割為兩場(chǎng)，每一場(chǎng)包含了一幀中全部奇數(shù)掃描行或者偶數(shù)掃描行，通常是先掃描奇數(shù)行得到第一場(chǎng)，然后掃描偶數(shù)行得到第二場(chǎng)。因?yàn)橐曈X(jué)暫留效應(yīng)，人眼將會(huì)看到平滑運(yùn)動(dòng)而不是閃動(dòng)半幀半幀圖像。不過(guò)這時(shí)會(huì)有幾乎不會(huì)被注意到閃爍出現(xiàn)，使得人眼輕易疲勞。當(dāng)屏幕內(nèi)容是橫條紋時(shí)，這種閃爍尤其輕易被注意到。逐行掃描(Progressive)逐行掃描每次顯示整個(gè)掃描幀，假如逐行掃描幀率和隔行掃描場(chǎng)率相同，人眼將看到比隔行掃描更平滑圖像，相對(duì)于隔行掃描來(lái)說(shuō)閃爍較小。視頻制式PAL（PhaseAlternatingLine）：供電頻率為50Hz、場(chǎng)頻為每秒50場(chǎng)、幀頻為每秒25幀、掃描線為625行圖像彩色誤差較小，與黑白電視兼容也好中國(guó)、德國(guó)NTSC（NationalTelevisionSystemCommittee）：供電頻率為60Hz，場(chǎng)頻為每秒60場(chǎng)，幀頻為每秒30幀，掃描線為525行美國(guó)、日本SECAM（SequentielCouleurAMemoire）：按次序傳送彩色與存放俄羅斯、法國(guó)、埃及分辨率分辨率能夠從顯示分辨率與圖像分辨率兩個(gè)方向來(lái)分類(lèi)。顯示分辨率（屏幕分辨率）是屏幕圖像精密度，是指顯示器所能顯示像素有多少。因?yàn)槠聊簧宵c(diǎn)、線和面都是由像素組成，顯示器可顯示像素越多，畫(huà)面就越精細(xì)，一樣屏幕區(qū)域內(nèi)能顯示信息也越多，所以分辨率是個(gè)非常主要性能指標(biāo)之一。能夠把整個(gè)圖像想象成是一個(gè)大型棋盤(pán)，而分辨率表示方式就是全部經(jīng)線和緯線交叉點(diǎn)數(shù)目。顯示分辨率一定情況下，顯示器越小圖像越清楚，反之，顯示器大小固定時(shí)，顯示分辨率越高圖像越清楚。圖像分辨率則是單位英寸中所包含像素點(diǎn)數(shù)，其定義更趨近于分辨率本身定義分辨率制式WD1D14CIF1×12CIF1×1/2DCIF3/4×2/3CIF1/2×1/2QCIF1/4×1/4PAL960×576720×576704×576704×288528×384352×288176×144NTSC960×480720×480704×480704×240528×320352×240176×120高清分辨率分辨率大于等于720p稱(chēng)為高清數(shù)碼監(jiān)控基礎(chǔ)技術(shù)：編碼和壓縮一路4CIF分辨率圖像，進(jìn)行A/D轉(zhuǎn)換后未經(jīng)壓縮數(shù)據(jù)量是(RGB)：一幀： 704×576×3字節(jié)＝1216512字節(jié)（不包含文件頭大?。┮幻耄?1216512字節(jié)/幀×25幀/秒＝30412800字節(jié)/秒＝29MB/秒一小時(shí)： 29MB/秒×3600秒/小時(shí)＝101.9GB/小時(shí)一天： 101.9GB/小時(shí)×二十四小時(shí)＝2.4TB/天壓縮基本原理安防監(jiān)控中視頻數(shù)據(jù)有極強(qiáng)相關(guān)性，有大量冗余信息冗余信息分為空域冗余信息和時(shí)域冗余信息壓縮技術(shù)就是將數(shù)據(jù)中冗余信息去掉壓縮技術(shù)包含幀內(nèi)壓縮技術(shù)、幀間壓縮技術(shù)和熵編碼壓縮技術(shù)壓縮標(biāo)準(zhǔn)監(jiān)控中主要采取MJPEG、MPEG1/2、MPEG4(SP/ASP)、H.264/AVC等幾個(gè)視頻編碼技術(shù)ChronologicalProgressionofITUandMPEGChronologicalProgressionofITUandMPEGH264概述H264基本原理H264壓縮技術(shù)主要采取了以下幾個(gè)方法對(duì)視頻數(shù)據(jù)進(jìn)行壓縮。包含：幀內(nèi)預(yù)測(cè)壓縮，處理是空域數(shù)據(jù)冗余問(wèn)題。幀間預(yù)測(cè)壓縮（運(yùn)動(dòng)估量與賠償），處理是時(shí)域數(shù)據(jù)冗余問(wèn)題。整數(shù)離散余弦變換（DCT），將空間上相關(guān)性變?yōu)轭l域上無(wú)關(guān)數(shù)據(jù)然后進(jìn)行量化。CABAC壓縮。經(jīng)過(guò)壓縮后幀分為：I幀，P幀和B幀:I幀：關(guān)鍵幀，采取幀內(nèi)壓縮技術(shù)。P幀：向前參考幀，在壓縮時(shí)，只參考前面已經(jīng)處理幀。采取幀音壓縮技術(shù)。B幀：雙向參考幀，在壓縮時(shí)，它即參考前而幀，又參考它后面幀。采取幀間壓縮技術(shù)。除了I/P/B幀外，還有圖像序列GOP。GOP:兩個(gè)I幀之間是一個(gè)圖像序列，在一個(gè)圖像序列中只有一個(gè)I幀。以下列圖所表示：下面我們就來(lái)詳細(xì)描述一下H264壓縮技術(shù)。H264壓縮技術(shù)H264基本原理其實(shí)非常簡(jiǎn)單，下我們就簡(jiǎn)單描述一下H264壓縮數(shù)據(jù)過(guò)程。經(jīng)過(guò)攝像頭采集到視頻幀（按每秒30幀算），被送到H264編碼器緩沖區(qū)中。編碼器先要為每一幅圖片劃分宏塊。以下面這張圖為例:劃分宏塊H264默認(rèn)是使用16X16大小區(qū)域作為一個(gè)宏塊，也能夠劃分成8X8大小。劃分好宏塊后，計(jì)算宏塊象素值。以這類(lèi)推，計(jì)算一幅圖像中每個(gè)宏塊像素值，全部宏塊都處理完后以下面樣子。劃分子塊H264對(duì)比較平坦圖像使用16X16大小宏塊。但為了更高壓縮率，還能夠在16X16宏塊上更劃分出更小子塊。子塊大小能夠是8X16?16X8?8X8?4X8?8X4?4X4非常靈活。上幅圖中，紅框內(nèi)16X16宏塊中大部分是藍(lán)色背景，而三只鷹部分圖像被劃在了該宏塊內(nèi)，為了愈加好處理三只鷹部分圖像，H264就在16X16宏塊內(nèi)又劃分出了多個(gè)子塊。這么再經(jīng)過(guò)幀內(nèi)壓縮，能夠得到更高效數(shù)據(jù)。下列圖是分別使用mpeg-2和H264對(duì)上面宏塊進(jìn)行壓縮后結(jié)果。其中左半部分為MPEG-2子塊劃分后壓縮結(jié)果，右半部分為H264子塊劃壓縮后結(jié)果，能夠看出H264劃分方法更具優(yōu)勢(shì)。宏塊劃分好后，就能夠?qū)264編碼器緩存中全部圖片進(jìn)行分組了。幀分組對(duì)于視頻數(shù)據(jù)主要有兩類(lèi)數(shù)據(jù)冗余，一類(lèi)是時(shí)間上數(shù)據(jù)冗余，另一類(lèi)是空間上數(shù)據(jù)冗余。其中時(shí)間上數(shù)據(jù)冗余是最大。下面我們就先來(lái)說(shuō)說(shuō)視頻數(shù)據(jù)時(shí)間上冗余問(wèn)題。為何說(shuō)時(shí)間上冗余是最大呢？假設(shè)攝像頭每秒抓取30幀，這30幀數(shù)據(jù)大部分情況下都是相關(guān)聯(lián)。也有可能不止30幀數(shù)據(jù)，可能幾十幀，上百幀數(shù)據(jù)都是關(guān)聯(lián)尤其親密。對(duì)于這些關(guān)聯(lián)尤其親密幀，其實(shí)我們只需要保留一幀數(shù)據(jù)，其它幀都能夠經(jīng)過(guò)這一幀再按某種規(guī)則預(yù)測(cè)出來(lái)，所以說(shuō)視頻數(shù)據(jù)在時(shí)間上冗余是最多。為了達(dá)成相關(guān)幀經(jīng)過(guò)預(yù)測(cè)方法來(lái)壓縮數(shù)據(jù)，就需要將視頻幀進(jìn)行分組。那么怎樣判定一些幀關(guān)系親密，能夠劃為一組呢？我們來(lái)看一下例子，下面是捕捉一組運(yùn)動(dòng)臺(tái)球視頻幀，臺(tái)球從右上角滾到了左下角。

H264編碼器會(huì)按次序，每次取出兩幅相鄰幀進(jìn)行宏塊比較，計(jì)算兩幀相同度。以下列圖：經(jīng)過(guò)宏塊掃描與宏塊搜索能夠發(fā)覺(jué)這兩個(gè)幀關(guān)聯(lián)度是非常高。進(jìn)而發(fā)覺(jué)這一組幀關(guān)聯(lián)度都是非常高。所以，上面這幾幀就能夠劃分為一組。其算法是：在相鄰幾幅圖像畫(huà)面中，通常有差異像素只有10%以?xún)?nèi)點(diǎn),亮度差值改變不超出2%，而色度差值改變只有1%以?xún)?nèi)，我們認(rèn)為這么圖能夠分到一組。在這么一組幀中，經(jīng)過(guò)編碼后，我們只保留第一帖完整數(shù)據(jù)，其它幀都經(jīng)過(guò)參考上一幀計(jì)算出來(lái)。我們稱(chēng)第一幀為IDR／I幀，其它幀我們稱(chēng)為P／B幀，這么編碼后數(shù)據(jù)幀組我們稱(chēng)為GOP。運(yùn)動(dòng)估量與賠償在H264編碼器中將幀分組后，就要計(jì)算幀組內(nèi)物體運(yùn)動(dòng)矢量了。還以上面運(yùn)動(dòng)臺(tái)球視頻幀為例，我們來(lái)看一下它是怎樣計(jì)算運(yùn)動(dòng)矢量。H264編碼器首先按次序從緩沖區(qū)頭部取出兩幀視頻數(shù)據(jù)，然后進(jìn)行宏塊掃描。當(dāng)發(fā)覺(jué)其中一幅圖片中有物體時(shí)，就在另一幅圖鄰近位置（搜索窗口中）進(jìn)行搜索。假如此時(shí)在另一幅圖中找到該物體，那么就能夠計(jì)算出物體運(yùn)動(dòng)矢量了。下面這幅圖就是搜索后臺(tái)球移動(dòng)位置。經(jīng)過(guò)上圖中臺(tái)球位置相差，就能夠計(jì)算出臺(tái)圖運(yùn)行方向和距離。H264依次把每一幀中球移動(dòng)距離和方向都統(tǒng)計(jì)下來(lái)就成了下面樣子。運(yùn)動(dòng)矢量計(jì)算出來(lái)后，將相同部分（也就是綠色部分）減去，就得到了賠償數(shù)據(jù)。我們最終只需要將賠償數(shù)據(jù)進(jìn)行壓縮保留，以后在解碼時(shí)就能夠恢復(fù)原圖了。壓縮賠償后數(shù)據(jù)只需要統(tǒng)計(jì)極少一點(diǎn)數(shù)據(jù)。以下所表示：我們把運(yùn)動(dòng)矢量與賠償稱(chēng)為幀間壓縮技術(shù)，它處理是視頻幀在時(shí)間上數(shù)據(jù)冗余。除了幀間壓縮，幀內(nèi)也要進(jìn)行數(shù)據(jù)壓縮，幀內(nèi)數(shù)據(jù)壓縮處理是空間上數(shù)據(jù)冗余。下面我們就來(lái)介紹一下幀內(nèi)壓縮技術(shù)。幀內(nèi)預(yù)測(cè)人眼對(duì)圖象都有一個(gè)識(shí)別度，對(duì)低頻亮度很敏感，對(duì)高頻亮度不太敏感。所以基于一些研究，能夠?qū)⒁环鶊D像中人眼不敏感數(shù)據(jù)去除掉。這么就提出了幀內(nèi)預(yù)測(cè)技術(shù)。H264幀內(nèi)壓縮與JPEG很相同。一幅圖像被劃分好宏塊后，對(duì)每個(gè)宏塊能夠進(jìn)行9種模式預(yù)測(cè)。找出與原圖最靠近一個(gè)預(yù)測(cè)模式。下面這幅圖是對(duì)整幅圖中每個(gè)宏塊進(jìn)行預(yù)測(cè)過(guò)程。幀內(nèi)預(yù)測(cè)后圖像與原始圖像對(duì)比以下：然后，將原始圖像與幀內(nèi)預(yù)測(cè)后圖像相減得殘差值。再將我們之前得到預(yù)測(cè)模式信息一起保留起來(lái)，這么我們就能夠在解碼時(shí)恢復(fù)原圖了。效果以下：經(jīng)過(guò)幀內(nèi)與幀間壓縮后，即使數(shù)據(jù)有大幅降低，但還有優(yōu)化空間。對(duì)殘差數(shù)據(jù)做DCT能夠?qū)埐顢?shù)據(jù)做整數(shù)離散余弦變換，去掉數(shù)據(jù)相關(guān)性，深入壓縮數(shù)據(jù)。以下列圖所表示，左側(cè)為原數(shù)據(jù)宏塊，右側(cè)為計(jì)算出殘差數(shù)據(jù)宏塊。將殘差數(shù)據(jù)宏塊數(shù)字化后以下列圖所表示：將殘差數(shù)據(jù)宏塊進(jìn)行DCT轉(zhuǎn)換。去掉相關(guān)聯(lián)數(shù)據(jù)后，我們能夠看出數(shù)據(jù)被深入壓縮了。做完DCT后，還不夠，還要進(jìn)行CABAC進(jìn)行無(wú)損壓縮。CABAC上面幀內(nèi)壓縮是屬于有損壓縮技術(shù)。也就是說(shuō)圖像被壓縮后，無(wú)法完全復(fù)原。而CABAC屬于無(wú)損壓縮技術(shù)。無(wú)損壓縮技術(shù)大家最熟悉可能就是哈夫曼編碼了，給高頻詞一個(gè)短碼，給低頻詞一個(gè)長(zhǎng)碼從而達(dá)成數(shù)據(jù)壓縮目標(biāo)。MPEG-2中使用VLC就是這種算法，我們以A-Z作為例子，A屬于高頻數(shù)據(jù)，Z屬于低頻數(shù)據(jù)?？纯此窃鯓幼?。CABAC也是給高頻數(shù)據(jù)短碼，給低頻數(shù)據(jù)長(zhǎng)碼。同時(shí)還會(huì)依照上下文相關(guān)性進(jìn)行壓縮，這種方式又比VLC高效很多。其效果以下：現(xiàn)在將A-Z換成視頻幀，它就成了下面樣子。從上面這張圖中顯著能夠看出采取CACBA無(wú)損壓縮方案要比VLC高效多H.265與H264區(qū)分H.265標(biāo)準(zhǔn)全稱(chēng)為高效視頻編碼(HighEfficiencyVideoCoding)，也即HEVC，相較于之前H.264標(biāo)準(zhǔn)有了相當(dāng)大改進(jìn)。H.265又何以讓如此多行業(yè)都青睞有加？故事開(kāi)始還是需要從H.264說(shuō)起，H.264也稱(chēng)作MPEG-4AVC(AdvancedVideoCodec，高級(jí)視頻編碼)，因其能夠得到比其余編碼標(biāo)準(zhǔn)更高視頻質(zhì)量和更低碼率，而得到了人們認(rèn)可，被廣泛應(yīng)用于網(wǎng)絡(luò)流媒體數(shù)據(jù)、各種高清楚度電視廣播以及衛(wèi)星電視廣播等領(lǐng)域。從編碼框架上來(lái)說(shuō)，H.265依然沿用了H.264混合編碼框架，主要包含：幀內(nèi)預(yù)測(cè)(intraprediction)、幀間預(yù)測(cè)(interprediction)、轉(zhuǎn)換(transform)、量化(quantization)、去區(qū)塊濾波器(deblockingfilter)、熵編碼(entropycoding)等模塊。如今更高清發(fā)展愈演強(qiáng)烈，H.264也碰到了瓶頸。以編碼單位來(lái)說(shuō)，H.264中每個(gè)宏塊(marcoblock，MB)大小都是固定16x16像素。然而，在更高分辨率下，單個(gè)宏塊所表示圖像內(nèi)容信息大大降低，H.264所采取宏塊經(jīng)過(guò)整數(shù)變換后，低頻系數(shù)相同程度也大大提升，出現(xiàn)大量冗余，造成H.264編碼對(duì)高清視頻壓縮效率顯著降低；其次，H.264算法宏塊個(gè)數(shù)暴發(fā)式增加，會(huì)造成每個(gè)編碼宏塊預(yù)測(cè)模式、運(yùn)動(dòng)矢量、參考幀索引和量化級(jí)等宏塊級(jí)參數(shù)信息占用更多碼流資源，在有限帶寬中，分配給真正描述圖像內(nèi)容殘差系數(shù)信息可用帶寬顯著降低了；再有，因?yàn)榉直媛侍嵘?，表示同一個(gè)運(yùn)動(dòng)運(yùn)動(dòng)矢量幅值也將大大增加，H.264編碼方式特點(diǎn)是數(shù)值越大使用比特?cái)?shù)越多，所以，伴隨運(yùn)動(dòng)矢量幅值大幅增加，H.264中用來(lái)對(duì)運(yùn)動(dòng)矢量進(jìn)行預(yù)測(cè)以及編碼壓縮率也將逐步降低。相比H.264，H.265提供了更多不一樣工具來(lái)降低碼率。H.265編碼單位能夠選擇從最小8x8到最大64x64。信息量不多區(qū)域(顏色改變不顯著，比如天空灰色部分)劃分宏塊較大，編碼后碼字較少，而細(xì)節(jié)多地方(細(xì)節(jié)改變較多，比如大樓部分)劃分宏塊就對(duì)應(yīng)小和多一些，編碼后碼字較多，這么就相當(dāng)于對(duì)圖像進(jìn)行了有重點(diǎn)編碼，從而降低了整體碼率，編碼效率就對(duì)應(yīng)提升了。這個(gè)過(guò)程有點(diǎn)像“感興趣區(qū)域編碼”，針對(duì)主要更多關(guān)鍵細(xì)節(jié)部分進(jìn)行增強(qiáng)劃塊，無(wú)更多關(guān)鍵細(xì)節(jié)部分進(jìn)行簡(jiǎn)單劃塊，不過(guò)這個(gè)過(guò)程在H.265上能夠自適應(yīng)識(shí)別實(shí)現(xiàn)。攝像機(jī)基礎(chǔ)知識(shí)模擬攝像機(jī)基本概念組成：主要由鏡頭、影像傳感器（CCD/CMOS）、ISP(ImageSignalProcessor)及相關(guān)電路組成工作原理：被攝物體經(jīng)鏡頭成像在影像傳感器表面，形成微弱電荷并積累，在相關(guān)電路控制下，積累電荷逐點(diǎn)移出，經(jīng)過(guò)濾波、放大后輸入DSP進(jìn)行圖像信號(hào)處理，最終形成視頻信號(hào)（CVBS）輸出傳感器傳感器ADCDSPDAC光圖像碼流模擬攝像機(jī)系統(tǒng)結(jié)構(gòu)CVBS網(wǎng)絡(luò)攝像機(jī)基本概念組成：主要由鏡頭、影像傳感器（CCD/CMOS）、ISP(ImageSignalProcessor)、DSP（DigitalSignalProcessor）及相關(guān)電路組成工作原理：被攝物體經(jīng)鏡頭成像經(jīng)過(guò)IRFilter濾波后在圖像傳感器表面，形成微弱電荷并積累，在相關(guān)電路控制下，積累電荷逐點(diǎn)移出，經(jīng)過(guò)濾波、放大后輸入DSP進(jìn)行圖像信號(hào)處理和編碼壓縮，(假如是球機(jī)，同時(shí)將控制信號(hào)發(fā)送給云臺(tái))最終形成數(shù)字信號(hào)輸出.DSPDSPCCD/CMOSISPNET光圖像碼流網(wǎng)絡(luò)攝像機(jī)系統(tǒng)結(jié)構(gòu)DSPDSPSensor工作原理每個(gè)感光元件對(duì)應(yīng)圖像傳感器中一個(gè)像點(diǎn)，因?yàn)楦泄庠荒芨袘?yīng)光強(qiáng)度，無(wú)法捕捉色彩信息，所以必須在感光元件上方覆蓋彩色濾光片。在這方面，不一樣傳感器廠商有不一樣處理方案，最慣用做法是覆蓋RGB紅綠藍(lán)三色濾光片，以1：2：1組成由四個(gè)像點(diǎn)組成一個(gè)彩色像素（即紅藍(lán)濾光片分別覆蓋一個(gè)像點(diǎn)，剩下兩個(gè)像點(diǎn)都覆蓋綠色濾光片），采取這種百分比原因是人眼對(duì)綠色較為敏感。而索尼四色CCD技術(shù)則將其中一個(gè)綠色濾光片換為翡翠綠色（英文Emerald，有些媒體稱(chēng)為E通道），由此組成新R、G、B、E四色方案。不論是哪一個(gè)技術(shù)方案，都要四個(gè)像點(diǎn)才能夠組成一個(gè)彩色像素，這一點(diǎn)大家務(wù)必要預(yù)先明確。

在接收光照之后，感光元件產(chǎn)生對(duì)應(yīng)電流，電流大小與光強(qiáng)對(duì)應(yīng)，所以感光元件直接輸出電信號(hào)是模擬。在CCD傳感器中，每一個(gè)感光元件都不對(duì)此作深入處理，而是將它直接輸出到下一個(gè)感光元件存放單元，結(jié)合該元件生成模擬信號(hào)后再輸出給第三個(gè)感光元件，依次類(lèi)推，直到結(jié)合最終一個(gè)感光元件信號(hào)才能形成統(tǒng)一輸出。因?yàn)楦泄庠呻娦盘?hào)實(shí)在太微弱了，無(wú)法直接進(jìn)行模數(shù)轉(zhuǎn)換工作，所以這些輸出數(shù)據(jù)必須做統(tǒng)一放大處理—這項(xiàng)任務(wù)是由CCD傳感器中放大器專(zhuān)門(mén)負(fù)責(zé)，經(jīng)放大器處理之后，每個(gè)像點(diǎn)電信號(hào)強(qiáng)度都取得一樣幅度增大；但因?yàn)镃CD本身無(wú)法將模擬信號(hào)直接轉(zhuǎn)換為數(shù)字信號(hào)，所以還需要一個(gè)專(zhuān)門(mén)模數(shù)轉(zhuǎn)換芯片進(jìn)行處理，最終以二進(jìn)制數(shù)字圖像矩陣形式輸出給專(zhuān)門(mén)DSP處理芯片。而對(duì)于CMOS傳感器，上述工作流程就完全不適用了。CMOS傳感器中每一個(gè)感光元件都直接整合了放大器和模數(shù)轉(zhuǎn)換邏輯，當(dāng)感光二極管接收光照、產(chǎn)生模擬電信號(hào)之后，電信號(hào)首先被該感光元件中放大器放大，然后直接轉(zhuǎn)換成對(duì)應(yīng)數(shù)字信號(hào)。換句話說(shuō)，在CMOS傳感器中，每一個(gè)感光元件都可產(chǎn)生最終數(shù)字輸出，所得數(shù)字信號(hào)合并之后被直接送交DSP芯片處理—問(wèn)題恰恰是發(fā)生在這里，CMOS感光元件中放大器屬于模擬器件，無(wú)法確保每個(gè)像點(diǎn)放大率都保持嚴(yán)格一致，致使放大后圖像數(shù)據(jù)無(wú)法代表拍攝物體原貌—表現(xiàn)在最終輸出結(jié)果上，就是圖像中出現(xiàn)大量噪聲，品質(zhì)顯著低于CCD傳感器(這幾年伴隨半導(dǎo)體制程工藝及加工工藝大幅度改進(jìn)，CMOS良品率大大提升，品質(zhì)上與CCD差異不大)。ISP與DSPISP

是ImageSignalProcessor簡(jiǎn)稱(chēng)，也就是圖像信號(hào)處理器。而DSP是DigitalSignalProcessor縮寫(xiě)，也就是數(shù)字信號(hào)處理器。ISP通慣用來(lái)處理ImageSensor（圖像傳感器）輸出數(shù)據(jù)，如做AEC（自動(dòng)曝光控制）、AGC（自動(dòng)增益控制）、AWB（自動(dòng)白平衡）、色彩校正、LensShading、Gamma校正、祛除壞點(diǎn)、AutoBlackLevel、AutoWhiteLevel等等功效處理。而DSP功效就比較多了，它能夠做些拍照以及回顯（JPEG編解碼）、錄像以及回放（Video編解碼）、H.264編解碼、還有很多其余方面處理，總之是處理數(shù)字信號(hào)了。個(gè)人認(rèn)為ISP是一類(lèi)特殊處理圖像信號(hào)DSPISP（ImageSignalProcessor）圖像信號(hào)處理器主要作用是對(duì)前端圖像傳感器輸出信號(hào)做后期處理。不一樣ISP用來(lái)匹配不一樣廠商圖像傳感器。ISP優(yōu)異在整個(gè)攝像機(jī)產(chǎn)品中很主要，應(yīng)該說(shuō)它直接影響展現(xiàn)給用戶(hù)影響畫(huà)質(zhì)優(yōu)劣。圖像經(jīng)過(guò)圖像經(jīng)過(guò)CCD或者CMOS采集后，需要經(jīng)過(guò)后期處理才能夠很好適應(yīng)不一樣環(huán)境，在不一樣光學(xué)條件下都能很好還原出現(xiàn)場(chǎng)細(xì)節(jié)。在ISP中它會(huì)完成我們經(jīng)常提及2A（AWB/AE，自動(dòng)白平衡/自動(dòng)曝光）或者3A（AWB/AE/AF，自動(dòng)白平衡/自動(dòng)曝光/自動(dòng)聚焦）。傳統(tǒng)模式下通常采取一顆DSP或者一顆FPGA來(lái)完成對(duì)圖像后期處理。有些攝像機(jī)產(chǎn)品支持3D降噪功效、寬動(dòng)態(tài)、慢快門(mén)、幀累積、強(qiáng)光抑制等功效也都是ISP來(lái)完成。現(xiàn)在應(yīng)用在高清攝像機(jī)產(chǎn)品中ISP通常有以下幾個(gè)起源：廠商自行研發(fā)：高清攝像機(jī)設(shè)備廠商為了愈加好配合后端壓縮、功效開(kāi)發(fā)，自行研發(fā)ISP處理算法，將算法集成至FPGA或DSP芯片中，接駁前端圖像傳感器。第三方研發(fā)：已經(jīng)逐步誕生了一批由非高清攝像機(jī)制造廠商推出一些ISP處理方案，他們直接出售不一樣ISP芯片給攝像機(jī)廠商配合不一樣廠商Sensor。套片模式：由Sensor廠商將自主開(kāi)發(fā)ISP結(jié)合自家Sensor形成圖像采集處理處理方案推向客戶(hù)，其中圖像處理算法及各種調(diào)試工作已經(jīng)完成，攝像機(jī)廠商只需要做接口對(duì)接并后端壓縮或轉(zhuǎn)換成數(shù)字視頻（HD-SDI）即可。這種模式我們稱(chēng)為Stand-AloneDevices或者CameraSystemOnchip。DSP芯片，也稱(chēng)數(shù)字信號(hào)處理器，是一個(gè)具備特殊結(jié)構(gòu)微處理器。DSP芯片內(nèi)部采取程序和數(shù)據(jù)分開(kāi)哈佛結(jié)構(gòu)，具備專(zhuān)門(mén)硬件乘法器，廣泛采取流水線操作，提供特殊DSP指令，能夠用來(lái)快速地實(shí)現(xiàn)各種數(shù)字信號(hào)處理算法。下列圖是圖像信號(hào)處理主要流程： 我們眼中用來(lái)分辨顏色錐狀細(xì)胞差異，錐狀細(xì)胞經(jīng)過(guò)對(duì)三原色感知來(lái)識(shí)別萬(wàn)色萬(wàn)物，而機(jī)器中是怎么樣識(shí)別呢?人眼把世界放進(jìn)大腦也可簡(jiǎn)單分為三步：眼球感應(yīng)到像(傳感器采集并轉(zhuǎn)換成數(shù)字信號(hào))——轉(zhuǎn)成神經(jīng)信號(hào)傳到大腦(經(jīng)過(guò)通訊系統(tǒng)將信號(hào)傳四處理器)——大腦處理并存放(處理器轉(zhuǎn)化成屏幕可顯示與存放格式)。圖像信號(hào)處理大致也是以這種流程捕捉圖像并進(jìn)行分析和存放。黑電平校正（暗電流校正）

暗電流指?jìng)鞲衅髟跊](méi)有入射光情況下。存在一定信號(hào)輸出，這是因?yàn)榘雽?dǎo)體熱運(yùn)動(dòng)造成。它大小和傳感器結(jié)構(gòu)及溫度關(guān)于，大約每升高9℃，其暗電流會(huì)添加1倍。因?yàn)槊恳粋€(gè)像素存在不平衡性，所以像素間暗電流也會(huì)不一致，造成電流噪聲。通常情況下，在傳感器中，實(shí)際像素要比有效像素多，像素區(qū)最靠邊行和列為不感光區(qū)，通慣用作自己主動(dòng)黑電平校正，其平均值作為校正值。顏色插補(bǔ)我們知道，Sensor感光原理是經(jīng)過(guò)一個(gè)一個(gè)感光點(diǎn)對(duì)光進(jìn)行采樣和量化，但在Sensor中，每一個(gè)感光點(diǎn)只能感光RGB中一個(gè)顏色。所以，通常所說(shuō)30萬(wàn)像素或130萬(wàn)像素等，指是有30萬(wàn)或130萬(wàn)個(gè)感光點(diǎn)。每一個(gè)感光點(diǎn)只能感光一個(gè)顏色。原始像素僅僅包含一個(gè)顏色信息（R或G或B），要重建色彩畫(huà)面。就必須從相鄰像素中得到失去信息組成RGB三種顏色。紅色及藍(lán)色插補(bǔ)通常遵照近期標(biāo)準(zhǔn)，進(jìn)行平均處理。作為本像素色彩值，由插值原理知，相鄰像素間存在依賴(lài)關(guān)系，結(jié)果造成畫(huà)面銳度降低。壞點(diǎn)檢測(cè)圖像傳感器輸出數(shù)據(jù)不等于就是圖像實(shí)際數(shù)據(jù)，模組測(cè)試時(shí)，就要寫(xiě)一個(gè)軟件，完成數(shù)據(jù)采集（取得Rawdata）－>彩色插值（目標(biāo)是取得RGB格式，便于圖像顯示）－>圖像顯示；這么就能夠發(fā)覺(jué)整個(gè)模組是否正常，有沒(méi)有壞點(diǎn)，臟點(diǎn)等，檢測(cè)出不良品；（軟件處理過(guò)程當(dāng)中，為了取得愈加好圖像質(zhì)量，還需要白平衡，gamma校正，彩色校正）

顏色校正

因?yàn)槿祟?lèi)眼睛可見(jiàn)光頻譜響應(yīng)度和半導(dǎo)體傳感器頻譜響應(yīng)度之間存在區(qū)分，還有透鏡等影響，插補(bǔ)后得到RGB值顏色會(huì)存在偏差，所以必須對(duì)顏色進(jìn)行校正，通常經(jīng)過(guò)顏色校正矩陣來(lái)實(shí)現(xiàn)。詳細(xì)彩色矯正參數(shù)。能夠經(jīng)過(guò)試驗(yàn)或從傳感器供給商中取得，當(dāng)然要得到不失真還原是不可能，僅僅能重復(fù)調(diào)試達(dá)成最好。通常經(jīng)過(guò)標(biāo)準(zhǔn)色卡進(jìn)行校正。Gamma校正

Gamma校正主要依照色度學(xué)原理進(jìn)行調(diào)整。色彩在不一樣顯示設(shè)備中頻譜響應(yīng)度不一樣，造成顏色失真。失真成冪指數(shù)關(guān)系。所以調(diào)整相對(duì)簡(jiǎn)單，分別對(duì)R、G、B調(diào)整就能夠。RGB、YUV、RAWDATA區(qū)分YUV:luma(Y)+chroma(UV)格式，通常情況下sensor支持YUV422格式，即數(shù)據(jù)格式是按Y-U-Y-V次序輸出。人眼對(duì)色度敏感程度要低于對(duì)亮度敏感程度。YUV，分為三個(gè)分量，“Y”表示明亮度（Luminance或Luma），也就是灰度值；而“U”和“V”表示則是色度（Chrominance或Chroma），作用是描述影像色彩及飽和度，用于指定像素顏色。與我們熟知RGB類(lèi)似，YUV也是一個(gè)顏色編碼方法，主要用于電視系統(tǒng)以及模擬視頻領(lǐng)域，它將亮度信息（Y）與色彩信息（UV）分離，沒(méi)有UV信息一樣能夠顯示完整圖像，只不過(guò)是黑白，這么設(shè)計(jì)很好地處理了彩色電視機(jī)與黑白電視兼容問(wèn)題。而且，YUV不像RGB那樣要求三個(gè)獨(dú)立視頻信號(hào)同時(shí)傳輸，所以用YUV方式傳送占用極少頻寬。RGB:傳統(tǒng)紅綠藍(lán)格式，比如RGB565，其16-bit數(shù)據(jù)格式為5-bitR+6-bitG+5-bitB。G多一位，原因是人眼對(duì)綠色比較敏感。RAWRGB:sensor每一像素對(duì)應(yīng)一個(gè)彩色濾光片，濾光片按Bayerpattern分布。將每一個(gè)像素?cái)?shù)據(jù)直接輸出，即RAWRGBdataRGB與YUV格式相互轉(zhuǎn)換本程序中函數(shù)能夠?qū)GB24格式像素?cái)?shù)據(jù)轉(zhuǎn)換為YUV420P格式像素?cái)?shù)據(jù)。函數(shù)代碼以下所表示。unsigned

char

clip_value(unsigned

char

x,unsigned

char

min_val,unsigned

char

max_val){

if(x>max_val){

return

max_val;

}else

if(x<min_val){

return

min_val;

}else{

return

x;

}

}

//RGB

to

YUV420

bool

RGB24_TO_YUV420(unsigned

char

*RgbBuf,int

w,int

h,unsigned

char

*yuvBuf)

{

unsigned

char*ptrY,

*ptrU,

*ptrV,

*ptrRGB;

memset(yuvBuf,0,w*h*3/2);

ptrY

=

yuvBuf;

ptrU

=

yuvBuf

+

w*h;

ptrV

=

ptrU

+

(w*h*1/4);

unsigned

char

y,

u,

v,

r,

g,

b;

for

(int

j

=

0;

j<h;j++){

ptrRGB

=

RgbBuf

+

w*j*3

;

for

(int

i

=

0;i<w;i++){

r

=

*(ptrRGB++);

g

=

*(ptrRGB++);

b

=

*(ptrRGB++);

y

=

(unsigned

char)(

(

66

*

r

+

129

*

g

+

25

*

b

+

128)

>>

8)

+

16

;

u

=

(unsigned

char)(

(

-38

*

r

-

74

*

g

+

112

*

b

+

128)

>>

8)

+

128

;

v

=

(unsigned

char)(

(

112

*

r

-

94

*

g

-

18

*

b

+

128)

>>

8)

+

128

;

*(ptrY++)

=

clip_value(y,0,255);

if

(j%2==0&&i%2

==0){

*(ptrU++)

=clip_value(u,0,255);

}

else{

if

(i%2==0){

*(ptrV++)

=clip_value(v,0,255);

}

}

}

}

return

true;

}

/**

*

Convert

RGB24

file

to

YUV420P

file

*

@param

url_in

Location

of

Input

RGB

file.

*

@param

w

Width

of

Input

RGB

file.

*

@param

h

Height

of

Input

RGB

file.

*

@param

num

Number

of

frames

to

process.

*

@param

url_out

Location

of

Output

YUV

file.

*/

int

simplest_rgb24_to_yuv420(char

*url_in,

int

w,

int

h,int

num,char

*url_out){

FILE

*fp=fopen(url_in,"rb+");

FILE

*fp1=fopen(url_out,"wb+");

unsigned

char

*pic_rgb24=(unsigned

char

*)malloc(w*h*3);

unsigned

char

*pic_yuv420=(unsigned

char

*)malloc(w*h*3/2);

for(int

i=0;i<num;i++){

fread(pic_rgb24,1,w*h*3,fp);

RGB24_TO_YUV420(pic_rgb24,w,h,pic_yuv420);

fwrite(pic_yuv420,1,w*h*3/2,fp1);

}

free(pic_rgb24);

free(pic_yuv420);

fclose(fp);

fclose(fp1);

return

0;

}

調(diào)用上面函數(shù)方法以下所表示。simplest_rgb24_to_yuv420("lena_256x256_rgb24.rgb",256,256,1,"output_lena.yuv");

從源代碼能夠看出，本程序?qū)崿F(xiàn)了RGB到Y(jié)UV轉(zhuǎn)換公式：Y=0.299*R+0.587*G+0.114*BU=-0.147*R-0.289*G+0.463*BV=0.615*R-0.515*G-0.100*B在轉(zhuǎn)換過(guò)程中有以下幾點(diǎn)需要注意：

1)

RGB24存放方式是Packed，YUV420P存放方式是Packed。

2)

U，V在水平和垂直方向取樣數(shù)是Y二分之一

轉(zhuǎn)換前RGB24格式像素?cái)?shù)據(jù)lena_256x256_rgb24.rgb內(nèi)容以下所表示。轉(zhuǎn)換后YUV420P格式像素?cái)?shù)據(jù)output_lena.yuv內(nèi)容以下所表示。基于FFmpeg實(shí)現(xiàn)利用FFmpeg中swscale實(shí)現(xiàn)YUV到RGB轉(zhuǎn)換，實(shí)現(xiàn)過(guò)程中，需要結(jié)構(gòu)AVPicture結(jié)構(gòu)，詳細(xì)實(shí)現(xiàn)方法以下。boolYV12ToBGR24_FFmpeg(unsignedchar*pYUV,unsignedchar*pBGR24,intwidth,intheight){if(width<1||height<1||pYUV==NULL||pBGR24==NULL)returnfalse;//intsrcNumBytes,dstNumBytes;//uint8_t*pSrc,*pDst;AVPicturepFrameYUV,pFrameBGR;//pFrameYUV=avpicture_alloc();//srcNumBytes=avpicture_get_size(PIX_FMT_YUV420P,width,height);//pSrc=(uint8_t*)malloc(sizeof(uint8_t)*srcNumBytes);avpicture_fill(&pFrameYUV,pYUV,PIX_FMT_YUV420P,width,height);//U,V交換uint8_t*ptmp=pFrameYUV.data[1];pFrameYUV.data[1]=pFrameYUV.data[2];pFrameYUV.data[2]=ptmp;//pFrameBGR=avcodec_alloc_frame();//dstNumBytes=avpicture_get_size(PIX_FMT_BGR24,width,height);//pDst=(uint8_t*)malloc(sizeof(uint8_t)*dstNumBytes);avpicture_fill(&pFrameBGR,pBGR24,PIX_FMT_BGR24,width,height);structSwsContext*imgCtx=NULL;imgCtx=sws_getContext(width,height,PIX_FMT_YUV420P,width,height,PIX_FMT_BGR24,SWS_BILINEAR,0,0,0);if(imgCtx!=NULL){sws_scale(imgCtx,pFrameYUV.data,pFrameYUV.linesize,0,height,pFrameBGR.data,pFrameBGR.linesize);if(imgCtx){sws_freeContext(imgCtx);imgCtx=NULL;}returntrue;}else{sws_freeContext(imgCtx);imgCtx=NULL;returnfalse;}}這份代碼轉(zhuǎn)換公式是YV12格式轉(zhuǎn)化成RGB24格式方法，公式以下：

YUV(256級(jí)別)能夠從8位RGB直接計(jì)算：Y=0.299R+0.587G+0.114BU=-0.1687R-0.3313G+0.5B+128V=0.5R-0.4187G-0.0813B+128反過(guò)來(lái)，RGB也能夠直接從YUV(256級(jí)別)計(jì)算:R=Y+1.402(Cr-128)G=Y-0.34414(Cb-128)-0.71414(Cr-128)B=Y+1.772(Cb-128)YUV420P和H264數(shù)據(jù)流

做視頻采集與處理，自然少不了要學(xué)會(huì)分析YUV數(shù)據(jù)。因?yàn)閺牟杉嵌葋?lái)說(shuō)，通常視頻采集芯片輸出碼流通常都是YUV數(shù)據(jù)流形式，而從視頻處理（比如H.264、MPEG視頻編解碼）角度來(lái)說(shuō)，也是在原始YUV碼流進(jìn)行編碼和解析。 視頻碼流在視頻播放器中位置以下所表示。 本文中程序是一個(gè)H.264碼流解析程序。該程序能夠從H.264碼流中分析得到它基本單元NALU，而且能夠簡(jiǎn)單解析NALU首部字段。經(jīng)過(guò)修改該程序能夠?qū)崿F(xiàn)不一樣H.264碼流處理功效。原理H.264原始碼流（又稱(chēng)為“裸流”）是由一個(gè)一個(gè)NALU組成。他們結(jié)構(gòu)以下列圖所表示。其中每個(gè)NALU之間經(jīng)過(guò)startcode（起始碼）進(jìn)行分隔，起始碼分成兩種：0x000001（3Byte）或者0x00000001（4Byte）。假如NALU對(duì)應(yīng)Slice為一幀開(kāi)始就用0x00000001，不然就用0x000001。

H.264碼流解析步驟就是首先從碼流中搜索0x000001和0x00000001，分離出NALU；然后再分析NALU各個(gè)字段。本文程序即實(shí)現(xiàn)了上述兩個(gè)步驟。代碼整個(gè)程序位于simplest_h264_parser()函數(shù)中，以下所表示。[cpp]

\o"viewplain"viewplain

\o"copy"copy/**

*

最簡(jiǎn)單視音頻數(shù)據(jù)處理示例

*

Simplest

MediaData

Test

*

*

雷霄驊

Lei

Xiaohua

*

*

中國(guó)傳媒大學(xué)/數(shù)字電視技術(shù)

*

Communication

University

of

China

/

Digital

TV

Technology

*

*

*

本項(xiàng)目包含以下幾個(gè)視音頻測(cè)試示例：

*

(1)像素?cái)?shù)據(jù)處理程序。包含RGB和YUV像素格式處理函數(shù)。

*

(2)音頻采樣數(shù)據(jù)處理程序。包含PCM音頻采樣格式處理函數(shù)。

*

(3)H.264碼流分析程序。能夠分離并解析NALU。

*

(4)AAC碼流分析程序。能夠分離并解析ADTS幀。

*

(5)FLV封裝格式分析程序。能夠?qū)LV中MP3音頻碼流分離出來(lái)。

*

(6)UDP-RTP協(xié)議分析程序。能夠?qū)⒎治鯱DP/RTP/MPEG-TS數(shù)據(jù)包。

*

*

This

project

contains

following

samples

to

handling

multimedia

data:

*

(1)

Video

pixel

data

handling

program.

It

contains

several

examples

to

handle

RGB

and

YUV

data.

*

(2)

Audio

sample

data

handling

program.

It

contains

several

examples

to

handle

PCM

data.

*

(3)

H.264

stream

analysis

program.

It

can

parse

H.264

bitstream

and

analysis

NALU

of

stream.

*

(4)

AAC

stream

analysis

program.

It

can

parse

AAC

bitstream

and

analysis

ADTS

frame

of

stream.

*

(5)

FLV

format

analysis

program.

It

can

analysis

FLV

file

and

extract

MP3

audio

stream.

*

(6)

UDP-RTP

protocol

analysis

program.

It

can

analysis

UDP/RTP/MPEG-TS

Packet.

*

*/

#include

<stdio.h>

#include

<stdlib.h>

#include

<string.h>

typedef

enum

{

NALU_TYPE_SLICE

=

1,

NALU_TYPE_DPA

=

2,

NALU_TYPE_DPB

=

3,

NALU_TYPE_DPC

=

4,

NALU_TYPE_IDR

=

5,

NALU_TYPE_SEI

=

6,

NALU_TYPE_SPS

=

7,

NALU_TYPE_PPS

=

8,

NALU_TYPE_AUD

=

9,

NALU_TYPE_EOSEQ

=

10,

NALU_TYPE_EOSTREAM

=

11,

NALU_TYPE_FILL

=

12,

}

NaluType;

typedef

enum

{

NALU_PRIORITY_DISPOSABLE

=

0,

NALU_PRIRITY_LOW

=

1,

NALU_PRIORITY_HIGH

=

2,

NALU_PRIORITY_HIGHEST

=

3

}

NaluPriority;

typedef

struct

{

int

startcodeprefix_len;

//!

4

for

parameter

sets

and

first

slice

in

picture,

3

for

everything

else

(suggested)

unsigned

len;

//!

Length

of

the

NAL

unit

(Excluding

the

start

code,

which

does

not

belong

to

the

NALU)

unsigned

max_size;

//!

Nal

Unit

Buffer

size

int

forbidden_bit;

//!

should

be

always

FALSE

int

nal_reference_idc;

//!

NALU_PRIORITY_xxxx

int

nal_unit_type;

//!

NALU_TYPE_xxxx

char

*buf;

//!

contains

the

first

byte

followed

by

the

EBSP

}

NALU_t;

FILE

*h264bitstream

=

NULL;

//!<

the

bit

stream

file

int

info2=0,

info3=0;

static

int

FindStartCode2

(unsigned

char

*Buf){

if(Buf[0]!=0

||

Buf[1]!=0

||

Buf[2]

!=1)

return

0;

//0x000001?

else

return

1;

}

static

int

FindStartCode3

(unsigned

char

*Buf){

if(Buf[0]!=0

||

Buf[1]!=0

||

Buf[2]

!=0

||

Buf[3]

!=1)

return

0;//0x00000001?

else

return

1;

}

int

GetAnnexbNALU

(NALU_t

*nalu){

int

pos

=

0;

int

StartCodeFound,

rewind;

unsigned

char

*Buf;

if

((Buf

=

(unsigned

char*)calloc

(nalu->max_size

,

sizeof(char)))

==

NULL)

printf

("GetAnnexbNALU:

Could

not

allocate

Buf

memory\n");

nalu->startcodeprefix_len=3;

if

(3

!=

fread

(Buf,

1,

3,

h264bitstream)){

free(Buf);

return

0;

}

info2

=

FindStartCode2

(Buf);

if(info2

!=

1)

{

if(1

!=

fread(Buf+3,

1,

1,

h264bitstream)){

free(Buf);

return

0;

}

info3

=

FindStartCode3

(Buf);

if

(info3

!=

1){

free(Buf);

return

-1;

}

else

{

pos

=

4;

nalu->startcodeprefix_len

=

4;

}

}

else{

nalu->startcodeprefix_len

=

3;

pos

=

3;

}

StartCodeFound

=

0;

info2

=

0;

info3

=

0;

while

(!StartCodeFound){

if

(feof

(h264bitstream)){

nalu->len

=

(pos-1)-nalu->startcodeprefix_len;

memcpy

(nalu->buf,

&Buf[nalu->startcodeprefix_len],

nalu->len);

nalu->forbidden_bit

=

nalu->buf[0]

&

0x80;

//1

bit

nalu->nal_reference_idc

=

nalu->buf[0]

&

0x60;

//

2

bit

nalu->nal_unit_type

=

(nalu->buf[0])

&

0x1f;//

5

bit

free(Buf);

return

pos-1;

}

Buf[pos++]

=

fgetc

(h264bitstream);

info3

=

FindStartCode3(&Buf[pos-4]);

if(info3

!=

1)

info2

=

FindStartCode2(&Buf[pos-3]);

StartCodeFound

=

(info2

==

1

||

info3

==

1);

}

//

Here,

we

have

found

another

start

code

(and

read

length

of

startcode

bytes

more

than

we

should

//

have.

Hence,

go

back

in

the

file

rewind

=

(info3

==

1)?

-4

:

-3;

if

(0

!=

fseek

(h264bitstream,

rewind,

SEEK_CUR)){

free(Buf);

printf("GetAnnexbNALU:

Cannot

fseek

in

the

bit

stream

file");

}

//

Here

the

Start

code,

the

complete

NALU,

and

the

next

start

code

is

in

the

Buf.

//

The

size

of

Buf

is

pos,

pos+rewind

are

the

number

of

bytes

excluding

the

next

//

start

code,

and

(pos+rewind)-startcodeprefix_len

is

the

size

of

the

NALU

excluding

the

start

code

nalu->len

=

(pos+rewind)-nalu->startcodeprefix_len;

memcpy

(nalu->buf,

&Buf[nalu->startcodeprefix_len],

nalu->len);//

nalu->forbidden_bit

=

nalu->buf[0]

&

0x80;

//1

bit

nalu->nal_reference_idc

=

nalu->buf[0]

&

0x60;

//

2

bit

nalu->nal_unit_type

=

(nalu->buf[0])

&

0x1f;//

5

bit

free(Buf);

return

(pos+rewind);

}

/**

*

Analysis

H.264

Bitstream

*

@param

url

Location

of

input

H.264

bitstream

file.

*/

int

simplest_h264_parser(char

*url){

NALU_t

*n;

int

buffersize=100000;

//FILE

*myout=fopen("output_log.txt","wb+");

FILE

*myout=stdout;

h264bitstream=fopen(url,

"rb+");

if

(h264bitstream==NULL){

printf("Open

file

error\n");

return

0;

}

n

=

(NALU_t*)calloc

(1,

sizeof

(NALU_t));

if

(n

==

NULL){

printf("Alloc

NALU

Error\n");

return

0;

}

n->max_size=buffersize;

n->buf

=

(char*)calloc

(buffersize,

sizeof

(char));

if

(n->buf

==

NULL){

free

(n);

printf

("AllocNALU:

n->buf");

return

0;

}

int

data_offset=0;

int

nal_num=0;

printf("-----+--------

NALU

Table

------+---------+\n");

printf("

NUM

|

POS

|

IDC

|

TYPE

|

LEN

|\n");

printf("-----+---------+--------+-------+---------+\n");

while(!feof(h264bitstream))

{

int

data_lenth;

data_lenth=GetAnnexbNALU(n);

char

type_str[20]={0};

switch(n->nal_unit_type){

case

NALU_TYPE_SLICE:sprintf(type_str,"SLICE");break;

case

NALU_TYPE_DPA:sprintf(type_str,"DPA");break;

case

NALU_TYPE_DPB:sprintf(type_str,"DPB");break;

case

NALU_TYPE_DPC:sprintf(type_str,"DPC");break;

case

NALU_TYPE_IDR:sprintf(type_str,"IDR");break;

case

NALU_TYPE_SEI:sprintf(type_str,"SEI");break;

case

NALU_TYPE_SPS:sprintf(type_str,"SPS");break;

case

NALU_TYPE_PPS:sprintf(type_str,"PPS");break;

case

NALU_TYPE_AUD:sprintf(type_str,"AUD");break;

case

NALU_TYPE_EOSEQ:sprintf(type_str,"EOSEQ");break;

case

NALU_TYPE_EOSTREAM:sprintf(type_str,"EOSTREAM");break;

case

NALU_TYPE_FILL:sprintf(type_str,"FILL");break;

}

char

idc_str[20]={0};

switch(n->nal_reference_idc>>5){

case

NALU_PRIORITY_DISPOSABLE:sprintf(idc_str,"DISPOS");break;

case

NALU_PRIRITY_LOW:sprintf(idc_str,"LOW");break;

case

NALU_PRIORITY_HIGH:sprintf(idc_str,"HIGH");break;

case

NALU_PRIORITY_HIGHEST:sprintf(idc_str,"HIGHEST");break;

}

fprintf(myout,"%5d|

%8d|

%7s|

%6s|

%8d|\n",nal_num,data_offset,idc_str,type_str,n->len);

data_offset=data_offset+data_lenth;

nal_num++;

}

//Free

if

(n){

if

(n->buf){

free(n->buf);

n->buf=NULL;

}

free

(n);

}

return

0;

}

上文中函數(shù)調(diào)用方法以下所表示。[cpp]

\o"viewplain"viewplain

\o"copy"copysimplest_h264_parser("sintel.h264");

結(jié)果本程序輸入為一個(gè)H.264原始碼流（裸流）文件路徑，輸出為該碼流NALU統(tǒng)計(jì)數(shù)據(jù)，以下列圖所表示。用ffmpeg把H264數(shù)據(jù)流解碼成YUV420P初始化參數(shù)[cpp]

\o"viewplain"viewplain\o"copy"copy//下面初始化h264解碼庫(kù)

avcodec_init();

av_register_all();

AVFrame

*pFrame_

=

NULL;

AVCodecContext

*codec_

=

avcodec_alloc_context();

/*

find

the

video

encoder

*/

AVCodec

*videoCodec

=

avcodec_find_decoder(CODEC_ID_H264);

if

(!videoCodec)

{

cout

<<

"codec

not

found!"

<<

endl;

return

-1;

}

//初始化參數(shù)，下面參數(shù)應(yīng)該由詳細(xì)業(yè)務(wù)決定

codec_->time_base.num

=

1;

codec_->frame_number

=

1;

//每包一個(gè)視頻幀

codec_->codec_type

=

AVMEDIA_TYPE_VIDEO;

codec_->bit_rate

=

0;

codec_->time_base.den

=

30;//幀率

codec_->width

=

1280;//視頻寬

codec_->height

=

720;//視頻高

if(avcodec_open(codec_,

videoCodec)

>=

0)

pFrame_

=

avcodec_alloc_frame();//

Allocate

video

frame

else

return

-1;

解碼

[cpp]

\o"viewplain"viewplain\o"copy"copyAVPacket

packet

=

{0};

int

frameFinished

=

dwBufsize;//這個(gè)是隨便填入數(shù)字，沒(méi)什么作用

packet.data

=

pBuffer;//這里填入一個(gè)指向完整H264數(shù)據(jù)幀指針

packet.size

=

dwBufsize;//這個(gè)填入H264數(shù)據(jù)幀大小

//下面開(kāi)始真正解碼

avcodec_decode_video2(codec_,

pFrame_,

&frameFinished,

&packet);

if(frameFinished)//成功解碼

{

int

picSize

=

codec_->height

*

codec_->width;

int

newSize

=

picSize

*

1.5;

//申請(qǐng)內(nèi)存

unsigned

char

*buf

=

new

unsigned

char[newSize];

int

height

=

p->codec->height;

int

width

=

p->codec->width;

//寫(xiě)入數(shù)據(jù)

int

a=0,i;

for

(i=0;

i<height;

i++)

{

memcpy(buf+a,pFrame_->data[0]

+

i

*

pFrame_->linesize[0],

width);

a+=width;

}

for

(i=0;

i<height/2;

i++)

{

memcpy(buf+a,pFrame_->data[1]

+

i

*

pFrame_->linesize[1],

width/2);

a+=width/2;

}

for

(i=0;

i<height/2;

i++)

{

memcpy(buf+a,pFrame_->data[2]

+

i

*

pFrame_->linesize[2],

width/2);

a+=width/2;

}

//===============

//到這里，buf里面已經(jīng)是yuv420p數(shù)據(jù)了，能夠?qū)λ鋈魏翁幚砝?/p>

//===============

delete

[]

buf;

}

不過(guò)我發(fā)覺(jué)這么解碼很耗cpu資源，我Core2

E74002.8G處理器，解碼1920X1080分辨率每秒30幀視頻時(shí)，CPU占用率能用到差不多50%。PS：原來(lái)avcodec_decode_video2這個(gè)函數(shù)會(huì)修改codec_里面參數(shù)，也就是說(shuō)假如原來(lái)里面填分別率是1280X720，運(yùn)行avcodec_decode_video2后codec_里面會(huì)變成實(shí)際視頻分辨率。主動(dòng)白平衡處理

假設(shè)使用過(guò)沒(méi)有白平衡數(shù)碼相機(jī)，會(huì)發(fā)覺(jué)熒光燈光人眼看起來(lái)是白色，但用數(shù)碼相機(jī)拍攝出來(lái)卻有點(diǎn)偏綠。相同，假設(shè)在白熾燈下，拍出圖像色彩就會(huì)顯著偏紅。人類(lèi)眼睛之所以把它們都看成白色。是因?yàn)槿搜圻M(jìn)行了修正。因?yàn)閳D像傳感器本身沒(méi)有這么功效，所以有必要對(duì)它輸出信號(hào)進(jìn)行一定修正。這么修正叫作白平衡。

白平衡控制經(jīng)過(guò)圖像色彩調(diào)整（通常調(diào)整R、B增益實(shí)現(xiàn)），使在各種光線條件下拍攝出照片色彩和人眼所表示景物色彩完全一樣。從理論上我們知道，伴隨色溫升高。要對(duì)色溫進(jìn)行較正，不然，物體在這種光線條件下所表現(xiàn)出來(lái)顏色就會(huì)偏離其正常顏色，所以須要降低sensor對(duì)紅色增益。添加sersor對(duì)藍(lán)光增益。同一時(shí)候在調(diào)整參數(shù)時(shí)一定程度上要考慮到總體亮度要保持大致不變。即以YUV來(lái)衡量時(shí)，Y值要基本保持不變，理論上以為能夠參考RGB->YUV變換公式中。RGB三分量對(duì)Y值貢獻(xiàn)，從而確定RGAIN和BGAIN改變百分比關(guān)系。但實(shí)際情況比這還要復(fù)雜一些，要考慮到不一樣sensor對(duì)R,B感光交叉影響和非線性，所以最好值可能和理論值會(huì)有一些偏差。

白平衡實(shí)現(xiàn)通常有手動(dòng)和自己主動(dòng)兩種模式，當(dāng)然對(duì)于攝像機(jī)主要以自己主動(dòng)白平衡為主。自己主動(dòng)白平衡通常基于“GreyWorld”假如，調(diào)整R、B增益，在選定參考白平衡區(qū)域內(nèi)達(dá)成R、G、B相等。自己主動(dòng)白平衡是基于假如場(chǎng)景色彩平均值落在一個(gè)特定范圍內(nèi)，假如測(cè)量得到結(jié)果偏離該范圍，則調(diào)整對(duì)應(yīng)參數(shù)，校正直到其均值落入指定范圍。該處理過(guò)程可能基于YUV空間，也可能基于RGB空間來(lái)進(jìn)行。對(duì)于Sensor來(lái)說(shuō)，通常處理方式是經(jīng)過(guò)校正R/B增益，使得UV值落在一個(gè)指定范圍內(nèi)。從而實(shí)現(xiàn)自己主動(dòng)白平衡。這么假如在非常多場(chǎng)所能夠達(dá)成非常好效果，但因?yàn)闊o(wú)法得到場(chǎng)景光源全部信息。所以自己主動(dòng)白平衡效果有時(shí)并不讓人愜意，此時(shí)能夠讓用戶(hù)自定義一個(gè)點(diǎn)火區(qū)域作為參考點(diǎn)。也實(shí)用白平衡感測(cè)器來(lái)實(shí)現(xiàn)。

白平衡對(duì)色彩效果影響非常大，一個(gè)好算法能夠使色彩效果更逼真。也能夠利用白平衡達(dá)成藝術(shù)效果。主動(dòng)曝光、AE評(píng)定

自己主動(dòng)曝光，簡(jiǎn)單地說(shuō)就是自己主動(dòng)控制曝光時(shí)間。達(dá)成曝光恰到優(yōu)點(diǎn)效果。曝光過(guò)分，圖像傳感器就會(huì)產(chǎn)生溢出，造成對(duì)照度下降，動(dòng)態(tài)靈敏度降低。曝光不夠，相同會(huì)造成對(duì)照度下降，動(dòng)態(tài)靈敏度降低，信噪比下降，畫(huà)面效果不好。所以在不一樣場(chǎng)景必須對(duì)曝光時(shí)間進(jìn)行控制。

自己主動(dòng)曝光主要是對(duì)某可選區(qū)域內(nèi)畫(huà)面亮度分量（y信號(hào)）進(jìn)行評(píng)定，若y偏小，增大曝光量，反之降低。感光寬容度

從最明亮到最黑暗，假如人眼能夠看到一定范圍。那么膠片（或CCD等電子感光器件）所能表現(xiàn)遠(yuǎn)比人眼看到范圍小多。而這個(gè)有限范圍就是感光寬容度。

人眼感光寬容度比膠片要高非常多，而膠片感光寬容度要比數(shù)碼相機(jī)CCD高出非常多！了解這個(gè)概念之后。我們就不難了解，為何在逆光條件下，人眼能看清背光建筑物以及刺眼天空云彩。而一旦拍攝出來(lái)，要么就是云彩顏色絢爛而建筑物變成了黑糊糊剪影，要么就是建筑物色彩細(xì)節(jié)清楚而原本美麗云彩卻成了白色一片再看人眼結(jié)構(gòu)。有瞳孔能夠控制通光量，有桿狀感光細(xì)胞和椎狀感光細(xì)胞以適應(yīng)不一樣光強(qiáng)。可見(jiàn)即使人眼有著非常高感光寬容度，依舊有亮度調(diào)整系統(tǒng)，以適應(yīng)光強(qiáng)改變。

那么對(duì)于camerasensor來(lái)說(shuō)。正確曝光就更為主要了。主動(dòng)曝光和18%灰

對(duì)于sensor來(lái)說(shuō)。又是怎樣來(lái)推斷曝光是否正確呢？非常標(biāo)準(zhǔn)做法就是在YUV空間計(jì)算當(dāng)前圖像Y值均值。調(diào)整各種曝光參數(shù)設(shè)定（自己主動(dòng)或手動(dòng)），使得該均值落在一個(gè)目標(biāo)值附近時(shí)候，就以為得到了正確曝光。

那么怎樣確定這個(gè)Y均值。以及怎樣調(diào)整參數(shù)使得sensor能夠?qū)?dāng)前圖像亮度調(diào)整到這個(gè)范圍呢？

這就包括到一個(gè)概念18%灰，通常以為室內(nèi)室外景物，在通常情況下，其平均反光系數(shù)大約為18%。而色彩均值，如前所述，能夠以為是一個(gè)中灰色調(diào)。這么能夠經(jīng)過(guò)對(duì)反光率為18%灰板拍攝。調(diào)整曝光參數(shù)。使其顏色靠近為中等亮度灰色（Y值為128）。然后，對(duì)于通常景物，就能自己主動(dòng)得到正確曝光了。

當(dāng)然這么自己主動(dòng)推斷曝光參數(shù)AE功效不是萬(wàn)能，對(duì)于反光率偏離通常均值場(chǎng)景。比喻雪景，夜景等。用這么方法就無(wú)法得到正確曝光量了。所以在sensor軟件處理模塊中，通常還會(huì)提供曝光級(jí)別