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

采集，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解决的。总之带宽非常贵。

祝你朋友好运。

编辑于 2016-04-06121

条评论感谢

分享

收藏•没有帮助•举报•作者保留权利

张云龙，全民TV

技术总监

528人赞同

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

PC、Android、iOS三大平台（一般互联网创业项目标配）每个平台要做2种端：面向客户的直播端，和面向主播的推流端（标配x2）

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

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

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

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

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

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

编辑于 2016-07-1694

条评论感谢

分享

收藏•没有帮助•举报•禁止转载

何李石，在七牛做世界上最好的直播云服务

344人赞同

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

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

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

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 上面很多多媒体和图形图像相关的处理：github.com/google/grafi

3. 编码

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

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

4. 传输

传输涉及到很多端：

从主播端到服务端

从收流服务端到边缘节点

再从边缘节点到观众端

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

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

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

国民首席、熊猫 TV 首席架构师杨武明在「Gopher 北京聚会」上做过一个「Golang在视频直播平台的高性能实践」的分享，值得参考：mp.weixin.qq.com/s?

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 庄明浩的长文分析：zhuanlan.zhihu.com/p/20

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

编辑于 2016-04-0821

条评论感谢

分享

收藏•没有帮助•举报•禁止转载

滕腾，退役设计师

好奇实验员

203人赞同

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

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

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

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

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

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

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

1.直播类型

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

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

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

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

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

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

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

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

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

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

秀场直播。

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

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

电竞直播。

以游戏赛事，游戏教程等为主要内容。最先是在美国兴起的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直播调试现场）

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

为什么捏？

一个服务商告诉我的：

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

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

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

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

编辑于 2016-07-046

条评论感谢

分享

收藏•没有帮助•举报•作者保留权利

金山18667号码农，码农

170人赞同

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

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

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

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

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

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

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

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

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

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

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

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

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

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

发布于 2016-06-132

条评论感谢

分享

收藏•没有帮助•举报•作者保留权利

家美，思维跳跃狂

35人赞同

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

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

前期要准备好至少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万，考虑到其他成本，半年内也一直在烧钱。

编辑于 2016-04-0719

条评论感谢

分享

收藏•没有帮助•举报•作者保留权利

凌寒，音视频技术攻城狮，计算机硕士

46人赞同

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

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

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

腾讯云。定位：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的专家支持，这在业界尚属领先。总的来说，网易视频云的性价比在云服务商里算是最高的。

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

编辑于 2016-04-065

条评论感谢

分享

收藏•没有帮助•举报•禁止转载

UCloud

曾凯源，UCloud直播云

46人赞同

直播产品首先要确认是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

编辑于 2016-04-2024

条评论感谢

分享

收藏•没有帮助•举报•禁止转载

张腾，欢迎同行交流~

23人赞同

前面有大神了，就不再赘述了，讲几个有可能遇到的问题

搭建直播框架很容易，搭建一个性能优良的框架就非常难了

1.大规模并发涌入的时候能否保持稳定，去年春晚网络直播，某乐，某腾被挤挂了，600万流量涌入我们的接口，顶住这样的的压力不是一件容易的事情。

2.低延时能保证吗？多低，三秒内可以吗，一秒呢？低延时的情况下，还能保证高质量（码率）吗？高质量低延时才是直播的真谛，自行车也能跑，有轮子，能跟汽车比吗？

3.网络抖动怎么办？任由客户卡在那里流失？运维部门匡匡地接电话，然后保证解决，其实之后做的只能自己测一测，改改参数什么的，有能力的还能联系联系CDN，看看节点情况，隔几天人家回复：确实当时那里的节点质量不好。 SO？客户已经流失掉了，那都是真金白银引进来的流量啊。

太多太多了，做一个框架容易，现在各种云服务吹的飞起，等你真正信了，用上了，就GG了...

发布于 2016-04-153

条评论感谢

分享

收藏•没有帮助•举报•作者保留权利

郑岐，网易公司-IM-直播-短信-专线电话

20人赞同

一、直播的技术架构：

直播视频采集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源码。感兴趣的朋友可私聊。欢迎交流，相互学习。

编辑于 2016-05-297

条评论感谢

分享

收藏•没有帮助•举报•作者保留权利

匿名用户

75人赞同

友情提示：

1、本答案偏题了；

2、提供不了技术支持，还有可能提供错误的技术支持；

3、本答案纯属娱乐；

－－－－－－－割－－－－－－割－－－－－－割－－－－－－－－－－－－－－－－－－－－

看到视频直播系统，我自己滚进来了……

正好刚刚从一个做音视频的团队离职，说一下上个公司的亲身经历吧，篇幅较长，不知道各位有没有耐心看下去。

我一直在用VC++写Windows客户端，去年4月份跳槽去了一家公司，名字就不提了，不大不小的一家公司，在软件园一期有独立的办公楼。进去后做的项目就是做一个类似于YY的项目，但是不会在国内推广，要在国外推广，所以不会和YY有市场占有率上的直接竞争，我负责实现Windows客户端。

面试的时候聊了不少，他们看中我实现UI和客户端架构能力。我也问了产品方面的事儿，说有一个产品团队负责，UI方面有一个UI团队负责实现界面效果。

进去后第一天开会，我说了一些我原来的一些项目经验，然后部门领导直接说：“那你以后就负责这个项目吧”，我当场懵逼了，这是什么节奏。要知道在上一家公司离职就是因为想做客户端负责人，然后实践一下团队内技术交换的想法，结果被上级领导即无道德底限又无智商底限的折腾黄了。结果在这家公司第一天就被委任如此重任，实在是懵逼的很，只好说，现在当务之急是把客户端做出来一个可发布版本，项目的事儿，发布完第一个版本再说吧。

刚开始看这个音视频客户端，那简直无法直视。产品业务逻辑没有、UI实现效果没有。我说有没有产品需求和设计文档，然后服务器人员发给我一份接口文档……

第一天下午入职把电脑装好后，第二天就开始写代码了。记得当初改客户端实现代码的时候发了一个朋友圈状态：“改了好几天代码，终于没有补破鞋的感觉了，取而代之的是要把屎做成饭的感觉，what a fucking day……”。

如果你理解MVC，你会理解那些不理解MVC的人写出来的代码是什么样的……所有的业务逻辑基本上都在Dialog里了，或者说是ViewController吧。

长话短说，就这样一边写代码，一边设计产品逻辑，一边告诉UI设计师怎么怎么去实现效果。大概一个月吧，发布了第一个客户端的可测试版本。

发布第一个版本的过程中发生了如下的事儿：

UI设计师给我的切图竟然失真……我去找UI设计师沟通，说提供给我的切图失真了，UI设计师一脸懵逼的看着我，什么是失真……

即时通讯模块是XMPP实现的，结果发现所有的业务逻辑都通过XMPP来实现的，比如获取个人资料，修改个人资料等功能都是通过XMPP消息来实现的……在上个公司天天吐槽后台服务器耦合性太高，看到了这个服务器，我好怀念他们……

我找部门经理说，客户端的产品逻辑应该重新设计下，说“现在登陆流程没有、大厅相关业务流程基本上没有、赠送礼物相关的业务逻辑没有”，产品组是不是应该重新规划下整个产品思路，就是照抄YY，也应该有一个明确的产品设计文档吧。结果被产品组回复：哎呀，现在产品组的这几个人每个人手里都有好几个别的项目，这个产品就先按你的想法做吧……我一脸懵逼……

音视频编解码是用的公司其他部门提供的技术……一个毕业一年多的女生既做音视频服务器又做客户端的音视频模块……

第一个版本终于发布了……

告诉部门经理说，第一个客户端版本虽然发布了，但是整个客户端架构还得大动，UI方面不用改了，架构必须重新写，不然后面添加功能耦合性太高了。部门经理说，好的，你先把现在的版本提交给测试吧，顺便把这个版本提交给测试组吧，你顺便负责下测试和发布流程。

测试组给我分了一个人，来测试整个系统……

两个月后，客户端重构版本发布了，看着清晰的MVC架构，我自己都佩服自己……开项目例会的时候我说客户端的重构版做完了，现在可以考虑下服务器的重构了。所有业务逻辑都放在XMPP服务器肯定是不行的，XMPP应该只提供即时通信功能，其他业务逻辑应该由一个Web服务器来提供。我这么描述的时候好没底气，因为我没写过服务器端代码……

我自己去找服务器的开发人员，说为什么要这么做，这么做的好处是什么……我是项目经理嘛，你们得听我的。

结果两个星期后，服务器开发人员调到别的部门了换了工作地点，不在北京了；接手了的服务器开发人员干了一个多月，有一天跟我说他要离职……换了另外一个人接手，半个月后告诉我他也要离职，工作交给了今年刚毕业的一个学生……我彻底懵逼了

好了，我他妈的不想写了，总之就是我得负责客户端代码，我得负责测试安排，我得负责产品，我得负责服务器架构设计，我他妈的还得负责联系公司的海外人员了解有没有对这个产品的推广计划，而我面试的时候只想安安静静地当一个写UI效果和业务功能的VC++工程师。

你们肯定要说，这样的破团队，只有你这样的傻逼才会想着呆下去，要我早就离职了。我只能说我喜欢上了公司的食堂，一天三顿都管饭。你要说，傻逼，那也不至于啊。我只能说，我去年花了6个月的时间，从一个身高175体重也是175的胖子，减到了标准的135斤。没有在食堂的饮食调节而是吃外卖的话，我做不到。其实工作了三个月之后我上班的唯一动力就是公司食堂了，因为我太想瘦下来了……

今年春节后上班第一天，我找部门经理说，我要离职了……

用一个月的时间给接手的人培训UI实现方面的知识，我说别在乎UI怎么实现的，如何把MVC模式理解好才是写客户端的基本，C++组的头头说，MVC我们都理解，你还是主要讲UI实现方面的知识吧。我当时差点就说“你理解个屌啊……理解的话我接手的时候客户端代码能烂成这样？”，但是我忍住了……没必要跟傻缺较劲不是……

其实上面的话跑题了，我也不能像别的大牛@姚冬、@张云龙一样回答这个问题，我只是个写业务逻辑的猴子。

我最后想说的是：要做一个视频直播系统，你们真的做过市场调研吗？真的考虑过清晰的产品逻辑吗？真的考虑过产品的卖点吗？太多的项目、太多的团队、太多的公司认为技术上实现了，产品好像自然而然的就有人用了，就有钱赚了。其实不是这样的，不是有钱赚了，而是有钱烧了。有很多人（比如上上个公司的Boss）认为码农怎么会懂产品，我就呵呵了，天天泡在产品的业务逻辑实现上的是程序员，有时候不是不理解产品，只是不想逾越自己的职责。

作为一个有追求的码农，有时候看着一些烧钱的项目真的好心疼……投资人拿钱去投资点实业多好，互联网行业真的不能创造价值，它只能帮助传统行业发挥原有的价值（此话非原创，不知道从哪看来的了……对原创者致敬），当你们投资一些项目的时候不要听那些人乱七八糟的胡扯了，只需要看这个项目具不具备这样的特质就行了。

PS：好像发个图片能有人点赞，个人原创作品《就干IT》。