如何搭建一个完整的视频直播系统？_音视频直播项目 课程设计

视频直播，可以分为 采集，前处理，编码，传输，解码，渲染 这几个环节，下面分别说下：

采集，iOS是比较简单的，Android则要做些机型适配工作，PC最麻烦各种奇葩摄像头驱动，出了问题特别不好处理，建议放弃PC只支持手机主播，目前几个新进的直播平台都是这样的。

前处理，现在直播美颜已经是标配了，80%的主播没有美颜根本没法看。美颜算法需要用到GPU编程，需要懂图像处理算法的人，没有好的开源实现，要自己参考论文去研究。难点不在于美颜效果，而在于GPU占用和美颜效果之间找平衡。GPU虽然性能好，但是也是有功耗的，GPU占用太高会导致手机发烫，而手机发烫会导致摄像头采集掉帧，iPhone6尤其明显，因为iPhone6的CPU和前置摄像头很近。

编码，肯定要采用硬编码，软编码720p完全没希望，勉强能编码也会导致CPU过热烫到摄像头。硬编码兼容性又是一个大坑，android上要有人去填。编码要在分辨率，帧率，码率，GOP等参数设计上找到最佳平衡点。

传输，自己做不现实，交给CDN服务商吧，也就是贵了点，相信有志于做直播平台改变世界的你不差钱。假设2W PCU大约每月带宽费用100万左右，因为清晰流畅的720p要1.5mbps左右。CDN只提供了带宽和服务器间传输，发送和接收端的网络连接抖动缓冲还是要自己写的。不想要卡顿，必然要加大缓冲，会导致延迟高，延迟高影响互动性，要做权衡。

解码，也肯定要硬解码，目前手机普遍支持硬解了，只是android上还是有兼容性大坑要填。

渲染，这个难点不在于绘制，而在于音画同步，目前几个直播做得都不好。

此外音频还有几个坑要填，比如降噪，音频编码器的选择，各种蓝牙耳机，各种播放模式的适配等，如果你想做主播和观众连线聊天，还有个回声消除问题。

以上是媒体模块，还有信令控制，登录、鉴权、权限管理、状态管理等等，各种应用服务，消息推送，聊天，礼物系统，支付系统，运营支持系统，统计系统等。

后台还有数据库，缓存，分布式文件存储，消息队列，运维系统等。

这些显然不是一个程序员能解决的，如果真的有这样的高手，请联系我，无论你现在薪水多少，我都出两倍。

第一期至少要融资2000万RMB，组建至少10人的技术团队，10人的产品运营团队，争取3个月产品上线，半年达到5W在线（2w 根本不够）然后融资1个亿，或许还有希望一搏。

也许有人对带宽问题存疑，请参考欢聚时代15年四季度财报，带宽成本为人民币1.611亿元，折合每月5000+万，当然不能用这个数去推算在线人数，因为YY采购量很大所以带宽平均成本低，而且YY不只是高清直播，还有很大比例的500kbps左右码率的直播，还有相当一部分带宽是靠P2P解决的。总之带宽非常贵。

祝你朋友好运。

技术点大家都回答的很详细了，我就我觉得视频直播系统中的一些难点再和大家分享下。

两年前我在做媒体云的时候，当时都是点播的业务。做到后面，我觉得点播业务其实并不像想象的那么难，你想你有一个稳定的存储，找一家靠谱的 CDN，然后找一个大概能用的播放器就做出来了，这有什么难的呢？你可以找云服务公司，也可以找外包，或者你自己招一个人都能做。但是现在发现到了移动，尤其是 3月份移动直播火起来之后，这个门槛突然变高了。因为内容产生方变成了移动端。从几个点来分析下为什么：

1 、首先内容产生方就是推流端，现在主流的 IOS、安卓，IOS比较简单，就是那个几个机型，基本大家适配都很好。但是安卓的碎片化是非常严重的，大量的精力都需要做对安卓的适配，而且软编耗电量普遍非常高，手机用了一会就会发烫，都担心会不会爆炸。用户体验就是在不同的网络情况下，上传的视频有可能会卡，有可能不连贯，报各种各样的错误，这个是作为一个开发者他自己不可能去适配的。说白了从用户那边提的需求就是推流端不能卡，画质要好，不能太烫，这是我们接触到的客户真正提的问题，是我们从有点偏技术的角度抽取出来的，它背后对应的是哪些事情。

2 、然后是分发网络。分发网络其实躲在一个很后面的地方，用户其实看不见的。真正对分发网络提需求用户也提不出来，所以基本这部分需求都会提给播放端，提的需求也是不能卡，不能花屏，首屏一定要快，一点就要看到，还不能把延时弄的太大。其实这些很多都是和源站分发网络有关系的，只是用户看不到这个需求会跟后面的播放器接在一起。

像首屏时间，就是用户点开就要看，以前那些开源架构就是 rtmp server，它是做不到一点开就能看的，现在一些开源的国内资源写得也比较好了，可以看到。我们是自己开发的，所以也花了一些工作，能保存之前的关键帧的信息，用户一点开就能看，这个就是很细节的东西了。如果这个做不好的话，会黑屏、绿屏，或者是半天看不着图像。

3、在播放器这边也是我们在接业务的时候，遇到用户投诉最多的，因为所有的问题都是在观看的时候体现的，所有的雷都得是播放器的同学去扛。这个需求也是不能卡，不能延迟太高。如果延迟高了，要追回来，追的时候声音不能变，最好是追的策略也能自己控制，这是用户真正提出来的需求。

要满足这些需求，我们需要做好多分辨率的适配，保证好流畅性，保证好我们追赶的策略不会出现任何异常。所以这三个端很多是相互耦合的，像推流和分发在一起，要保障好用户的流畅性和画质，分发和播放器在一起要保证好低延时和播放的流畅。所有的这些需求里共同的一点就是不能卡顿。

这个是我们的系统架构图。最下层是依托金山的云服务，因为我们已经有了很好的平台，提供了我们计算资源，提供了存储，提供了很多自建的节点，当然还不够多，我们还是个融合 CDN，然后提供了数据分析的能力。我们依托它做了橙色的这一层，就是我们自己的核心，流媒体直播，然后围绕这个核心我们在做的回看点播、在线转码、鉴权、内容审核。

1.回看点播：因为这不是一个短视频录播的项目，而是一个直播，直播就决定它的并发不会很高，内容不会很多，热点比较少。如果你不回看的话，用户很难维持它的日活，很难维护用户黏度，所以用户一定会要求做回看的。

2.在线转码：推流端其实做了很多把更好的画质想尽办法传上来的工作，投了很多人力来做。传上来之后，观看也在移动端，它不一定看得了。如果他看不了怎么办？我们就需要在线转，在线转码其实承担的更多更重要的事情。

3.鉴权：用户都不想被盗链，尤其是推流的时候，如果我不鉴权，谁都可以来推。所以这是必须要有的

4.内容审核：现在我们没有办法帮他做到自动审核，技术还不够。现在做到的是截图，按用户指定的时间定期截图，这样的话，用户就可以请一些外包来看是不是有敏感内容，是不是要下线，这个对于现在这种三四秒延迟的直播来说非常重要。你做不到的话，没准政策因素你就做不下去了。

5.数据分析：一部分是依托金山已有的，一部分是我们自己做的，因为我们延迟性，时效性要求更高。客户会经常大半夜突然提出一个主播看起来特别卡，问你为什么，要是像以前那种方式，一个小时生成报表，然后出体验图，告诉他为什么卡了，客户可没有这个耐心。我们现在基本能做到5秒间隔就出之前的各种问题定位，这个定位包括从源站收集的数据画的曲线。还有从端上，如果端上用户允许的话，推流和拉流端我们都会有上报数据，几个曲线一拟合，我们就知道问题出在哪里。

利息相关：金山云架构师。

谢邀。刚刚接手 全民TV 的研发团队不久，短期内还在疯狂填坑，在我看来，视频直播项目的研发算是涉及绝大多数主流互联网技术，整体做下来修为可以提升不少，大概把眼前的问题想了一下：

• PC、Android、iOS三大平台（一般互联网创业项目标配）
• 每个平台要做2种端：面向客户的直播端，和面向主播的推流端（标配x2）
  
• 视频编码涉及非常多的技术参数和细节（领域特殊技术）
• 完整的礼物系统、支付系统、运营系统、任务系统（不亚于一般页游项目）
• 即时聊天IM服务（弹幕，既要保证实时性，又要抗住高并发）
• 视频推流拉流链路依赖第三方CDN（超越一般创业项目的运维成本）
• 因为涉及钱的问题，经常与各种黑暗势力斗争（色情、广告、刷小号、刷充值、告侵权、DDoS等等）

大神 回答了很多视频直播相关的技术难点，这算是视频直播中最核心的技术之一了，但对于创业团队来说，还有更多技术攻坚之外的技术压力：

• 即使聊天IM技术难度也很大啊，尼玛一个大主播的直播间有十几万人同时在线，一个人发消息要十几万人都收到啊，大主播还经常带节奏，十几万人一起发消息要十几万人一起收啊，想象这个瞬间的高峰是个什么鬼！
• 视频直播的链路很长，CDN经常坑爹啊，主播推流客户端各种乱配，运营商各种劫持，出了问题都不知道甩锅给谁啊！
• 支付系统一定要仔细搞啊，每个环节都要仔细想清楚各种异常情况啊，所有消费都要有流水记录，警惕苹果黑卡啊
• 研发团队不好招人啊，我每周筛选6、70份简历，安排面试1、20人，也才能敲定3、4个offer，以这样的强度估计还要再坚持几个月啊
• 各种合作方的接入，各种赛事活动的接入，市场、运营、产品、客服各方都给你提需求啊，一个人要掰成好几个人用
• 即便如此，作为研发，看到不顺心的代码还是想重构啊，要在高速公路上冒着烟极速飞奔的汽车上，一边开车一边换轮胎啊！
• 团队快速扩张，彼此要磨合，管理能力还要能跟上啊，新人大量加入，还要安排好工作啊。

总之过去的一个月我是感觉自己无论在技术能力还是管理能力上的进步好像都超过了此前5年在大公司积累的总和，做视频直播项目真的很虐心，也真的非常磨练人，现在整个视频直播领域狼烟四起，颇有当年百团大战的意味，作为研发，我想要是能与现在的团队一起奋斗成长，并在这个领域争得一块立足之地，也算是一项非常了不起的成就了。

如果你仅仅为了一个构想的新模式而尝试涉足我觉得现在这个时间点已经没有必要了，各方面资源的投入成本都会非常非常高，做个demo玩玩还行，深入做下去真是山高路远坑深。

顺便打个广告，为我的团队招人，可以发简历到 zhangyunlong@qmtv.com

最近直播很火，很多大公司和中小创业者都想抓住这个机会做一番事业。「如何搭建一个完整的视频直播系统？」这是一个很大的问题，不是一两个答案能够解释清楚的，但我还是尽量技术和创业的角度提供给题主尽可能多的信息。

正如 @姚冬 所说，一个完整的直播系统大致包含这几个环节：采集、前处理、编码、传输、解码和渲染。在两端传输的过程中再加上一个服务端处理。大致的模型如下：

在主播推流端涉及到的环节有采集、前处理和编码，在观众端涉及到的环节就是解码和渲染，在这两个端之间建立起传输通道的则是服务端，它负责接收主播端的推流，将其处理之后分发给观众播放端：

1. 采集

采集是播放环节中的第一环，iOS 系统因为软硬件种类不多，硬件适配性较好，所以比较简单。Android 则不同，市面上硬件机型非常多，难以做到一个库适配所有硬件。PC 端的采集也跟各种摄像头驱动有关，推荐使用目前市面上最好用的 PC 端开源免费软件 OBS: Open Broadcaster Software

参考教程：斗鱼游戏直播教程-OBS直播软件篇[推荐]

2. 前处理

正如 @姚冬 所说，「80% 的主播没有美颜根本没法看。」不光是美颜，很多其它的视频处理如模糊效果、水印等也都是在这个环节做。目前 iOS 端比较知名的是 GPUImage 这个库，提供了丰富端预处理效果，还可以基于这个库自己写算法实现更丰富端效果：GitHub - BradLarson/GPUImage: An open source iOS framework for GPU-based image and video processing

Android 也有 GPUImage 这个库的移植：GitHub - CyberAgent/android-gpuimage: Android filters based on OpenGL (idea from GPUImage for iOS)

同时，Google 官方开源了一个伟大的库，覆盖了 Android 上面很多多媒体和图形图像相关的处理：https://github.com/google/grafika

3. 编码

编码主要难点有两个：1. 处理硬件兼容性问题。2. 在高 fps、低 bitrate 和音质画质之间找到平衡。

iOS 端硬件兼容性较好，可以直接采用硬编。而 Android 的硬编的支持则难得多，需要支持各种硬件机型，推荐使用软编。

4. 传输

传输涉及到很多端：

• 从主播端到服务端
  
• 从收流服务端到边缘节点
  
• 再从边缘节点到观众端

推流端和分发端理论上需要支持的并发用户数应该都是亿级的，不过毕竟产生内容的推流端在少数，和消费内容端播放端不是一个量级，但是他们对推流稳定性和速度的要求比播放端高很多，这涉及到所有播放端能否看到直播，以及直播端质量如何。

很多人吐槽现在的 CDN 不靠谱，我也承认传统的 CDN 在新时代显得心有余力不足。你能够借助 CDN 快速实现大规模的流分发，但是稳定高速的推流上传可能还需要自己做很多工作。这也是为什么我们七牛在这方面做这么多工作的原因之一。

如果要自己动手做，服务端方面最好的参考资料可能是这个了：v3_CN_Home · ossrs/srs Wiki · GitHub

国民首席、熊猫 TV 首席架构师杨武明在「Gopher 北京聚会」上做过一个「Golang在视频直播平台的高性能实践」的分享，值得参考：https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=404230356&idx=1&sn=6b73f971c4cf1170adaf4d249480ed9a&scene=1&srcid=0301qrbBZPrLxORTiD5D5IO1&key=b28b03434249256be5dfe068862f4c51d10c5e16b3659de35ce26bd4868f3a186366844bc7a8d3eaf48192b75536009b&ascene=0&uin=MTUwMTI2NjQ2MA%3D%3D&devicetype=iMac+MacBookPro11%2C2+OSX+OSX+10.11.4+build(15E65)&version=11020201&pass_ticket=TplbLKZJE2ZwCTACdAM6vZw%2FaJtVhaRrbn0An3uI6OAbctOQaAXHM9DZBdalM5Fi

PPT 地址：ppt/GolangPerformancePractice.pdf at master · yangwm/ppt · GitHub

5. 服务端处理

为了让主播推上来的流适配各个平台端各种不同协议，需要在服务端做一些流处理工作，比如转码成不同格式支持不同协议如 RTMP、HLS 和 FLV，一路转多路流适配各种不同的网络状况和不同分辨率的终端设备。

6. 解码和渲染

解码和渲染，也即音视频的播放，目前 iOS 端的播放兼容性较好，在延迟可接受的情况下使用 HLS 协议是最好的选择。Android 的硬件解码和编码一样也存在兼容性问题，目前比较好的开源播放器是基于 ffplay 的 ijkplayer：GitHub - Bilibili/ijkplayer: Android/iOS video player based on FFmpeg n3.0, with MediaCodec, VideoToolbox support.

目前，我们七牛在客户端采集、编码解码以及推流拉流加速方面做了很多工作，以上干货也是基于这个过程中踩过的坑整理出来的：Pili Streaming Cloud · GitHub

既然是创业，肯定要考虑到前期投入和未来的商业化，这方面我建议先看看熊猫 TV 庄明浩的长文分析：http://zhuanlan.zhihu.com/p/20717041

他在投入熊猫 TV 创业之前以投资人的视角从投资的角度深入观察、分析了视频和直播行业 2 年。

最近正好在做这方面的项目。

虽然是采购方，天天跟工程狮混在一起，对架构也略有了解。

写了大致的结构图，基本已经很清楚了。

懒的看文章的，直接点击放大，看原图就可以了。

新兴的直播行业现在正处于一个爆发式增长的状态，先从以秀场为主的直播方式，再到游戏直播，再到以UGC（user-generated Content）为主的内容生产方式的移动直播，将各行各业的内容以直播的方式分享。

不同模式的直播产品正在涌入市场，目前国内直播App就有200多个，其中100左右个项目获得了融资，形成激烈的竞争。

而背后的视频直播系统也需要一个庞大的技术链支持，下面简单介绍一下视频直播系统的技术链。

1.直播类型

视频直播根据不同的服务对象，大致可以分为2B和2C两种类型。

两种类型在技术本质上没有太多区别，但在产品形式上有很大区别。

2B指的是为企业提供直播服务。

例如微吼、易直播、趣直播、视秀等平台，帮助企业做直播解决方案。

企业召开发布会，就可以使用这些公司的服务。企业搭建专属直播室，企业级直播服务公司可以提供标准化的产品，也可提供个性化的定制服务，将其API嵌入自家App中。

2C指的是为普通用户提供直播服务。

市场上大部分直播平台都是这类型。又可分为一对一和一对多。

一对一是指视频源从一个客户端传输到另一客户端。如Facetime，Skype，微信，QQ的视频通话功能。

一对多是指视频源从一个客户端传输到多个客户端。这种形式即“网络视频直播”。

根据直播内容及形式又可分为以下几个种类：

秀场直播。

主要是主播展示才艺的形式，大部分为女性主播，是中国最早的直播形式。

目前秀场直播主要有爱奇艺奇秀、腾讯QT星主播，优酷的来疯等等。

电竞直播。

以游戏赛事，游戏教程等为主要内容。最先是在美国兴起的http://Justin.TV，之后改为Twitch，被亚马逊收购。国内主要有斗鱼，战旗，熊猫，虎牙等游戏直播平台。

移动直播。

是以移动设备为视频源的直播方式。这种形式最早在2015上半年，起源于美国的创业公司Meerkat，Periscope。之后Periscope被Twitter收购，Facebook也涉及这一领域，在Twitter，Facebook的竞争压力下，Meerkat放弃了直播视频社交网络业务。

在2015年下半年，中国拷贝了这种形式。以视频化社交为方向，代表产品有映客和花椒，陌陌美拍等的直播功能。

活动直播。

主要为各种现场活动提供直播服务。这种服务通常由toB直播服务公司提供。需要相对好的人脉资源，直播要求高，行业壁垒高，大部分创业者无法涉及。对各种讲座，峰会以及商业活动进行直播，主要有微吼直播等。对各种演唱会的直播，主要有优酷，乐视等大型视频网站。

而在内容划分上，各中直播模式依赖不同的内容生产方式。如下图所示：

注：

UGC，User-generated Content也称为UCC，User-created Content

PGC，Professionally-generated Content也称为PPC，Professionally-produced Content

OGC，Occupationally-generated Content

2.视频直播系统

一个直播系统大概可以分为一下几个模块，媒体模块，服务模块，管理模块。

媒体模块是直播系统的技术核心，服务模块是关乎用户体验，管理模块对数据，系统进行管理控制。

2．1媒体模块

2.1.1采集

采集是直播系统中的第一环节，获取视频源。

因为iOS是软硬件种类不多，官方也提供了稳定可靠的接口，比较简单。

Android因为机型种类繁多，需要适配机型，会是很大一部分工作。

而PC也面临各种摄像头驱动，难点在于机型适配。

2.1.2前处理

前处理，主要用于图像美化，风格化，图像处理方面。

当前直播的美颜功能已不可或缺，除了秀场需求以外，在UGC内容生产方式下，大量的内容对美颜都有较高的要求。

美颜简单的可以通过美颜镜头，但局限性大，限于PC端的主播，更好的办法是通过软件实现，需要图像处理方面的人员，美颜算法需要需要用到GPU编程，要自己参考论文去研究。

难点在于美颜效果是否自然，GPU占用与效果的平衡。GPU用于高性能计算，但功耗也相对高，需要考虑到手机温度对数据采集的影响。温度过高，摄像头容易掉帧。图像处理不仅仅是美颜，在交互中可能会涉及到滤镜，人脸识别，人物风格化等，使得客户拥有更好的互动体验。

目前iOS上比较好的图像处理库是GPUImage，提供了丰富的预处理效果，也可利用该库自定义设计。

Android上也提供了功能强大的图像处理库grafika。

2.1.3编码

在编码方面，有两种编码方式，硬编码（硬件）与软编码（软件）。

目前大部分硬件都支持硬编码，但在Android上存在兼容性问题，源于不同厂商的芯片差异巨大，难以构建统一的库来兼容全平台。

编码的工作主要是对视频，音频的原始数据进行编码处理，得到可用的视频，音频数据。

编码涉及一系列的技术，常用的编码方式有CBR、VBR；对于视频，常用的编码标准是H.265、H.264、MPEG-4等，可封装为MKV、AVI、MP4等；对于音频的常用编码标准有G.711μ、AAC、Opus等，封装有MP3、OGG、AAC等。

编码通过压缩音视频数据来减少数据体积，方便音视频数据的推流，拉流和存储。大大提高存储传输效率。

H.265是当前性能最高的编码技术，在相同视频质量下，相比于H.264，H.265仅需一半的带宽，使得低于1.5Mbps的网络能够传输1080p的高清视频。

在编码方面的核心是平衡分辨率、码率、帧率、GOP（Group of Pictures）使得体积与画质达到最优，参数组合为技术核心，也是个家的商业机密。

2.1.4传输

传输涉及系统的多个部分，连接主播端，服务端，客服端等多个部分。

传输效率高与否决定直播系统的性能好不好，传输是直播系统非常重要的技术核心。

下面是传输的简单示意图：

从推流端到服务端。数据经过推流端采集和预处理，编码之后推流到服务端，流传输就涉及到相应的传输协议，最常用的协议是RTMP(Real Time Messaging Protocol，实时消息传送协议)，RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。还有RTSP,HLS等。

RTMP的传输延迟通常在1-3秒，符合手机直播对性能的要求，因此RTMP是手机直播中最常见的传输协议。之后通过QoS（Quality of Service指一个网络能够利用各种基础技术，为指定的网络通信提供更好的服务能力, 是网络的一种安全机制，是用来解决网络延迟和阻塞等问题的一种技术。）将流数据推送到网络端，通过CDN分发。

在直播场景中，网络不稳定很常见，需要通过QoS来保证直播体验。服务端还需要对数据流一定的处理，转码，使得数据流支持HLS，HTTP-FLV，RTMP等格式的拉流，支持一转多，适配不同网络、分辨率的终端。

推流作为视频源的传输，在稳定性速度上都比拉流高得多。实现推拉流的技术线没有雄厚的人才与资金是不现实的，通常需要依赖第三方的CDN提供商。

在实际中，大多数直播平台会接入多个视频云服务提供商，做拉流线路互备，视频集群也是可优化部分来提高直播流畅性与稳定性。

2.1.5解码，渲染

拉流获取音视频数据后，需要通过解码器解码，渲染才能在播放器上播放。

H.264和H.265是有所压缩的，在解码恢复之后是缺损的原数据。

之前提到的体积最小画质最优的编码参数，就是在这里恢复画质的，该参数组合是非常重要的技术。现在的播放器普遍都需要高清支持，解码也应选择硬解码。iOS能够较好的支持，但Android还需要很多工作去弥补Android在平台差异的缺陷。

而在播放端，保证音画同步的同时，保证稳定流畅的直播流量，需要服务端与播放端做调度优化。

2．2服务模块

服务模块涉及用户体验，从用户方的收益一部分也来自于服务模块。

系统需要完整的礼物，支付，运营，任务等系统，复杂度不亚于页游系统。

国内直播平台的营利模式决定：平台从打赏中抽成。礼物系统就成为平台的盈利方式。礼物系统是多数视频直播平台的标配。

在中国部分人有礼品消费的习惯。平台为用户主播设计多个等级、爵位等头衔。利用财富榜，家族榜，等级榜类拉动消费。

IM技术。IM即时通讯服务。包括聊天室、弹幕等。弹幕交互方式是很好的体验，偏年轻化，大量用户愿意通过弹幕互动。高峰时，弹幕消息量特别大，一是需要考虑到高峰时弹幕的实时性和高并发量，二是要在产品策略上作一些体验上的优化。

支付系统需要仔细处理各种异常，消费流水记录。

系统还需要在政策上作相应的考虑，例如国家规定所有直播必须打水印并存留15天以上。在内容审核方面，淫秽、暴力、犯罪、敏感问题的审核。在数据分析方面也需要相应的统计系统。

2．3管理模块

管理模块包括客户端的设计与维护、后台数据库、后台控制系统。

该部分根据直播平台的特性、定位设计相应的管理策略。具体技术上还包括缓存、分布式文件存储、消息队列，运维系统等等。

2．4 OBS直播软件

Open Broadcaster Software（OBS）是一款很好用的PC端直播开源软件。该软件提供了对H264 (x264) 、AAC编码的支持。支持多场景多数据源，到Twitch, YouTube等平台的LRS支持。支持输出视频，基于GPU的游戏捕捉提供高性能的视频流等等众多支持。能够很好地完成采集、编码。

以上简单地介绍了视频直播系统的技术构架，构架本身容易，但构建性能优良的构架就很有难度，需要在传输速度与效率、推流端兼容性、客户端体验上作深入的工作。

但说实话，如果仅从问题描述来看，我觉得这样的格局，对未来的生存表示担忧。

现在铺天盖地的直播，从游戏直播、到秀场、到移动端。

看似是块很大的蛋糕，但能留到最后的，一定是巨头中的其中一家。

很多初创团队，都觉得直播的市场很大，机会很多，但这个时间点入场，给初创者的时间并不多。

王思聪的熊猫TV，腾讯投资斗鱼和龙珠，最近疯狂烧钱的腾讯直播和企鹅直播，360投的花椒直播，陌陌的哈你直播、微博的一直播，金沙江投资映客，这些豪华阵容在直播的战场上厮杀的火热。

这类2C直播平台最重要的就是利用直播内容和主播人气吸引巨大的流量。

有流量就有钱进来。

这样的游戏规则下，各大2C平台就疯狂的买内容，签主播。广告狂轰乱炸，争夺江湖地位。

疯狂烧钱的同时，也只有一轮又一轮不断的融资才能生存下来。

有资本进入的地方就有对赌。

不管是2C的映客、斗鱼、熊猫，还是2B的微吼直播。

相比2C端频繁的资本大战，在2B端发展还是相对稳健。

还是以微吼直播为例，被爆已完成B轮对赌，对赌金额达7000万元人民币，有望在年内成为业内首家盈利的直播平台。

现在企业直播服务、城市直播服务的市场还是被严重低估。

尽管现在很多工作上的事情在微信里沟通、讨论。但是我们知道，选择微信，只是因为大家都在用它！只是大家都在用它！

封闭的社交环境使其在商业协作中难登大雅之堂的主因。

单从沟通介质所能承载的信息量来看：文字 < 语言 < 视频 < 面对面交流。

网络直播这种面对面的交流能够承载最丰富最真实的信息，这也让微吼直播这样的2B直播行业迎来了千载难逢的机会。

回到题主的问题，我觉得自己搭建直播平台，还不如在别人已经创造好的平台上发现新的机会。

（个人观点，人还是要有梦想的嘛。）

很多回答，已经给题主提了不少的建议。知乎上网络服务公司，响应也真是够快的，在问题的评论里，有几家也跟题主对接上了。

粗略看了下，2C和2B的都有，直播服务的大趋势就是这样。

（图片我下午拍的，2B直播调试现场）

最后，补充一句：搭建视频直播系统一定要符合中国特色。

为什么捏？

一个服务商告诉我的：

我们架的这套视频云协作系统，核心技术是思科的。

老牛逼了，海外版本预设的是，不同的人发言的时候，系统会自动判断麦克风声音方向，高清摄像头就会自动转向发言的人，并且自动优化构图。然后，系统会把发言的人放大，突出显示在现场的大屏幕上。

但引进到国内后，这套系统就被改成了：

领导的画面永远最大，并且永远在最中间…

谢邀，最近回答了关于直播的问题，今天就有人邀请我回答技术贴了。以下都以秀场直播为基础进行介绍——简单说，一个直播平台的技术搭建，按照各端的顺序，大概是下边这样的：

先从采集端说起，也就是通过摄像头拍摄到直播者的图像以及录制声音。单就这个地方来说，其实是没什么问题的。但是楼上几个答案提到的安卓机型碎片化很严重的问题也是客观存在的。所以，自己做架构的时候，一定要注意多终端适配，另外就是离线采集技术、手动对焦等等也会影响用户体验。

接下来一个重要的环节就是前处理，其实最主要的部分就是GPU渲染的实时美颜。一方面，实时美颜的算法本身，就相当考验APP厂商的技术实力；而另一方面，如何能够利用有限的GPU资源进行美颜处理，也是一个很关键的点。这里就不能不提到兼容性的问题。虽然现在国内手机芯片市场占据领先地位的只有高通和联发科，GPU也是除了高通就是PowerVR，但是如果再考虑到各种因素，想在前处理方面做好技术的适配确实需要相当的成本。这段时间国内很多直播产品迭代都比较快，所以直接后果就是技术适配做得差，很多常见的机型都会闪退和骤停。

另外，除了美颜之外，前处理还有一个点是水印、时间戳等等。因为现在很多小平台之间，都会互相盗链，恶性竞争，这样算是防患于未然。

再之后就是编码。我们都知道把视频上传到优酷上会有一个编码的过程，直播也如此。只不过，前者依靠的是云计算，后者则是通过手机自身CPU的性能进行编码——考虑到国内很多网红主播用流量直播的现状，以及国内大多数地区的网速，先上传后编码完全不现实。而在这种情况下，最常见的一个问题就是手机发烫，原因是CPU和GPU同时在没有良好优化的情况下进行长时间的满负荷工作。这又会带来两重问题，其一是用户体验差，其二是电量消耗快。最严重的一次，我一个朋友拿手机直播时我随手拿起来看了一下，有种“烫手”的感觉。

编码本身的算法也有讲究，一方面要减小CPU的使用率，另一方面又要控制码率更低。所以基本上，如果你自己或者服务商的编码标准不是H.264或者H.265，基本上就可以一票否决了。

接下来到了传输部分，这里边的重点在于推流。因为如果只是传输路径上某一个点有故障，只是一部分人看不了，但如果推流出了问题，所有的人都看不了了。更何况，移动直播平台的竞争非常激烈，如果技术上不过关，一旦宕机影响用户体验，后果会很严重。前一阵子花椒直播找张继科直播，30万人的量就出现了宕机，很明显就是传输方面没到位。

传输这一块是技术活。所以基本上国内大多数成熟的直播平台，都选择把这一块交给专业的CDN厂商去做。毕竟，创业公司一般都会把精力专注于自己的业务，而自建CDN这种很垂直的事情，连很多非运维的技术人员都不懂，再加上服务器、带宽之类的成本，自己做很困难。

这就涉及到CDN的选择问题。先科普一下，CDN最核心的资源比拼就是内容分发节点，但是如果涉及到直播的话，流传输的技术架构也同样重要。

从架构上来看，国内大概是三类：

第一类是传统的CDN老牌，代表是网宿、蓝汛。他们的优势是骨干带宽强，缺点是架构上明显没有跟上步伐，而且价格比较高。

第二类是云CDN，优势相对会大一些。这个问题下关于CDN的推荐基本上都是关于云CDN的，比如Ucloud，七牛云、又拍云等都推出了自己的云CDN，楼上的答案也已经提到了他们各自的优势，题主也可以进行参考。

除了以上两类，最近还有一家CDN采用和前两者有所不同的模式，是迅雷旗下一家名叫网心科技的公司推出的星域CDN。他们的模式比较独特，除了正常的大型骨干节点之外，还通过名叫“赚钱宝”的智能硬件连接家庭路由器，从而利用闲置带宽布局了几十万个家庭内容分发节点。这种模式的优势是：在内容传输时可以做到更快地建立起传输路径，对于直播这种对实时传输要求比较高的技术来说，还是有一些好处的。

国内三大主流CDN直播支持技术对比图，以各自领域最优数据进行对比

数据来源：国内三大主流CDN横向全对比_DoNews-互联网

国内三大主流CDN横向全对比_DoNews-互联网

目测题主的朋友是创业公司，在预算方面还是比较紧的，就不要考虑传统CDN从后两种之间选择好了。建议是去这几家公司的官网对比一下价格。我这里截了几张图，从上到下分别是七牛云，Upyun和星域。

七牛云

Upyun

星域CDN直播

不同的CDN厂商，根据不同流量区间价格不一样，按流量计费和按带宽计费也是不一样的。

直播平台的带宽成本比较高，这时价格之间的差异对选择天平的倾斜影响还是相当大的。或者，也可以找一些免费送流量的公司体验一下，这样可以无需充值就能感受到服务的效果。比如说：七牛0-10GB就是完全免费的，星域注册也会送100G。另外，如果数据量够大的话，星域的单价比起其他家明显会低很多。

另外，可以通过观察CDN企业服务的直播平台来认识他们的实力。毕竟，大公司在采购时会有很严格的要求，基本上能通过的也都是经过九九八十一难，“剩者为王”。自己列了一张表，不一定全，仅供参考。

从CDN说回直播本身，在拉流之后就是视频的解码、渲染等等，这一块对于硬件的要求比编码会低一些，技术上难度也会小一点。这里边也有一些细节，比如软硬码自动切换，连麦互动，H.265解码，动态追帧，播录一体化这些。每一个细节，都有可能带来用户体验上的差距。

当然，以上说的只是直播平台技术里视频的一部分，楼上

老师说的很好，音频、礼物、数据库甚至支付都是不得不考虑的事情。 至于技术准备和资金门槛，只能说：以一个创业公司的资金和资源从零做起的话，很多问题其实确实是不太容易解决的。一个好的直播平台，光是技术的解决方案上百万就是杯水车薪，而且要找到靠谱的人才能画好这笔钱。尤其是赶上这轮资本寒冬，直播平台里边老大老二基本分出来了，如果现在想融到两千万然后拿出上千万搞技术——未必可行。

好在国内市场足够大，允许各种各样的竞争者同时出现，所以最近有一些做云计算和CDN的厂商，干脆把直播的技术解决方案整合成了SDK，卖给创业公司。

这类SDK能做的事情，还是比较多的，网上找来了张图，题主和大家也可以参考一下。而且，这一类解决方案因为相对标准化，所以成本相当低，价格也不高。当然，做这种事情的门槛不低，基本上都是比较大的CDN厂商在做。

比如文章上边提到的星域，就是直接把视频推拉流、采集、转码之类的技术打包在了一起，同时优化各个环节。毕竟，CDN行业的竞争很激烈，价格也是逐年下跌，所以服务商们为了找自己的差异化竞争点，还是很卖力气的。

总结起来，一是直播平台在技术方面的要求很高，尤其是CDN一块专业性很强，想完全用自己的技术解决不现实；二是，要么舍得砸钱招BAT技术团队，要么就用标准化的技术解决方案——毕竟直播平台技术只不过决定着及格线，真正的核心竞争力在于产品和运营。如果真的有那么多钱，还不如把技术上省下来的钱花在网红的签约和入驻上，对吧！

直播产品首先要确认是PGC还是UGC，即要区分是固定网红或签约主播进行直播，还是随便一个路人都可以进行直播，两种场景的差异很大。 目测这里应该更偏向于PGC的直播。

成熟在运营的产品其实已经有不少，720P更多是针对的PC用户，移动端的没有这个必要。首先要确认是属于以下哪种场景：

#1 PC推流+PC观看

#2 PC推流+PC、移动观看

#3 移动推流+移动观看

涉及的技术有视频编解码、客户端开发、大规模直播流分发、产品前端开发等。

#1的最低成本的投入方案：OBS+任选flashplayer(之前笔误把ijkplayer归成了flashplayer，这里诚挚道歉，再给做个宣传：ijkplayer: ijkplayer非常不错)+云直播， OBS是开源免费的PC端推流工具，斗鱼直播的主播们对这个软件应该非常熟悉了，稳定、流格式标准、占用资源少还有丰富插件，如混音。 一般免费的flashplayer都可以直接播放RTMP的视频直播。 云直播 即CDN的方案。 可以到云服务或CDN公司申请，推荐UCloud直播云，花10来分钟即可自助完成配置。这个方案，客户还需要搞定除视频外的其他功能，比如聊天室，打赏灯。 缺点是OBS目前没有太好的美颜插件，好在专业主播 都有配美颜摄像头，300~500 不等。

#2 相对于#1 来说多了移动端播放的入口，研发成本肯定大大增加，可以先考虑是iOS还是Android，APP 和 视频直播都自研 投入人力不菲，我没见过有创业公司这么干的。 一般的做法是：APP框架自己搭建，找开源或第三方的视频直播SDK 集成 视频直播能力，相关的SDK 有很多；还有一种实时性没那么高的做法是内嵌浏览器直接用HTML5播放直播流，但是需要CDN提供商支持HLS协议，一般延迟在5~7秒。

#3 这么玩需要移动端有较强的研发实力，起码需要1位或以上音视频编解码的资深攻城狮。 具体的方案：开源SDK（如kickflip，坑多慎入）或第三方推流SDK+播放SDK（UCloud、亲加等）+直播加速CDN。 目前业内已有的APP把这块体验的门槛做得很高，如秒开，低延迟，美颜等特性已成标配，需要第三方的SDK能支持这些功能。提供SDK的公司很多，逃离不开稳定性，兼容性两个话题。 iOS的机型少一些好处理，Android太多了。 如某米的低端机型，市场占有率高，使用芯片较杂，硬编的兼容性是非常差的，软编性能又不够高，美颜、混音的处理是开不起来的，不然会非常卡， 层面要考虑这些是否是目标主播。从付费比例来看，iOS和Android高端机的机主可以作为首发目标，低端机型的覆盖再慢慢搞。另外就是IM的功能，提供SDK的公司也很多，比较出名的如环信、融云，功能上其实都差不多。

另外的一些建议：

如果是PC 端推流的PGC内容(通常说的美女秀场)，为了节约成本，可以把帧率调到15或16，可以节省35%左右带宽。 对于2W在线来说，720P 按每路至少1000kps码率，就得20G带宽，省个35%就是7G，每个月省10好几万。

实时直播流转码的功能（比如适配多终端或多屏幕大小）。看似高大上，实际投入产出比极低，一般4核的设备可以实时转码个位数的直播流，2w在线，按1:5主播观看算，就有4000路流，这个设备投入是天文数字，所以别花心思自己搞设备区转了。 当然对于足够针对热度的流做优化是有价值的。

搭车放个招人广告，有视频终端或后台系统开发的同学，可以发简历至ken.zeng@ucloud.cn

提问者如果打算自建视频直播平台，成本确实很高，技术门槛也比较高。我就从调用相关云服务的角度来说好了。相对来说，效率要高得多。

搭建一个完整的视频直播系统，首先要了解一般直播产品的架构。架构图如下：

其次要选择一个功能完善，性能良好，运行稳定的视频云平台。目前市场上主流的有百度云，腾讯云，乐视云，欢聚云，暴风云，网易视频云，目睹直播这些。还有其他的就不一一列举了，重点分析一下列举的这几个的特点。

腾讯云。定位：Paas层。推流SDK支持Windows、Web、Android、iOS。播放器SDK支持Web（Flash、H5）、Android、iOS。CDN全球400+。优势是互动直播方案比较成熟，但是稳定性不佳。收费方式是按核心机房和边缘节点的带宽进行计费。技术支持：开发文档和工单。

网易视频云。定位：Paas层。推流SDK支持Windows、Web、Android、iOS。播放器SDK支持Windows、Web、Android、iOS。CDN数600+。优势是推流码流可以自适应，自带美颜、混音等扩展功能。直播功能价格，同样按流量和带宽计费，但是使用推出的套餐会相对别家便宜很多。技术支持：文档和工具交流，提供1V1的专家技术支持。

百度云指的是百度开放云。定位是Paas层。现在发布到2.0版本，还比较成熟。推流SDK 支持PC、Android、iOS,移动端支持闪光灯、滤镜等功能，暂不支持动态码流自适应。播放器SDK支持Web（Flash、H5）、Android、iOS。CDN主要覆盖了一二线城市。优势是功能较完善，但是使用复杂度很高。价格有两种计费方式分别是按直播下行流量和带宽峰值。技术支持主要通过开发文档和QQ群。

欢聚云也就是我们知道的YY。定位：Paas层。目前云服务还没开放，需要邀请码才能试用。推流SDK支持PC、Android、iOS和Web。播放器SDK支持Web端（Flash、H5），移动端支持HLSFLV。优势是支持音视频连麦。价格不详，技术支持只有一些文档。

暴风云。定位：Paas层。推流SDK有Windows直播助手和移动端直播助手。播放器SDK支持Web(Flash、H5)、Android、iOS。CDN数不详，但是默认直播并发不能超过2000人。优势是在视频云是做的最早的公司。计费也有两种，按流量和按带宽。技术支持：开发文档和QQ交流。

目睹直播。定位：Saas。推流SDK支持Windows、Web、Android、iOS、导播台。播放器SDK支持PC、Android、iOS。CDN数不详。优势是扩展功能较丰富。计费：0.04~0.06元/分钟/人。技术支持不详。

总的来说，这些产品各有优劣。个人觉得，有两方面需要注意。一个是视频云服务的稳定性。如果本身云服务系统就有一大堆问题，那接入的时候肯定问题更多。所以可以先考虑行业大公司的云服务。网易视频云和百度云的稳定性都做的不错。第二个是技术支持的力度，换句话说出了问题之后的响应和解决速度能有多快。网易视频云在技术服务有1V1的专家支持，这在业界尚属领先。总的来说，网易视频云的性价比在云服务商里算是最高的。

选择完视频云服务公司，就可以根据相应的情况进行搭建，接入直播功能。具体操作的时候，肯定还是会有各种各样的问题，那就不是一个知乎问答能解决的了。

姚冬、

和 张云龙 的答案都很好很全面。

看到这个问题好几次了，不少人都提到了美颜这个点，忍不住来发篇回（硬）答（广）。

关于美颜，以下几点应该是标配：

• 美颜处理流畅快速
  
• 滤镜效果自然
  
• 适配机型足够多
  
• 耗电量低

我所在的 TuSDK 团队目前正专注于移动端图像服务，我们积累了十年以上图像领域相关经验，从图片处理和相机 SDK 做起，目前针对直播市场也推出了专门的解决方案 http://tusdk.com/video 。

目前我们取得的效果：

• iOS 每帧处理时间小于 1ms，Android 在 3ms 左右
  
• 通过 GPU 识别技术适配市面上绝大部分机型
  
• 可根据需要调整滤镜和美颜效果

正在做的事情：

• 动态贴纸
• 与已有的人脸识别技术结合，实现更多需求

提供两种服务：

• 独立的客户端处理引擎，适用于已经成形的移动视频产品，用以完善功能、提升体验。
  
• 一站式解决方案，包含了前后端的所有功能，更全面、更专业的视频直播方案。

一、直播的技术架构：
直播视频采集SDK（PC/IOS/Anddroid）——直播CDN

（直播流分发加速）——直播视频播放器SDK（PC/IOS/Android）

二、音视频处理的一般流程：

数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示

1、数据采集：

摄像机及拾音器收集视频及音频数据，此时得到的为原始数据

涉及技术或协议：

摄像机：CCD、CMOS

拾音器：声电转换装置（咪头）、音频放大电路

2、数据编码：

使用相关硬件或软件对音视频原始数据进行编码处理（数字化）及加工（如音视频混合、打包封装等），得到可用的音视频数据

涉及技术或协议：

编码方式：CBR、VBR
编码格式
视频：H.265、H.264、MPEG-4等，封装容器有TS、MKV、AVI、MP4等
音频：G.711μ、AAC、Opus等，封装有MP3、OGG、AAC等

3、数据传输：

将编码完成后的音视频数据进行传输，早期的音视频通过同轴电缆之类的线缆进行传输，IP网络发展后，使用IP网络优传输

涉及技术或协议：

传输协议：RTP与RTCP、RTSP、RTMP、HTTP、HLS（HTTP Live Streaming）等

控制信令：SIP和SDP、SNMP等

4、解码数据：

使用相关硬件或软件对接收到的编码后的音视频数据进行解码，得到可以直接显示的图像/声音

涉及技术或协议：

一般对应的编码器都会带有相应的解码器，也有一些第三方解码插件等

5、播放显示：

在显示器（电视、监视屏等）或扬声器（耳机、喇叭等）里，显示相应的图像画面或声音

涉及技术或协议：

显示器、扬声器、3D眼镜等

三、常见的视频直播相关协议：

1、RTMP(Real Time Messaging Protocol，实时消息传送协议)

RTMP是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。它有三种变种：

1）、工作在TCP之上的明文协议，使用端口1935；

2）、RTMPT封装在HTTP请求之中，可穿越防火墙；

3）、RTMPS类似RTMPT，但使用的是HTTPS连接；

RTMP协议是被Flash用于对象、视频、音频的传输。这个协议建立在TCP协议或者轮询HTTP协议之上。RTMP协议就像一个用来装数据包的容器，这些数据既可以是AMF格式的数据，也可以是FLV中的视音频数据。一个单一的连接可以通过不同的通道传输多路网络流，这些通道中的包都是按照固定大小的包传输的。

2、RTSP(Real Time Streaming Protocol，实时流传输协议)

RTSP定义了一对多应用程序如何有效地通过IP网络传送多媒体数据。RTSP提供了一个可扩展框架，数据源可以包括实时数据与已有的存储的数据。该协议目的在于控制多个数据发送连接，为选择发送通道如UDP、组播UDP与TCP提供途径，并为选择基于RTP上发送机制提供方法。

RTSP语法和运作跟HTTP/1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。代理服务器的缓存功能也同样适用于RTSP，并且因为RTSP具有重新导向功能，可根据实际负载情况来切换提供服务的服务器，以避免过大的负载集中于同一服务器而造成延迟。

3、RTP(Real-time Transport Protocol，实时传输协议)

RTP是针对多媒体数据流的一种传输层协议，详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议），视频会议和一键通系统（配合H.323或SIP），使它成为IP电话产业的技术基础。

RTP是建立在UDP协议上的，常与RTCP一起使用，其本身并没有提供按时发送机制或其它服务质量（QoS）保证，它依赖于低层服务去实现这一过程。

RTP 并不保证传送或防止无序传送，也不确定底层网络的可靠性，只管发送，不管传输是否丢包，也不管接收方是否有收到包。RTP 实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，如在视频解码中，就不需要顺序解码。

4、RTCP(Real-time Transport Control Protocol，实时传输控制协议）

RTCP是RTP的配套协议，为RTP媒体流提供信道外的控制。RTCP和RTP一起协作将多媒体数据打包和发送，定期在多媒体流会话参与者之间传输控制数据。

RTCP的主要功能是为RTP所提供的服务质量（QoS）提供反馈，收集相关媒体连接的统计信息，例如传输字节数，传输分组数，丢失分组数，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息来提高服务质量，比如限制流量或改用压缩比小的编解码器。

四、直播下的聊天室功能

1、直播的场景下，除了视频直播还有一块就是聊天功能，观众打开一个直播房间时，也就自动进入了一个聊天室，观众可以发文字发表情进行互动，道具打赏也是基于聊天室的接口做上去的。
2、聊天室和群聊的功能类似，两者的区别是：聊天室的场景下，用户进入后才能看到聊天信息，群成员信息，退出后再进来就看不到之前的历史消息了。
3、聊天室其实是im即时通讯中的一个功能，im主要能实现一对一聊天、群聊、聊天室3种场景。

五、利益相关

我们团队是做直播、IM即时通讯技术的，底层架构都是做好的，开放给开发者sdk和api接口、demo源码。感兴趣的朋友可私聊。欢迎交流，相互学习。知乎专栏 这篇文章汇集了我对这个行业的理解，欢迎大家指点

直播技术要求这块上面已经讲的很详细了，我就不再赘述了。作为又拍直播云的研发，这边就说说接入又拍直播云（直播云 - 一站式视频直播加速）的流程，非常的简单方便。新用户通过官网注册账号，并进行个人/公司认证，审核通过后可以正常使用控制台。详细步骤如下所述：

创建服务：

Step1，创建服务。进入又拍云官网——控制台——点击【创建服务】。参考如下：

Step2. 配置服务.

源站选择及配置：

• 又拍云源，用户通过推流器或编码器主动将直播流推送至又拍，经过又拍的流媒体加速中心加速后，通过相应的拉流 URL 进行访问。适用场景为秀场主播、游戏直播和在线教育等；
  
• 自主源站，客户提供直播源服务器，又拍向客户源请求源数据。适用场景为电视台，体育比赛等。

又拍云源配置：

• 推流域名：用于推送直播流的域名，长度小于60个字符，支持泛域名绑定，比如：*.yourdomain. com
  
• 播放域名：用于播放直播流的域名，默认支持 RTMP，HLS 和 HTTP-FLV；推流域名、播放域名共计最多可绑定个域名，支持泛域名，所绑定的域名需要备案；
  
• 接入点：支持1-60位英文字符和数字，如：rtmp://http://push.example.com/{接入点}/{流名}，该项可不填，为空时表示，可以使用任意的接入点。
  

示例：接入点：live； 推流域名：http://push.example.com； 播放域名：http://pull.example.com
则

• 推流地址：rtmp:// http://push.example.com /live/streamid
  
• rtmp 播放地址：rtmp://http://pull.example.com/live/ streamid
  
• hls 播放地址：http:// http://pull.example.com/live/ streamid.m3u8
  
• flv 播放地址：http:// http://pull.example.com/live/ streamid.flv
  

自主源站，请填写自己的源站地址

• 源站：支持 RTMP/HTTP 两种协议回源，源站支持输入域名/IP，请填写正确的源站地址，直播流将推流到源站拉取直播流进行分发
  
• 播放域名：用于播放直播流的域名，默认支持 RTMP，HLS 和 HTTP-FLV，推流域名、播放域名共计最多可绑定 10 个域名，支持泛域名，所绑定的域名需要备案；
  
• 接入点：支持1-60位英文字符和数字，如：rtmp://http://push.example.com/{接入点}/{流名}，该项可不填，为空时表示，可以使用任意的接入点。
  

示例：接入点：live；协议为：RTMP；源站：11.11.11.11 ；端口为：1935
则

• 回源地址为：rtmp:// 11.11.11.11:1935/live/streamid
  
• 播放域名：http://pull.example.com
  
• hls 播放地址：http:// http://pull.example.com/live/ streamid.m3u8
  
• flv 播放地址：http:// http://pull.example.com/live/ streamid.flv
  

注：流名默认支持任意字符串

Step3. 配置成功

配置完成后，系统会自动为您生成该推流域名需要 CNAME 地址，您可以前往域名的 DNS 服务商为自主域名添加 CNAME 地址。

——————————分割线——————————
三步完成配置，就是这么轻松简单。
附上又拍直播云文档： http://docs.upyun.com/live/

什么分析，什么架构上面 两位大哥已经分析得比较清楚了。我就给大家提供一个方便；
下面是我在开发直播APP中整理的一些技术，欢迎 GitHub持续更新-欢迎Star


直播关键字

采集、前处理、编码、传输、解码、渲染, 推流, 拉流、连麦、直播、互动、RTMP

原理科普

1. 为何一直推荐WebRTC？
2. RTMP vs RTMFP
3. 大话直播
4. android音视频点/直播模块开发一些基本概念
5. 【如何快速的开发一个完整的iOS直播app】(原理篇)
6. 姚东（YY），金山18667号码农，张云龙（全民TV), 何李石（七牛）分享如何搭建直播平台浅谈
7. 视频参数（流媒体系统，封装格式，视频编码，音频编码，播放器）对比
8. 流媒体中用到的几个协议简介
9. 【总结】视音频编解码技术零基础学习方法
10. 【移动开发】关于视频直播技术，你想要知道的都在这里了（三）编码和封装
11. 【HTML 5】 视频直播一站式扫盲
12. 【React Native】 在直播应用中的实践 | 架构师实践日
13. TCP 的那些事儿（上）

WebRTC

1. Getting Started with WebRTC
2. 【WebRTC】使用WebRTC搭建前端视频聊天室——入门篇
3. 【WebRTC】用WebRTC搭建前端视频聊天室——信令篇
4. 用WebRTC搭建前端视频聊天室——点对点通信篇
5. WebRTC的RTCDataChannel
6. 7 Creative Uses of WebRTC’s Data Channel
7. Android之WebRTC介绍

流媒体-服务器-CDN

1. 奥点云
2. 七牛
3. 网宿
4. UCloud
5. 【Nginx】优秀的免费Web服务器，通过扩展的nginx-rtmp模块，可以支持流媒体播放和管理。
6. 【EasyDarwin】高性能开源流媒体服务器，支持RTSP、HLS、HTTP直播

IM

礼物系统，聊天系统，弹幕系统多半依赖IM，可根据自定义的消息来定义不同消息类型；

1. 环信
2. 极光IM
3. Teameeting-MsgServer 免费开源

连麦互动

1. 视频直播中用户连麦技术模型与特点分析（转载）
2. 全球首创4人连麦-RTMP + RTC
3. 亲加通讯云郝飞：探讨直播低延迟低流量的粉丝连麦技术

性能优化

1. 移动直播技术秒开优化经验（含PPT）
2. QQ空间直播秒开优化实践
3. Facebook 直播如何撐起瞬間 80 萬人的流量？
4. 浅析低延迟直播协议设计：RTP/RTCP
5. 如何实现1080P延迟低于500ms的实时超清直播传输技术

优秀开源项目

1. 【Android】DyncRTMPLiveClient-Android-推流-拉流-连麦-弹幕
2. 【IOS】MPCHybirdEngine-IOS-推流-拉流-连麦-美颜-弹幕
3. ijkplayer-播放器
4. 基于ijkplayer的视频直播软件
5. 【IOS】现了作为一个直播App的基本功能，比如本地视频流采集、播放、美颜、礼物、点赞出心
6. 【IOS】PLCameraStreamingKit
7. 【IOS】一个高仿项目

App技术点

1. 【IOS】仿在直播、映客、Periscope、花椒等直播APP点赞动画
2. 【IOS】上弹幕源码实现
3. 【IOS】基于IOS的图像处理 美颜
4. 开源的H.264编码器
5. 【IOS】直播开源项目 喵播-APP
6. 【Android】开源弹幕
7. 【Android】仿花椒直播聊天的时候消息向上弹出，一定时间后自动消失的效果
8. QQ 空间直播页面礼物冒泡效果

服务提供商

1. AnyRTC-全球首创RTMP + RTC;
2. 网易云信 - 在线教育;
3. 腾讯云 - 老牌公司;
4. 声网
5. 阿里云

专栏博客

1. WebRTC开发总结
2. 铂渊信息技术
3. 雷霄骅(leixiaohua1020)的专栏一个广院工科生的视音频技术笔记

竞品分析-产品方向

1. 全民娱乐直播：映客、花椒直播竞品分析
2. 花椒和映客直播App竞品分析
3. 视频直播的发展历程、产品分类及现况
4. 站在风口，移动直播+营销将何去何从？
5. “映客直播”产品体验报告
6. 移动直播异军突起：ME直播产品体验报告

业界新闻

1. AnyRTC：国内独家拥有四连麦技术的直播平台
2. 直播逐渐渗透各行各业，在未来有哪些新的趋势？
3. 给你一幅中国 VR 产业的全景图（内附PDF版）
4. 在直播大战中杀出重围的一种套路—搞CP
5. PPT+长文推荐：『直播』大时代
6. 以直播类产品为例，产品总监如何制定公司2016年的KPI？
7. 【直播风口】--资讯整合
8. 游戏直播产品的 10 个 Growth Hacking 营销案例盘点

欢迎加入我们一起研究直播技术：

GitHub持续更新-欢迎Star

QQ群：580477436

Email: zhulang@dync.cc

视频直播，确实不是你想做，想做就能做。这是一个强！技术&强！运营的工作，非常消耗资源，需要巨额的带宽成本和顶尖的技术人才。所以第一你得有钱，其次有钱也不能解决问题，得有人才

作为一个想速成的公司来说，能买的服务就尽量买吧（不要问我怎么知道的），省时省力。视频云，买！（个人比较喜欢网宿的服务），还有你说的美颜功能，买！客服系统，买！

前期要准备好至少600万，不一定够花3个月，好，接下来我告诉你怎么花钱

一、带宽成本=30万/月
以2w人同时在线来看，手机码率如果在600Kb，电脑的码率在1M，基本可以算是高清了，那么每月的带宽费用就至少在30万

二、人力成本=50万/月
10个技术 = 2万*10人 = 20万（服务端4个，IOS3个，安卓3个）
10个运营 = 1万*10人 = 10万 （主播管理6个，活动策划2个，主播财务管理2个）
2个产品经理 = 5万「谢三藏提醒」
5个审核和推荐（假设有500个同时直播）= 3万
3个客服 = 2万
1个数据 = 2万
5个市场和渠道 = 2万*5 = 10万
其他人员，如财务、Hr等 = 3万

三、渠道支出 = 100万/月
你得投广告吧，你得买新用户吧，一个比较理想的用户单价，假设他为10元/个，那么你想保持2万的同时在线，一天至少得要20万的DAU，粗暴的假设，每天的量中10万是新增用户（对于一款新产品这个新增用户占比太友好了），其中5万是自然新增（我特么说的是不是太理想了），那么你每日，是日！哦，的花费就在50万，一个月得1500万。我知道说到这里你肯定不服，考虑到你要从0做起，一个月做到20万DAU（然而并不太可能），假设这是一个线性增长，且新增用户的一半是自然新增不算费用，那么一个月的费用依然在100万左右

四、其他成本 = 20万/月

好了，算到这里，每个月大概需要200万的支出，我还是比较节俭的，目前市面上的直播公司，尤其是最近比较火的手机直播软件公司，没有一个是草根出身的，都是抱大腿有干爹的，他们有钱、有技术、有推广资源，但他们一年后还能不能存在，谁也不能肯定。所以，如果有其他更好的更容易的创业方向，还是选择其他吧

补充：不知道为什么，你没有提到经济系统，做了用户付费之后，你可能每个月能有100万的流水，30万的收入。美好么？不美好。就算你每天都是20万的DAU，付费率5%，每月流水1000万，收入300万，考虑到其他成本，半年内也一直在烧钱。

如何快速搭建一个完整的手机直播系统

在这个直播如火如荼的时代，各大云服务提供商也站到了时代的风口上，因此，如何选择产品和服务快速搭建直播系统，我想应该是众多创业者最关心的问题了，趣拍直播SDK就很好集成，下面会跟大家一一分享。

下面，我们先看下搭建一个完整的手机直播都包含哪些必须的环节：推流端（采集、前处理、编码、推流），服务端处理（转码、录制、截图、鉴黄），播放器（拉流、解码、渲染）、互动系统（聊天室、礼物系统、赞）。

手机直播推流端需要做哪些工作？

直播推流端即主播端，主要通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发。

采集

手机直播SDK通过手机摄像头和麦克风直接采集视频数据和音频数据。其中,视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。对于采集到的原始音视频的体积是非常大的，因此需要经过压缩技术来处理，降低视频的大小来提示传输效率。 在手机视频采集方面，iOS系统在硬件的兼容性方面做得比较好，系统本身提供了比较完整的视频采集的接口，使用起来也比较简单。但是，Android系统就比较麻烦了，千奇百怪的机型都有，适配起来非常难。我们在初期做了一项调研，发现Android的适配率还不到50%。

前处理

在这个环节主要处理美颜、水印、模糊等效果。特别是美颜功能几乎是直播的标配功能，没有美颜的直播主播们根本提不起兴趣。我们见过太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上。所以，在选择直播SDK时，没有美颜和水印功能基本就可以选择放弃了。

美颜实际上是通过算法去识别图像中的皮肤部分，再对皮肤区域进行色值调整。通常情况下人的肤色与周边环境色调存在较大差异，通过颜色对比，找到皮肤的基本轮廓，进一步进行肤色检查还可以确定人脸范围。找到了皮肤的区域，可以进行色值调整、添加白色图层或调整透明度等来等来达到美白效果。美颜除了美白效果还需要磨皮功能，磨皮实际上就是用模糊滤镜实现的。滤镜有很多种，如高斯滤波，双边滤波，导向滤波，到底选择什么样的模糊滤镜各家也有自己的喜好。

在美颜处理方面，最著名的GPUImage提供了丰富的效果，同时可以支持IOS和Android，还支持自己写算法实现自己最理性的效果。GPUImage本事内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了，比如大家可以试试使用GPUImageBilateralFiter的双边滤波滤镜来处理基本的磨皮效果，想要实现更理想的效果还是要通过自定义算法去实现的，各家也都有自己一套算法。

编码

为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积。现在比较常用的视频编码是H.264，但具有更高性能的H.265编码技术正在飞速发展，并可能很快成为主流；在音频方面，通比较常用的是用AAC编码格式进行压缩，其它如MP3、WMA也是可选方案。视频经过编码压缩大大提高了视频的存储和传输效率，当然，经过压缩后的视频在播放时必须进行解码。通俗点讲就是编码器将多张图像进行编码后产生一段段GOP（Group of Pictures），播放时解码器读取一段段GOP进行解码后读取图像并进行渲染显示。 在编码方面的核心是在分辨率、码率、帧率等参数中找到最佳平衡点，达到体积最小画面最优的效果，这些参数各家也都有自己的一套核心参数。

2012年8月，爱立信公司推出了首款H.265编解码器，六个月后，国际电联(ITU)就正式批准通过了HEVC/H.265标准，称之为高效视频编码(High Efficiency Video Coding)，相较于之前的H.264标准有了相当大的改善，做到了仅需要原来一半带宽即可播放相同质量的视频，低于1.5Mbps的网络也能传输1080p的高清视频。国内，如阿里云、金山云都在推自己的H.265编解码技术，随着直播的快速发展和对带宽的依赖，H.265编解码技术已有全面取代H.264的趋势。当然，全面推开应用还需要些时间。
另外，硬件编码已经成为手机直播的首选方案，软编码处理在720p以上的视频颓势非常明显。在IOS平台上硬件编码的兼容性比较好，可以直接采用，但在 Android 平台上，Android的MediaCodec 编码器，针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的成本还是非常高的。

推流

要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。 在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。

当然，在网络传输方面全部自己来做基本不现实，找提供推流服务的CDN服务商提供解决方案是最好的选择，可参考文章开头介绍的云视频服务商。据了解，阿里云是国内唯一能自研CDN缓存服务器的厂商，性能还是非常有保障的。通常，大多数直播平台都会同时接入多个视频云服务提供商，这样可以做拉流线路互备，对推流后视频集群再进行优化也可提高直播的流畅性和稳定性。

服务端处理需要做哪些工作？

要想适配各终端和平台，服务端还需要对流进行转码，如支持RTMP、HLS、FLV等格式拉流，支持一路转多路适配不同网络和分辨率的终端设备。另外，像现在必备的鉴黄功能也需要服务端完成。

截图、录制、水印

像阿里云、金山云、UCloud等云服务商都提供了实时转码技术将用户推流码率较高（比如720P）实时转化成较低清晰度（比如360P）的流以适应播放端的需求。如果要自己搭建实时转码系统，这个成本是极高的。一台8核设备只能实时转10 路流，如果一个正常的直播平台有1000路流，那至少就需要100台设备，加上后期的运维成本，一般公司就吃不消了。实时截图功能和实时转码类似，只是一般单机可以处理100路流。市面上云服务提供商基本上都提供了服务端转码、截图、录制功能，建议选择好的云服务提供商即可，可以节约大量成本。

鉴黄

2016年，4月14日上午10时，文化部公布了一则消息，斗鱼、虎牙、YY、熊猫TV、战旗TV、龙珠直播、六间房、9158等网络直播平台因涉嫌提供含宣扬淫秽、暴力、教唆犯罪等内容的互联网文化产品，被列入查处名单。文化部已部署相关执法机构查处涉案企业，将及时公布处罚结果。在前期的野蛮生长后，国家介入管制一定程度上遏制了直播的发展速度，但更有利于直播行业打造健康的生态，进入良性发展。这也意味着直播行业鉴黄成了必须环节，使用技术手段去鉴黄是手机直播平台必然采用的方案。
市面上提供鉴黄服务的方案主要有两种，第一种是对视频进行截图，然后对图片进行鉴黄，返回鉴黄结果和分值。典型的企业有阿里（绿网）、图谱科技，他们目前都支持直接传入视频，经过服务端分析返回结果，鉴黄的结果分为色情、疑似色情、正常或性感，并对每种结果进行打分。通常由业务系统接入鉴黄服务，根据鉴黄结果对直播流进行控制，如切断直播流、禁用用户的账号等。第二种是和CDN结合，直接对直播流进行分析，识别结果也分为色情、疑似色情、性感和正常，业务系统根据识别结果直接控制直播流。典型的企业是Viscovery，这套方案的优点是实时性保证比较好，缺点是必须部署到CDN或自己的机房，使用成本相对高一些。

趣拍微视频云服务作为一站式直播解决方案提供商，我们的主旨是让用户以最短时间、最小成本接入直播服务。因此，用户只需在控制台对鉴黄服务进行配置就可以针对每个应用，每一路直播流进行实时审核，审核内容包括色情、暴恐、时政敏感等。在控制台中，趣拍微视频服务实时将鉴黄结果返回，用户可以直接查看色情直播和违规界面的截图，同时可以对直播流进行控制，切断问题直播流。我们提供了短信、邮件和站内信提供功能，避免漏洞一个非法视频，给平台造成损失。数据统计功能让用户可以把握平台最新的动态信息，为进一步采取必要的措施提供可靠的依据。同时，为了满足用户定制化需求，我们还提供了丰富的接口，可以很方便的将鉴黄服务接入到自己的业务系统。

播放器端需要做哪些工作？

在播放器端如何做到秒开，在直播过程中保证画面和声音清晰度的同时，稳定、流程、无卡顿的直播流量，这些工作都需要播放器端配合服务端来做优化，做到精确调度。

拉流

拉流实际是推流的逆过程。首先通过播放端获取码流，标准的拉流格式有RTMP、HLS、FLV等。RTMP是Adobe的专利协议，开源软件和开源库都支持的比较好，如开源的librtmp库，播放端只要支持flashPlayer的就能非常简单的播放RTMP直播，直播延迟一般在1–3秒。HLS是苹果提出的基于HTTP的流媒体传输协议，HTML5可以直接打开播放，通过微信、QQ等软件分享出去，用户也可以直接观看直播，可以说手机直播app，HLS拉流协议是必须支持的，缺点是延迟通常大于10秒。FLV（HTTP-FLV）协议是使用HTTP协议传输流媒体内容的一个协议，也不用担心被Adobe的专利绑架，直播延迟同样可以做到1–3秒。

趣拍微视频云服务的直播拉流提供了RTMP、HLS、FLV三种格式，满足不同业务场景的需求，如对即时性要求较高或有互动需求的可以采用RTMP或FLV格式进行直播拉流播放；对于有回放或跨平台需求的，推荐使用HLS。当然，三种协议是可以同时使用的，分别用到自己的场景就可以了。

解码和渲染

拉流获取封装的视频数据后，必须通过解码器解码、渲染后才能在播放器上播放。它是编码的逆过程，是指从音视频的数据中提取原始数据。前面介绍的H.264和H.265编码格式都是有损压缩，所以在提取后的原始数据，并非原始采样数据，存在一定的信息丢失。因此，在视频体积最小的情况下通过各种编码参数保留最好的原始画面，成为了各视频公司的核心机密。

考虑对高清的支持，解码肯定还是要选择硬解码的。前面介绍过，IOS系统由于硬件比较单一、比较封闭，支持的比较好，Android系统由于平台差异非常大，编解码要完全兼容各平台还需要很多工作要做。

渲染最大的难点不在与画面绘制，而在于画音同步，业内大部分直播平台在这块做的都还是不够的。我们在这方面积累了一些经验和大家分享。

手机直播中的交互系统

手机直播中最常见的交互有聊天室（弹幕）、点赞、打赏和礼物等，有些比较有特色的手机直播平台也加入了和主播互动的游戏功能。交互系统涉及消息的实时性和互动性，在技术实现上大多是使用IM的功能来实现的，对服务器的压力也是比较大。 对于在线人数比较多的房间，弹幕消息量是非常大，主播与用户其实都看不过来，为了缓解服务器压力，在产品策略可以做一些必要的优化，比如对于发送消息的频率进行限制或对每条消息发送对象的上限进行限制等。

聊天室

手机直播中的弹幕交互功能已经成为直播必不可少的部分，是用户和主播互动的主要方式。手机直播中的弹幕实际上就是IM中的聊天室功能。聊天室和群聊功能类似，但聊天室的消息是不需要分发给不在线的用户的，对于历史消息也不需要查看，用户只有进入聊天室后才能查看聊天消息和群成员信息。要面对复杂多变的网络状况，还需要根据用户位置就近选择近对应运营商的单线机房接入弹幕消息服务，让弹幕更及时。当然，可以根据团队情况选择自己搭建还是选择第三方的聊天服务。

趣拍直播SDK提供丰富的聊天室功能和接口，以最简单的方式对接自己的聊天系统或第三方的聊天系统。

礼物系统

礼物系统已是绝大多数手机直播平台的标配了，它是这些平台主要的收入来源。在手机直播平台上我们常常可以见到土豪秒榜、土豪对刷的情景，据报道，明星直播一场礼物收入几十万也是常有的事，一年千万收入的网红也不少，可见国内有礼物消费习惯的土豪还不少。另一方面，送礼物的形式增强了用户和主播之间的互动交流，也是主播依赖平台的最主要原因。

礼物的收发在技术实现上也是用聊天室接口做的，通常采用IM中的自定义消息实现，当用户收到或发送礼物时将自定义消息对应的礼物图形渲染出来。另外，面对大量用户刷礼物时，礼物系统对一致性要求就比较高了，所以在实现上存一份数据建多条索引是一种很好的选择，也可以降低对事务的依赖。

手机直播的前景

手机直播行业现在如此火热，我们认为这个火热会在很长一段时间内持续，并且在未来通过和各行业的整合，会成为具有无限可能性的行业。所以直播SDK的选择也成为一些企业的转折点，就比如趣拍直播SDK吧，拥有视频开发行业长达10年的历史，和阿里云、支付宝、钉钉、芒果直播有着紧密的合作，关于趣拍直播的云服务和技术总是能跑在行业的前面，选择趣拍直播SDK是一种信任。

往主要原因包括如下几点：

第一，手机直播的UGC生产模式比PC端的直播更明显，人人都有设备，随时随地开播，完全顺应了互联网时代的开放性原则，全民直播时代将内容生产潜力发挥到最大。如今，“网红经济”如此火热，更是刺激更多人去创造和传播优质内容。作为网红经济的代表，papi酱融资1200万，估值2亿，广告招标沟通会门票8000元/张，单条贴片广告中标价2200万，一个个数字都如此刺激大众眼球。手机直播中的网红价值也在被更多创业者重视，拥有极大的增涨空间。

第二，网络带宽和速度在逐渐提高，网络成本在逐渐下降，4G乃至今后的5G也会像今天的有线网络那么廉价，为手机直播提供一个极佳的发展环境。技术的发展，手机可以承载的内容也就越丰富，文字、声音、视频、游戏等都会在手机直播中呈现，创造更加丰富的用户体验。各行业都可以将直播作为一种工具接入到自己的应用中，教育、社交、电商、金融等行业都可以通过手机直播形式开展新业务，增强与用户之间的互动，提高用户粘性。比如，教育领域中的课后辅导完全可以以直播的形式开展业务，电商也可借助直播让用户挑选商品，促进销售。

第三，一个与VR/AR技术相结合的手机直播为整个行业的未来提供了新的发展空间。VR/AR直播能够让用户身临其境，带动主播与观众更贴切真实的互动，大大提高平台的用户参与度。更加创新的硬件设备与直播的结合，如穿戴设备，更加丰富的传感器，更方便的采集信息，也将会大大拓展手机直播未来的应用场景。哪家公司如果在VR/AR和穿戴设备上取得突破性进展势必会在直播行业取得领先地位。

总之，手机直播欣欣向荣的发展已是必然趋势，尽管国家层级在加强管控、内容创作上还比较单一，红海一片搏死拼杀，但是它的未来是一个具有无限可能的超级市场，这个领域必然将会诞生千亿市值的巨头。

播推流端即主播端，主要通过手机摄像头采集视频数据和麦克风采集音频数据，经过一系列前处理、编码、封装，然后推流到CDN进行分发。

采集

手机直播SDK通过手机摄像头和麦克风直接采集视频数据和音频数据。其中,视频采样数据一般采用RGB或YUV格式、音频采样数据一般采用PCM格式。对于采集到的原始音视频的体积是非常大的，因此需要经过压缩技术来处理，降低视频的大小来提示传输效率。 在手机视频采集方面，iOS系统在硬件的兼容性方面做得比较好，系统本身提供了比较完整的视频采集的接口，使用起来也比较简单。但是，Android系统就比较麻烦了，千奇百怪的机型都有，适配起来非常难。我们在初期做了一项调研，发现Android的适配率还不到50%。

前处理

在这个环节主要处理美颜、水印、模糊等效果。特别是美颜功能几乎是直播的标配功能，没有美颜的直播主播们根本提不起兴趣。我们见过太多case是因为没有美颜功能被抛弃使用的。另外国家明确提出了，所有直播都必须打有水印并回放留存15天以上。所以，在选择直播SDK时，没有美颜和水印功能基本就可以选择放弃了。

美颜实际上是通过算法去识别图像中的皮肤部分，再对皮肤区域进行色值调整。通常情况下人的肤色与周边环境色调存在较大差异，通过颜色对比，找到皮肤的基本轮廓，进一步进行肤色检查还可以确定人脸范围。找到了皮肤的区域，可以进行色值调整、添加白色图层或调整透明度等来等来达到美白效果。美颜除了美白效果还需要磨皮功能，磨皮实际上就是用模糊滤镜实现的。滤镜有很多种，如高斯滤波，双边滤波，导向滤波，到底选择什么样的模糊滤镜各家也有自己的喜好。

在美颜处理方面，最著名的GPUImage提供了丰富的效果，同时可以支持IOS和Android，还支持自己写算法实现自己最理性的效果。GPUImage本事内置了120多种常见滤镜效果，添加滤镜只需要简单调用几行代码就可以了，比如大家可以试试使用GPUImageBilateralFiter的双边滤波滤镜来处理基本的磨皮效果，想要实现更理想的效果还是要通过自定义算法去实现的，各家也都有自己一套算法。

编码

为了便于手机视频的推流、拉流以及存储，通常采用视频编码压缩技术来减少视频的体积。现在比较常用的视频编码是H.264，但具有更高性能的H.265编码技术正在飞速发展，并可能很快成为主流；在音频方面，通比较常用的是用AAC编码格式进行压缩，其它如MP3、WMA也是可选方案。视频经过编码压缩大大提高了视频的存储和传输效率，当然，经过压缩后的视频在播放时必须进行解码。通俗点讲就是编码器将多张图像进行编码后产生一段段GOP（Group of Pictures），播放时解码器读取一段段GOP进行解码后读取图像并进行渲染显示。 在编码方面的核心是在分辨率、码率、帧率等参数中找到最佳平衡点，达到体积最小画面最优的效果，这些参数各家也都有自己的一套核心参数。

2012年8月，爱立信公司推出了首款H.265编解码器，六个月后，国际电联(ITU)就正式批准通过了HEVC/H.265标准，称之为高效视频编码(High Efficiency Video Coding)，相较于之前的H.264标准有了相当大的改善，做到了仅需要原来一半带宽即可播放相同质量的视频，低于1.5Mbps的网络也能传输1080p的高清视频。国内，如阿里云、金山云都在推自己的H.265编解码技术，随着直播的快速发展和对带宽的依赖，H.265编解码技术已有全面取代H.264的趋势。当然，全面推开应用还需要些时间。
另外，硬件编码已经成为手机直播的首选方案，软编码处理在720p以上的视频颓势非常明显。在IOS平台上硬件编码的兼容性比较好，可以直接采用，但在 Android 平台上，Android的MediaCodec 编码器，针对不同的芯片平台表现差异还是非常大的，要完全实现全平台兼容的成本还是非常高的。

推流

要想用于推流还必须把音视频数据使用传输协议进行封装，变成流数据。常用的流传输协议有RTSP、RTMP、HLS等，使用RTMP传输的延时通常在1–3秒，对于手机直播这种实时性要求非常高的场景，RTMP也成为手机直播中最常用的流传输协议。最后通过一定的Qos算法将音视频流数据推送到网络断，通过CDN进行分发。 在直播场景中，网络不稳定是非常常见的，这时就需要Qos来保证网络不稳情况下的用户观看直播的体验，通常是通过主播端和播放端设置缓存，让码率均匀。另外，针对实时变化的网络状况，动态码率和帧率也是最常用的策略。

当然，在网络传输方面全部自己来做基本不现实，找提供推流服务的CDN服务商提供解决方案是最好的选择，可参考文章开头介绍的云视频服务商。据了解，阿里云是国内唯一能自研CDN缓存服务器的厂商，性能还是非常有保障的。通常，大多数直播平台都会同时接入多个视频云服务提供商，这样可以做拉流线路互备，对推流后视频集群再进行优化也可提高直播的流畅性和稳定性。

我的这个回答更偏向于移动端直播的构建，期间走了不少歪路，在这里总结下经验提供给大家，有错误的地方欢迎指正。

推荐阅读（都是自己写的文章）：

移动直播六大关键技术详解

直播云功能基础篇：推流和拉流、多协议输出、多访问方式、回源端口自定义

直播云功能处理篇：转码、录制、视频水印、视频截图

直播云功能高级篇：防盗链、秒级禁播、自动鉴黄、API接口

正文：

视频直播，主要涉及到采集、预处理、编码、传输、服务器转码、解码这样一个流程。如图所示

一、采集：采集主要包含图像采集和音频采集；

图像采集设置前置摄像头、后置摄像头，并配置采集的参数、图像数据的长宽、fps、输出的方向、横屏竖屏等，然后从回调中取到数据。

音频采集和编码主要面临的挑战在于：噪声消除（Denoise）、回声消除（AEC）算法等。

前期不需要音频数据处理需求的时候， 只需配置音频采集的采样频率、采样精度和声道。

二、预处理：分为音频处理和视频处理两个方面。

音频处理是直播难点之一，尤其主播离手机有一段距离，直播环境会有噪音，所以直播的音频处理是整体降噪的过程。增益降噪等处理可直接从 speex 项目中抽出来的声音处理代码，然后调用、处理。如有类似在直播的时候播放背景音乐的混音需求，就需要使用 Audio Unit 来实现音频数据的混音，而还需要将混音的背景音乐转成 PCM 数据，拷贝一份送入混音，原来的数据送入播放器。

滤镜、美颜功能是直播标配，如果需要美白、水印、裁剪等处理效果，就必须处理拿到的 buffer, 这个时候还要考虑到拿到的数据是 YUV 还是 RGB。iOS 上是不能对 YUV 格式直接进行美颜处理，只能是 RGB 格式。可选择使用 GPUImage 库，调用 GPUImage 来进行采集和美白、水印、裁剪的处理，然后取出来进行编码上传，并显示在预览画面上。

三、编码：

软编码: 现在广泛采用 FFmpeg 库结合编码库来实现，FFmpeg + x264 来编码视频数据 YUV/RGB 输出 H264 数据， FFmpeg+fdk_aac 来编码音频数据 PCM 输出 AAC 数据。

硬编码: iOS 8 之后开放了硬解码和硬编码 AP，所以基本上都是选择 VideoToolBox 和 AudioToolBox 进行图像和音频的硬编码。

四、传输：又拍云播放器采用 FFMPEG 进行数据的接收，推流端默认使用 FFMPEG 进行数据的封包发送。

相对来说，封包最主要注意的一个点是时间戳。因为用的 AVPacket 封包，每个包都会有一个DST(Decode Time Stamp)、PST (Presentation Time Stamp) 参数，从字面上可以理解，就是解码时间和显示时间，在没有 B 帧存在的情况下 DTS 的顺序和 PTS 的顺序应该是一样的。这块还涉及到重连和丢帧，用户的网络情况波动断开了,会进行重连。重连失败之后才会发送失败回调。丢帧是一个弱网情况的策略，根据音视频数据的缓冲区大小来判断是否丢帧,丢帧会优先丢非关键帧，保留关键帧，而一旦需要丢关键帧的时，关键帧后的非关键帧也会一起丢掉直到下一个关键帧，来保证画面不会花屏。

五、服务端

现在主流的两种推送协议是 RTMP 和 HLS，两者的优缺点我就不在这里做比较了。又拍直播云采用用的是 RTMP 协议。

六、播放器

播放器主要负责拉流、解码、播放。

1. 解析协议

播放器端根据 URL 解析所用的流媒体协议（RTMP，HLS）。

2. 解封装

解封装，就是 demux 的过程，从容器格式（FLV，TS）中，分离出音视频数据。

3. 解码

解码，就是把获取到的数据解压缩，恢复成原始数据。解码就是将 H264 变成 YUV，AAC 变成PCM。解码可以使用软解码，硬解码。

4. 渲染数据

采用 OpenGL 渲染 YUV 数据，呈现视频画面。将 PCM 送入设备的硬件资源播放，产生声音。

iOS 播放流式音频，使用 Audio Queue 的方式，即利用 AudioToolbox.Framework 框架。

这里都讲的都比较简单，没有深入到技术点。如果对直播技术兴趣的小伙伴，可以阅读推荐阅读，欢迎技术探讨交流。

视频直播技术还没有什么成熟的框架。都是各大公司自己弄的，技术门槛不低。同时涉及的带宽、服务器资源惊人。自建基本没戏。没有上亿的资金做垫底，我觉得就不用想了。可以考虑下云服务。例如网易云。同时在线2万。网易的报价是70万/月。什么美颜混音暂时就不用想了。
=================
这种问题其实纯粹浪费大家时间，对IT一窍不通的土豪根本不知道后面成本是多么惊人。

✔又一个具有国内特色扎堆项目

✔俗称一窝蜂项目，早如地产，上个是电商，现在是视频直播

✔只能说这浑水不好腾

他们都在吓唬你 ！！！
需要哪些准备工作，技术门槛有多高，资金支出要多少？
只需要找个外包团队，技术门槛在当前云环境下极低（聊天有聊天云 视频有cdn视频云） 100万！ 你不需要雇佣任何技术人员就能帮你搞定，剩下就是带宽费用了 2万人花不了多少钱

ps 我可以介绍很多技术团队给你 100万 app都可以搞定 ，看你后边怎么运营怎么砸钱了

看到90多个认真的回答，虽然信息量很大，但是窃以为楼主无法按照这些思路是解决问题。
我在即构科技做技术，有一些实操的经验。让我尽量根据实操经验去回答，希望有价值。

如何搭建一个完整的视频直播系统？

朋友打算打造一个全新模式的视频直播平台，主要功能有些类似现在很多的美女直播平台。假设前期同时在线观看人数为2W人，清晰度不低于720P，拥有美颜、混音等附加功能，还有最重要的不能卡顿。如果以上假设成立，需要做哪些准备工作，技术门槛有多高，资金支出要多少？

本来想长篇累牍的给你提供信息，但是最后长叹一口气，觉得必须要对你诚实。你要搭建的完整的视频直播系统技术门槛很高。不是一个创业团队短期内能够做到的。高在哪里？
1）技术积累：语音视频技术是硬骨头，不是简单搞几个页面，不是搞一个业务支撑系统，这是需要经过多年技术积累的。比如说YY，他们做很多年才积累到今天的水平。比如说腾讯，他们也是摸爬打滚了好多年才有几天的辉煌。
2）人力成本：语音视频工程师的价格是相当贵的，如果不是最贵的IT工程师，也是最贵之一。语音处理的模块包括噪音抑制，回声消除，自动增益，前向纠错，丢帧补偿，抖动缓冲等几个模块至少每人负责一个，然后要实现跨平台和全终端兼容，每个平台必须又要有一个人做。这么算起来，整个语音视频团队就至少十个人了。假定一个平均工资，十个人算下来一年也是不少钱的。
3）开发周期：开发周期至少要大半年，那还是一流的开发团队才能做到的。开发完成以后，效果好不好还是未知数。曾经有团队找到我，说他们很厉害，一年就开发出来了，但是就是回声消除和噪声抑制效果不好。我心里想，word哥阿，那是核心问题，核心问题你没解决，能算做好了吗？

上面说的是门槛，如果这个门槛没有吓住你，请继续看下面我的知识分享：
不卡顿是一个核心的特征，低延迟又是另外一个核心特征。但是这两个特征是一堆矛盾兄弟：如果要做到互动效果好，就要低延迟，如果要低延迟，就要把缓冲队列做的尽量短；如果缓冲队列短，就避免不了卡顿。因此，最折中的方案必须是要找到不卡顿和低延迟的平衡点，让语音视频不卡顿的情况下，达到最低的延迟。即构科技给花椒直播提供的视频直播方案中，充分的展现了这两个特征的平衡。我也是在给花椒直播提供服务的过程中，真心体会到，简简单单一句说“不卡顿就好了”，是多么的不容易，是多少个码农熬夜通宵的蹉跎青春。

“假设前期同时在线观看人数为2W人”
这个观看人数不算多的，对于一个能支持高并发的方案来说，2W多人观看是小case。还是拿我熟悉的即构科技说事情吧（因为别的公司我也不懂），单个房间支持百万在线整体支持千万级高并发的。团队是早期腾讯QQ出来的，多年的高并发经验积累也不是盖的。

清晰度不低于720P，
这需要保证比较高的码率，带宽要达到800kbps以上，也就是说终端的上行带宽要达到1M以上才比较合适。

拥有美颜、混音等附加功能
美颜可以做成插件的方式，如果自己能做出来，就用自己的，做的效果不好，就用别家的。
混音的功能可以在本地提供回调接口，把额外的语音流和本地采集进来的语音流混合在一起，产生背景音乐的效果。即构科技这边的做法是在SDK中提供了接口，开发这可以通过调用接口把数据扔个下层SDK进行混音。

上面也说了技术门槛有高，资金不是创业团队能承受的，最要紧的是，时间和机会成本，那是创业公司的生命线。我见到的很多创业公司都是两手准备， 一手采用第三方的视频直播SDK，尽快上线开展业务；另外一手自己组建团队稳扎稳打的研发，没有时间压力，慢工出细活。等到自己的方案成熟了，就把第三方直播SDK替代掉，自己控制核心技术，妥妥的。

直播，突然成为了中国互联网的一个最流行的词汇。在《2016-2020年中国网络直播行业深度调研及投资前景预测报告》中的数据表示，2015年，全国在线直播平台数量接近200家，其中网络直播的市场规模约为90亿，网络直播平台用户数量已经达到2亿，大型直播平台每日高峰时段同时在线人数接近400万，同时直播的房间数量超过3000个，更可怕的是，这一数据还在以极快的速度向上攀升。

高票答案非常详细的说了开发相关的前期工作。这边重要讲一下网络直播平台开销中的另一个大头：带宽的问题。在大量用户体量下，直播类的应用对于服务器的要求要高过一般的应用。

1、更大的数据量
视频数据和文本数据完全是两个量级的概念，假设一个直播房间有5000人，视频1s的数据60K，那么就需要5000*60=300000KB=292.97MB，基本已经达到了2-3三个手游的大小了，而这只是一个房间产生的流量。当前某著名网络直播APP日活跃用户超过了800W，服务器将承受458Gbps的带宽压力。

2、更高的并发量
不同于普通应用和游戏，直播类应用的使用时间段非常的集中，一般来说，社交类的直播app时间集中在晚饭后时间至睡前20点~23点，游戏类App活跃时间集中在下班后18~20点间，秀场类App集中在13点和18(午休及下班时间)，因此在这短短几小时之间，会涌入大量的用户，一次大V的直播通常就会造成百万级的用户登录，APP需要有详尽的限流、分流和负载均衡策略，保证服务器不会被冲垮。

3、更真实的用户登录场景
直播应用与普通应用相比，交互的功能异常多，除了直播视频流的服务器压力之外，还要包括用户消息推送、聊天、礼物、支付以及统计系统带来的数据交互压力，服务器进行需要识别不同的业务字段，才能精确判定用户的行为是否成功完成，从交互频率的角度上来说，直播类的应用，与其说更像应用，不如说更像游戏。

4、更低的延迟
直播需要一个很强的即时性，如果主播的行为和用户的评论无法同步的时候，会给用户非常不好的体验，如果一个用户发现其他用户在欢呼鼓掌，但是屏幕中的主播什么动静都没有的时候，这个直播应用基本可以不要再用了，因此直播类应用不仅需要面对更大的数据量和更高的并发，还要保证更低的延迟。通常可以要保证服务器的处理数据速度要快，要有足够强大的带宽；另外则是通过P2P算法保证数据分享的合理性，保证服务器的数据和P2P的数据可以达到平衡。

直播应用下的服务器成本，与将要承受的流量情况息息相关，不同的直播应用，交互的频度、深度不同，就会产生不同的带宽压力。我们一起来算一笔帐，为直播应用准备服务器，大概需要多少钱？ 首先，我们要买一个服务器。买多大的服务器呢？服务器的带宽要满足直播应用的带宽需求，在这里，科普一下带宽是怎么看的： 带宽通常使用的单位是bps（bits per second），8 bits通常等于1Byte，100Mbps在换算成我们熟悉的文件大小的时候，要除以8，也就是在100Mbps的带宽下，每秒钟可以下载12.5MB的文件，那么一般来说，直播应用需要多少带宽呢？

直播应用一般使用的分辨率是360p，720p以及1080p三种，按照题主以720p来计算，那么直播应用需要1024kbps的带宽，也就是每秒传递的数据大小为1024/8=128KB。简单来说，如果在APP中打开直播，使用了720p的分辨率，一个用户每秒钟需要传输128KB的数据（当然实际情况中直播应用还有消息推送，送礼，支付等行为，直播画面分辨率、压缩比等区别，实际会消耗更多的数据）。

以目前最红火的几大直播平台为例，斗鱼TV的在线人数可以超过1000 万，战旗 TV 在在线人数约500 万左右，龙珠在线人数约 400 万左右，虎牙在线人数约100万，直播平台的带宽成本通常是带宽峰值月结的形式，按照题主说的，前期2W左右的在线，理论上当月的开销就在30W人民币左右。 所以对于直播应用来说，服务器最难处理的环节就是视频流量和用户交互等高频率高带宽的场景，由于用户的行为难以预测，经常会出现突发性的暴涨，进行活动时流量可能是平时的几十倍。

所以在直播系统的准备中，一定要对所有接口进行压力测试，提前暴露问题并解决，确保活动的顺利实施。这里安利一款产品WeTest服务器性能可同时调用的场景接口，不断增加可实现的并发数，提供更大的并发压力和更真实的行为场景，节省成本。

做直播不仅需要完整的系统，千万别遗漏了服务器是否稳定，支撑住整个平台的正常运营。