Android 关于直播，推流，拉流

1.直播

集成的腾讯的互动直播的SDK做到（注册开发者，填写信息，创建项目，下载SDK，导入项目，配置build文件，添加user-pressen权限和Activity权限，在application文件中初始化就完成了集成的步骤。）

用ijkplayer的实现播放，ijkplayer功能很强大，它是bilibili基于ffmpeg做的一个轻量级视频播放框架，能播放本地视频，也能播放网络流媒体，Android和ios都可以用，支持编码，解码，转码，复用，解复用，流，过滤器等功能，支持大多是视频格式的播放，并且还提供了录制，转换以及流化音频格式的是方案，它有一个特别先进的libavcodec的编码库。

2.推流

通过摄像头和麦克获取视频和音频数据，把视频和音频数据压缩成H264视频格式和ACC音频格式，封装并发送给服务器，服务器再根据相关的协议分发。

3.拉流

从服务器获取相关的二进制信息，再通过解复用得到封装前的H264视频和ACC音频，再解压，把解压后的视频和音频同步到耳机和屏幕上。

4.推流拉流的三种协议

HLS协议：苹果公司的开发的，把流媒体切分成若干片段（TS文件），通过一个m3u列表文件，将这些TS文件集中起来播放。分发的协议是http协议，优点是可以根据网络状态的不同选择不同码率的流，根据网络状态调整自动调整清晰度。

RTSP协议和RTMP协议：RTSP协议实时性比较好，是共有协议，有专门维护的机构，一般以TS或者mp4为传输格式，有两个通道，可以满足实时性0.5秒以内的直播需求。RTMP是私有协议，没有被完全公开，只有一个通道，一般一flv和f4v为传输格式

5.直播中音视频不同步的问题

修改时间戳：选择一个时间戳，在生成数据流时依据参考时间给每个数据库都打上时间戳，播放时读取数据库上的时间戳。

6.优化延迟，卡顿，抖动，流畅度

产生原因：

1.推流端网络抖动导致数据无法发送到服务器，造成播放端卡顿。

2.播放端网络抖动导致数据累积在服务器上拉不下来，造成播放发困。

解决方案：

播放器将拉流线程和解码线程分开，建立一个缓冲队列用于缓冲音视频数据，拉流线程从服务器拉取音视频流放入队列，解码线程从服务器获取音视频数据解码播放。列的长度可以调整。当网络发生抖动时，播放器无法从服务器上获取到数据或获取数据的速度较慢，此时队列中缓存的数据可以起到一个过渡的作用，让用户感觉不到网络发生了抖动。

7.丢包处理方案

7.1.重传：丢什么数据传什么数据，不会浪费资源

7.2.向前纠错（FEC）：发送方将要发送的数据附加上一定的冗余纠错码一并发送，接收方则根据纠错码对数据进行差错检测，如发现差错，由接收方进行纠正，特点：使用纠错码（纠错码编码效率低且设备复杂）、单向信道、发送方无需设置缓冲器。(FEC 算法其中一个称之为异或。假如有 4 个数据，那么它们可以取 4 个异或值，其中每一个数据都可以由另外 4 个异或值计算出来。还可以把 ABCD 和 E 想象成一个数据包，如果我们传输 ABCD 这四个数据包，第五个数据包传输的是 E，这五个数据包可以丢失任何 1 个数据包。接收方收到数据之后，能够把它丢的数据恢复出来。前向纠错算法能处理的是连续数据里只丢 1 个包。同时丢失 A 和 B，这个算法不能解决。)

7.3.交叉传输 -- 处理连续丢包的情况

交叉传输，我们日常看到多媒体可能是按照时序的，一个多媒体片断是由 1 到 10 组成。如果此过程当中有丢包，比如 3456 连续丢失，那么此次丢包的影响可能表现在视频播放出现停顿。若丢的是关键帧那么影响非常大，会导致后面一大片的花屏。因此当连续丢包对流媒体伤害特别大的情况下，可以采用交叉传输策略。1 到 10，原来是 3 个 3 个传，如 123、456、789 各传一次，那么现在可以改变传输策略，采用 147、280 和 369 的传输策略，这样一组数据丢掉，实际丢失在流媒体中间穿插的数据，播放程序可以在几乎不失真的状态下把视频恢复出来。

8.直播流程

采集视频，音频→视频处理（美颜，滤镜等）→音视频数据压缩→推流→流媒体服务器数据处理→拉流→音视频解码→播放→聊天互动→弹幕

9.音频数据参数

9.1声道数：单声道，立体声

9.2采样率：每分钟获得声音样本的次数，

9.3采样位数：8位，16位

10.视频数据参数分析

10.1分辨率：一张图由多少像素点组成

10.2帧率：一个视频，每一秒由多少图像构成

10.3码率：视频文件体积/时间（kbit/s或者mbit/s）