音视频基本概念

音视频原理

Byte, bit

• bit就是位，也叫比特位，是计算机表示数据最小的单位
• byte就是字节 1byte=8bit
• 1byte就是1B
• 1KB=1024B 1B= 8b

帧

• 帧（Frame）：就是一张静止的画面， 是视频的最小单位

- 帧率

• 帧速率（FPS）：每秒播放图片（帧）的数量。
• 高帧率可以得到更流畅，更逼真的动画。
• 一般来说30fps就是可以接受的， 提高的60fps可以明显提升交互感和逼真感， 但超过75fps就不容易有明显的提升。
• 帧率超过屏幕刷新率， 则会浪费图像处理能力， 因为监视器不能以这么快的速度更新。

视频帧

• 分为I, P, B帧
• I帧为关键帧， 解码时只需要本帧数据就可以完成。
• P帧为这一帧和之前的一个关键帧的差别， 解码时需要之前缓存的画面叠加本帧定义生成最终画面
• B帧记录的是本帧和前后 帧的差别

音频帧

• PCM，未经编码的音频数据， 不需要帧的概念， 利用采样率和采样精度就可以播放。
• AMR， 规定为每20MS的音频为1帧。
• MP3:

分辨率

视频成像产品所形成的图像大小或尺寸

刷新率

• 分垂直刷新率， 水平刷新率， 一般指垂直刷新率
• 刷新率越高， 图像越稳定， 对眼睛影响越小
• 刷新率越低， 图像抖动， 眼睛疲劳越快
• 达到80HZ以上的刷新率， 完全可以消除图像闪刷和抖动感

码率

• 码率（Bit Rate）：码率就是比特率， 码率是单位时间内播放的连续的媒体的比特率，单位是kb/s或者Mb/s。
• 一般来说同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。码流越大，说明单位时间内取样率越大，数据流，精度就越高，处理出来的文件就越接近原始文件，图像质量越好，画质越清晰，要求播放设备的解码能力也越高。
• 码率越高， 带宽消耗的越高。

码率的常见三种模式：

• CBR
  • 全程码率恒定
  • 文件大小可预测
  • 编码压力小，直播常用
• VBR
  • 码率可变
  • 简单场景码率低，复杂场景码率高
• CRF
  • 固定质量模式
  • CRF值越低，视频看起来质量越高

视频和图像的关系

频就是图片一帧一帧连起来的产物，连起来的越快看着越流畅，用帧率（就是每秒播放图片的数量FPS）来衡量视频的流畅度。那么根据图片大小的算法就能算出视频的大小。

视频的大小 = 时长（秒） * 帧率（FPS）* 图片大小；

那么1920×1280分辨率， 30FPS，时长1秒的视频的大小就是：1920 * 1280 * 24 / 8 * 30 / 1024 / 1024 = 210.9375 M，

经过编码后实际没有这么大

RTMP协议

RTMP，全称 Real Time Messaging Protocol，即实时消息传送协议。Adobe 公司为 Flash 播放器和服务器之间音视频数据传输开发的私有协议。工作在 TCP 之上的明文协议，默认使用端口 1935。协议中的基本数据单元成为消息（Message），传输的过程中消息会被拆分为更小的消息块（Chunk）单元。最后将分割后的消息块通过 TCP 协议传输，接收端再反解接收的消息块恢复成流媒体数据。

RTMP 主要有以下几个优点：

• RTMP 是专为流媒体开发的协议，对底层的优化比其它协议更加优秀，同时它 Adobe Flash 支持好，基本上所有的编码器（摄像头之类）都支持 RTMP 输出。现在 PC 市场巨大，PC 主要是 Windows，Windows 的浏览器基本上都支持 Flash。
• RTMP适合长时间播放，曾经有过测试，联系 100 万秒，即 10 天多连续播放没有出现问题。最后 RTMP 的延迟相对较低，一般延时在 1-3s 之间，一般的视频会议，互动式直播，完全是够用的。

当然 RTMP 并没有尽善尽美，它也有不足的地方：

• 一方面是它是基于 TCP 传输，非公共端口，可能会被防火墙阻拦；
• 另一方面，也是比较坑的一方面是 RTMP 为 Adobe 私有协议，很多设备无法播放，特别是在 iOS 端，需要使用第三方解码器才能播放。

FLV 协议

FLV (Flash Video) 是 Adobe 公司推出的另一种视频格式，是一种在网络上传输的流媒体数据存储容器格式。其格式相对简单轻量，不需要很大的媒体头部信息。整个 FLV 由 The FLV Header, The FLV Body 以及其它 Tag 组成。因此加载速度极快。采用 FLV 格式封装的文件后缀为 .flv。
而我们所说的 HTTP-FLV 即将流媒体数据封装成 FLV 格式，然后通过 HTTP 协议传输给客户端。

HTTP-FLV 依靠 MIME 的特性，根据协议中的 Content-Type 来选择相应的程序去处理相应的内容，使得流媒体可以通过 HTTP 传输。相较于 RTMP 协议，

• HTTP-FLV 能够好的穿透防火墙，它是基于 HTTP/80 传输，有效避免被防火墙拦截。
• 它可以通过 HTTP 302 跳转灵活调度/负载均衡，支持使用 HTTPS 加密传输，也能够兼容支持 Android，iOS 的移动端。

HTTP-FLV 的缺点，由于它的传输特性，会让流媒体资源缓存在本地客户端，在保密性方面不够好。因为网络流量较大，它也不适合做拉流协议。

HLS协议

HLS (HTTP Live Streaming) 则是苹果公司基于 HTTP 的流媒体传输协议。主要应用于 iOS 设备，包含(iPhone, iPad, iPod touch) 以及 Mac OSX 提供音视频直播服务和录制内容（点播）等服务。

相对于常见的流媒体协议，HLS 最大的不同在于它并不是一下请求完整的数据流。它会在服务器端将流媒体数据切割成连续的时长较短的 ts 小文件，并通过 M3U8 索引文件按序访问 ts 文件。客户端只要不停的按序播放从服务器获取到的文件，从而实现播放音视频。

HLS 的优势：

• Apple 的全系列产品支持：由于 HLS 是苹果提出的，所以在 Apple 的全系列产品包括 iPhone、 iPad、safari 都不需要安装任何插件就可以原生支持播放 HLS， 现在 Android 也加入了对 HLS 的支持。
• 穿透防火墙。基于 HTTP/80 传输，有效避免防火墙拦截
• 性能高。通过 HTTP 传输， 支持网络分发，CDN 支持良好，且自带多码率自适应，Apple 在提出 HLS 时，就已经考虑了码流自适应的问题。

HLS 的劣势：

• 实时性差，延迟高。HLS 的延迟基本在 10s+ 以上
• 文件碎片。特性的双刃剑，ts 切片较小，会造成海量小文件，对存储和缓存都有一定的挑战

流媒体协议 RTMP, HTTP-FLV, HLS 简单对比

RTMP 协议为流媒体而设计，在推流中用的比较多，同时大多 CDN 厂商支持RTMP 协议。

HTTP-FLV 使用类似 RTMP流式的 HTTP 长连接，需由特定流媒体服务器分发的，兼顾两者的优点。以及可以复用现有 HTTP 分发资源的流式协议。它的实时性和 RTMP 相等，与 RTMP 相比又省去了部分协议交互时间，首屏时间更短，可拓展的功能也更多。

HLS 作为苹果提出的直播协议，在 iOS 端占据了不可撼动的地位，Android 端也同时提供相应的支持。