qq视频直播(最新的直播app软件大全)

作者:王宇(腾讯影音高级架构师)

自我介绍，毕业加入腾讯，一直从事客户端研发工作。我在一家互联网公司，踩着互联网的浪潮，一直走在最前沿，从最早的PC *** ，到移动时代的手Q，再到腾讯IoT的嵌入式系统，直播领域近两年风起云涌。接下来我主要介绍一下 *** 视频直播的架构和原理。

今天我主要介绍三个方面，视频直播的框架和基本介绍；

直播中的一些关键技术:主要包括播控、性能、质量等。直播APP整体解决方案。

先看直播前后后台的大致框架，通过流媒体App或第三方流媒体设备将数据推送到后台服务器；

服务器对接收到的数据进行代码转换，并发送给DC；

观众从OC拉相应的直播流观看；

目前主要采用RMTP、HLS、FLV直播形式。接下来，让我们来关注一下直播过程中的客户端架构。

这是实时客户端的一般框架。

左侧是流媒体端:音视频采集；预处理；音频和视频编码和解码；封装数据 *** 传输；

它是正确的播放器: *** 接收数据；音视频解码；视频渲染和音频播放。

整个过程是一个线性的流线型过程，过程看起来比较简单。

视频编码是一个压缩的过程。如何压缩视频数据方便 *** 传输？这里有几个纬度:

1.每一帧数据的帧内压缩，也就是这里的I帧，可以独立恢复图像数据，一般比较大；

2.两个连续的帧之间有相似之处。参考前一帧的数据，只记录差值，这样数据量比较小，也就是这里的P帧采用前向预测编码；

3.再者，如果参考记录两帧数据的差异，数据量会更小，压缩率更高，也就是这里的B帧采用双向预测插值编码。

麦克风收集的原始PCM数据通常很大。以44.1k和两个声道为例，码率在1M左右，不压缩很难传输。音频编码是指根据不同的音频格式对采集的PCM数据进行压缩。当然目的是在保证音质的情况下，尽可能的压缩音频数据。目前使用AAC进行压缩。

流媒体音视频数据包格式。原始编码的音视频数据不利于 *** 传输。目前，有许多包格式:

1.RTMP协议，需要解包和打包。每个数据帧被分割成小块，用协议头发送，一般用于流式传输；

2.FLV格式，比较简单。每个数据帧添加一个协议头，一般用于播放；

3.HLS格式，将一组音视频数据组合起来，通过m3u8样式关联起来，相当于一个个小文件，适合网页播放。

直播的框架和基本原理就是这么简单，但是要有好的体验却不是一件很简单的事情。基本上是几个人一两个月就能做出来，但是需要长期的积累和打磨才能优化出一个好的效果。

接下来我们来看看直播过程中的一些关键问题，包括:秒开首屏，流畅度和延迟的控制，实时视听同步等等。

我们看一个直播，恨不得等半天才能出画面，体验明显很差。我们期待的是立即看到画面，即秒开之一屏。

首先看解码过程:推送端上传一个P帧，播放端拉一个P帧。如果帧是连续的，可以立即求解并正常显示；如果没有先前的参考帧，但只接收到P帧，则直到遇到关键帧才能显示。如果数据来了就能立刻显示，之一次打开就必须接收一个I帧，那么问题来了。服务器如何保证返回给玩家的之一帧是I帧？

假设一个人在看，流媒体终端上传一个P帧，服务器发给播放终端，播放正常，服务器放入缓存队列；有了这样一个相邻数据的缓存队列，当一个新的观众播放它时，可以直接从缓存队列中取出最新的GOP，一次性返回给观众。此时播放器可以立即解析I帧渲染，让它秒开。

有了平滑延迟控制，就播放而言，数据一来就播放。这个问题应该就这么简单，但是..

回放有两种要求:

1.更注重游戏场景的流畅度；

2.更注重主播场景下的低延迟；

所以有两种模式:流畅和极速。流畅是缓冲播放，极速是数据播放，缓冲大了就做速度播放；看起来不错，但是..

其实发现平滑模式会带来延迟大的问题，而速度模式有很大概率被卡。有更好的方案吗？这里的问题根源是 *** 神经过敏。在低延迟的同时保证流畅播放，其实就是流畅度和低延迟的平衡。应该如何设计？

对于玩家来说， *** 自带数据，自己玩，这是一种生产消费模式。正常情况下，生产多少，消费多少。然而， *** 抖动会导致停滞和数据积累，从而导致时间延迟。

这是过去一段时间的数据统计。有两个指标:

1.要播放的数据大小反映的是时延，即AvgCache在这里的过去时期；

2.过去一段时间 *** 抖动的大小决定了要播放的数据抖动的大小，也就是决定了抖动，也就是这里的抖动是随着时间的推移而修正的。

如果平均缓存太大，则延迟太大。为了消除延迟，需要快速消耗一些数据。这里会消耗多少数据？

理想情况下，需要加快红色曲线所示的MinCache的数据，这样才能保证不会触发堵塞，达到最小延迟。但这太理想化了，这里需要更加谨慎，所以做如下调整:

1.引入最小门槛，最多加速到这个水平如图；

2.不是一下子加速到更佳状态，而是设置更大加速时间。

综上，统计数据决策加快；调整计算时间，恒定加速度；这样就可以调整到更佳状态，这就是自适应回放控制策略。

这里有三种加速策略:

1.直接丢弃一些数据；

2.短时快速播放；

3.长时间更快的播，让人意识不到快播。

这里的问题根源在于消耗更多的数据。毫无疑问，丢弃，快加速和慢加速都是不利的。这三种方案各有利弊。瞬间伤害大的好还是长期伤害低的好？这里还是看个人喜好，萝卜白菜各有所爱，最终还是要看用户反馈来选择。既然做了速播，必然会遇到声画不同步的问题。怎么解决？

如何同步声音？

经典的声画同步有三种方案:音频同步到视频；将音频和视频与外部时钟同步；将视频同步到音频；

很难频繁调整方案音频的速度，所以直接pass

二是方案卡顿时需要时间修正，加减速时不容易保持同步；

第三种方案视频和音频同步很自然，视频可以很方便的进行调速处理。目前主要推荐第三种方案，实现起来相对简单。接下来，我们来看看整个播放控制方案。

音视频抖动队列分离，方便数据检索，控制器根据抖动大小和当前策略决定加速还是正常播放；

音频点播，最后，音频将PTS同步到视频，视频据此修正当前帧的播放时间，解决声画不同步的问题；

引入负反馈机制，保证解码数据不会太大；

如何加快声音？声音处理包括变调和变速、变调和不变调、变速和不变调。这里采用了变速不变调的算法来加快声音的速度。

再来看看实际效果。这是两个伤害模型的效果，左边的是瞬间高伤害，右边的是长期低伤害。你可以感受到两者的不同效果。

如何保证高分辨率下的性能？一般360p能达到更好的性能。那么问题来了。如何保证720P流媒体播放和1080P播放的性能？主要包括以下几个方面:

1.整个系统采用多线程处理，流媒体和播放都是流水线流程。每个处理进程采用独立线程，每秒帧率完全由单个处理进程的更大耗时决定，而不是整个进程的处理时间。

2.多核手机已经普及，在手机性能达标的同时，利用软编码和软解可以完成高帧率编解码。

3.目前手机基本都支持硬编码硬件解码。对于高分辨率，硬件编解码器可以显著减少CPU的使用并提高性能。

4.能由GPU处理的，尽量由GPU完成，比如局部渲染和图像处理，格式转换等。

5.采用ARM指令集优化提高性能，如视频裁剪、旋转等算法。

既然做的是live SDK，有问题怎么定位？如何监控直播质量？

这里有两种主要的问题:

1.开发和测试过程中遇到的问题；

2.用户当前的 *** 问题；这里直播质量主要包括CPU占用率、卡顿率、播放延迟、上下行带宽等等。

如何定位用户遇到的问题？日志必须是之一手资料。如何方便快捷的获取日志？

这里有一套日志提取系统，包括三个步骤:获取地址柔色、问题重现、提取日志分析；这是我们的日志提取系统。

为了监控直播质量，这里做了一套完整的数据上报和分析系统，基本涵盖了各种关键指标，不仅可以反映直播的各种表现，方便优化，还可以辅助定位各种问题。这是这个广播终端的整体统计数据，包括下行带宽，卡顿率，缓冲区大小，CPU占用率。这是一个宏观的统计数据，反映了当前直播观看终端的一个质量。

有了直播质量监控，可以更细致的做一些运营分析。比如最近我们在内部对一个游戏直播的流畅度做了一个运营统计分析，把外网用户分成三组，通过配置不同的播放端参数来统计质量。最后，我们得出了几个有趣的结论:

这是一个流媒体直播终端的质量评测。每一项都按照一些指标进行评分，然后给出一个综合评分，评价当前流媒体直播终端的质量。

这就是直播后台的整个大体框架。

以上主要是完成视频的流式传输和播放，包括接入集群、计算集群和CDN加速 *** ；

以下是账号、消息、社交互动系统等基础服务。我们用这些后台服务搭建了一个小型的直播App。

小直播客户端App和业务后台源代码向客户开放，为直播App提供了一套完整的集成解决方案。基于此，可以方便地完成一个直播App的开发。

这是我们做的小直播App，可以在官网下载体验。

更多资讯请关注官方微信官方账号:风织网(微信ID: BEFOIO)或WebRTC风织网(微信ID: webrtcorgcn)