1、前置知识
-
流式传输
-
所谓流媒体是指采用流式传输的方式传输在Internet播放的媒体格式；
-
流式传输的方式是将视频和音频等多媒体文件经过特殊的方式分成一个个的压缩包，由服务器向客户端连续、实时传输，客户端通过解压操作对这些数据进行解压，多媒体就会像发送之前那样显示出来
-
转码就是将直播流转化成不同的协议格式，以便支持不同的客户端设备
-
分发到CDN网络则是为了解决直播服务器的拥堵，响应慢等问题
-
直播中运用到的技术有：音频/视频处理、图形处理、视频/音频压缩、CDN分发、即时通讯、信令服务等相关技术；
-
一个完整直播APP实现流程
-
采集 → 滤镜处理 → 编码 → 推流 → CDN分发 → 拉流 → 解码 → 播放互动
-
-
完整直播APP的原理
-
直播原理
扫描二维码关注公众号，回复： 14872165 查看本文章
-
将主播录制的视频推送到服务器，再由服务器分发给观众观看
-
-
直播环节
-
推流端：音视频采集、美颜处理、3A处理、编码、推流等
-
服务端：转码、录制、截图、鉴黄等
-
播放器：拉流、解码、渲染等
-
互动系统：聊天室、礼物系统、弹幕系统、点赞等
-
-
-
一个完整的直播APP所要具备的功能
-
聊天
-
私聊、普通聊天室、点亮、推送、黑名单、禁言、直播间关闭评论等
-
-
礼物
-
礼物、红包、排行榜、充值、内购、提现等
-
-
直播列表
-
关注、热门、最新、分类直播用户列表、直播间预约等
-
-
自己直播
-
录制、推流、解码、播放、美颜、心跳、后台切换、桌面共享、直播间内人员操作等
-
-
房间逻辑
-
创建房间、加入房间、退出房间、关闭房间、切换房间、房管、房间用户等
-
-
用户逻辑
-
普通登录、第三方登录、操作个人信息、个人相关列表、关注等
-
-
观看直播
-
聊天、弹幕、礼物、直播间状态、用户状态等
-
-
统计
-
业务统计、第三方统计等
-
-
超管
-
禁播、隐藏、审核等
-
-
2、直播原理浅析
2.1 音视频处理相关
-
视频采集处理后推流到流媒体服务器
-
首先从前端采集设备中获取原始的音频和视频数据
-
对音视频进行额外的处理，如音频的混音、降噪等处理；对视频进行水印、滤镜和时间戳等处理
-
按照相关规范要求对处理后的音视频数据进行编码
-
对编码后的数据进行相关封装处理，使得不同多媒体内容可以同步播放，且提供另外的处理如添加索引
-
通过流媒体协议将封装好的内容推送到流媒体服务器上
-
-
流媒体服务器
-
对流媒体内容进行采集(接收推流)、缓存、调度和传输播放(以流式协议实现用户分发)
-
-
观看端
-
只需要拥有支持对应流媒体传输协议的播放器即可
-
需要关注的是服务端是通过什么协议返回的直播流，然后选取相应的播放器进行播放即可
-
-
常见音频编码方式
-
WAV(无损)
-
就是在PCM数据格式的前面加上44字节，分别用来描述PCM的采样率、声道数、数据格式等信息
-
优点：音质非常好、大量软件都支持
-
缺点：没有经过压缩处理，内存占用比较大
-
适用场景：多媒体开发的中间文件、保存音乐和音效素材
-
-
MP3(有损)
-
具有不错的压缩比，使用LAME编码，听感上非常接近源MAV文件
-
特点：音质在128Kbpit/s，压缩率比较高，大量软件个硬件都支持，兼容性好
-
缺点：
-
技术比较落后，同码率下音质会比AAC、OGG差一些
-
仅有两个声道
-
-
-
AAC(Adpative audio coding：有损)
-
AAC是新一代的音频压缩技术，通过一些附加的编码技术(如PS、SBR等)，衍生出了LC-AAC、HE-AAC、HE-AAC V2三种主要的编码格式，相比于MP3有更高的压缩率
-
HE-XXX技术：HE即high efficiency，注重高效性，HE-AAC混合了AAC与SBR技术，SBR技术即Spectral Band Replication(频段复制)，关键点在于低码流下提供全带宽的编码而不会产生多余的信号，传统的音频编码会产生令人不快的噪音信号，SBR解决问题的方法是让核心编码去编码低频信号，但是他会增加音频的宽带；
-
-
特点：
-
提升压缩率：可以用更小的文件获得更好的音质
-
提升多声道：可以提供最多48个全音域声道
-
更高的解析度：最高支持96KHz的采样频率
-
更高的解码效率：解码播放所占的资源更少
-
-
-
Ogg(有损)
-
在中低码率场景下，OGG除了音质好之外，还是完全免费的，OGG有着非常出色的算法，可以用更小的码率达到更好的音质，128Kbit/s的Ogg比192Kbit/s甚至更高码率的MP3还要出色
-
特点：可以用更小的码率实现更高的音质，高中低码率下均有良好的表现
-
缺点：兼容性不好，流媒体特性不支持
-
-
FLAC(无损)
-
有更高的压缩算法，且
无损压缩，在压缩过程中不会破坏任何原有的音频资讯
-
-
2.2 云直播服务
云直播服务是指在云端处理好了转码、内容分发等技术难点，对外只提供对应的接口即可
-
视频直播服务(ApsaraVideo Live)
-
是基于领先的内容接入与分发网络和大规模分布式实时转码技术打造的音视频直播平台，提供便捷接入、高清流畅、低延迟、高并发的音视频直播服务
-
阿里云直播过程图解
-
【学习地址】：FFmpeg/WebRTC/RTMP/NDK/Android音视频流媒体高级开发
【文章福利】：免费领取更多音视频学习资料包、大厂面试题、技术视频和学习路线图，资料包括（C/C++，Linux，FFmpeg webRTC rtmp hls rtsp ffplay srs 等等）有需要的可以点击1079654574加群领取哦~
3、富途证券直播原理与实战
3.1 直播流程
-
视频直播
-
总流程：采集 → 前处理 → 编码 → 传输 → 解码 → 渲染
-
采集：
-
一般由客户端完成(IOS、安卓、PC或其他工具如OBS)，iOS相对简单，安卓需要做一些机型适配工作，PC端则需要适配各种机型和摄像头
-
-
前处理
-
常见处理有
-
音频处理：混音、降噪和声音特效处理
-
视频处理：美颜、水印、各种滤镜特效和动态贴图等
-
-
主要是直播美颜，美颜算法需要用到GPU编程，没有现有的开源项目，难点在于GPU占用和美颜效果之间找平衡，不在于如何实现美颜效果
-
-
编码
-
采用硬编码，软编码720P完全没戏，且使用时会占用CPU导致设备发热等问题
-
编码要在分辨率、码率、帧率、GOP(Group of Pictures画面组)等参数设计上找到最佳平衡点
-
拓展
-
GOP(Group of Pictures)就是一组连续的画面，GOP是序列中的一个图片集，GOP的第一个图像必须为I帧，这样可以保证GOP不需要参考其他图像，可以独立解码
-
MPEG编码将画面（即帧）分为I、P、B三种，I是内部编码帧，P是前向预测帧，B是双向内插帧。简单地讲，I帧是关键帧，可以理解为一个完整的画面，而P帧和B帧记录的是相对于I帧的变化，P帧表示跟前一帧的差别，B帧表示前后帧差别。没有I帧，P帧和B帧就无法解码，这就是MPEG格式难以精确剪辑的原因，也是我们之所以要微调头和尾的原因
-
-
-
传输
-
一般交给CDN服务商
-
-
解码
-
是对之前编码的操作，进行解码，在Web里需要解码是HLS
-
-
渲染
-
播放器进行渲染，目前使用的是腾讯云播放器
-
-
腾讯云直播方案图解
-
4、斗鱼直播原理解析(主H5端)
4.1 直播技术方案
斗鱼直播间并没有直接的
.flv的网络请求，而是多了许多.xs的网络请求，特殊之处在于.xs网络请求的相应Content-Type是video/x-flv，其原理还是用到了HTTP-FLV方案；
-
使用
.xs的方式的原因解析-
取决于拉流方式
-
并不是完全使用HTTP去拉流，而是采用CDN和P2P两种方式同时去拉流
-
.xs并不是一个完整的FLV流，而是一个子FLV流 -
具体请求逻辑
-
首次请求的时候会去请求一个完整的FLV流
-
当P2P连接成功后，再切换成子流(断开完整的FLV流请求接口，然后去拉子流)
-
原因是：P2P连接较慢，如果首次就采用P2P的方式进行请求数据，那么视频的起播速度会非常慢
-
-
-
-
具体步骤分析
-
首次请求先获取完整的FLV流
-
建立P2P连接后断开FLV流请求，切换为请求子流
-
P2P拉流也是有缺点的，例如直播延迟较高，不适用于低延迟直播场景，对用户的设备和宽带都有所消耗，因为除了从其他用户那里拉流，当前用户还要上传自己的视频数据给其他用户
-
-
同时创建WebSocket连接，用于推送其他正在观看当前流的用户，使得播放器可以直接从推流的用户那拉流
-
斗鱼的P2P是基于WebRTC的DataChannel，会创建很多WebRTC连接，可以接收其他用户分享的视频数据，自己也会共享当前下载到的视频给其他用户
-
当然在后期的优化中，会尝试将多个WebRTC合并到一个WebRTC里，这样可以优化到相关的逻辑
-
-
无论是HTTP，还是HTTP-P2P，其最终目的都是获取FLV视频数据
-
在PC端的
Response Headers为Content-Type:video/x-flv或Content-Type: video/x-p2p
5、拓展
5.1 浅析媒体流
5.1.1 相关概念
-
流媒体开发
-
网络层(socket或stp)负责传输
-
协议层(RTMP或HLS)负责发网络打包(切片)
-
封装层(flv、ts)负责编解码数据的封装
-
编码层(h.264和AAC)负责图像音频压缩处理
-
-
GOP(Group of Pictures)画面组
-
一个画面组就是一组连续的画面，每个画面都是一帧，一个GOP就是很多帧的集合
-
直播的数据其实就是一组图片，包括I帧、P帧和B帧，当用户第一次观看的时候就会寻找I帧
-
播放器会到服务器寻找最近的I帧反馈给用户，也正是如此，GOP Cache导致了端到端的延迟，因为它必须拿到最近的I帧
-
GOP Cache的长度越长，画面质量越好
-
-
码率
-
图片进行压缩后每秒显示的数据量
-
-
帧率
-
每秒显示的图片数量，影响画面的流畅度、二者成正比
-
-
视频封装格式
-
一种存储视频信息的容器，流式封装可以由TS、FLV等，索引式封装有MP4、MOV、AVI等
-
5.1.2 相关技术手段
-
音视频采集数据的格式
-
音频采集的数据一般都是PCM的格式
-
视频采集的数据一般都是YUV或RGB格式，采集到的原始数据体积非常大，需要通过压缩技术处理来提高传输效率
-
-
视频处理
-
视频图像处理
-
视频最终都是通过GPU，一帧一帧的渲染到屏幕上的，因此可以通过OpenGL ES对视频进行各种加工处理以达到不同的效果
-
现在视频中的美颜、特效等大多都是通过GPUImage这个框架实现的
-
OpenGL(Open Graphics Library)是定义了一个跨编程语言、跨平台的编程接口的底层图形库
-
OpenGL ES (OpenGL for Embedded Systems) 是 OpenGL三维图形 API 的子集，针对手机、 Pad和游戏主机等嵌入式设备而设计
-
-
视频编码框架
-
FFmpeg：是一个跨平台的开源视频框架，可以实现如视频编码、解码、转码、串流、播放等丰富的功能，其支持的视频格式和播放协议非常丰富
-
X264：将视频原数据YUV编码压缩成H.264格式
-
videoToolbox：苹果自带的视频硬解码和硬编码API，但是是在iOS8之后才开放
-
audioToolbox：苹果自带的音频硬解码和硬编码API
-
硬解码：用GPU来解码，减少CPU运算
-
优点：播放流畅、低功耗、解码速度快
-
缺点：兼容性好
-
-
软解码：用CPU来解码
-
优点：兼容好
-
缺点：加大CPU负担，好点==耗电增加、没有硬解码流畅，解码速度相对较慢
-
-
-
-
视频编码技术
-
主要作用：是将视频像素数据压缩成视频码流，从而降低视频的数据量
-
视频压缩编码标准：对视频进行压缩或解压缩的编码技术，如MPEG、H.264等
-
MPEG：是一种视频压缩方式，采用了帧间压缩，仅存储连续帧之间有差别的地方，从而达到较大的压缩比，优势在于单个画面清晰度较高
-
H.264/AVC：是一种视频的压缩方式，采用事先预测和MPEG中的P-B帧一样的帧预测方法压缩，可以根据需要产生适合网络情况的视频流，有更高的压缩比和更好的图像质量，优势在于动画连贯性上的清晰度，但是对系统要求更高
-
-
-
视频封装格式
-
TS：一种流媒体封装格式，流媒体的封装可以实现不需要加载索引就可以进行播放，大大减少了首次载入的延迟，当视频较长时，非TS类的视频的索引会相当大，影响用户体验
-
两个TS片段之间可以无缝拼接，播放器可以实现连续播放
-
-
FLV：一种流媒体封装格式，由于其形成的文件极小，加载速度极快，使其成为较主流的流视频格式
-
-
-
直播推流相关
-
数据传输框架
-
librtmp：用来传输RTMP协议格式的数据
-
RTMP(实时消息传输协议)：由Adobe公司为Flash播放器开发的协议，该协议建立在TCP协议或轮训HTTP协议之上
-
-
-
推流过程
-
建立TCP连接
-
建立RTMP链接，发送各种控制指令
-
获取原始视频和音频数据
-
对原始音视频数据进行压缩编码(视频编码为h264，音频编码为AAC)
-
对编码后的音视频数据进行打包
-
发送打包后的音视频数据
-
-
-
数据拉流相关
-
直播协议选择
-
即时性要求较高或有互动需求的可以采用RTMP或RTSP
-
有回放或跨平台需求的，推荐使用HLS
-
-
直播协议对比
-
HLS是基于HTTP协议实现，传输内容包括两部分，一是M3U8描述文件、二是TS媒体文件，可实现流媒体的直播或点播，主要用于iOS
-
HLS是以点播的技术方式来实现直播
-
HLS是
自适应码率，客户端会根据网络状况自动选择不同码率的视频流，条件允许的情况下会使用高码率 -
HLS主要是延时比较大，RTMP的优势在于延时低，且HLS协议的小切片会生成大量的文件，存储和处理这些文件或造成大量的资源浪费
-
-
-
-
流媒体服务器相关
-
数据分发方式
-
CDN(Content Delivery Network)，即内容分发网络，一个代理服务器，相当于一个中介，将网站的内容分发到最接近用户的网络“边缘”，提高用户访问网站的相应速度
-
CDN工作原理(如请求流媒体数据)
-
上传流媒体数据到服务器
-
服务器存储流媒体数据
-
客户端播放流媒体，向CDN请求编码后的流媒体数据
-
CDN的服务器响应请求，当当前节点上没有所请求的流媒体数据，则向源站继续请求
-
若节点上存在所请求的流媒体数据，CDN就将流媒体数据发送到客户端
-
若不存在所请求的流媒体数据或数据已过期，CDN节点将会请求上一级的源站获取数据，源站响应CDN的请求，将流媒体数据分发到相应的CDN节点上
-
-
CDN获取到流媒体数据后将其发送给客户端
-
-
-