直播业务知识整理

╰+哭是因爲堅強的太久メ 2023-07-08 09:29 33阅读 0赞

# 直播相关 #

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

[**参考链接**][Link 1]

## 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 将对应的数据转发到房间内，让其他人看得到。

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

### 聊天 ###

*  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*

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01hcmtzaW5vYmVyZw_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200226111350708.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L01hcmtzaW5vYmVyZw==,size_16,color_FFFFFF,t_70
[Link 1]: https://blog.csdn.net/weixin_41956752/article/details/82858138
[Link 2]: https://blog.csdn.net/Marksinoberg/article/details/93172276