作者：宋少东
链接：https://www.zhihu.com/question/41868659/answer/95092032
来源：知乎
著作权归作者所有，转载请联系作者获得授权。

技术相对都比较成熟，设备也都支持硬编码。IOS还提供现成的 Video ToolBox框架，可以对摄像头和流媒体数据结构进行处理，但Video ToolBox框架只兼容8.0以上版本，8.0以下就需要用x264的库软编了。Andriod 可以考虑用 ffmpeg 软编。

github上有现成的开源实现，推流、美颜、水印、弹幕、点赞动画、滤镜、播放都有，技术其实不是很难，而且现在很多云厂商都提供SDK，招几个懂行经验丰富的就可以，并不必须是流媒体人才。

链接：
如何搭建一个完整的视频直播系统？ - 网络主播

映客、Periscope、花椒等直播APP点赞动画:
GitHub - singer1026/DMHeartFlyAnimation: 直播点赞动画

Android开源弹幕：
GitHub - Bilibili/DanmakuFlameMaster: Android开源弹幕引擎·烈焰弹幕使 ～ JNI source:Bilibili/NativeBitmapFactory

IOS开源弹幕：
GitHub - panghaijiao/HJDanmakuDemo: A high performance danmaku engine for iOS

金山云移动端开源SDK：
https://github.com/ksvc

七牛云移动端推流开源SDK:
GitHub - pili-engineering/PLCameraStreamingKit: Pili RTMP Streaming SDK for iOS, H.264 and AAC hardware encoding supported. Camera and Microphone as input source.

基于Android手机推流：
GitHub - begeekmyfriend/yasea: RTMP streaming client in pure Java for Android for those who hate JNI.

基于IOS的图像处理：
GitHub - BradLarson/GPUImage: An open source iOS framework for GPU-based image and video processing

完整的基于IOS手机直播:
GitHub - songsmith/LiveVideoCoreSDK

IOS-推流端的 RTMP库：
GitHub - songsmith/ios-librtmp: For PushSDK

OBS-PC端主播推流工具，斗鱼等游戏直播都在用
GitHub - jp9000/obs-studio: OBS

RTMP直播可以用nginx-rtmp
GitHub - arut/nginx-rtmp-module: NGINX-based Media Streaming Server

开源播放器也很多，ffplay、jwplayer、ijkplayer等等，我就不一一给你发了，哈哈
https://github.com/Bilibili/ijkplayer

其实最难的难点是提高首播时间、服务质量即Qos，如何在丢包率20%的情况下还能保障稳定、流畅的直播体验，需要考虑以下方案：

1. 为加快首播时间，收流服务器主动推送 GOP 至边缘节点，边缘节点缓存 GOP，播放端则可以快速加载，减少回源延迟

2. gop丢帧，为解决延时，为什么会有延时，网络抖动、网络拥塞导致的数据发送不出去，丢完之后所有的时间戳都要修改，切记，要不客户端就会卡一个 gop的时间，是由于 dts 和 pts 的原因，或者播放器修正 dts 和 pts 也行（推流端丢gop更复杂，丢 p 帧之前的 p 帧会花屏）

3. 纯音频丢帧，要解决音视频不同步的问题，要让视频的 delta增量到你丢掉音频的delta之后，再发音频，要不就会音视频不同步

4. 源站主备切换和断线重连

5. 根据TCP拥塞窗口做智能调度，当拥塞窗口过小说明丢包率过高，需要切换节点和故障排查

6. 增加上行、下行带宽探测接口，当带宽不满足时降低视频质量，即降低码率

7. 定时获取最优的推流、拉流链路IP，尽可能保证提供最好的服务

8. 监控必须要，监控各个节点的Qos状态，来做整个平台的资源配置优化和调度

9. 如果你家产品从推流端、CDN、播放器都是自家的，保障 Qos 优势非常大

10. 当直播量非常大时，要加入集群管理和调度，保障 Qos

11. 播放端通过增加延时来减少网络抖动，通过快播来减少延时

12. 引入TCP/IP 优化，针对直播业务做下行TCP/IP优化，在某一个节点丢包率50%情况下，800kb码率可流畅播放

2016-05-27 补充：
我先后调研了七牛云、金山云、乐视云、腾讯云、百度云、斗鱼直播伴侣 推流端，功能几乎都是一样的，没啥亮点，不同的是整个直播平台服务差异和接入的简易性。后端现在 RTMP/HTTP-FLV 清一色，APP挂个源站直接接入云厂商或CDN就OK。直播要做好真心不易，楼主也做的不是很好，只是在不断的摸索、改进和优化，关于如何选择接入的云厂商或CDN，哪个稳定选哪个！

带宽成本：

粗略计算，斗鱼 TV 的在线人数超过 1000 万 +，战旗 TV 在在线人数约 500 万 +，龙珠在线人数约 400 万 +，虎牙在线人数约 100 万 +（统计于 2016 年 2 月 18 日，以各大节目在线人数人工相加得出，并未统计全部节目）。

直播平台的带宽成本费用通常取带宽峰值月结，当月 100 万最高同时在线人数，对应消耗带宽 1.5T，月结费用 3000 万人民币，20块钱1M的样子，根据直播方需求不同，价格也不一样，质量越好的就越贵。

PS：此计算方式来源于网络

可以算出各家在带宽方面每年需要付出的成本，斗鱼 TV 为 3 亿人民币，战旗 TV 为 1.5 亿人民币，龙珠为 1.2 亿人民币，虎牙为 3000 万 + 人民币。

运营层面：
正是因为现在做这个的太多了，所以你要运营和推广，这个就比较烧钱了，反正我现在知道的一些做移动直播、游戏直播、秀场直播的A轮至少得上千万。

用户体验：
离不开CDN和云厂商，他们会帮你解决大部分的技术问题，不流畅、卡顿、花屏、带宽不够、攻击、用户体验不好等一系列问题，还给你提供免费技术支持，上面提到的那些技术方案就是云厂商和CDN来帮你解决的。编辑于 2016-10-31 55 条评论 感谢

分享

收藏 • 没有帮助 • 举报

• 作者保留权利 收起

14 赞同反对，不会显示你的姓名

卜赫 资深兔子爱好者

14 人赞同

直播的技术难点还是挺多的，就我目前了解到的一些来谈谈，可以结合这个去做团队搭建： 客户端： 客户端主要类型是 iOS、Android、PC、专业设备。 最后一个了解不多，后续再补充。 iOS 的优势在于 8.0 之后开放了硬编码的接口，介于只有 Apple 在做硬件，在… 显示全部

直播的技术难点还是挺多的，就我目前了解到的一些来谈谈，可以结合这个去做团队搭建：

客户端：
客户端主要类型是 iOS、Android、PC、专业设备。 最后一个了解不多，后续再补充。

iOS 的优势在于 8.0 之后开放了硬编码的接口，介于只有 Apple 在做硬件，在硬件兼容性上要好很多，但是很少有人会告诉你在 iOS 不同版本上还是有很多的坑和差异，这点需要时间积累和经验。另外在软编上，码控方面会好一点。

Android 的问题在于机型和版本的集合实在太多了，硬编变成了不可能完成的任务，只能希望 google 有什么在硬件上一致的协议等等了，这点在 MTK 这个低端平台上尤为突出，MTK 用 gpu 做硬件编解码，没有专业的 DSP 芯片，这个真心很累。软编也有很多选型，不一定非要用 ffmpeg ，思科的 openh264 也是不错的选择。

PC 上有一个不错的跨平台推流软件 OBS ，免费也还算的上靠谱，问题是他是 GPL，商业不友好，而且用起来有些麻烦，尤其是结合 DV 使用的时候。

所以，这些问题都会在做的过程中被发现，并花费大量的时间和精力进行解决，需要招聘专业的视频开发工程师，iOS 工程师，Android 工程师。

服务器端：

服务器端方案有两个，一个依赖 CDN 厂商：
nginx-rtmp or srs + CDN ，nginx-rtmp 或者 srs 做为源站，上下行用 CDN 厂商，CDN 厂商对于直播场景还是做了一些优化的，比如用 push 模型降低延迟，但是因为直播的场景和传统的文件分发的场景不一致，文件分发看中的其实 CDN 的 cache 功能，而直播看中的是网络分发能力，主要是最佳链路的选择，需要运维人员和有一定开发能力的工程师、搭建这套系统和在不同 CDN 厂商间按需选择。

另一个是自建节点，就更复杂了，但是好处就是可以选择更优质的节点，按需部署节点，用更智能的算法选择链路，这个对分布式算法，网络都有非常高的要求，找到这样的工程师有时候是要靠运气的。主要需要网络工程师、分布式工程师和算法工程师，还要有资深运维人员。

附上上述项目地址仅供参考：
GitHub - pili-engineering/PLCameraStreamingKit: Pili RTMP Streaming SDK for iOS, H.264 and AAC hardware encoding supported. Camera and Microphone as input source.

GitHub - pili-engineering/PLPlayerKit: Pili Live Streaming player SDK for iOS, RTMP and HLS play supported.

GitHub - pili-engineering/PLDroidCameraStreaming: Pili RTMP Streaming SDK for Android, H.264 and AAC software encoding or hardware encoding are both supported.

GitHub - pili-engineering/PLDroidPlayer: Pili Live Streaming player SDK for Android, RTMP and HLS supported.

GitHub - ossrs/srs: SRS is industrial-strength live streaming cluster, for the best conceptual integrity and the simplest implementation.

GitHub - arut/nginx-rtmp-module: NGINX-based Media Streaming Server

GitHub - jp9000/OBS: Open Broadcaster Software

GitHub - cisco/openh264: Open Source H.264 Codec

编辑于 2016-07-25 2 条评论 感谢

分享

收藏 • 没有帮助 • 举报

• 作者保留权利 收起

10 赞同反对，不会显示你的姓名

郑岐 网易公司-IM-直播-音视频

10 人赞同

一、回答这个问题，我们先看看一个直播产品的功能模块，根据功能模块才好分析所需要的技术人才和判断难点。 1、从推流到拉流的通道，这当中包括数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示整个流程；因此，需要懂流媒体处理的技术； … 显示全部

一、回答这个问题，我们先看看一个直播产品的功能模块，根据功能模块才好分析所需要的技术人才和判断难点。
1、从推流到拉流的通道，这当中包括数据采集→数据编码→数据传输(流媒体服务器) →解码数据→播放显示整个流程；因此，需要懂流媒体处理的技术；
2、内容复制分发，也就是cdn这块，服务器收集到主播视频后再通过在全国各地的节点将视频内容分发到终端。cdn是直播中最贵的，技术难度较高，一般都是采用第三方的；如果自己做的话，也需要和cdn厂商对接有经验的技术；
3、美颜：美颜涉及到复杂的算法和图像处理技术，美颜起初是用于图片上，目前图片上的美颜技术已经较为成熟，然而在视频上的美颜还需要很长的路要走。这里就需要图像处理算法工程师；
4、聊天室：我们在看直播的时候，还可以在聊天室中聊天，这是应用了im及时通讯中的聊天室功能，聊天室和群聊的区别是，只有用户进入聊天室才能发言，看到好友，退出聊天室后就类似于退群，就收不到消息，看不到用户，看不到聊天记录了。因此，聊天室这块需要在即时通讯方面经验丰富的工程师；
5、服务器：对于直播产品来说，流量变化是非常大的，一天中直播的流量高峰期基本在晚上，有时候搞个活动，或周杰伦跑来直播了，那这个时候流量可能是平时的几十倍。流量忽高忽低对服务器自然提出了很高的要求。

二、难点
从客户终端来看，一个简单的直播产品，在技术底层的操作确实如此之多，每一项技术都是一个行业。
1、开发量大：上面已经提了最基本的几项开发，每一项开发工作都是很耗费时间的；
2、技术要求高：以聊天室举例，聊天室看似只是直播中的一个小功能，然而对消息处理做不好，就直接导致闪退、卡顿等问题。尤其是在一个聊天室中用户并发量上万的时候，想想1s种要送多少礼物，多少点赞，多少发言，在这种高并发的场景，对im的要求极其高；
3、烧钱，以cdn为例，目前企业自建的平均成本是1.3万元/G/月，刚开始用第三方会便宜一些。但是，可以看看YY的财报，一大部分成本都在cdn上，映客CEO也表示过目前成本最大的还是在于cdn；
4、坑多：第一部分提到的技术，如果在最开始没有把选型做好，或者技术能力不够，那么以后就走上了漫漫的填坑路，新的功能来不及做，老的坑还没有填好；
5、时间成本：等我辛辛苦苦搞了大半年开发了一个直播产品时，直播这场战争或许已经死去了很多家，这个时候活下的直播产品已经拥有了大量用户，我拿什么和他们竞争。

三、利益相关
我们团队是做直播、im技术的，底层架构都是做好的，开放给开发者sdk、api接口、demo，开发者接入后就可以实现直播的功能。
到这里我已经告诉你，怎么样解决直播技术的难点了，哈哈。
知乎专栏 这篇文章汇集了我对这个行业的理解，欢迎大家指点。

编辑于 2016-08-01 11 条评论 感谢

分享

收藏 • 没有帮助 • 举报

• 作者保留权利

超级向向阳 http://UCloud.cn技术团队

5 人赞同

贴一个我司流媒体研发总监曾凯源于〖KVM社区&UCloud技术微信群〗线上的分享，希望对大家实现直播服务有启发，顺带给我司做个小广告。 直播场景&直播服务架构直播场景首先，介绍当下很火的直播场景。目前对直播场景的基本分类主要有媒体&活动直播、游戏直播… 显示全部

贴一个我司流媒体研发总监曾凯源于〖KVM社区&UCloud技术微信群〗线上的分享，希望对大家实现直播服务有启发，顺带给我司做个小广告。

直播场景&直播服务架构直播场景

首先，介绍当下很火的直播场景。目前对直播场景的基本分类主要有媒体&活动直播、游戏直播、秀场直播和社交直播。

媒体&活动直播

特点：单向，无交互，流数少，延迟容忍度高 >10s；包含电视转流、演唱会直播等。

这类目前对于直播的技术要求较低，低上行，高下行。

游戏直播

特点：单向，无交互，流数多，延迟容忍度高 >5s；目前国内CDN产商抢得最激烈的一块。

本身的业务场景其实并不需要那么低的延迟。延迟是2秒、5秒还是10秒其实对体验的影响不是十分大。不过由于竞争激烈，拉高了延迟门槛。

秀场直播

特点：单向，文字交互，流数量多，延迟容忍度低 2~5s；这个是目前大家都能看得到盈利模式的一种。除了主播在播外，观众可以点赞，文字，送礼物，有一定的交互性。所以对直播的延迟要求苛刻，越低越好。推流主要是专业主播PC端，流数量多。

此类直播也称为美女秀场，市场上存在大大小小公司，基本带宽在1~5G。 秀场平台非常多。

社交直播

特点：单向，文字交互，流数量非常多，延迟容忍度低 2~5s；社交直播和秀场直播，在交互上类似，区别比较大有两点：1. 秀场一般都是有限的主播把内容运营起来，推流的数量较少，一般是<100路；2. 社交直播是路人即可产生内容，所以直播的流数会上升到1000，甚至10000。

目前最火的一块，有映客，在直播，花椒等。整体直播云的设计是以满足技术及并发要求最高的社交直播需求为主要目标。

直播服务架构解析

要完成这类直播产品，需要有哪些模块支撑？通常包括直播内容采集、直播后台系统和直播内容播放三个模块。

1. 内容采集：采集的方式有很多，从一般几十块PC摄像头到几十万的专业录制编码设备，还有移动端的手机前后置摄像头；分布式推流：这里是比较成熟的架构，用户在推流之前会通过名字服务，一般是DNS智能解析或是自有按IP调度系统获取最靠谱的推流节点，然后把流上传到服务器。

2. 直播后台系统：在分布式推流节点“接入”了用户流之后，后续一系列的分发、转码、截图、录制、存储等构成了直播后台系统；这里根据不同的业务需求，需要有不同的后台服务来支撑。

3. 直播内容播放：这个就比较好理解了，一般输出是PC屏幕、手机、现在还有VR头盔。

直播云的云化，主要是解决了视频流 上传、处理和分发 的一系列问题。用户只需要实现采集和播放即可。

直播云架构

直播云最核心、难度最大的部分是直播的流分发网络的架构和分发算法设计，直接决定了整套服务可支撑的并发数和质量以及服务成本。

以下重点分析UCloud核心分发网络这块的设计和演进。直播云架构主要有核心的流分发网络、运营子系统和业务逻辑子系统三大部分构成。

运营子系统包括了调度系统、监控系统和故障处理系统。

1. 调度系统：实现直播索引及调度的能力，主要解决三个问题：用户去哪个IP推流？流如何分发？用户去哪个IP观看？

2. 监控系统：实时监控整套分发体系的上行压力、下行压力、中间网络质量及服务状态等。

3. 故障处理系统：负责IP、机房、片区网络不可用时的处理。

业务子系统包含了非常多的系统，这里列举几个常见的。

1. 实时转码：是一个集群，作用是在用户推流码率较高（比如720P）、但是会有移动端观看的用户时，需要实时转成360P低清晰度的流；这个子系统实际服务能力非常有限，一台8核设备只能实时转10+路流，如果来1000路，就需要100台。这里给一个重要经验：如果做不到按流的按需实时转码，建议不要搭建实时转码集群。因为成本极高！

2. 实时截图：架构和实时转码类似，一般单机可处理100+流。

3. 实时录制：即将直播内容实时保存下来存储成点播文件。

推荐下我司知乎【机构号】https://www.zhihu.com/org/ucloud-yun-ji-suan

本答案出处：直播云平台架构如何构建？【 附PPT】

发布于 2016-12-04 2 条评论 感谢

分享

收藏 • 没有帮助 • 举报

• 作者保留权利 收起

14 赞同反对，不会显示你的姓名

刘博 独立思考/结果主义/伪优等生/其实是个笨蛋

14 人赞同

技术实现难度还是挺多的，主要是客户端和服务器端。 服务器端这块，只要接入直播云服务就基本没难度，因为各个云服务商已经把直播传输和分发的工作做了。他们会帮你解决大部分的技术问题，不流畅、卡顿、花屏、带宽不够、攻击、用户体验不好等一系列问题，… 显示全部

技术实现难度还是挺多的，主要是客户端和服务器端。

服务器端这块，只要接入直播云服务就基本没难度，因为各个云服务商已经把直播传输和分发的工作做了。他们会帮你解决大部分的技术问题，不流畅、卡顿、花屏、带宽不够、攻击、用户体验不好等一系列问题，还给你提供免费技术支持。客户端这块，难度主要是服务模块的开发，礼物系统，聊天系统，支付系统，运营系统，任务系统，安全系统，统计系统，每个模块的开发难度不亚于一款手游。

技术人才这块的话，需要对协议，编解码，音视频处理，网络传输，都要有比较深的理解。
带宽成本，具体可以根据云服务商的收费结合自身网站的用户量来计算。

最后我推荐又拍直播云（https://www.upyun.com/live.html），性价比高，服务好，容易接入。