所选语种没有对应资源,请选择:

本站点使用Cookies,继续浏览表示您同意我们使用Cookies。Cookies和隐私政策>

提示

尊敬的用户,您的IE浏览器版本过低,为获取更好的浏览体验,请升级您的IE浏览器。

升级

CloudEC V600R019C00 典型故障处理(企业入驻式,融合会议)

评分并提供意见反馈 :
华为采用机器翻译与人工审校相结合的方式将此文档翻译成不同语言,希望能帮助您更容易理解此文档的内容。 请注意:即使是最好的机器翻译,其准确度也不及专业翻译人员的水平。 华为对于翻译的准确性不承担任何责任,并建议您参考英文文档(已提供链接)。
视频无画面/凝固

视频无画面/凝固

现象以及可能的原因

现象:在多方会议或者点对点通话中,特定的会场,看不到其他会场的画面,或不能被其他会场看到,或看到的画面出现凝固。

终端、传输网以及媒体处理设备的异常都可能导致会议无画面,常见的问题根因分别描述如下:

【终端问题】:包括会议发言方终端误操作导致摄像头关闭;会议发言方终端软硬件故障,没有视频输入,比如摄像头故障;或者终端/网关发送的帧异常导致解码失败。

【传输网故障】:包括会议发言方发送给MCU的视频报文丢失;或者反过来,MCU发送给会议接收方终端的视频报文丢失。

【媒体设备故障】:包括MCU对I帧请求没有响应;MCU软硬件故障(设备重启等);SBC丢失I帧/I帧请求。

处理思路

对于会议无画面/画面凝固的处理思路,基于SessionInsight上采集的指标,从接收方终端起始,沿着媒体处理的方向反方向逐段排查确认,最终达到问题定位的目的。

处理步骤

图1-30 视频无画面/凝固问题分析
P1,当前会场看其他会场视频无画面/凝固

【判断规则】:

当前会场看其他会场视频无画面/凝固,通过当前会场接收方向的接收帧率和解码帧率来判断:当由于网络异常或者SBC/MCU设备原因等导致最终没有有效的视频报文输出时,用户最终输出解码帧率为0。若解码帧率为0而接收帧率为有效值(1~30),则可以判断为未正常解码导致的无画面/凝固。

【示例说明】:

图1 终端视频网络接收包数&解码帧率指标所示,打开接收方视频模块的网络接收包数和解码帧率,查看故障时间段的解码帧率,帧率降低到0fps,说明解码画面出现凝固/无画面,这种情况下,当前会场看其他会场视频无画面/凝固,具体造成无画面/凝固的原因需要进一步分析(具体请参见P2,终端收到的报文有丢包~P9,SBC丢失I帧/I帧请求)。

图1-31 终端视频网络接收包数&解码帧率指标
P2,终端收到的报文有丢包

【判断规则】:

当前会场看其他会场视频无画面/凝固,通过当前会场接收方向的接收帧率和解码帧率来判断:当由于网络异常或者SBC/MCU设备原因等导致终端没有收到视频报文时,用户接收帧率和解码帧率均为0。对应时间段内终端接收报文没有增加(未收到视频报文)。

【示例说明】:

图1-32所示,打开MCU侧视频编码帧数和发送包数统计,这两个数值持续增加,说明MCU侧编码发送正常。如图1-33所示,打开接收方视频模块的网络接收包数和解码帧率,查看故障时间段的解码帧率,帧率降低到0fps,说明解码画面出现凝固/无画面,该时间段内网络接收包数没有增加,说明接收方未收到视频报文。这种情况下,当前会场看其他会场视频无画面/凝固,则可以判断是端侧未收到视频报文导致的视频无画面/凝固。

图1-32 MCU视频编码帧数&发送包数指标
图1-33 终端视频接收包数&解码帧率指标

具体导致接收端未收到视频报文的原因,可能是MCU到SBC的报文全部丢失、SBC未转发视频报文或SBC到终端的报文全部丢失,需要进一步分析(具体请参见P3,MCU到SBC的报文有丢包P13,SBC转发报文全部丢失P2,终端收到的报文有丢包)。

P6,终端收到的报文异常

【判断规则】:

当前会场看其他会场视频无画面/凝固,通过当前会场接收方向的接收帧率和解码帧率来判断:当终端收到的报文异常时,接收方解码帧率为0。对应时间段内终端接收报文数正常增加,但解码异常次数持续增加。

【示例说明】:

图1-34所示,打开接收方视频模块的接收帧率和解码帧率,查看故障时间段的解码帧率,帧率降低到0fps,说明解码画面出现凝固/无画面,该时间段内接收帧率正常,网络丢包率为0(无丢包)。这种情况下,当前会场看其他会场视频无画面/凝固,则可以判断是端侧收到的报文异常导致的视频无画面/凝固。该场景下,可以进一步查看网络接收包数正常增加,而解码异常次数持续上升。

图1-34 终端视频解码帧率&接收帧率指标
P7,MCU对I帧请求没有响应

【判断规则】:

当前会场看其他会场视频无画面/凝固,通过当前会场接收方向的接收帧率和解码帧率来判断:MCU对I帧请求没有响应时,接收方解码帧率为0。对应时间段内终端接收报文数正常增加,由于丢包等原因造成端侧持续发出I帧请求,但MCU未响应该请求(MCU编码发送的I帧数没有增加)。

【示例说明】:

图1-35所示,打开接收方视频解码模块的I帧请求数(ReqIFframes(Decoding)),故障周期内I帧请求数持续增加。同时,如图1-36所示,查看MCU侧视频编码I帧数(Iframe(Coding)),该数值未持续增加。这种情况下,当前会场看其他会场视频无画面/凝固,则可以判断是MCU对I帧请求没有响应导致的视频无画面/凝固。该场景下,可以进一步查看MCU侧接收到的I帧请求持续增加(IframeReqs(Coding))。

图1-35 终端视频解码请求I帧数指标
图1-36 MCU视频编码I帧数&接收I帧请求数指标
P8,MCU软硬件故障

【判断规则】:

当前会场看其他会场视频无画面/凝固,通过当前会场接收方向的接收包数、接收帧率和解码帧率来判断:当MCU软硬件故障时,会议多个接收方均未收到视频报文,接收帧率和解码帧率为0。

【示例说明】:

图1-37所示,打开多个接收方视频模块的接收包数和丢包率(丢包数),查看各方故障时间段的接收包数和丢包数,从某时刻起接收包数不再增加说明MCU未向各接收方发送视频报文。这种情况下,当前会场看其他会场视频无画面/凝固,则可以判断是MCU软硬件故障导致的视频无画面/凝固。该场景下,可以进一步查看MCU侧是否正常发送视频报文。

图1-37 终端视频接收包数&丢包数指标
P9,SBC丢失I帧/I帧请求

【判断规则】:

当前会场看其他会场视频无画面/凝固,通过当前会场接收方向的接收帧率和解码帧率来判断:当SBC丢失I帧/I帧请求,接收方解码I帧数量没变化。对应时间段内终端接收报文数正常增加,接收端持续发送I帧请求,但接收到的视频码流中I帧数没有增加导致解码失败。

【示例说明】:

图1-38所示,查询接收终端的视频解码I帧数量与I帧请求数量,当终端持续请求I帧,但是解码I帧数量没有变化时,说明中间网元将I帧请求丢失了。

图1-38 终端视频解码I帧数&I帧请求数指标
P10,其他会场看当前会场视频无画面/凝固

【判断规则】:

其他会场看当前会场视频无画面/凝固,通过查看MCU上当前会场的接收帧率和解码帧率来判断:当由于网络异常或者端侧摄像头异常等导致MCU未收到有效视频报文时,MCU上该会场解码帧率为0。若解码帧率为0而接收帧率为有效值(1~30),则可以判断为未正常解码导致的无画面/凝固。具体造成无画面/凝固的原因需要进一步分析(P11,MCU收到的报文有丢包P18,MCU未开启无码流检测)。

P11,MCU收到的报文有丢包

【判断规则】:

其他会场看当前会场视频无画面/凝固,通过查看MCU上当前会场的接收帧率和解码帧率来判断:当MCU未收到视频报文时,用户接收帧率和解码帧率均为0。对应时间段内MCU上接收报文没有增加(未收到视频报文)。

【示例说明】:

图1-39所示,打开端侧视频发送帧数/包数统计,发现端侧编码发送正常。如图1-40所示,打开MCU上当前会场视频模块的网络接收包数和解码帧率,查看故障时间段的解码帧率,帧率降低到0fps,说明解码画面出现凝固/无画面,该时间段内网络接收包数没有增加,说明MCU侧未收到视频报文。这种情况下,其他会场看当前会场视频无画面/凝固,则可以判断是MCU未收到视频报文导致的视频无画面/凝固。

图1-39 终端视频发送帧数指标
图1-40 MCU视频接收包数&解码帧率指标

具体导致MCU未收到视频报文的原因,可能是终端到SBC的报文全部丢失、SBC未转发视频报文或SBC到MCU的报文全部丢失,需要进一步分析(P8,终端到SBC的报文有丢包P13,SBC转发报文全部丢失P7,MCU收到的报文有丢包)。

P13,SBC转发报文全部丢失

【判断规则】:

其他会场看当前会场视频无画面/凝固,通过查看MCU上当前会场的接收帧率和解码帧率来判断:当MCU未收到视频报文时,用户接收帧率和解码帧率均为0。对应时间段内MCU上接收报文没有增加(未收到视频报文)。此时视频源端发送正常。

【示例说明】:

图1-41所示,打开端侧编码模块发送帧数统计(Send Frames),可以看到发送帧数持续增加(正常发送)。然后打开MCU上当前会场网络接收模块的接收包数和解码帧率,如图1-42所示,查看故障时间段的解码帧率,帧率降低到0fps,说明解码画面出现凝固/无画面,该时间段内网络接收包数没有增加,说明MCU侧未收到视频报文。这种情况下,其他会场看当前会场视频无画面/凝固,则可以判断是SBC转发报文全部丢失导致的视频无画面/凝固。

图1-41 终端视频发送帧数指标
图1-42 MCU视频接收包数&解码帧率指标
P15,MCU收到的报文异常

【判断规则】:

其他会场看当前会场视频无画面/凝固,通过查看MCU上当前会场的接收帧率和解码帧率来判断:当MCU收到的报文异常时,MCU对应该会场接收解码帧率为0。对应时间段内终端接收报文数正常增加,但解码异常次数持续增加。

【示例说明】:

图1-43所示,打开MCU接收方视频模块的接收帧率和解码帧率,查看故障时间段的解码帧率,帧率降低到0fps,说明解码画面出现凝固/无画面,该时间段内接收帧率正常,网络丢包率为0(无丢包)。这种情况下,当前会场看其他会场视频无画面/凝固,则可以判断是MCU收到的报文异常导致的视频无画面/凝固。该场景下,可以进一步查看网络接收包数正常增加,而解码异常次数持续上升。

图1-43 MCU视频接收包数&解码帧率指标
P16,终端摄像头故障

【判断规则】:

其他会场看当前会场视频无画面/凝固,通过查看当前会场端侧的采集帧率和编码帧率、编码字节数来判断:当终端摄像头故障时,编码字节数会明显降低,采集帧率和编码帧率正常。

【示例说明】:

图1-44所示,打开发送方视频模块的采集总帧数(OutputFrames(Collection))和编码字节数(Bytes(Coding)),在故障时间段的编码字节数上升幅度明显减少,而对应的采集帧率和采集总帧数保持恒定,说明画面复杂度降低(黑屏或无画面)。这种情况下,其他会场看当前会场视频无画面/凝固,则可以判断是终端摄像头故障。

图1-44 终端视频采集总帧数&编码字节数指标
P17,SBC丢失I帧/I帧请求

【判断规则】:

其他会场看当前会场视频无画面/凝固,通过当前会场接收方向的接收帧率和解码帧率来判断:当SBC丢失I帧/I帧请求,MCU接收方向解码I帧数量无变化。对应时间段内MCU接收报文数正常增加,MCU侧持续发送I帧请求,但接收到的视频码流中I帧数没有增加导致解码失败。

【示例说明】:

图1-45所示,查询MCU的视频解码I帧数量与I帧请求数量,当MCU持续请求I帧,但是解码I帧数量没有变化时,说明中间网元将I帧请求丢失了。

图1-45 MCU视频解码I帧数量&I帧请求数量指标
P18,MCU未开启无码流检测

【判断规则】:

其他会场看当前会场视频无画面/凝固,通过查看MCU上当前会场的接收帧率和解码帧率来判断:当MCU未开启无码流检测时,终端离会后MCU未挂断该会场,导致其他会场观看该会场画面凝固。

【示例说明】:

图1-46所示,打开MCU上当前会场视频模块的网络接收包数和解码帧率,查看故障时间段的接收帧率和解码帧率,都降低到0fps,说明解码画面出现凝固/无画面,该时间段内网络接收包数没有增加,说明MCU侧未收到视频报文。这种情况下,其他会场看当前会场视频无画面/凝固,则可以判断是MCU未开启无码流检测,终端离会后MCU未挂断该会场导致的视频无画面/凝固。

图1-46 MCU视频接收包数&解码帧率指标
翻译
下载文档
更新时间:2019-08-07

文档编号:EDOC1100059052

浏览量:2861

下载量:28

平均得分:
本文档适用于这些产品
相关版本
相关文档
Share
上一页 下一页