视频直播的流程可以分为如下几步：
1.采集 —>处理—>编码和封装
2.推流到服务器—>服务器流分发
3.播放器流播放
图解：
一.采集
采集是整个视频推流过程中的第一个环节，它从系统的采集设备中获取原始视频数据，将其输出到下一个环节。
视频的采集涉及两方面数据的采集：音频采集和图像采集，它们分别对应两种完全不同的输入源和数据格式。
1.音频采集
音频数据既能与图像结合组合成视频数据，也能以纯音频的方式采集播放。
音频的采集过程：通过设备将环境中的模拟信号采集成 PCM 编码的原始数据，然后编码压缩成 MP3 等格式的数据。
常见的音频压缩格式有：MP3，AAC，HE-AAC，Opus，FLAC，Vorbis (Ogg)，Speex 和 AMR等。
音频采集和编码主要的挑战：延时敏感、卡顿敏感、噪声消除（Denoise）、回声消除（AEC）、静音检测（VAD）和各种混音算法等。
2.图像采集
将图像采集的图片结果组合成一组连续播放的动画，即构成视频中可肉眼观看的内容。
视频采集的采集源：摄像头采集、屏幕录制和从视频文件推流等。
图像的采集过程：主要由摄像头等设备拍摄成 YUV 编码的原始数据，然后经过编码压缩成 H.264 等格式的数据。
常见的视频封装格式有：MP4、3GP、AVI、MKV、WMV、MPG、VOB、FLV、SWF、MOV、RMVB 和 WebM 等。
图像采集和编码的主要挑战：设备兼容性差、延时敏感、卡顿敏感以及各种对图像的处理操作如美颜和水印等。
部分方案介绍
方案一： 通过android Camera拍摄预览中设置setPreviewCallback实现onPreviewFrame接口，实时截取每一帧视频流数据
方案二： 通过android 的MediaRecorder，在SetoutputFile函数中绑定LocalSocket实现
方案三： 流媒体服务器方式，利用ffmpeg或GetStreamer等获取Camera视频
方案四： 待补充...
二.处理
视频或者音频完成采集之后得到原始数据，为了增强一些现场效果或者加上一些额外的效果，我们一般会在将其编码压缩前进行处理，比如打上时间戳或者公司 Logo 的水印，祛斑美颜和声音混淆等处理。
在主播和观众连麦场景中，主播需要和某个或者多个观众进行对话，并将对话结果实时分享给其他所有观众，连麦的处理也有部分工作在推流端完成。
处理环节中分为音频和视频处理，音频处理中具体包含混音、降噪和声音特效等处理，视频处理中包含美颜、水印、以及各种自定义滤镜等处理。
三.编码和封装（压缩）
（1）编码
如果把整个流媒体比喻成一个物流系统，那么编解码就是其中配货和装货的过程，这个过程非常重要，它的速度和压缩比对物流系统的意义非常大，影响物流系统的整体速度和成本。
同样，对流媒体传输来说，编码也非常重要，它的编码性能、编码速度和编码压缩比会直接影响整个流媒体传输的用户体验和传输成本。
-
视频编码的意义
原始视频数据存储空间大，一个 1080P 的 7s 视频需要 817 MB
原始视频数据传输占用带宽大，10 Mbps 的带宽传输上述 7s 视频需要 11 分钟
而经过 H.264 编码压缩之后，视频大小只有 708k ，10 Mbps 的带宽仅仅需要 500ms ，可以满足实时传输的需求，所以从视频采集传感器采集来的原始视频势必要经过视频编码。
|
|
原始视频 |
H.264编码压缩 |
| 清晰度 |
1080P |
1080P |
| 时长 |
7s |
7s |
| 大小 |
>800M |
<750K |
| 网速 |
10Mbps |
10Mbps |
| 上传时间 |
>10min |
<1s |
-
基本原理
为什么巨大的原始视频可以编码成很小的视频呢?这其中的技术是什么呢?核心思想就是去除冗余信息：
1）空间冗余：图像相邻像素之间有较强的相关性
2）时间冗余：视频序列的相邻图像之间内容相似性
3）编码冗余：不同像素值出现的概率不同
4）视觉冗余：人的视觉系统对某些细节不敏感
5）知识冗余：规律性的结构可由先验知识和背景知识得到 -
编码器的选择
视频编码器经历了数十年的发展，已经从开始的只支持帧内编码演进到现如今的 H.265 和 VP9 为代表的新一代编码器，下面是一些常见的视频编码器：
1）H.264/AVC
2）HEVC/H.265
3）VP8
4）VP9
5）FFmpeg
注：音频编码器有Mp3, AAC等。
压缩编码部分方案介绍
方案一： 不编码，直接通过Socket传输原始YUV420SP视频帧
方案二： JPEG. 将原始YUV420SP视频帧压缩转换为JPEG格式，JPEG传输
方案三： H.264/AVC.将原始YUV420SP视频帧压缩成H.264再传输
常见的基于H264的开源Encoder有JM、X264、T264、Hdot264等
方案四： MPEG4.将原始YUV420SP视频帧压缩成MPEG4再传输
方案五： 待补充...
（2）封装
沿用前面的比喻，封装可以理解为采用哪种货车去运输，也就是媒体的容器。
所谓容器，就是把编码器生成的多媒体内容(视频，音频，字幕，章节信息等)混合封装在一起的标准。
容器使得不同多媒体内容同步播放变得很简单，而容器的另一个作用就是为多媒体内容提供索引，也就是说如果没有容器存在的话一部影片你只能从一开始看到最后，不能拖动进度条，而且如果你不自己去手动另外载入音频就没有声音。
下面是几种常见的封装格式：
1）AVI 格式(后缀为 .avi)
2）DV-AVI 格式(后缀为 .avi)
3）QuickTime File Format 格式(后缀为 .mov)
4）MPEG 格式(文件后缀可以是 .mpg .mpeg .mpe .dat .vob .asf .3gp .mp4等)
5）WMV 格式(后缀为.wmv .asf)
6）Real Video 格式(后缀为 .rm .rmvb)
7）Flash Video 格式(后缀为 .flv)
8）Matroska 格式(后缀为 .mkv)
9）MPEG2-TS 格式 (后缀为 .ts)
注：目前，我们在流媒体传输中，尤其是直播中主要采用的就是 FLV 和 MPEG2-TS 格式，分别用于 RTMP/HTTP-FLV 和 HLS 协议。
四.推流到服务器
推流是直播的第一公里，直播的推流对整个直播链路影响非常大，如果推流的网络不稳定，无论如何做优化，观众的体验都会很糟糕。所以也是我们排查问题的第一步，如何系统地解决这类问题需要我们对相关理论有基础的认识。
1.推送协议：
RTSP（Real Time Streaming Protocol）：实时流传送协议，是用来控制声音或影像的多媒体串流协议, 由Real Networks和Netscape共同提出的；
RTMP(Real Time Messaging Protocol)：实时消息传送协议，是Adobe公司为Flash播放器和服务器之间音频、视频和数据传输 开发的开放协议；
HLS(HTTP Live Streaming)：是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议；
2.RTMP协议介绍（主流）
RTMP 是目前主流的流媒体传输协议，广泛用于直播领域，可以说市面上绝大多数的直播产品都采用了这个协议。
它基于 TCP，是一种设计用来进行实时数据通信的网络协议，主要用来在平台（flash/AIR ）和支持 RTMP 协议的流媒体/交互服务器之间进行音视频和数据通信。
支持该协议的软件包括 Adobe Media Server/Ultrant Media Server/red5 等。
它有三种变种：
RTMP工作在TCP之上的明文协议，使用端口1935；
RTMPT封装在HTTP请求之中，可穿越防火墙；
RTMPS类似RTMPT，但使用的是HTTPS连接；
RTMP协议就像一个用来装数据包的容器，这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据。
一个单一的连接可以通过不同的通道传输多路网络流。这些通道中的包都是按照固定大小的包传输的。
传输方案
方案一： Socket传输
方案二： HTTP传输
方案三： RTP/RTSP传输
方案四： 流媒体服务器方式，如live555等
方案五： 待补充...
五.服务器流分发
流媒体服务器的作用：1.直播流的发布 2.转播分发功能
流媒体服务器有诸多选择，如商业版的Wowza。
不过学习可以选择的是Nginx，它是一款优秀的免费Web服务器，
搭建Nginx服务器在下篇文章介绍。
六.播放器流播放
1.解码
播放前首先要解码，类似拆开快递的过程。这个只要选择与编码对应的解码器即可。
2.播放
解码之后就可以直接播放了。
比如使用的传输协议是RTMP， 所以只要支持 RTMP 流协议的播放器都可以使用，如：
- 电脑端：VLC等
- 手机端：Vitamio以及ijkplayer等
第一部分：视频主播端的操作，即采集、处理、编码与封装、推流到流媒体服务器
第二部分：流媒体服务器，负责把从第一部分接收到的流进行处理并分发给观众。
第三部分：观众，只需要拥有支持流传输协议的播放器即可。
分享一下网上看到的几套方案
以320×240大小的视频传输为例
| 方案 | 压缩率 | 压缩/传输方式 | 实时性 | 平均流量消耗 | 传输距离 |
| 用camera的回调函数发送原始的yuv420数据 | 0 | 无压缩，按帧传输 | 高(20~30 fps) | 很高(6.5 Mbps)太恐怖了O_O | 近距离有线或无线 |
| 用MediaRecorder对yuv420进行H264硬编码后发送 | 高(95%) | 帧间压缩，视频流传输 | 高(20 fps) | 低(30~70 Kbps) | 可以远距离 |
| 调用本地H264编码库(JNI)对一帧YUV420数据编码后发送 | 高(97%) | 帧间压缩，按帧传输 | 低(2 fps) | 低(20 Kbps) | 可以远距离 |
| 对一帧数据用GZIP库压缩后发送（很奇葩的做法） | 较高(70%~80%) | 帧内压缩，按帧传输 | 低(5 fps) | 较高(300 Kbps) | 可以远距离 |
| 对一帧数据用JPEG方式压缩后传输 | 一般(60%左右) | 帧内压缩，按帧传输 | 高(25 fps) | 高(170 Kbps) | 可以远距离(带宽允许的话) |
参考链接：
https://blog.csdn.net/hjwang1/article/details/11237623
https://blog.csdn.net/huaxun66/article/details/53427771