傳輸系統(tǒng)視頻通道白屏問題研究

李石鳳

摘要：CCTV系統(tǒng)通過傳輸系統(tǒng)的H.264視頻板卡，匯集各個(gè)站點(diǎn)圖像供調(diào)度人員和行值人員調(diào)看及大屏顯示。二號(hào)線傳輸?shù)囊曨l板卡編碼過程中出現(xiàn)異常，導(dǎo)致某些站點(diǎn)的圖像上傳至控制中心客戶端時(shí)顯示為白色畫面中間有個(gè)圖標(biāo)，為問題狀態(tài)，此問題簡稱白屏問題。經(jīng)過多次排查，確認(rèn)傳輸系統(tǒng)視頻板卡某些通道的存在問題。此問題最終定位為視頻板卡H.264的軟件BUG，需升級(jí)所有H.264板卡的固態(tài)軟件firmware。板卡升級(jí)解決白屏問題，并優(yōu)化傳輸系統(tǒng)的網(wǎng)管OMS的告警提示。

關(guān)鍵詞：CCTV系統(tǒng); OTN系統(tǒng); OVS系統(tǒng); OMS系統(tǒng)

南京地鐵二號(hào)線傳輸系統(tǒng)采用的是OTNX3M2.5G設(shè)備，是通信等相關(guān)專業(yè)的組網(wǎng)設(shè)備，傳輸站間的視頻、語音、監(jiān)控等數(shù)據(jù)和控制信號(hào)。CCTV系統(tǒng)主要用于監(jiān)視地鐵內(nèi)部公共場(chǎng)所的運(yùn)行、檢修和售檢票作業(yè)情況、變電所設(shè)備室設(shè)備運(yùn)行情況，提高行車指揮透明度的輔助通信工具，借助于傳輸系統(tǒng)的環(huán)網(wǎng)供調(diào)度人員，行車值班人員使用。線路開通多年后，多個(gè)站點(diǎn)發(fā)生控制中心調(diào)看某些車站視頻圖像，圖像顯示為白色，中間有個(gè)小圖標(biāo)，為問題狀態(tài)，后續(xù)把此類故障歸結(jié)為傳輸系統(tǒng)視頻通道白屏問題。

一、傳輸系統(tǒng)與CCTV 系統(tǒng)架構(gòu)

CCTV系統(tǒng)借用傳輸系統(tǒng)的視頻板卡，上傳各個(gè)站點(diǎn)的視頻圖像到控制中心供大屏和客戶端;并通過以太網(wǎng)通道，監(jiān)控全線的CCTV系統(tǒng)設(shè)備狀態(tài)，并下發(fā)中心的操作命令。兩者之間的聯(lián)動(dòng)關(guān)系如圖1所示：

二、白屏問題排查

此類問題多次發(fā)生，重點(diǎn)介紹12 月調(diào)度人員反應(yīng)行調(diào)2客戶端無法調(diào)看羊山公園圖像的排查過程。本次故障從中心與站點(diǎn)的兩側(cè)排查。

（一）中心排查

網(wǎng)管通信維護(hù)人員趕至現(xiàn)場(chǎng)處理，通過多個(gè)客戶端對(duì)比排查，確認(rèn)故障現(xiàn)象如下：行調(diào)2 客戶端“無法調(diào)看”羊山公園的所有圖像，羊山公園所有攝像機(jī)的畫面顯示的圖像，但可以調(diào)看其他站如馬群、經(jīng)天路等站點(diǎn)圖像。

行調(diào)1 客戶端“可以”正常調(diào)看羊山公園所有圖像。網(wǎng)管客戶端“可以”調(diào)看羊山公園站的所有圖像及其他站點(diǎn)圖像。

所有客戶端都釋放，都不調(diào)看羊山公園站圖像。改變調(diào)看順序，利用行調(diào)2 首先調(diào)看，測(cè)試情況如下：行調(diào)2 客戶端調(diào)看羊山公園站圖像，發(fā)現(xiàn)“可以”調(diào)看羊山公園站的所有圖像。停留在羊山公園畫面。

行調(diào)1 客戶端調(diào)看羊山公園站圖像，發(fā)現(xiàn)不可以調(diào)看羊山公園站的圖像，所有畫面的顯示都變成圖2 的圖標(biāo)。停留在羊山公園站調(diào)看狀態(tài)。

網(wǎng)管客戶端調(diào)看羊山公園站圖像，各個(gè)攝像機(jī)終端畫面正常。

經(jīng)過多次改變調(diào)看順序測(cè)試后，發(fā)現(xiàn)三個(gè)客戶端同時(shí)調(diào)看羊山公園站畫面時(shí)，順序?yàn)椤暗诙蛻舳恕笔菬o法調(diào)看畫面，顯示都為圖2。如上面測(cè)試中，第二客戶端當(dāng)時(shí)為行調(diào)1 客戶端。

在此過程中，網(wǎng)管人員查看CCTV 網(wǎng)管和傳輸系統(tǒng)網(wǎng)管，確認(rèn)都沒有告警指示。

（二）站點(diǎn)排查

正線通信維護(hù)員現(xiàn)場(chǎng)查看CCTV 系統(tǒng)矩陣輸出端圖像，發(fā)現(xiàn)上傳傳輸系統(tǒng)的12 路圖像，有兩種顯示：正常視頻圖像及黑屏，沒有如的圖標(biāo)顯示。

查看傳輸系統(tǒng)H.264 板卡側(cè)的12 路視頻圖像，現(xiàn)象與矩陣側(cè)相同，H.264 板卡各通道的指示燈顯示也正常。至此故障處理進(jìn)入迷茫區(qū)域，有故障現(xiàn)象，確無法確認(rèn)故障點(diǎn)。初步定義為軟件故障，為使故障盡快恢復(fù)，只能小范圍的依次重啟相關(guān)聯(lián)的矩陣板卡及H.264 板卡。重啟矩陣后故障現(xiàn)象依舊;接著重啟H.264 板卡;故障恢復(fù)。故把故障點(diǎn)定位在H.264 板卡。

接下來的2 個(gè)月中，多個(gè)站依次出現(xiàn)此類現(xiàn)象的故障，雖然重啟后恢復(fù)，但此類故障沒有消失跡象，卻有爆發(fā)擴(kuò)張的跡象。這給通信的維保和調(diào)度人員的工作都帶來很大的困擾。

三、白屏問題原因分析

通過兩個(gè)月故障的處理與統(tǒng)計(jì)，確定此類故障是系統(tǒng)級(jí)的故障，不是單點(diǎn)故障，必須從根本上解決此類故障，不能單純的從板卡重啟方面處理。

梳理系統(tǒng)原理，參考圖1 確認(rèn)視頻數(shù)據(jù)上傳涉及CCTV 自身的系統(tǒng)及傳輸系統(tǒng)。根據(jù)前面的故障現(xiàn)象可以確定兩點(diǎn)：鑒于部分客戶端可以正常調(diào)看白屏站點(diǎn)圖像，說明站點(diǎn)CCTV 系統(tǒng)正常，站點(diǎn)與中心的傳輸存在異常，導(dǎo)致站點(diǎn)某些通道視頻無法上傳。鑒于除白屏站點(diǎn)，其他站點(diǎn)圖像都可以正常顯示于大屏及客戶端。判定中心側(cè)客戶端和中心傳輸輸出板卡正常。

借助于OVS 系統(tǒng)，查看各站點(diǎn)的視頻輸入通道的圖像是否正常，首次全面的統(tǒng)計(jì)二號(hào)線28 個(gè)站點(diǎn)（每個(gè)站點(diǎn)12 路輸入）的輸入通道的情況，統(tǒng)計(jì)出來有6 個(gè)站點(diǎn)存在通道白屏：

根據(jù)系統(tǒng)資料，確認(rèn)的圖標(biāo)是傳輸系統(tǒng)內(nèi)部的圖標(biāo)。結(jié)合H.264 板卡原理分析：模擬視頻接入板卡經(jīng)編碼變?yōu)閿?shù)字信號(hào)傳輸?shù)街行陌蹇ń獯a輸出模擬信號(hào)到大屏，或直接數(shù)字信號(hào)輸出至各客戶端。接著從3 個(gè)方面跟蹤分析：

（1） 確認(rèn)中心CCTV 系統(tǒng)的服務(wù)器控制命令是否正常下發(fā)。

站點(diǎn)端傳輸側(cè)的白屏通道的端口，外接小監(jiān)視器，中心借用客戶端占用此通道，并選擇此站點(diǎn)不通終端顯示，確認(rèn)監(jiān)視器上顯示的畫面根據(jù)客戶端的命令適時(shí)調(diào)整。由此說明中心的控制命令正常下發(fā)站點(diǎn)，由此確定中心側(cè)CCTV 系統(tǒng)與傳輸系統(tǒng)側(cè)軟件接口的正常。

（2） 確認(rèn)H.264 板卡的硬件是否正常：硬件方面：更換故障點(diǎn)及正常站點(diǎn)的板卡，確定圖像的上傳是否受影響，更換后發(fā)現(xiàn)故障點(diǎn)的板卡插入正常站點(diǎn)，圖像是正常上傳，沒有白屏通道。由此可確認(rèn)板卡的硬件是正常的。

（3） 確認(rèn)H.264 板卡的軟件是否正常，軟件方面主要從H.264的彩條測(cè)試的功能和H.264 的板卡內(nèi)部的信息排查。

1 H.264 的彩條測(cè)試功能

通過H.264 自帶的通道測(cè)試功能，發(fā)送彩條，看客戶端能否接受到彩條畫面，選取一個(gè)正常通道和一個(gè)白屏通道對(duì)比測(cè)試，此功能主要的原理圖如圖2 下：

測(cè)試結(jié)果：

正常通道：可以看到彩條顯示，由此確認(rèn)站點(diǎn)的輸入板卡編碼功能和中心的輸出板卡的解碼功能正常。

白屏通道：客戶端無法看到彩條顯示，由于正常通道的測(cè)試情況已經(jīng)證明中心輸出側(cè)板卡的解碼功能正常，只能是站點(diǎn)輸入板卡的編碼部分存在問題

2 H.264 內(nèi)部信息查詢

通過web 界面進(jìn)入H.264 的板卡內(nèi)部，查看各通道和數(shù)據(jù)包情況：

對(duì)比白屏通道與正常通道狀態(tài)

通過OVS 和客戶端配合，調(diào)看1 通道（正常）和8 通道（異常）的視頻，正常通道1 和白屏通道8 的顯示狀態(tài)是一樣，都是streaming。由此無法確定那個(gè)通道異常。

查看h.264 的數(shù)據(jù)包的狀態(tài)

高級(jí)模式下，查看Ethernet 欄，發(fā)現(xiàn)Errorcounters 存在數(shù)據(jù)，說明此視頻板卡傳輸中存在錯(cuò)誤包。

至此明確此類故障點(diǎn)是傳輸系統(tǒng)H.264 的相關(guān)軟件故障。

從上圖3 可以發(fā)現(xiàn)H.264 同時(shí)含有編碼和解碼硬件，說明即可設(shè)置成站點(diǎn)的輸入板卡，也可設(shè)置成中心的輸出板。此次的故障點(diǎn)主要在輸入側(cè)，即編碼側(cè)的故障。

總結(jié)如上的分析，傳輸系統(tǒng)主要有兩點(diǎn)問題：H.264 板卡的輸入端的編碼存在問題，此類板卡存在不穩(wěn)定因素;傳輸?shù)腛MS 存在缺陷，無法偵測(cè)到H.264 的通道的軟件故障。

四、問題整改措施

結(jié)合原廠支持，最終判定問題點(diǎn)可能是H.264 的固態(tài)軟件版本，查看H.264 的firmware 版本，發(fā)現(xiàn)軟件版本非常低，這可能是導(dǎo)致板卡存在不穩(wěn)定的原因，及OMS 無法監(jiān)控到H.264通道故障。建議升級(jí)板卡的firmware.

二號(hào)線是2010 年5 月28 號(hào)開通，已過質(zhì)保期限。協(xié)調(diào)傳輸廠家人員處理時(shí)，廠家要求付費(fèi)升級(jí)，經(jīng)多方舉證，確認(rèn)此類故障是系統(tǒng)缺陷，非設(shè)備個(gè)體或老化故障。原廠人員同意提供firmware 版本免費(fèi)升級(jí)，把h.264 的視頻板卡的軟件版本從2.1.133 升級(jí)成4.0.1.升級(jí)之后。

OTN 廠家對(duì)全線的所有視頻板卡進(jìn)行升級(jí)。升級(jí)之后各通道的白屏現(xiàn)象消失，所有站點(diǎn)通道都可正常上傳圖像。運(yùn)行至今，只有興隆大街的視頻返修板卡出現(xiàn)一次白屏現(xiàn)象，并由OMS 提示出告警：登錄H.264 板卡內(nèi)部，查看相關(guān)數(shù)據(jù)，告警信息比較清晰，除數(shù)據(jù)包中有錯(cuò)誤數(shù)據(jù)， 數(shù)據(jù)通道也顯示出告警信息“stoppederror”：

升級(jí)后，經(jīng)過多年的運(yùn)行，白屏現(xiàn)象只出現(xiàn)過一次，即興隆大街的返修板件。OMS 系統(tǒng)可以偵測(cè)到白屏通道的故障，H.264 內(nèi)部的告警信息也比較直觀。由此證明傳輸系統(tǒng)視頻通道白屏故障原因?yàn)镠.264 的firmware，此次故障研究及相關(guān)的升級(jí)措施，解決此問題，并優(yōu)化傳輸系統(tǒng)OMS 的網(wǎng)管功能。

總結(jié)

經(jīng)過四個(gè)月的持續(xù)處理、跟蹤和近兩年的觀察，確認(rèn)解決傳輸系統(tǒng)的視頻通道白屏的故障。在故障研究過程中，由于知識(shí)結(jié)構(gòu)限制，也曾經(jīng)進(jìn)入誤區(qū)，盲目的認(rèn)為是單板卡的硬件問題，考慮送修，咨詢廠家一塊H.264 的維修費(fèi)用是1.8 萬。后來由于此類問題的不斷出現(xiàn)，結(jié)合中心和站點(diǎn)排查，終于明確原因是系統(tǒng)軟件問題，即傳輸系統(tǒng)視頻板卡本身的缺陷。以此為切入點(diǎn)，免費(fèi)提供新版本，升級(jí)板件的軟件，節(jié)約系統(tǒng)的升級(jí)費(fèi)用同時(shí)避免不必要的板卡維修費(fèi)用。