传输系统视频通道白屏问题研究
来源:用户上传
作者:
摘 要：CCTV系统通过传输系统的H.264视频板卡，汇集各个站点图像供调度人员和行值人员调看及大屏显示。二号线传输的视频板卡编码过程中出现异常，导致某些站点的图像上传至控制中心客户端时显示为白色画面中间有个图标，为问题状态，此问题简称白屏问题。经过多次排查，确认传输系统视频板卡某些通道的存在问题。此问题最终定位为视频板卡H.264的软件BUG，需升级所有H.264板卡的固态软件firmware。板卡升级解决白屏问题，并优化传输系统的网管OMS的告警提示。
关键词：CCTV系统; OTN系统; OVS系统; OMS系统
南京地铁二号线传输系统采用的是OTNX3M2.5G设备，是通信等相关专业的组网设备，传输站间的视频、语音、监控等数据和控制信号。CCTV系统主要用于监视地铁内部公共场所的运行、检修和售检票作业情况、变电所设备室设备运行情况，提高行车指挥透明度的辅助通信工具，借助于传输系统的环网供调度人员，行车值班人员使用。线路開通多年后，多个站点发生控制中心调看某些车站视频图像，图像显示为白色，中间有个小图标，为问题状态，后续把此类故障归结为传输系统视频通道白屏问题。
一、传输系统与CCTV 系统架构
CCTV系统借用传输系统的视频板卡，上传各个站点的视频图像到控制中心供大屏和客户端;并通过以太网通道，监控全线的CCTV系统设备状态，并下发中心的操作命令。两者之间的联动关系如图1所示：
二、白屏问题排查
此类问题多次发生，重点介绍12 月调度人员反应行调2客户端无法调看羊山公园图像的排查过程。本次故障从中心与站点的两侧排查。
（一）中心排查
网管通信维护人员赶至现场处理，通过多个客户端对比排查，确认故障现象如下：行调2 客户端“无法调看”羊山公园的所有图像，羊山公园所有摄像机的画面显示的图像，但可以调看其他站如马群、经天路等站点图像。
行调1 客户端“可以”正常调看羊山公园所有图像。网管客户端“可以”调看羊山公园站的所有图像及其他站点图像。
所有客户端都释放，都不调看羊山公园站图像。改变调看顺序，利用行调2 首先调看，测试情况如下：行调2 客户端调看羊山公园站图像，发现“可以”调看羊山公园站的所有图像。停留在羊山公园画面。
行调1 客户端调看羊山公园站图像，发现不可以调看羊山公园站的图像，所有画面的显示都变成图2 的图标。停留在羊山公园站调看状态。
网管客户端调看羊山公园站图像，各个摄像机终端画面正常。
经过多次改变调看顺序测试后，发现三个客户端同时调看羊山公园站画面时，顺序为“第二客户端”是无法调看画面，显示都为图2。如上面测试中，第二客户端当时为行调1 客户端。
在此过程中，网管人员查看CCTV 网管和传输系统网管，确认都没有告警指示。
（二）站点排查
正线通信维护员现场查看CCTV 系统矩阵输出端图像，发现上传传输系统的12 路图像，有两种显示：正常视频图像及黑屏，没有如的图标显示。
查看传输系统H.264 板卡侧的12 路视频图像，现象与矩阵侧相同，H.264 板卡各通道的指示灯显示也正常。至此故障处理进入迷茫区域，有故障现象，确无法确认故障点。初步定义为软件故障，为使故障尽快恢复，只能小范围的依次重启相关联的矩阵板卡及H.264 板卡。重启矩阵后故障现象依旧;接着重启H.264 板卡;故障恢复。故把故障点定位在H.264 板卡。
接下来的2 个月中，多个站依次出现此类现象的故障，虽然重启后恢复，但此类故障没有消失迹象，却有爆发扩张的迹象。这给通信的维保和调度人员的工作都带来很大的困扰。
三、白屏问题原因分析
通过两个月故障的处理与统计，确定此类故障是系统级的故障，不是单点故障，必须从根本上解决此类故障，不能单纯的从板卡重启方面处理。
梳理系统原理，参考图1 确认视频数据上传涉及CCTV 自身的系统及传输系统。根据前面的故障现象可以确定两点：鉴于部分客户端可以正常调看白屏站点图像，说明站点CCTV 系统正常，站点与中心的传输存在异常，导致站点某些通道视频无法上传。鉴于除白屏站点，其他站点图像都可以正常显示于大屏及客户端。判定中心侧客户端和中心传输输出板卡正常。
借助于OVS 系统，查看各站点的视频输入通道的图像是否正常，首次全面的统计二号线28 个站点（每个站点12 路输入）的输入通道的情况，统计出来有6 个站点存在通道白屏：
根据系统资料，确认的图标是传输系统内部的图标。结合H.264 板卡原理分析：模拟视频接入板卡经编码变为数字信号传输到中心板卡解码输出模拟信号到大屏，或直接数字信号输出至各客户端。接着从3 个方面跟踪分析：
（1） 确认中心CCTV 系统的服务器控制命令是否正常下发。
站点端传输侧的白屏通道的端口，外接小监视器，中心借用客户端占用此通道，并选择此站点不通终端显示，确认监视器上显示的画面根据客户端的命令适时调整。由此说明中心的控制命令正常下发站点，由此确定中心侧CCTV 系统与传输系统侧软件接口的正常。
（2） 确认H.264 板卡的硬件是否正常：硬件方面：更换故障点及正常站点的板卡，确定图像的上传是否受影响，更换后发现故障点的板卡插入正常站点，图像是正常上传，没有白屏通道。由此可确认板卡的硬件是正常的。
（3） 确认H.264 板卡的软件是否正常，软件方面主要从H.264的彩条测试的功能和H.264 的板卡内部的信息排查。
1 H.264 的彩条测试功能
通过H.264 自带的通道测试功能，发送彩条，看客户端能否接受到彩条画面，选取一个正常通道和一个白屏通道对比测试，此功能主要的原理图如图2 下： 测试结果：
正常通道：可以看到彩条显示，由此确认站点的输入板卡编码功能和中心的输出板卡的解码功能正常。
白屏通道：客户端无法看到彩条显示，由于正常通道的测试情况已经证明中心输出侧板卡的解码功能正常，只能是站点输入板卡的编码部分存在问题
2 H.264 内部信息查询
通过web 界面进入H.264 的板卡内部，查看各通道和数据包情况：
对比白屏通道与正常通道状态
通过OVS 和客户端配合，调看1 通道（正常）和8 通道（异常）的视频，正常通道1 和白屏通道8 的显示状态是一样，都是streaming。由此无法确定那个通道异常。
查看h.264 的数据包的状态
高级模式下，查看Ethernet 栏，发现Errorcounters 存在数据，说明此视频板卡传输中存在错误包。
至此明确此类故障点是传输系统H.264 的相关软件故障。
从上图3 可以发现H.264 同时含有编码和解码硬件，说明即可设置成站点的输入板卡，也可设置成中心的输出板。此次的故障点主要在输入侧，即编码侧的故障。
总结如上的分析，传输系统主要有两点问题：H.264 板卡的输入端的编码存在问题，此类板卡存在不稳定因素;传输的OMS 存在缺陷，无法侦测到H.264 的通道的软件故障。
四、问题整改措施
结合原厂支持，最终判定问题点可能是H.264 的固态软件版本，查看H.264 的firmware 版本，发现软件版本非常低，这可能是导致板卡存在不稳定的原因，及OMS 无法监控到H.264通道故障。建议升级板卡的firmware.
二号线是2010 年5 月28 号开通，已过质保期限。协调传输厂家人员处理时，厂家要求付费升级，经多方举证，确认此类故障是系统缺陷，非设备个体或老化故障。原厂人员同意提供firmware 版本免费升级，把h.264 的视频板卡的软件版本从2.1.133 升级成4.0.1.升级之后。
OTN 厂家对全线的所有视频板卡进行升级。升级之后各通道的白屏现象消失，所有站点通道都可正常上传图像。运行至今，只有兴隆大街的视频返修板卡出现一次白屏现象，并由OMS 提示出告警：登录H.264 板卡内部，查看相关数据，告警信息比较清晰，除数据包中有错误数据， 数据通道也显示出告警信息“stoppederror”：
升级后，经过多年的运行，白屏现象只出现过一次，即兴隆大街的返修板件。OMS 系统可以侦测到白屏通道的故障，H.264 内部的告警信息也比较直观。由此证明传输系统视频通道白屏故障原因为H.264 的firmware，此次故障研究及相关的升级措施，解决此问题，并优化传输系统OMS 的网管功能。
总结
经过四个月的持续处理、跟踪和近两年的观察，确认解决传输系统的视频通道白屏的故障。在故障研究过程中，由于知识結构限制，也曾经进入误区，盲目的认为是单板卡的硬件问题，考虑送修，咨询厂家一块H.264 的维修费用是1.8 万。后来由于此类问题的不断出现，结合中心和站点排查，终于明确原因是系统软件问题，即传输系统视频板卡本身的缺陷。以此为切入点，免费提供新版本，升级板件的软件，节约系统的升级费用同时避免不必要的板卡维修费用。
转载注明来源:https://www.xzbu.com/1/view-15249252.htm
