音视频技术小分享

直播技术剖析

直播流程

直播流程： 录制->编码->网络传输->解码->播放 （中间还会有转码的过程，转成不同分辨率的流）

Ucloud 直播技术分享连载：http://blog.ucloud.cn/archives/694

1. 网络接入部分，实现对用户位置的判断。（通过用户访问的dns进行判断用户所在的网络地址）
2. 视频传输协议的选择
3. 缓存策略

• I帧(important)表示关键帧。你可以理解为这一帧画面的完整保留；解码时只需要本帧数据就可以完成。（因为包含完整画面） GOP表示 多少秒一个I帧
• P帧表示这一帧跟之前的一个关键帧（或P帧）的差别。解码时需要用之前缓存的画面叠加上本帧定义的差别，生成最终画面。（也就是差别帧，P帧没有完整画面数据，只有与前一帧的画面差别的数据）
• B帧是双向差别帧。**B帧记录的是本帧与前后帧的差别（具体比较复杂，有4种情况）。换言之，要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的与本帧数据的叠加取得最终的画面。

视频流知识

视频质量概念

音视频计划博客 ： https://juejin.im/entry/59422a015c497d006bc15b1d

• https://blog.csdn.net/oldmtn/article/details/7533773

1. 码率

编码器每秒编出的数据大小，一般单位是kbps，比如800kbps代表编码器每秒产生800kb（或100KB）的数据。
基本的算法是：【码率】(kbps)=【文件大小】x8 x 1024/【时间】(秒)

CBR(Constant BitRate）

固定码率。

VBR(Variable BitRate)

动态码率，目前obs开播基本为动态码率

1. 帧率

FPS（每秒钟要多少帧画面）； 以及Gop（表示多少秒一个I帧） ，人体帧率24 FPS已经看不出区别

帧率×分辨率=压缩前的每秒数据量（这里可以算出一个字节大小）

压缩比=压缩前的每秒数据量/码率

• 码率影响体积，与体积成正比：码率越大，体积越大；码率越小，体积越小。
• 帧率影响画面流畅度，与画面流畅度成正比：帧率越大，画面越流畅；帧率越小，画面越有跳动感。如果码率为变量，则帧率也会影响体积，帧率越高，每秒钟经过的画面越多，需要的码率也越高，体积也越大。
• 分辨率影响图像大小，与图像大小成正比：分辨率越高，图像越大；分辨率越低，图像越小。

简单的比喻： 码率是自来水管的谁呀，分辨率720p/1080p就是水管网的直径，分辨率可能就是自来水龙头的粗细。最重要的是水源地的水源是否充足，即视频的源头信息是否满足

FPS： 每秒钟要多少帧画面

视频码率规格建议：

视频流协议

常见的视频流协议有 RTMP、HTTP-FLV、HLS

考虑三种协议的时延以及适用场景

详细解析：https://www.jianshu.com/p/4c89b2c83e59

• RTMP 工作于TCP上的应用层协议，默认为1935端口
  RTMP协议比较全能，既可以用来推送又可以用来直播，其核心理念是将大块的视频帧和音频帧“剁碎”，然后以小数据包的形式在互联网上进行传输，而且支持加密，因此隐私性相对比较理想，但拆包组包的过程比较复杂，所以在海量并发时也容易出现一些不可预期的稳定性问题。
• FLV HTTP-FLV
  HTTP-FLV协议由Adobe公司主推，格式极其简单，只是在大块的视频帧和音视频头部加入一些标记头信息，由于这种极致的简洁，在延迟表现和大规模并发方面都很成熟。唯一的不足就是在手机浏览器上的支持非常有限，但是用作手机端APP直播协议却异常合适，延迟低
• HLS
  HLS协议：苹果推出的解决方案，将视频分成5-10秒的视频小分片，然后用m3u8索引表进行管理，由于客户端下载到的视频都是5-10秒的完整数据，故视频的流畅性很好，但也同样引入了很大的延迟（HLS的一般延迟在10-30s左右）。相比于FLV， HLS在iPhone和大部分android手机浏览器上的支持非常给力，所以常用于QQ和微信朋友圈的URL分享
  适用于赛事等情况

H5 原生仅支持 mp4/webm， 不支持flv，但是flash支持flv却资源开销巨大

所以b站针对这个情况 推出了 ： https://github.com/Bilibili/flv.js/

H264 编码格式

refer to ：https://juejin.im/entry/5833dc86570c35006c22cfb1

优秀的编码技术能够实现 以更低的码率传递更优质的视频流。

核心技术： 一张图片经H.264编码器之后，被编码成一个或者多个片