【流媒体测试】推流学习笔记

流媒体协议RTSP、RTMP
　RTSP+RTP主要用于IPTV，原因是传输数据使用的是UDP，在网络环境比较稳定的情况下，传输效率是比较高的；
　RTMP主要用于互联网音视频传输，它使用的是TCP传输，因为互联网环境相对较差，采用RTMP保证了视频的传输质量，但是其传输延迟相对较高，传输效率相对较低。

UDP与TCP比较：
UDP：无连接协议，也称透明协议，也位于传输层。
1） TCP提供面向连接的传输，通信前要先建立连接（三次握手机制）； UDP提供无连接的传输，通信前不需要建立连接。
2） TCP提供可靠的传输（有序，无差错，不丢失，不重复）； UDP提供不可靠的传输。
3） TCP面向字节流的传输，因此它能将信息分割成组，并在接收端将其重组； UDP是面向数据报的传输，没有分组开销。
4） TCP提供拥塞控制和流量控制机制； UDP不提供拥塞控制和流量控制机制。

1 推流

推流框架
将视频（H264）和音频（AAC）格式数据分别解码为图像（RGB/YUV）和声音（PCM），再根据时间戳同步播放。

1.1 实时推流
1）队列：音频包和视频包放到同1个队列
需要队列的原因：编码后直接把包推流，网络信号不好的时候，会被阻塞

• 队列如何设计？
  生产者消费模型、现线程安全

2）如果网络拥塞，比如拥塞2秒
如果2秒没有推送任何数据包，那队列攒了2秒的数据。如果攒积数据太多，drop数据。检测到I帧，停止drop。

3）队列大小控制
积累1秒数据，能不能drop数据，要2秒才考虑去drop数据。

4）延迟：主要队列数据积累

• 推流队列
  网络拥塞的时候会积攒数据，网络好的情况队列不会有缓存的。
  
  推流端积攒数据，可以在推流端drop数据，音频做变速，视频drop非I帧
• 流媒体服务器的缓存队列
  服务器->拉流端 网络不好的时候采集积攒数据，才会导致延迟。网络好的时候快速往拉流端发。
• 拉流队列
  

问题：拉流2秒信号不好，没有拉到数据，网络恢复后，500ms拿到2秒数据：正常速率播放，延迟1.5秒。
解决方式：改变速率播放（技术难）或drop数据（技术简单）。

5）队列时间统计
push->pop
获取
back_pts front_pts
计算队列里面数据包持续的时间
如果出现回绕怎么办，通过 帧间隔*包数量 去做矫正
ffmpeg接口阻塞的问题

RTMP Darren推流
流媒体服务器：单个tcp通道，音频、视频、控制数据都是同一个通道

拉流：
客户端RTMP
PC web HTTP-FLV webtrc
手机web HLS（延迟比较）
TS TS

1个人推流，多个人拉流
1）某个拉流卡顿是否会阻塞其他人：不会

拉流卡顿，服务器里面队列会被循环覆盖，服务器可以设置拉流大小的。

每个客户端的队列，拷贝的码流是浅拷贝，类似share_ptr智能指针内存引用计数。

2）如果客户端不出现网络卡顿，那服务器不会缓存多少数据，如果出现了卡顿服务器缓存数据不会太少。

卡顿5秒>流媒体缓存5秒>网络恢复后 客户端是很快收到5秒的数据 ->客户端缓存了5秒数据->如果正常速度播放，延迟会有5秒
（1）丢掉一部分数据，比如4秒
（2）变速播放

3）读写数据周期
读取数据的周期

read：
每次读取1帧数据，读5帧要用户态/内核切换5次
每次读取5帧数据，只需要切换1次

写数据的周期
比如攒积10帧数据再write，可以减少cpu占用率

4）服务器延迟

（1）读写数据周期
（2）拉流队列的缓存
（3）gop cache queue

检测到最新的I帧就更新gop cache

gop cache开启的情况下，工牌 queue才有数据
比如gop2秒
开启：I P … P P I PP…P I
1）第2个I最理想的情况：指cacheI帧，刚好拉取到I帧
2）最糟糕，刚好错过I帧，等到I帧才有画面（可能要等2秒）
3）如果客户端队列数据超过阈值（最大延迟1秒），缓存队列那就只能最多缓存1秒的数据，变速播放加快数据消耗

2 测试延迟

推流->流媒体服务器转发SRS->拉流
在哪里会产生延迟？
1）推流端、采集数据延迟、编码延迟、推流延迟
（1）采集延迟：8k 2048个采样点 耗时间隔0.256秒=256毫秒（一般是23.3ms）
（2）编码延迟：不要插入b帧，使用zero latency配置
（3）推流：数据就是实时采集的，有数据马上推出去
检测指标
队列里面：音频帧数量、视频数量，能持续播放的时长
码率分析
推流码率—编码码率
1mbps----2mbps
---- 降低码率 1mbps
卡的比较：优先发送音频包

2）流媒体服务器转发

（1）怎么转发数据
各自有独立的队列，生产者（推流），消费者（拉流）
队列是有大小，比如最大缓存30秒。如果超过30秒的数据，覆盖旧数据。
（2）服务器有可能延迟
socket read读取数据是需要切换用户态/内核态的切换
20ms读取一次数据，200ms读取一次数据，延迟就比20ms读取一次大

3）拉流端
5秒后用户网络恢复正常
200ms内拉取5秒的数据

avformat_find_stream_info获取视频流， 查找编码信息，并尝试使用对应解码器去解，检测是否成功。
（1）从buffer读取数据，分析编码，但是对应这部分读取的buffer数据是不扔掉的，读取1秒时长去分析，这个函数被执行了1秒
（2）我们从buffer读取数据，分析编码器，也尝试解码，但是读取来的数据用完就扔掉

av_read frame 获取视频的一帧，获取音频的若干帧
（1）队列数据缓存较多
队列缓存数据多，不用丢掉，使用播放端是需要支持变速播放的功能
起播缓存阈值，这里音频数据达到X毫秒才开始播放。起播越大，越流畅，但是延迟大。

（2）网络抖动->直播是实时流，为什么还要做音视频同步，直播需要时间戳来做音视频同步。

① 网络抖动是指最大延迟和最小延迟的时差。比如你访问一个网站的最大延迟是10ms，最小延迟是5ms，那么网络抖动是5ms。

② 网络抖动原因：

• I帧较大，占用带宽时间比较长
• 信号不好的时候，网络拥塞的的时候

③ 解决网络抖动：
做缓存

– 采集端，采集间隔是匀称的，不代表接收端收到帧间隔也是匀称的。
I帧代表jpeg图片（371kb，40ms要能发送出去，37110248/0.04=75980800，约76mb，I帧发送，很容耗时大于>1/帧率）

I P P帧
40ms 40ms
– 接收端
P P I
90ms 80ms 0

• 视频帧间隔不匀称
• I帧

网络抖动是指最大延迟和最小延迟的时差。比如你访问一个网站的最大延迟是10ms，最小延迟是5ms，那么网络抖动是5ms

（2）服务器抖动 ：读写

经常出现卡顿后，一般是攒积数据缓存

如有侵权，请联系删除。