直播疑难杂症排查(7)— 黑屏、花屏、闪屏问题

简介:

首先我们要明白,黑屏、花屏、闪屏等问题,可能是推流端的问题,也可能是播放器的问题,遇到这些现象,我们要第一时间用别的播放器(如 VLC,ffplay)试试,如果都出现同样的问题,那么多半是流本身的问题了,反之,则很可能是播放器的问题。


1.  播放黑屏


现象:画面是黑的,没有图像,但是有声音。


1.1 主播端摄像头权限问题


无论 Android 还是 iOS,App 使用摄像头都是需要申请授权的,特别是 Android 6.0 以后,如果 App 层面不做专门的处理的话,很可能出现摄像头权限被禁用的情况。


如果 App 没有获取到摄像头权限,视频就无法采集成功,从而导致推出来的流只有音频数据。


解决方案:


App 层面肯定要小心处理权限问题,检测到未获取相应权限则禁止开播,或者反复提示主播授予权限。另外,可以询问出现问题的主播是否有摄像头预览画面,如果 App 没有获得权限的话,是没有预览画面的。


1.2 主播端编码失败


视频数据采集到后,下一步就是经过编码器,由于参数配置或者某些机型的硬编兼容性问题,很可能数据送入编码器后,编码失败,并无输出,从而导致没有视频数据送入到推流模块。


解决方案:


一般推流 SDK 都会统计推流的实时视频帧率,CDN 服务端也会有一些帧率监控,因此,如果发现这些统计得到的推流帧率为 0,同时又确定不是没有采集到数据,那么多半是编码器的原因,可以想办法查看下该机型的日志看看具体的报错信息。


1.3 视频解码失败


前面的文章有提到过,当播放器遇到不支持的视频格式,或者数据内容/格式异常,则会解码失败,从而导致无解码视频输出。


针对不支持的格式:


- 要提前了解播放器本身支持哪些音视频格式,如 H.264,mp4v,aac 等等,避免播放不支持的格式

- 播放器本身遇到的硬解或者软解失败,应该有日志报错,或者抛出异常给应用层提示用户


针对视频数据内容错误:


需要分析码流文件本身,常见的数据内容错误导致的解码失败有如下几种:


- 送入解码器的帧数据不完整

- H.264 的视频码流,缺失了 SPS,PPS 等必要的信息头

- iOS 的 VideoToolbox 解码,只支持 avcc 方式打包的 H.264 数据

- 部分 Android 机型硬编出来的数据有额外的 naul 头

- 其他等等


1.4 码流的前半段只有音频没有视频


这种情况,多半出自 HLS 切片产生的码流,当主播用同一个地址推流,前半段只推了音频(可能是摄像头权限被禁用,也可能是选择了纯音频推流等等),然后接着又同时推了音视频流,那么,服务端 HLS 切片产生的文件,就会出现这样的情况。


基于 ffmpeg 的播放器,会在解析完视频头后初始化解码器,因此,对于这种码流,往往会出现仅有音频或者仅有视频播放的情况。


解决方案


从 App 端尽可能避免出现这种使用姿势,修改播放器的代码,对这种码流进行兼容处理。


2.  播放花屏/绿屏


现象:播放画面出现图像紊乱,大面积的异常颜色的方块图,或者绿屏现象


1.1 丢失参考帧导致的


一般 H.264 码流有 I、B、P 三种帧类型,I 帧是关键帧,B 帧是双向预测内插编码帧,P 帧是前向预测编码帧。


I 帧由于是帧内压缩,因此可以独立解码播放,而 B 帧,一旦丢失了 I 帧或者后面的 P 帧,则会解码失败,而 P 帧一旦丢失了前面的 I/B/P 帧,也会导致解码失败。


对于丢失了参考帧而导致的解码失败,一般就会出现花屏的现象,花屏的严重程度依赖于丢失的参考帧对即将解码的帧的重要程度。


那么,什么情况下会丢失参考帧呢 ?


首先,推流/播放的代码层面,需要注意,不要丢弃编码后、解码前的视频帧数据,不过实际场景中,遇到下面的情况,难免还是会产生丢帧:


- 网络不好,编码后的数据发不出去

- 系统低内存,队列里面无法承受更多的帧数据


因此,在这些极端的情况下,不得不丢帧的话,最合理的策略就应该是一次丢一整个 GOP,即:一旦开始丢了一个 I 帧,那么在遇到下一个 I 帧之前的所有视频帧,均丢弃掉,这样即可有效避免播放器端产生解码花屏。


1.2 播放器没有从关键帧开始解码


原理依然如上面所述,如果不从关键帧开始解码,则必然会由于丢失了参考信息而导致解码花屏。

因此,播放器,无论是首播,还是断网重连后,都应该判断第一帧视频是否是关键帧,如果不是,则应该等到第一个关键帧到达之后再送入解码器。


基于 ffmpeg 的播放器,如何判断关键帧,可以参考我的这篇文章:《FFMPEG Tips (3) 如何读取每一帧的信息》


1.3 码流中视频尺寸发生变化


很多直播 App,横屏直播和竖屏直播,使用的是不同的推流尺寸 ,当主播由竖屏推流改为横屏推流,同时又不改变推流地址的话,观众端拉到的流就会出现中间发生了视频尺寸的变化,比如:从 848 x 480 变成了 1280 x 720 等等。


播放器需要实时检测,如果发现视频尺寸发生了变化,则需要重置解码器以及相关逻辑,否则容易出现解码花屏或者出现内存越界等异常。


1.4 硬编硬解的兼容性问题


当然,如果使用的是 Android 硬编硬解,则难免会遇到一些比较坑爹的手机,硬编硬解没有失败报错,但是输出的图像确实异常的情况。


Android 硬编硬解的兼容性问题,代码上小心仔细,充分考虑机型的兼容性,不轻易写死任何参数,剩下能做的就是靠白名单/黑名单了。


1.5 推流端图像尺寸和格式处理不当


图像的格式和尺寸,都是非常重要的参数,一定要严格配置正确。


比如:如果采集到的视频是 NV21 ,编码器只支持 I420,那么编码出来的图像自然会出现颜色问题。


比如:在一些场景切换的过程中,前后摄像头切换,视频的尺寸可能发生了变化,但是剪裁、处理、编码模块没有相应的修改尺寸,那么,也会出现各种视频错乱的现象。


3.  播放闪屏


闪屏问题,从根源来看,就是播放的过程中,出现了两种不同的画面来回切换,从而看起来像 “闪屏”,比如,黑白两张图片交替渲染。下面我们再来看看直播场景下,什么原因会引发该现象。


3.1 播放器缓冲机制原因


网络不好的时候,播放器会频繁缓冲,曾遇到过一种案例,就是某直播 App 应用,在缓冲的时候,使用了一张广告图片,在某种极端弱网情况下,由于频繁缓冲,导致真实的播放画面和广告图片来回快速切换,导致闪屏现象。


这个情况是完全可以从播放器的缓冲策略上避免的,每次缓冲后,不要收到一帧后就立即渲染,而是适当地多缓冲一些数据,再发送缓冲结束的消息,从而可以频繁 ms 级别的缓冲切换产生的闪屏。


3.2 推流端的原因


推流端产生闪屏的流,往往发生在有画面合成的代码模块,比如:叠加水印、摄像头/图片切换推流、连麦合流等等。


画面的合成,一定要铭记一点,任何情况下,都要避免出现,有合成/没有合成 两种画面的交替。



本文转自 Jhuster 51CTO博客,原文链接:http://blog.51cto.com/ticktick/1931846,如需转载请自行联系原作者

相关文章
|
21天前
|
Web App开发 缓存 安全
电脑屏幕上的广告太多怎么解决?
安装一个广告拦截扩展或软件,如AdBlock Plus、uBlock Origin等。这些工具可以帮助拦截网页广告,在浏览器的扩展商店中搜索并添加这些扩展。例如,在Chrome中,你可以访问Chrome网上应用店来安装。
|
2月前
|
弹性计算 Windows
为什么雾锁王国游戏画面卡顿、回退?
本文介绍如何查看服务器负载及购买自定义配置的服务器。
|
10月前
|
Web App开发 存储 缓存
我是如何优化弹窗拖拽卡顿的?内附排查和优化过程
我是如何优化弹窗拖拽卡顿的?内附排查和优化过程
170 0
我在B站录制视频啦——RayCaster原理实现
前言 之前做了一期关于B站的视频,反响效果还不错。感谢各位小伙伴的支持,但是我是个追求原理的工程师, three.js 射线检测到底是怎么去实现的,我🤔还是决定用简短的时间,带大家回顾下。到底是怎么实现的,本篇文章阅读大概5分钟你就能掌握。 图片 B站🔍喜欢图形的Fly 背景 如何知道鼠标所在位置是否存在图形,转换问题角度来看可以看做从鼠标所处位置发出一根射线,这根射线是否与三角形相交,换而言之即为「鼠标所在位置在一个三角形内是否存在投影的一点?」 图片 投影图 思路解析 根据上述描述可知,我们的真实需求是需要判断鼠标所在位置是否在三角形内,这里我们介绍一个最快的方法,我们可以以鼠标
我在B站录制视频啦——RayCaster原理实现
软件的卡顿与卡死,意思是不同的
软件的卡顿与卡死,意思是不同的
556 0
|
运维 监控 算法
优酷技术实践:自动检测及修复视频播放异常
音视频播放器的工作内容可以描述为:根据流媒体协议还原音视频内容的过程。在还原的 每个阶段都存在丢失精度的风险,而最终呈现的结果也是一个主观的内容,这就给播放器输出结果的评估引入了一些痛点问题。
优酷技术实践:自动检测及修复视频播放异常