作者：姚冬
链接：https://www.zhihu.com/question/42162310/answer/93858266
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
视频直播，可以分为 采集，前处理，编码，传输，解码，渲染 这几个环节，下面分别说下：
采集，iOS是比较简单的，Android则要做些机型适配工作，PC最麻烦各种奇葩摄像头驱动，出了问题特别不好处理，建议放弃PC只支持手机主播，目前几个新进的直播平台都是这样的。
前处理，现在直播美颜已经是标配了，80%的主播没有美颜根本没法看。美颜算法需要用到GPU编程，需要懂图像处理算法的人，没有好的开源实现，要自己参考论文去研究。难点不在于美颜效果，而在于GPU占用和美颜效果之间找平衡。GPU虽然性能好，但是也是有功耗的，GPU占用太高会导致手机发烫，而手机发烫会导致摄像头采集掉帧，可能原因是过热会导致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解决的。总之带宽非常贵。
作者：金山18667号码农
链接：https://www.zhihu.com/question/42162310/answer/105746193
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
1 、首先内容产生方就是推流端，现在主流的 IOS、安卓，IOS比较简单，就是那个几个机型，基本大家适配都很好。但是安卓的碎片化是非常严重的，大量的精力都需要做对安卓的适配，而且软编耗电量普遍非常高，手机用了一会就会发烫，都担心会不会爆炸。用户体验就是在不同的网络情况下，上传的视频有可能会卡，有可能不连贯，报各种各样的错误，这个是作为一个开发者他自己不可能去适配的。说白了从用户那边提的需求就是推流端不能卡，画质要好，不能太烫，这是我们接触到的客户真正提的问题，是我们从有点偏技术的角度抽取出来的，它背后对应的是哪些事情。
2 、然后是分发网络。分发网络其实躲在一个很后面的地方，用户其实看不见的。真正对分发网络提需求用户也提不出来，所以基本这部分需求都会提给播放端，提的需求也是不能卡，不能花屏，首屏一定要快，一点就要看到，还不能把延时弄的太大。其实这些很多都是和源站分发网络有关系的，只是用户看不到这个需求会跟后面的播放器接在一起。
像首屏时间，就是用户点开就要看，以前那些开源架构就是 rtmp server，它是做不到一点开就能看的，现在一些开源的国内资源写得也比较好了，可以看到。我们是自己开发的，所以也花了一些工作，能保存之前的关键帧的信息，用户一点开就能看，这个就是很细节的东西了。如果这个做不好的话，会黑屏、绿屏，或者是半天看不着图像。
3、在播放器这边也是我们在接业务的时候，遇到用户投诉最多的，因为所有的问题都是在观看的时候体现的，所有的雷都得是播放器的同学去扛。这个需求也是不能卡，不能延迟太高。如果延迟高了，要追回来，追的时候声音不能变，最好是追的策略也能自己控制，这是用户真正提出来的需求。
要满足这些需求，我们需要做好多分辨率的适配，保证好流畅性，保证好我们追赶的策略不会出现任何异常。所以这三个端很多是相互耦合的，像推流和分发在一起，要保障好用户的流畅性和画质，分发和播放器在一起要保证好低延时和播放的流畅。所有的这些需求里共同的一点就是不能卡顿。
<img src="https://pic3.zhimg.com/305d29e8d0c2d3317d34286f2c75dcba_b.jpg" data-rawwidth="803" data-rawheight="322" class="origin_image zh-lightbox-thumb" width="803" data-original="https://pic3.zhimg.com/305d29e8d0c2d3317d34286f2c75dcba_r.jpg">
这个是我们的系统架构图。最下层是依托金山的云服务，因为我们已经有了很好的平台，提供了我们计算资源，提供了存储，提供了很多自建的节点，当然还不够多，我们还是个融合 CDN，然后提供了数据分析的能力。我们依托它做了橙色的这一层，就是我们自己的核心，流媒体直播，然后围绕这个核心我们在做的回看点播、在线转码、鉴权、内容审核。
1.回看点播：因为这不是一个短视频录播的项目，而是一个直播，直播就决定它的并发不会很高，内容不会很多，热点比较少。如果你不回看的话，用户很难维持它的日活，很难维护用户黏度，所以用户一定会要求做回看的。
2.在线转码：推流端其实做了很多把更好的画质想尽办法传上来的工作，投了很多人力来做。传上来之后，观看也在移动端，它不一定看得了。如果他看不了怎么办？我们就需要在线转，在线转码其实承担的更多更重要的事情。
3.鉴权：用户都不想被盗链，尤其是推流的时候，如果我不鉴权，谁都可以来推。所以这是必须要有的
4.内容审核：现在我们没有办法帮他做到自动审核，技术还不够。现在做到的是截图，按用户指定的时间定期截图，这样的话，用户就可以请一些外包来看是不是有敏感内容，是不是要下线，这个对于现在这种三四秒延迟的直播来说非常重要。你做不到的话，没准政策因素你就做不下去了。
5.数据分析：一部分是依托金山已有的，一部分是我们自己做的，因为我们延迟性，时效性要求更高。客户会经常大半夜突然提出一个主播看起来特别卡，问你为什么，要是像以前那种方式，一个小时生成报表，然后出体验图，告诉他为什么卡了，客户可没有这个耐心。我们现在基本能做到5秒间隔就出之前的各种问题定位，这个定位包括从源站收集的数据画的曲线。还有从端上，如果端上用户允许的话，推流和拉流端我们都会有上报数据，几个曲线一拟合，我们就知道问题出在哪里。
采集是播放环节中的第一环，iOS 系统因为软硬件种类不多，硬件适配性较好，所以比较简单。Android 则不同，市面上硬件机型非常多，难以做到一个库适配所有硬件。PC 端的采集也跟各种摄像头驱动有关，推荐使用目前市面上最好用的 PC 端开源免费软件 OBS: https://obsproject.com/
前期准备：
「80% 的主播没有美颜根本没法看。」不光是美颜，很多其它的视频处理如模糊效果、水印等也都是在这个环节做。目前 iOS 端比较知名的是 GPUImage 这个库，提供了丰富端预处理效果，还可以基于这个库自己写算法实现更丰富端效果：
https://github.com/BradLarson/GPUImage
Android 也有 GPUImage 这个库的移植：https://github.com/CyberAgent/android-gpuimage
同时，Google 官方开源了一个伟大的库，覆盖了 Android 上面很多多媒体和图形图像相关的处理：
https://github.com/google/grafika
编码主要难点有两个：1. 处理硬件兼容性问题。2. 在高 fps、低 bitrate 和音质画质之间找到平衡。
iOS 端硬件兼容性较好，可以直接采用硬编。而 Android 的硬编的支持则难得多，需要支持各种硬件机型，推荐使用软编。
推流端和分发端理论上需要支持的并发用户数应该都是亿级的，不过毕竟产生内容的推流端在少数，和消费内容端播放端不是一个量级，但是他们对推流稳定性和速度的要求比播放端高很多，这涉及到所有播放端能否看到直播，以及直播端质量如何。
很多人吐槽现在的 CDN 不靠谱，我也承认传统的 CDN 在新时代显得心有余力不足。你能够借助 CDN 快速实现大规模的流分发，但是稳定高速的推流上传可能还需要自己做很多工作。这也是为什么我们七牛在这方面做这么多工作的原因之一。
如果要自己动手做，服务端方面最好的参考资料可能是这个了：https://github.com/ossrs/srs/wiki/v3_CN_Home
国民首席、熊猫 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地址： https://github.com/yangwm/ppt/blob/master/GolangPerformancePractice.pdf
为了让主播推上来的流适配各个平台端各种不同协议，需要在服务端做一些流处理工作，比如转码成不同格式支持不同协议如 RTMP、HLS 和 FLV，一路转多路流适配各种不同的网络状况和不同分辨率的终端设备。
解码和渲染，也即音视频的播放，目前 iOS 端的播放兼容性较好，在延迟可接受的情况下使用 HLS 协议是最好的选择。Android 的硬件解码和编码一样也存在兼容性问题，目前比较好的开源播放器是基于 ffplay 的 ijkplayer：
bilibili播放器： https://github.com/Bilibili/ijkplayer
目前客户端采集、编码解码以及推流拉流加速方面做了很多工作，以上干货也是基于这个过程中踩过的坑整理出来的：
https://github.com/pili-engineering
既然是创业，肯定要考虑到前期投入和未来的商业化，这方面我建议先看看熊猫 TV 庄明浩的长文分析：
https://zhuanlan.zhihu.com/p/20717041
---------------------------------------------------------------------------------------------
因为iOS是软硬件种类不多，官方也提供了稳定可靠的接口，比较简单。
Android因为机型种类繁多，需要适配机型，会是很大一部分工作。
当前直播的美颜功能已不可或缺，除了秀场需求以外，在UGC内容生产方式下，大量的内容对美颜都有较高的要求。
美颜简单的可以通过美颜镜头，但局限性大，限于PC端的主播，更好的办法是通过软件实现，需要图像处理方面的人员，美颜算法需要需要用到GPU编程，要自己参考论文去研究。
难点在于美颜效果是否自然，GPU占用与效果的平衡。GPU用于高性能计算，但功耗也相对高，需要考虑到手机温度对数据采集的影响。温度过高，摄像头容易掉帧。图像处理不仅仅是美颜，在交互中可能会涉及到滤镜，人脸识别，人物风格化等，使得客户拥有更好的互动体验。
目前iOS上比较好的图像处理库是GPUImage，提供了丰富的预处理效果，也可利用该库自定义设计。
Android上也提供了功能强大的图像处理库grafika。
在编码方面，有两种编码方式，硬编码（硬件）与软编码（软件）
目前大部分硬件都支持硬编码，但在Android上存在兼容性问题，源于不同厂商的芯片差异巨大，难以构建统一的库来兼容全平台。
编码的工作主要是对视频，音频的原始数据进行编码处理，得到可用的视频，音频数据。
编码通过压缩音视频数据来减少数据体积，方便音视频数据的推流，拉流和存储。大大提高存储传输效率。
H.265是当前性能最高的编码技术，在相同视频质量下，相比于H.264，H.265仅需一半的带宽，使得低于1.5Mbps的网络能够传输1080p的高清视频。
在编码方面的核心是平衡分辨率、码率、帧率、GOP（Group of Pictures）使得体积与画质达到最优，参数组合为技术核心，也是个家的商业机密。
传输涉及系统的多个部分，连接主播端，服务端，客服端等多个部分。
传输效率高与否决定直播系统的性能好不好，传输是直播系统非常重要的技术核心。
从推流端到服务端。数据经过推流端采集和预处理，编码之后推流到服务端，流传输就涉及到相应的传输协议，最常用的协议是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提供商。
在实际中，大多数直播平台会接入多个视频云服务提供商，做拉流线路互备，视频集群也是可优化部分来提高直播流畅性与稳定性。
拉流获取音视频数据后，需要通过解码器解码，渲染才能在播放器上播放。
H.264和H.265是有所压缩的，在解码恢复之后是缺损的原数据。
之前提到的体积最小画质最优的编码参数，就是在这里恢复画质的，该参数组合是非常重要的技术。现在的播放器普遍都需要高清支持，解码也应选择硬解码。iOS能够较好的支持，但Android还需要很多工作去弥补Android在平台差异的缺陷。
而在播放端，保证音画同步的同时，保证稳定流畅的直播流量，需要服务端与播放端做调度优化。
服务模块涉及用户体验，从用户方的收益一部分也来自于服务模块。
系统需要完整的礼物，支付，运营，任务等系统，复杂度不亚于页游系统。
国内直播平台的营利模式决定：平台从打赏中抽成。礼物系统就成为平台的盈利方式。礼物系统是多数视频直播平台的标配。
在中国部分人有礼品消费的习惯。平台为用户主播设计多个等级、爵位等头衔。利用财富榜，家族榜，等级榜类拉动消费。
IM技术。IM即时通讯服务。包括聊天室、弹幕等。弹幕交互方式是很好的体验，偏年轻化，大量用户愿意通过弹幕互动。高峰时，弹幕消息量特别大，一是需要考虑到高峰时弹幕的实时性和高并发量，二是要在产品策略上作一些体验上的优化。
系统还需要在政策上作相应的考虑，例如国家规定所有直播必须打水印并存留15天以上。在内容审核方面，淫秽、暴力、犯罪、敏感问题的审核。在数据分析方面也需要相应的统计系统。
管理模块包括客户端的设计与维护、后台数据库、后台控制系统。
该部分根据直播平台的特性、定位设计相应的管理策略。具体技术上还包括缓存、分布式文件存储、消息队列，运维系统等等。
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的都有，直播服务的大趋势就是这样。
接下来一个重要的环节就是前处理，其实最主要的部分就是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-互联网
http://www.donews.com/net/201607/2932777.shtm
作者：青岚
链接：https://www.zhihu.com/question/42162310/answer/122869096
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
目测题主的朋友是创业公司，在预算方面还是比较紧的，就不要考虑传统CDN从后两种之间选择好了。建议是去这几家公司的官网对比一下价格。我这里截了几张图，从上到下分别是七牛云，Upyun和星域。
&lt;img src="https://pic3.zhimg.com/3af23c2e2d98136dc95f90dee19fce9a_b.png" data-rawwidth="425" data-rawheight="143" class="origin_image zh-lightbox-thumb" width="425" data-original="https://pic3.zhimg.com/3af23c2e2d98136dc95f90dee19fce9a_r.jpg"&gt;
七牛云
&lt;img src="https://pic4.zhimg.com/91496f4cc60d13564597f261b57b355b_b.png" data-rawwidth="557" data-rawheight="132" class="origin_image zh-lightbox-thumb" width="557" data-original="https://pic4.zhimg.com/91496f4cc60d13564597f261b57b355b_r.jpg"&gt;
Upyun
&lt;img src="https://pic2.zhimg.com/d59c24f4e6505a5b02f3a171fe536649_b.png" data-rawwidth="558" data-rawheight="174" class="origin_image zh-lightbox-thumb" width="558" data-original="https://pic2.zhimg.com/d59c24f4e6505a5b02f3a171fe536649_r.jpg"&gt;
星域CDN直播
不同的CDN厂商，根据不同流量区间价格不一样，按流量计费和按带宽计费也是不一样的。
直播平台的带宽成本比较高，这时价格之间的差异对选择天平的倾斜影响还是相当大的。或者，也可以找一些免费送流量的公司体验一下，这样可以无需充值就能感受到服务的效果。比如说：七牛0-10GB就是完全免费的，星域注册也会送100G。另外，如果数据量够大的话，星域的单价比起其他家明显会低很多。
另外，可以通过观察CDN企业服务的直播平台来认识他们的实力。毕竟，大公司在采购时会有很严格的要求，基本上能通过的也都是经过九九八十一难，“剩者为王”。自己列了一张表，不一定全，仅供参考。
&lt;img data-rawheight="554" data-rawwidth="2082" src="https://pic3.zhimg.com/796f64a730685cd5afdd0a81b7f4a502_b.jpg" class="origin_image zh-lightbox-thumb" width="2082" data-original="https://pic3.zhimg.com/796f64a730685cd5afdd0a81b7f4a502_r.jpg"&gt;
从CDN说回直播本身，在拉流之后就是视频的解码、渲染等等，这一块对于硬件的要求比编码会低一些，技术上难度也会小一点。这里边也有一些细节，比如软硬码自动切换，连麦互动，H.265解码，动态追帧，播录一体化这些。每一个细节，都有可能带来用户体验上的差距。
当然，以上说的只是直播平台技术里视频的一部分，楼上
老师说的很好，音频、礼物、数据库甚至支付都是不得不考虑的事情。
至于技术准备和资金门槛，只能说：以一个创业公司的资金和资源从零做起的话，很多问题其实确实是不太容易解决的。一个好的直播平台，光是技术的解决方案上百万就是杯水车薪，而且要找到靠谱的人才能画好这笔钱。尤其是赶上这轮资本寒冬，直播平台里边老大老二基本分出来了，如果现在想融到两千万然后拿出上千万搞技术——未必可行。
好在国内市场足够大，允许各种各样的竞争者同时出现，所以最近有一些做云计算和CDN的厂商，干脆把直播的技术解决方案整合成了SDK，卖给创业公司。
&lt;img src="https://pic4.zhimg.com/a005993bad653d9d3c243287959ddf8f_b.png" data-rawwidth="558" data-rawheight="418" class="origin_image zh-lightbox-thumb" width="558" data-original="https://pic4.zhimg.com/a005993bad653d9d3c243287959ddf8f_r.jpg"&gt;
这类SDK能做的事情，还是比较多的，网上找来了张图，题主和大家也可以参考一下。而且，这一类解决方案因为相对标准化，所以成本相当低，价格也不高。当然，做这种事情的门槛不低，基本上都是比较大的CDN厂商在做。
比如文章上边提到的星域，就是直接把视频推拉流、采集、转码之类的技术打包在了一起，同时优化各个环节。毕竟，CDN行业的竞争很激烈，价格也是逐年下跌，所以服务商们为了找自己的差异化竞争点，还是很卖力气的。
总结起来，一是直播平台在技术方面的要求很高，尤其是CDN一块专业性很强，想完全用自己的技术解决不现实；二是，要么舍得砸钱招BAT技术团队，要么就用标准化的技术解决方案——毕竟直播平台技术只不过决定着及格线，真正的核心竞争力在于产品和运营。如果真的有那么多钱，还不如把技术上省下来的钱花在网红的签约和入驻上，对吧！
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
