直播业务知识整理

直播相关

整理的一些直播业务下相关基础知识点。

参考链接

1采集

音频

• 麦克风是否可用
• 检测手机对某个音频采样率的支持
• 音频采集时设置正确的缓冲区大小
• 特殊场景如连麦进行回声消除

视频

• 摄像头是否可用
• 摄像头采集到的图像是横屏，需要进行旋转处理后进行展示
• 各种手机屏幕大小比例特殊处理

2处理

处理内容

将视频帧进行加工，然后一帧一帧的渲染到屏幕上。

• 美颜
• 水印

处理框架技术

• GPUImage

  基于 OpenGL ES 的一个强大的图像、视频处理框架，支持各种预定义以及自定义滤镜效果。

• OpenGL

  Open Graphics Library 定义了一个跨编程语言、跨平台的编程接口的标准，是一个功能强大的，调用方便的底层图形库。

• OpenGL ES

  OpenGL for Embedded Systems 是 OpenGL 的三维图形 API 的子集，针对手机，PDA 和游戏主机等嵌入式设备而设计。

3编解码

编码：将视频流，音频流等数据以特定的容器格式封装成文件

解码：将视频流、音频流字幕等合成的文件中（容器格式 FLV，TS）分解出视频，音频或者字幕，各自进行解码。

框架

• FFMpeg

  一个跨平台的开原视频框架，能实现视频编码，解码，转码，串流，播放等丰富的功能。支持的视频格式以及播放协议非常丰富，几乎包含了所有的音视频编解码、封装格式以及播放协议。

• libxxx

视频编码技术

对食品进行压缩（视频编码）或者解压缩（视频解码）。

主要目标是将视频像素数据压缩成视频码流，降低视频的数据量。

P-B-I 帧分别是什么：
I帧（关键帧）保留一幅完整的画面，解码时只需要本真数据就可以完成。

P 帧（差别帧）保留这一帧和之前帧的差别，解码的时候需要用之前缓存的画面叠加本帧的差别，来生成最终的画面，所以可以看出 P 帧没有完整的画面数据，只有与前一帧的画面差别的数据，

B 帧（双向差别帧）保留的是本帧与前后帧的差别，解码 B 帧，不仅要取得之前的缓存画面，还需要解码之后的画面，通过前后画面与本帧的数据叠加来输出最终的画面。因为 B 真压缩率搞，所以几码的时候会比较消耗 CPU。

• MPEG

  采用帧间压缩，仅仅存储连续帧之间有差别的地方，从而达到比较大的压缩比。

• H.264/AVC

  采用实现预测（和 MPEG 中的 P-B 帧一样的帧预测压缩算法），可以根据需要产生网络情况传输的视频流，拥有更高的压缩比和更好的图像质量。

• H.265/HEVC

  基于 H.264，属于增强版

• 合成muxing

  将视频流音频流甚至是字幕流封装到一个文件中（比如文件格式为 FLV，TS 等）作为一个信号进行传输。

音频编码技术

• AAC

  音频编码技术，压缩音频用。

码率控制

视频播放软件中的 1024.720 高清标清流畅等，指的就是各种码率

视频封装格式

• TS

  流媒体封装格式，不需要加载索引之后再播放，减少了首屏延迟

  两个 TS 片段可以无缝拼接，播放器得以连续播放

• FLV

  流媒体文件封装格式，文件极小，加载速度很快。

解码

• 硬解码

  用 GPU 来解码，减少了 CPU 运算。

  优点：播放流畅，功耗低，解码速度快。
  缺点：兼容性不好，厂商有关。

• 软解码

  用 CPU 来解码

  优点：兼容性好
  缺点：耗CPU、功耗高，没有硬解码流畅，解码速度相对较慢。

传输

传输协议

• RTMP

  实时消息传输协议，为播放器和服务器之间，音频视频以及数据传输开发的一套开放协议。

  建立在 TCP 协议之上

  RTMP 协议就像是一个用来封装数据包的容器，这些数据可以是 FLV 中的音视频数据，一个单一的链接可以通过不同的通道传输多路网络流（这些通道中的包都是按照固定的大小来进行传输的）

流媒体服务器

• SRS
• BMS
• NGINX

数据分发

• CDN

  • 推流地址
  • 拉流地址

推流

拉流

• 直播协议对比

  • *RTMP

    比较全能，即可以用来推送，又可以用来直播。

    核心理念：将大块的视频帧和音频帧剁碎，然后以小数据包的形式在互联网上进行传输，支持加密。拆包组包比较复杂，海量并发时容易出现一些不可预测的稳定性问题。

  • *FLV

    只是在大块的视频帧和音频帧头部加入一些标记头信息，所以处理起来很方便。

    缺点：手机浏览器上的支持有限，但是手机端 APP 的直播协议却异常成熟，可以很好的使用。

  • *HLS

    基于 HTTP 协议实现，传输内容包括两部分：M3u8 描述文件➕TS 媒体文件
    可以实现流媒体的直播和点播
    （HLS 其实是以点播的形式来实现的直播，所以会有延迟，而且可以根据网络状态选择不同码率的视频流，实现的方法是服务器端提供多码率视频流清单）

    对比 RTMP。HLS 时延较大，RTMP 时延低；HLS 会产生大量文件，造成资源浪费。但好处是这些文件的存在让低端设备也能很好的处理。

  • HTTP-FLV

    基于 HTTP 协议实现的流式媒体传输。

    因为HTTP 本身没有很复杂的状态交互，所以从延迟角度看，HTTP-FLV 要优于 RTMP

  • RTSP

    实时流传输协议：定义了一对多应用程序如何有效地通过 IP 网络传输多媒体内容。

  • RTP

    基于 UDP 实现，本身没有按时发送和其他 Qos(服务质量保证)，时延小，误差稍大。

    服务质量保证由 RTP 的配套协议 RTCP 来收集媒体连接的统计信息，如串数字结束，传输分组数，丢失分组数，单向和双向网络延迟等

• 直播协议选择

  即时性要求较高，或者有互动需求的可以采用 RTMP，RTSP

  对有回放或者跨平台需求的，推荐使用 HLS。

互动

交互本身是个多模块互相配合的场景。先来大致描述下一个直播业务的场景。

打开 APP 一个热门页面（从打开 APP 开始就会和 PHP 接口层交互）
点击某一个房间（PHP 进行权限校验，返回合法用户需要的一些信息给 APP）
连 websocket，进行聊天直接交互
送礼，元数据中房间信息，主播信息等都可以拿得到。
送礼消息要展示给房间内其他用户，但是送礼本身走的是 PHP，而非 ws。所以需要借助 Redis 进行 pub/sub 做一次“透传”行为，让 ws 将对应的数据转发到房间内，让其他人看得到。

关于“透传”模型，这里有一个比较通俗的参考

聊天

• websocket 服务器

  • netty-java 框架

  • 1协议升级，客户端参数传递链接

    第一步是客户端用 HTTP 来申请 upgrade，并传递过来一些服务器认证身份的参数，来避免外界干扰
    进行握手：
    Sec-WebSocket-Key1和Sec-WebSocket-Key2在旧的WEBSOCKET协议中是没有的，因为判断当前请求是否WEBSOCKET，主要还是通过请求头中的Connection是不是等于Upgrade以及Upgrade是否等于WebSocket，也就是说判断一个请求是否WEBSOCKET请求，只需要判断请求头中的Connection及Upgrade，判断新旧版本可以通过是否包含“Sec-WebSocket-Key1”和“Sec-WebSocket-Key2”。
    客户端请求
    Upgrade:websocket
    Connection:Upgrade
    服务器响应 101 状态码 切换协议，连接为 websocket连接

  • 2消息互联

业务交互

• PHP 服务器

  • 业务机

    火星这边一般叫 get 机，也就是常说的业务机器，真正负责更新用户信息，房间信息以及CRUD等操作的执行。

    GET 机原则上来讲可以快速扩容，前提是代码环境准备好，因此一般为了避免雪崩，get 机群最好是有一两台随时准备上线的机器，一旦某些 get 机出问题，可以立即修改前端机 Nginx 配置来顶上去，减少业务损失。

  • 前端机

    负责业务请求转发与负载均衡。

    一般可以作为汇总请求日志来使用，但是要注意单点问题，一旦宕机，需要拿到 Nginx 配置然后迅速重启服务，

推拉流

推流

主播将本地视频源和音频源推送到云端服务器，有时也称为“RTMP 发布”

拉流

XMind: ZEN - Trial Version