直播流媒体协议中RTMP和HLS协议是我们比较熟悉的。RTMP（real-time message protocol）实时消息协议，上层基于TCP协议，因此具有稳定，可控等特性。在播放端时延上一般为3-5s。HLS（HTTP Live Stream）是Apple公司的动态码率自适应技术，支持点播和直播功能。以HTTP为基础，因此其穿透能力强、无论是点播还是直播，都是通过HTTP进行媒体流数据请求，但正是因为基于HTTP协议，我们知道，HTTP是用于文本请求的，所以无论是在点播还是在直播，都会对流进行切片，切成一个个适合的小分片，而这造成了在直播中，主播端播放的时候会有15s左右的延迟。这在直播体验上会有点差强人意。基于HLS的整体功能框架如下图2：
RTMP在直播中用的比较多，然而，在弱网环境下，上层基于TCP协议的缺点也暴露的比较明显。在弱网环境下，丢包的概率大大增加，基于TCP协议的丢包重传给带宽造成了更大的压力，加剧了网络拥塞。再者，直播的多样化需求、如连麦，如多人讨论等需求的提出，RTP（real-time transport protocol）协议族成了多样化直播的有利协议。若如果只是单纯使用RTP协议，还无法做到直播多样化的功能，RTP协议只是携带流媒体数据，而做到流媒体控制，当然还需要RTCP（real-time transport control protocol）协助。因此，现在多样化要求下的直播，大多基于WebRTC进行二次开发，或进行裁剪，或进行优化，或加入相关自定义插件。关于流媒体协议，会在流媒体协议系列中讲到。
WebRTC（Web Real-Time Communication）是一个基于网页浏览器进行实时语音对话或者视频对话的API。谷歌于2011年6月对WebRTC进行了开源。WebRTC提供了实时视频会议的核心技术。WebRTC架构如图3所示：WebRTC完成了从音视频采集到音视频播放的全过程。最重要的还完成了NAT穿越功能，为点对点音视频通信提供了基础。对于WebRTC这块，在WebRTC技术系列中会详细讲到。
WebRTC既然是点对点的，那么如果单纯的直播功能，能用WebRTC吗？答案是肯定的，从图3 WebRTC的框架图可以看到，WebRTC具备了音视频引擎，同时提供了网络传输方案，而直播无非就是音视频流数据传输，因此WebRTC是完全能做到的。搭建MCU（Multi-point Control Unit）或者SFU（Selective forward Unit）网络结构来解决一端客户端进行网络音视频传输到MCU或者SFU服务，继而由MCU或者SFU服务转发到用户端（直播中，用户一般称为粉丝端）。
实际上，目前好多公司即使是单纯的直播功能点也用到了WebRTC。可能有人会有疑问，单纯的直播为啥不直接使用RTMP。这其中主要有几个原因，一是WebRTC基于RTP协议，RTP上层基于UDP协议，这在弱网条件下，不会像RTMP一样，进行重复重传，加剧网络拥塞，而WebRTC通过各种技术来解决丢包问题。二是在后续直播功能扩展下更加方便快捷，如加入多人连麦功能等。当然，在扩展性上如连麦，rtmp也可以完成，但因为基于TCP需要进行三次握手，每次连接都产生了额外的RTT，存在高延迟的问题，因此rtmp方案是不太可取的。当然，一开始项目就使用了RTMP协议，并且也搭建了RTMP服务器，特别是整个大集团都在使用RTMP的时候，是不可能一刀切的从RTMP转到RTP的，因此就会有如下的RTP推流之后经过MCU再转RTMP的方案存在。
图 rtmp方案
图 rtp方案
一个完整的直播功能，一般包括主播端、粉丝端（播放端）、以及服务端。服务端涉及的功能很多，可能会分成不同功能的服务，但这里我们把这些功能统一为服务端。主播端，顾名思义，就是信息内容分享者，对话议题发起者，是音视频流发起的一端。粉丝端：既是观看主播信息的用户，是获取音视频流的一端。服务端：既充当接收流，保存流中间方，而且也是各种信号命令的控制者，如主播在直播过程中想发送优惠券，那么命令就通过服务器，继而发送给用户。三者的关系如下图4：这里主播推流的操作涉及的协议可以是RTMP（以RTMP为协议的流媒体传输）、HLS、或者RTP/RTCP等，也可以是先RTP，再转RTMP。根据业务情况进行，推流涉及的一些开源库可以是FFmpeg、WebRTC。
图 完整直播架构
前面说到，多样化直播功能需求下，主播侧基于RTP/RTCP协议进行流媒体传输。而粉丝侧是基于RTP或RTMP协议进行的流媒体传输。下图中是一个完整音视频拉流播放流程，根据开源库FFmpeg的执行流程来分析的，至于WebRTC的音视频播放则是直接通过RTP进行的，并没有像FFmpeg那样，根据不同的流媒体协议来进行。一般情况下，在多样化直播中，播放端一般都是在FFmpeg开源库进行开发。实际上，FFmpeg也具备推流能力，只不过因为WebRTC天然的视频通话能力，在多样化直播需求中显然更具备优势。因此，一般情况下，推流直接基于WebRTC、拉流基于FFmpeg。FFmpeg的拉流流程如下图所示，如根据RTMP协议进行流传输，确定流文件为何种格式，由特定的格式进行相关的处理、进行音频视频解码、渲染播放。关于FFmpeg这块，将在FFmpeg进行详细分析。
多样化直播涉及的内容链路主要包括流媒体协议, 协议选择，根据媒体信息选择封装格式、根据音频和视频数据，分解出编解码格式、得出编解码数据之后，推流的进行发送，拉流进行渲染播放。关于音频处理中，发送端，涉及采集----> 3A处理 ——>发送 ， 接送方，接收丢包恢复 ——> NetEQ缓存解码——> 混音播放，这其中，涉及各种算法，包括卡尔曼滤波算法、3A、NetEQ等。 关于视频处理，发送端，涉及摄像头采集——> 编码（v8，h264）——>发送，接收方，接收丢包恢复——> jitterbuffer——>解码——>屏幕显示。在音视频的传输过程中，涉及到FEC、延迟丢包重传等算法。
