本文来自于腾讯bugly开发者社区，非经作者同意，请勿转载，原文地址：http://dev.qq.com/topic/5811d42e7fd6ec467453bf58
作者：李智文
分享内容：
互联网内容载体变迁历程，文字——图片/声音——视频——VR/AR——…….。从直播1.0秀场时代（YY），2.0游戏直播（斗鱼、虎牙、熊猫）到如今全民直播3.0泛生活娱乐时代（映客、花椒），国外直播app（Meerkat 、Periscope），随着VA/AR/MR提出的沉浸式视听体验，直播4.0时代很快就能到来。
在这个全民娱乐的时代，直播已经火得不要不要的，各大公司都有自己的直播产品。本文主要从直播的一些基本知识,一步步打造直播app。直播那么火的背后有什么样的技术支撑呢？
先将这些APP按照视频网站按照视频网站、弹幕视频、直播平台、在线秀场、移动短视频、移动直播来划分类别。再按照内容和社交这个维度来进行区分，可以明显看出视频网站、弹幕网站和直播平台更偏内容，他们对内容的需求更加高，用户在上面进行社交沉淀相对比较浅。
而后面三者更加偏向社交，他们强调人而不强调内容。所以短期内不会有大的竞争关系，只是前三类、后三者之间的竞争会出现。
大体框架
基本是下图这个套路：
录制->编码->网络传输->解码->播放
以上为直播的整体流程，根据该流程分为以下技术点：
PC直播（固定场所）——>移动端（形式自由）。
随着越来越多的直播类 App 上线，移动直播进入了前所未有的爆发阶段，目前大多数移动直播以 Native 客户端为主。但是H5端的直播在移动直播端也承载着不可替代的作用，例如 H5 有着传播快，易发布的优势。
完整的直播包括：
如何生产视频数据
封装格式的主要作用是把视频码流和音频码流按照一定的格式存储在一个文件中。
为什么要分封装格式和视频编码格式呢？
这个其实跟网络分七层模型一个原理。解耦和，降低依赖，底层给上层提供基础功能，底层和上层都都可以单独扩展，可以以多种方案组合编码与封装，比如MP4与H264、MP4与MPEG、TS与H264等等。比如这里面的这边文章的编码就只负责将最原始的音频和视频数据就行压缩，而压缩完的数据要怎么组织就拜托给上层的封装，封装接到视频音频数据负责给数据编号，指定同步协议，加入字幕等操作。经过封装后，得到的就是可以播放的上面提到的视频文件MP4或者MKV等等。把这个过程反过来就是上图描述的视频播放的过程。
PC端的摄像头、屏幕
对于PC端的流媒体源，可以使用Open Broadcaster Software串流（支持多种直播平台）。
移动端iOS、Android的摄像头和麦克风。
iOS、Android主要是系统提供的API实现。
webRTC （Web Real-Time Communication）
webRTC是一个支持网页浏览器进行实时语音对话或视频对话的技术，可以在网页浏览器中进行采集、传输、播放，缺点是只在 PC 的 Chrome 上支持较好，移动端支持不太理想。
使用 webRTC 录制视频基本流程是：
window.navigator.webkitGetUserMedia() 获取用户的PC摄像头视频数据。window.webkitRTCPeerConnection (一种视频流数据格式)。webscoket将视频流数据传输到服务端由于许多方法都要加上浏览器前缀，所以很多移动端的浏览器还不支持 webRTC，所以真正的视频录制还是要靠客户端（iOS,Android）来实现,效果会好一些。
推荐Andorid4.3（API18）或以上使用硬编，以下版本使用软编；iOS使用全硬编方案。
FLV（Flash Video）是Adobe公司设计开发的一种流行的流媒体格式，FLV可以使用Flash Player进行播放，FLV封装格式的文件后缀通常为“.flv”。总体上看，FLV包括文件头（File Header）和文件体（File Body）两部分，其中文件体由一系列的Tag组成。
特点：视频文件体积轻巧、封装简单
每个Tag前面还包含了Previous Tag Size字段，表示前面一个Tag的大小。Tag的类型可以是视频、音频和Script，每个Tag只能包含以上三种类型的数据中的一种。图2展示了FLV文件的详细结构。
Tag Data
Audio Tag
Video Tag
Script Tag（控制帧）或叫meta data tag
该类型Tag又通常被称为Metadata Tag，会放一些关于FLV视频和音频的元数据信息如：duration、width、height等。通常该类型Tag会跟在File Header后面作为第一个Tag出现，而且只有一个。
如图以Android为例的推流的流程图：
如何推
往哪里推
国内常见公开的直播协议有几个：RTMP、HDL（HTTP-FLV）、HLS、RTP。
Real Time Messaging Protocol是 Macromedia 开发的一套视频直播协议，现在属于 Adobe。
使用RTMP技术的流媒体系统有一个非常明显的特点：使用 Flash Player 作为播放器客户端，而Flash Player 现在已经安装在了全世界将近99%的PC上，因此一般情况下收看RTMP流媒体系统的视音频是不需要安装插件的。用户只需要打开网页，就可以直接收看流媒体。
和 HLS 一样都可以应用于视频直播，区别是 RTMP 基于 flash 无法在 iOS 的浏览器里播放，但是实时性比 HLS 要好。所以一般使用这种协议来上传视频流，也就是视频流推送到服务器。
rtmp现在大部分国外的CDN已不支持，在国内流行度很高。原因有几个方面：
即使用HTTP协议流式的传输媒体内容，直接向后台上传编码后的流媒体数据。相对于RTMP，HTTP更简单和广为人知，而且不担心被Adobe的专利绑架。内容延迟同样可以做到2~5秒，打开速度更快，因为HTTP本身没有复杂的状态交互。所以从延迟角度来看，HTTP-FLV要优于RTMP。
SRS2.0支持该协议：GitHub
即Http Live Streaming，是由苹果提出基于HTTP的流媒体传输协议。HLS有一个非常大的优点：HTML5可以直接打开播放；这个意味着可以把一个直播链接通过微信等转发分享，不需要安装任何独立的APP，有浏览器即可，所以流行度很高。社交直播APP，HLS可以说是刚需 。
Issue：SRS3.0提出了一种增强型HLS+
Real-time Transport Protocol，用于Internet上针对多媒体数据流的一种传输层协议。
实际应用场景下经常需要RTCP（RTP Control Protocol）配合来使用，可以简单理解为RTCP传输交互控制的信令，RTP传输实际的媒体数据。
RTP在视频监控、视频会议、IP电话上有广泛的应用，因为视频会议、IP电话的一个重要的使用体验：内容实时性强。
对比与上述3种或实际是2种协议，RTP和它们有一个重要的区别就是默认是使用UDP协议来传输数据，而RTMP和HTTP-FLV是基于TCP协议传输。
实时音视频流的场景不需要可靠保障，因此也不需要有重传的机制，实时的看到图像声音，网络抖动时丢了一些内容，画面模糊和花屏，完全不重要。TCP为了重传会造成延迟与不同步，如某一截内容因为重传，导致1秒以后才到，那么整个对话就延迟了1秒，随着网络抖动，延迟还会增加成2秒、3秒，如果客户端播放是不加以处理将严重影响直播的体验。
是否有除了HLS外更低延迟的方案？
HLS的优点点是显而易见的：移动端无需安装APP使用兼容HTML5的浏览器打开即可观看，所有主流的移动端浏览器基本都支持HTML5，在直播的传播和体验上有巨大的优势。
下面是 HTTP-FLV、HLS 、 RTMP 的对比：
所谓推流，就是将我们已经编码好的音视频数据发往视频流服务器中，常用的第三方库 librtmp-iOS 进行推流，librtmp 封装了一些核心的 API 供使用者调用。例如推流 API 等等，配置服务器地址，即可将转码后的视频流推往服务器。一般的推流服务器都配置了服务器端信息。
百度云推流SDK: 官方文档
七牛推流SDK: Github上的官方源码及说明
网易云推流SDK：官方文档
腾讯云推流SDK：官方文档
其他推流SDK：
https://github.com/daniulive/SmarterStreaming
https://github.com/leixiaohua1020/simplest_ffmpeg_mobile
https://github.com/begeekmyfriend/yasea
https://github.com/simple-rtmp-server/srs-sea
那么如何搭建一个推流服务器呢？
简单的推流服务器搭建，服务器支持 RTMP ，大概需要以下几个步骤：
下面是 nginx 的配置文件
[后台SDK]主要是调用腾讯云API。
[服务器API]提供了直播控制台api概览：
腾讯云直播方案整体流程
方案根据腾讯云的快速对接，最终形成闭环逻辑。
如何看
下载直播视频有以下方式：
1. HLS
2. rtmp
3. flv
好看的指标参数
码率：影响体积，与体积成正比：码率越大，体积越大；码率越小，体积越小。
帧率：影响画面流畅度，与画面流畅度成正比：帧率越大，画面越流畅；帧率越小，画面越有跳动感。如果码率为变量，则帧率也会影响体积，帧率越高，每秒钟经过的画面越多，需要的码率也越高，体积也越大。
分辨率：影响图像大小，与图像大小成正比：分辨率越高，图像越大；分辨率越低，图像越小。
对于H5视频播放，可以使用 HLS(HTTP Live Streaming)协议播放直播流，iOS和 Android 都天然支持这种协议，配置简单，直接使用 video 标签即可。
使用 video在移动客户端上播放直播视频：
<video controls autoplay>
<source src="xxx.m3u8" type="application/vnd.apple.mpegurl"/>
</video>HLS是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。
HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。
HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。
由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点决定了延迟一般总是会高于普通的流媒体直播协议。
每一个 .m3u8 文件，分别对应若干个 ts 文件，这些 ts 文件才是真正存放视频的数据，m3u8 文件只是存放了一些 ts 文件的配置信息和相关路径，当视频播放时，.m3u8 是动态改变的，video 标签会解析这个文件，并找到对应的 ts 文件来播放，所以一般为了加快速度，.m3u8 放在 Web 服务器上，ts 文件放在 CDN 上。
支持的视频流编码为H.264，音频流编码为AAC。
简单讲就是把整个流分成一个个小的，基于 HTTP 的文件来下载，每次只下载一些，前面提到了用于 H5 播放直播视频时引入的一个 .m3u8 的文件，这个文件就是基于 HLS 协议，存放视频流元数据的文件。
.m3u8 文件，其实就是以 UTF-8 编码的 m3u 文件，这个文件本身不能播放，只是存放了播放信息的文本文件。
打开之后就是这个样子：
#EXTM3U m3u文件头，必须放在第一行
#EXT-X-MEDIA-SEQUENCE 第一个TS分片的序列号
#EXT-X-TARGETDURATION 每个分片TS的最大的时长
#EXT-X-ALLOW-CACHE 是否允许cache
#EXT-X-ENDLIST m3u8文件结束符
#EXTINF extra info，分片TS的信息，如时长，带宽等#EXTM3U
#EXT-X-TARGETDURATION:11
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:10.133333,
fileSequence0.ts
#EXTINF:10.000666,
fileSequence1.ts
#EXTINF:10.667334,
fileSequence2.ts
#EXTINF:9.686001,
fileSequence3.ts
#EXTINF:9.768665,
fileSequence4.ts
#EXTINF:10.000000,
fileSequence5.ts
#EXT-X-ENDLISTts 文件，就是存放视频的文件：
HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。
我们知道 hls 协议是将直播流分成一段一段的小段视频去下载播放的，所以假设列表里面的包含5个 ts 文件，每个 TS 文件包含5秒的视频内容，那么整体的延迟就是25秒。因为当你看到这些视频时，主播已经将视频录制好上传上去了，所以时这样产生的延迟。当然可以缩短列表的长度和单个 ts 文件的大小来降低延迟，极致来说可以缩减列表长度为1，并且 ts 的时长为1s，但是这样会造成请求次数增加，增大服务器压力，当网速慢时回造成更多的缓冲，所以苹果官方推荐的 ts 时长时10s，所以这样就会大改有30s的延迟。所以服务器接收流，转码，保存，切块，再分发给客户端，这里就延时的根本原因。
更多关于延迟的问题可以参考苹果官方地址：
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html
但是 H5 直播视频却有一些不可替代的优势:
RTMP协议是应用层协议，是要靠底层可靠的传输层协议（通常是TCP）来保证信息传输的可靠性的。在基于传输层协议的链接建立完成后，RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的NetConnection链接，在Connection链接上会传输一些控制信息，如SetChunkSize,SetACKWindowSize。其中CreateStream命令会创建一个NetStream链接，用于传输具体的音视频数据和控制这些信息传输的命令信息。他们的关系如图所示：
RTMP协议传输时会对数据做自己的格式化，这种格式的消息我们称之为RTMP Message，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message划分为带有Message ID的Chunk，每个Chunk可能是一个单独的Message，也可能是Message的一部分，在接受端会根据chunk中包含的data的长度，message id和message的长度把chunk还原成完整的Message，从而实现信息的收发。
RTMP在收发数据的时候并不是以Message为单位的，而是把Message拆分成Chunk发送，而且必须在一个Chunk发送完成之后才能开始发送下一个Chunk。每个Chunk中带有MessageID代表属于哪个Message，接受端也会按照这个id来将chunk组装成Message。
举个例子
chunk表示例1
首先包含第一个Message的chunk的Chunk Type为0，因为它没有前面可参考的chunk，timestamp为1000。type为0的header占用11个字节，假定CSID为3<127，因此Basic Header占用1个字节，再加上Data的32个字节，因此第一个chunk共44＝11+1+32个字节。
第二个chunk和第一个chunk的CSID，TypeId，Data的长度都相同，因此采用Chunk Type＝2，timestamp delta＝1020-1000＝20，因此第二个chunk占用36=3+1+32个字节。
第三个chunk和第二个chunk的CSID，TypeId，Data的长度和时间戳差都相同，因此采用Chunk Type＝3省去全部Message Header的信息，占用33=1+32个字节。
第四个chunk和第三个chunk情况相同，也占用33=1+32个字节。
最后实际发送的chunk如下：
chunk表示例2
注意到Data的Length＝307>128,因此这个Message要切分成几个chunk发送，第一个chunk的Type＝0，Timestamp＝1000，承担128个字节的Data，因此共占用140=11+1+128个字节。
第二个chunk也要发送128个字节，其他字段也同第一个chunk，因此采用Chunk Type＝3，此时时间戳也为1000，共占用129=1+128个字节。
第三个chunk要发送的Data的长度为307-128-128=51个字节，还是采用Type＝3，共占用1+51＝52个字节。
最后实际发送的chunk如下：
Q:为什么RTMP要将Message拆分成不同的Chunk呢？
A:通过拆分，数据量较大的Message可以被拆分成较小的“Message”，这样就可以避免优先级低的消息持续发送阻塞优先级高的数据，比如在视频的传输过程中，会包括视频帧，音频帧和RTMP控制信息，如果持续发送音频数据或者控制数据的话可能就会造成视频帧的阻塞，然后就会造成看视频时最烦人的卡顿现象。同时对于数据量较小的Message，可以通过对Chunk Header的字段来压缩信息，从而减少信息的传输量。
阻塞 vs. CPU
Chunk的默认大小是128字节，在传输过程中，通过一个叫做Set Chunk Size的控制信息可以设置Chunk数据量的最大值，在发送端和接受端会各自维护一个Chunk Size，可以分别设置这个值来改变自己这一方发送的Chunk的最大大小。大一点的Chunk减少了计算每个chunk的时间从而减少了CPU的占用率，但是它会占用更多的时间在发送上，尤其是在低带宽的网络情况下，很可能会阻塞后面更重要信息的传输。小一点的Chunk可以减少这种阻塞问题，但小的Chunk会引入过多额外的信息（Chunk中的Header），少量多次的传输也可能会造成发送的间断导致不能充分利用高带宽的优势，因此并不适合在高比特率的流中传输。在实际发送时应对要发送的数据用不同的Chunk Size去尝试，通过抓包分析等手段得出合适的Chunk大小，并且在传输过程中可以根据当前的带宽信息和实际信息的大小动态调整Chunk的大小，从而尽量提高CPU的利用率并减少信息的阻塞机率。
来源于《带你吃透RTMP》
播放一个RTMP协议的流媒体需要经过以下几个步骤：握手，建立连接，建立流，播放。RTMP连接都是以握手作为开始的。建立连接阶段用于建立客户端与服务器之间的“网络连接”；建立流阶段用于建立客户端与服务器之间的“网络流”；播放阶段用于传输视音频数据。
一个RTMP连接以握手开始，双方分别发送大小固定的三个数据块
1. 握手开始于客户端发送C0、C1块。服务器收到C0或C1后发送S0和S1。
2. 当客户端收齐S0和S1后，开始发送C2。当服务器收齐C0和C1后，开始发送S2。
3. 当客户端和服务器分别收到S2和C2后，握手完成。
理论上来讲只要满足以上条件，如何安排6个Message的顺序都是可以的，但实际实现中为了在保证握手的身份验证功能的基础上尽量减少通信的次数，一般的发送顺序是这样的：
1. Client发送C0+C1到Sever
2. Server发送S0+S1+S2到Client
3. Client发送C2到Server，握手完成
服务器在收到客户端发送的连接请求后发送如下信息：
主要是告诉客户端确认窗口大小，设置节点带宽，然后服务器把“连接”连接到指定的应用并返回结果，“网络连接成功”。并且返回流开始的的消息（Stream Begin 0）。
对于直播中的用户交互大致可以分为：
1. 送礼物
2. 发表评论或者弹幕
3. 对于送礼物，在 H5 端可以利用 DOM 和 CSS3 实现送礼物逻辑和一些特殊的礼物动画，实现技术难点不大。
对于弹幕来说，要稍微复杂一些，可能需要关注以下几点：
1. 弹幕实时性，可以利用 webscoket 来实时发送和接收新的弹幕并渲染出来。
2. 对于不支持 webscoket 的浏览器来说，只能降级为长轮询或者前端定时器发送请求来获取实时弹幕。
3. 弹幕渲染时的动画和碰撞检测(即弹幕不重叠)等等
该组件主要适用于基于Html5的web 大群互动直播场景。具备如下特点:
1）支持匿名身份入群，粉丝与主播进行亲密互动
2）支持多人聊天，主播同一个帐号多标签页收发消息，粉丝再多也不用愁
3）支持多种聊天方式，文本，表情，红包，点赞，想怎么互动就怎么互动
4）支持不同优先级消息的频率控制，一键在手，权利尽在掌握中
5）对互动直播场景进行了专门的优化，参与人数多，消息量再大也能从容应对
目前较为成熟的直播产品，大致都是以 Server 端、 H5直播前端 和 Native（Android,iOS）搭配实现直播。
主要从android客户端出发，从最初的录制视频到客户端观看直播的整个流程，给出了各个技术点的概要和解决方案，从0到1完成了简单的直播实现。从0到1易，从1到100还有更多的技术细节有待研究。
更多精彩内容欢迎关注bugly的微信公众账号：
腾讯 Bugly是一款专为移动开发者打造的质量监控工具，帮助开发者快速，便捷的定位线上应用崩溃的情况以及解决方案。智能合并功能帮助开发同学把每天上报的数千条 Crash 根据根因合并分类，每日日报会列出影响用户数最多的崩溃，精准定位功能帮助开发同学定位到出问题的代码行，实时上报可以在发布后快速的了解应用的质量情况，适配最新的 iOS, Android 官方操作系统，鹅厂的工程师都在使用，快来加入我们吧！
原文：http://blog.csdn.net/tencent_bugly/article/details/52981166