本篇主要介绍直播系统的核心工作流程。直播与普通点播视频最大的区别在于其实时性，这要求系统在数据的采集、传输、处理和分发每一个环节都要进行低延迟优化。本篇将详细拆解推流、拉流、转码以及 CDN 分发等核心环节。
推流
客户端（通常是主播端 / 摄像头端）把采集到的音视频数据 主动发送 到流媒体服务器。 常见协议：RTMP、SRT、WebRTC（上行）
拉流
客户端（观众端）从流媒体服务器 请求并接收 音视频数据，用来播放。 常见协议：RTMP、FLV、HLS、WebRTC（下行）、HTTP-FLV
直播工作原理
直播的工作原理大体上和视频工作原理相同，直播与视频文件转码的最大区别是封装格式上。
直播需要在直播源接收以及直播输出这一头一尾做特殊处理，一般情况下，直播需要从网络接收直播源的视频数据，也需要把处理后的数据输出到网络上，所以在直播系统中，除了视频转码程序之外，还需要两个流媒体服务，一个用于获取直播源数据，转码程序从这个流媒体服务中拉取视频流处理，另一个用于用户拉取视频流观看，转码程序会不断将处理完的视频数据推送到这个流媒体中。
流媒体服务的具体软件根据不同的视频流协议而不同，如果直播推流协议和直播观看协议是相同的话，也可以只用一个流媒体服务；流媒体服务就是视频流的中转站，流媒体服务会在内存中实时存储视频流的一部分数据，随着时间的推移，数据会被循环覆盖。
直播源数据获取
由于具体协议和应用场景的不同，直播源获取方式会有一些区别。
比如直播平台直播的场景下，主播需要将视频流推送到直播平台的流媒体服务上，协议一般为RTMP，流媒体服务软件可以是SRS，加入了rtmp-server的nginx等等。
如果是转播的场景，则不需要自身系统的流媒体服务参与接收，视频转码软件直接拉取对方的数据流即可。实际上就是直接拉去对方系统的流媒体服务的视频流数据，此时的协议可能是RTMP，HLS，HTTP-FLV，RTSP等等，无论什么协议，只要自身的视频转码软件支持这个协议就可以了。
还有一种场景是文件直播，业务上称为录播，其实就是直播源是视频文件，这种场景下也不需要流媒体服务参与接收，只需要视频转码软件按播放时间慢慢读取就可以了。
直播转码
也就是视频转码，这里可以对直播流加上水印，高清/流畅转换，码率限制，直播录像等等。 直播转码程序其实与视频文件转码程序差别不大，如高清/流畅转码，码率限制等，甚至可以通过设置一些流媒体服务软件就可以实现了。如果不需要任何转码处理，且没有安全权限等设置的话是可以直接从流媒体服务中拉取视频流观看的，且推流和观看地址一般是一样的。研发直播转码程序的意义在于一些高级功能，如直播倒计时，信号中断自动补帧，导播/轮播，画中画等，这部分正是一个直播的技术核心。毕竟流媒体服务软件一般是与协议绑定且现成的。
业务数据同步：SEI 消息
在互动直播（如带货、在线答题）中，画面与业务数据的绝对同步至关重要。
- 问题：如果通过 WebSocket 发送指令，由于视频拉流存在 2-5s 延迟，会导致画面还没到，红包/题目先弹出的尴尬。
- 原理：利用 SEI (Supplemental Enhancement Information) 将业务数据嵌入视频帧中。
- 前端实现：前端播放器解析每一帧自带的 SEI 字符串，触发对应的 UI 弹出，确保“画到即事到”。
直播流输出及直播CDN
在处理完视频源后，需要将视频数据输出到流媒体服务，用户从流媒体服务中拉取视频流数据就可以观看了，直播流观看的协议一般是HTTP-FLV，HLS等，如果是延迟度要求高，则一般使用RTMP、WEBRTC等。RTMP协议目前主流浏览器是不支持的（禁用了flash）
用户直接拉取流媒体服务的视频流是可以观看的，但是这样占用的带宽是很大的，视频码率的单位和带宽的单位是一样的，如果视频流的码率是2mbps，服务器的带宽是100mbps，理论上支持50人在线观看的，如果观看人数过多，则需要使用直播CDN。
直播CDN
直播CDN实际上也可以看作是流媒体服务，只是他有很多边缘节点，分摊了请求压力，如果使用直播CDN,视频转码软件直接将视频流数据输出到直播CDN即可，一般是通过RTMP协议推送到CDN服务，当然也有主动拉取的CDN服务，但主动拉取的CDN服务不建议使用，因为主动拉取的CDN服务可能会存在多个服务器回源，很难准确预估带宽的需要。
直播CDN一般提供自动转观看协议的功能，一般会提供RTMP、WEBRTC、HTTP-FLV，HLS等协议的观看地址，但一般直播CDN不提供转码服务，如高清，流畅转换，一般需要额外的直播转码云服务或自己的视频转码软件。因为观看协议转换实际上就是视频转码中的重封装，是不怎么消耗性能的。但是转码是非常消耗性能的，一般视频转码的云服务都是按时间计算费用。
