直播技术细节概要
直播技术细节概要
问题
- 功能点
- 平台
- 转码
- 截图
- 水印
- 剪辑
- 视音抽取
- 视频转GIF
- 多码率
- 单聊
- 群聊
- 文本, 表情, 图片
- 语音
- 人脸美化
- 技术细节
- 录制
- 编码
- 网络传输
- 解码
- 播放
- 性能指标
- 网络
- 协议
- 编解码
- 移动终端
- 弱网
- 低延迟, 秒开
- 接入推荐人日
- 费用
UCloud直播云实现接入网络优化的技术细节
全局负载均衡-就近接入
HTTPDNS
- 可精准获得用户端的IP
- 可避免DNS解析劫持
BGP中转架构-最短传输路径
BGP即Border Gateway Protocol (边界网关协议)
- 南电信北联通
- 路程要绕远,网络延迟高且不稳定
- 高峰期拥堵,导致直播流卡顿
- 直播当中每个包的延时可以缩短100ms
直播应用层协议及传输层协议的选择以及对直播体验影响的分析
直播协议的选择
国内常见公开的直播协议有几个:RTMP, HLS, HDL(HTTP-FLV), RTP
RTMP
- 开源软件和开源库的支持稳定完整
- 播放端安装率高
- 内容延迟在2~5秒
HTTP-FLV
即使用HTTP协议流式的传输媒体内容
HLS
即Http Live Streaming,是由苹果提出基于HTTP的流媒体传输协议, 基于HLS的直播流URL是一个m3u8的文件,里面包含了最近若干个小视频TS
- HTML5可以直接打开播放
- 是5~7秒的延迟
RTP
即Real-time Transport Protocol,用于Internet上针对多媒体数据流的一种传输层协议
- RTP在视频监控、视频会议、IP电话上有广泛的应用
- 内容实时性强
- 默认是使用UDP协议来传输数据
在传输直播流媒体过程中的内容缓存与传输策略优化细节原理
I帧
表示关键帧.解码时只需要本帧数据就可以完成
P帧
表示这一帧跟之前的一个关键帧(或P帧)的差别
B帧
双向差别帧. B帧压缩率高,但是编解码时会比较耗费CPU,而且在直播中可能会增加直播延时,因此在移动端上一般不使用B帧。
延迟与卡顿的折中
直播的延时与卡顿是分析直播业务质量时,非常关注的两项指标。互动直播的场景对延时非常敏感,新闻体育类直播则更加关注播放的流畅度。
- 服务端提供灵活的配置策略
- 服务端对所有连接的网络情况进行智能检测
丢包策略
- 正确判断何时需要进行丢包
- 如何丢包以使得对观众的播放体验影响最小
客户端的优化
解析优化
本机缓存域名的解析结果,对域名进行预解析,每次需要直播推流和播放的时候不再需要再进行DNS过程。此处节省几十到几百毫秒的打开延迟
播放优化
直播播放器的相关技术点有:直播延时、首屏时间(指从开始播放到第一次看到画面的时间)、音视频同步、软解码、硬解码
播放步骤描述
- 根据协议类型(如RTMP、RTP、RTSP、HTTP等),与服务器建立连接并接收数据;
- 解析二进制数据,从中找到相关流信息;
- 根据不同的封装格式(如FLV、TS)解复用(demux);
- 分别得到已编码的H.264视频数据和AAC音频数据;
- 使用硬解码(对应系统的API)或软解码(FFMpeg)来解压音视频数据;
- 经过解码后得到原始的视频数据(YUV)和音频数据(AAC);
- 因为音频和视频解码是分开的,所以我们得把它们同步起来,否则会出现音视频不同步的现象,比如别人说话会跟口型对不上;
- 最后把同步的音频数据送到耳机或外放,视频数据送到屏幕上显示。
首屏时间优化
- 通过预设解码器类型,省去探测文件类型时间
- 缩小视频数据探测范围,意味着减少了需要下载的数据量
延时优化
- 视频缓存策略
- 下载数据探测池技术
推流优化
- 适当的Qos(Quality of Service,服务质量)策略
- 合理的关键帧配置
软硬编解选择
推荐Andorid4.3(API18)或以上使用硬编,以下版本使用软编;iOS使用全硬编方案;
播放解码
Andorid、iOS播放器都使用软解码方案,经过我们和大量客户的测试以及总结,虽然牺牲了功耗,但是在部分细节方面表现会较优,且可控性强,兼容性也强,出错情况少,推荐使用
云端机型及网络适配
终端在推流、播放前会获取通过协议上报当前的机型配置、网络情况、IP信息。云端会返回一个已最适合的编解码策略配置:走软编还是硬编、各项参数的配置,就近推流服务的IP,就近播放服务的IP。 终端获取一次即可,不需要每次推流、播放前都去获取一次。