找回密码
 立即注册
LiveVideoStack 首页 资讯 查看内容
  • QQ空间
  • 回复
  • 收藏

展望2018音视频技术:AV1 AI 区块链 WebRTC(一)

2018-1-3 17:46

编者按:音视频技术的历史可能要追溯到19世纪末——特斯拉与爱迪生的伟大时代。直到今天,他们的发明依然伴随我们生活的每时每刻。2018年音视频技术将有哪些突破?来自学霸君的资深架构师袁荣喜从编解码器、客户端、传输网络、动态缓冲区以及媒体处理技术几个方面解析实时音视频技术。展望2018,区块链、AI、WebRTC、AV1将成为关键词。


本文由LiveVideoStack与《程序员》杂志联合策划,并将在《程序员》杂志2018年1月刊发布。最后,感谢《程序员》杂志主编卢鸫翔的建议与高效配合。


文 / 袁荣喜

策划 / LiveVideoStack,《程序员》杂志

责编 / 卢鸫翔


实时音视频技术是源于早期的VoIP通信,随着后来互联网的发展进程,这项技术2003年被Skype引入到PC桌面系统,开启了整个实时音视频技术新纪元。经过15年的进化,基于PC上的实时音视频技术日渐成熟,也涌现了像WebRTC这样的开源项目。但随着近几年移动互联网和4G的兴起,实时音视频领域有了更广泛的应用,引来了新的技术难题和挑战。经过2016年直播大战后,音视频应用得到了用户的认可,直接促成了2017年实时音视频应用的大爆发,在娱乐方面出现了像狼人杀、陌生人视频社交、在线抓娃娃等风口;在协作应用领域出现了Slack和Zoom等多人远程协作应用;在行业应用上也有很大的突破,例如像VIPKID、学霸君1V1等强劲的在线教育产品。在苹果8月份宣布新一代iOS浏览器Safari支持WebRTC后,实时音视频技术成为了时下热门技术体系。


但实时音视频相关技术门槛非常高,很多细节并不为人所知,其中涉及到平台硬件、编解码、网络传输、服务并发、数字信号处理、在线学习等。虽然技术体系繁多,但总体上归纳两类:1对1模式和会议模式。我从这两个分类对实时音视频相关技术做简单介绍,主要有以下几方面: 


  • 编解码器

  • 客户端上传

  • 实时传输网络

  • 动态缓冲区

  • 媒体处理技术


编解码器


谈到视频编码器,就会想到MPEG4、H.264、H.265、WMA等等,但不是所有的视频编码器都可以用来作为实时视频的编码器,因为实时视频编码器需要考虑两个因素:编码计算量和码率带宽,实时视频会运行在移动端上,需要保证实时性就需要编码足够快,码率尽量小。基于这个原因现阶段一般认为H.264是最佳的实时视频编码器,而且各个移动平台也支持它的硬编码技术。


  • H.264/ AVC 


H.264是由ITU和MPEG两个组织共同提出的标准,整个编码器包括帧内预测编码、帧间预测编码、运动估计、熵编码等过程,支持分层编码技术(SVC)。单帧720P分辨率一般PC上的平均编码延迟10毫秒左右,码率范围1200 ~ 2400kpbs,同等视频质量压缩率是MPEG4的2倍,H.264也提供VBR、ABR、CBR、CQ等多种编码模式,各个移动平台兼容性好。


  • VP8/VP9 


除H.264以外,适合用于实时视频的编码器还有Google提供的VP8,VP8采用了H.264相似的编码技术,计算复杂度和H.264相当,不支持SVC,相同视频质量的压缩率比H.264要小一点,不支持B帧。而后Google又在VP8的基础上研发了VP9,官方号称VP9在相同视频质量下压缩率是VP8的2倍,对标的对手是H.265,VP9已经嵌入到WebRTC当中,但VP9编码时CPU计算量比较大,对于VP9用于实时视频我个人持保留意见。不管是VP8还是VP9硬编方式只有Android支持,iOS和其他的移动平台并不支持。


  • 音频编码器


实时音视频除了视频编码器以外还需要音频编码器,音频编码器只需要考虑编码延迟和丢包容忍度,所以一般的MP3、AAC、OGG都不太适合作为实时音频编码器。从现在市场上来使用来看, Skype研发的Opus已经成为实时音频主流的编码器。Opus优点众多,编码计算量小、编码延迟20ms、窄带编码-silk、宽带编码器CELT、自带网络自适应编码等。


图1:语音编码器编码延迟与码率对比


客户端推流


实时音视频系统都是一个客户端到其他一个或者多个客户端的通信行为,这就意味着需要将客户端编码后的音视频数据传输到其他客户端上,一般做法是先将数据实时上传到服务器上,服务器再进行转发到其他客户端,客户端这个上传音视频数据行为称为推流。这个过程会受到客户端网络的影响,例如:Wi-Fi信号衰减、4G弱网、拥挤的宽带网络等。为了应对这个问题,实时音视频系统会设计一个基于拥塞控制和QoS策略的推流模块。


  • 拥塞控制


因为客户端有可能在弱网环境下进行推流,音视频数据如果某一时刻发多了,就会引起网络拥塞或者延迟,如果发少了,可能视频的清晰不好。在实时音视频传输过程会设计一个自动适应本地网络变化的拥塞控制算法,像QUIC中的BBR、WebRTC中GCC和通用的RUDP。思路是通过UDP协议反馈的丢包和网络延迟(RTT)来计算当前网络的变化和最大瞬时吞吐量,根据这几个值调整上层的视频编码器的码率、视频分辨率等,从而达到适应当前网络状态的目的。


  • QoS策略


客户端推流除了需要考虑网络上传能力以外,还需要考虑客户端的计算能力。如果在5年前的安卓机上去编码一个分辨率为640P的高清视频流,那这个过程必然会产生延迟甚至无法工作。为此需要针对各个终端的计算能力设计一个QoS策略,不同计算能力的终端采用不同的视频编码器、分辨率、音频处理算法等,这个QoS策略会配合拥塞控制做一个状态不可逆的查找过程,直到找到最合适的QoS策略位置,图2是一个实时音频的QoS策略迁移过程实例。


图2:实时语音的QoS状态迁移


原作者: 袁荣喜 来自: LiveVideoStack
文章点评
相关文章