v1_CN_Product

HOME > CN(1.0) > Product

SRS产品规划

关于SRS的来源，定位，愿景和计划。

• Release1.0, 2013~2014，开发代号：HuKaiqun（胡开群）。
• Release2.0, 2014~2017，开发代号：ZhouGuowen（周国文）。
• Release3.0, 2017至今，开发代号：OuXuli（欧旭理）。
• Release4.0, 开发代号（暂定）：Leo（付亮）。
• Release5.0, 开发代号（待定）。

BigThanks

SRS是2013.9我从蓝汛离职后，我参考nginx_rtmp写了个简洁直播源站服务器。蓝汛接我工作的同事也可以看到服务器如何一步步构建。蓝汛的客户也可以用这个源站，那些乱七八糟的源站对接太麻烦。我想用业余时间构建不受客户随意影响的产品，只遵循核心价值而加入功能，而不是为了赚钱或者客户头脑发热，总之，实现我对于产品价值和质量，真正实现客户核心要求，定位清晰，一个实践现代软件工程和研发理念的服务器。

2013.10底加入观止负责研发管理工作。后来观止创想做编码器，编码器需要输出到rtmp服务器，nginx-rtmp又经常出问题，就打算用我的SRS替换nginx-rtmp。后来编码器上线过程中，我也逐步完善了SRS，是快速成长期。开放服务器，就让客户可以更好的用我们编码器，而且我们编码器可以支持拉模式。这个阶段主要是源站阶段。

2014.3进入反馈期，树苺派，极路由，cubieboard等嵌入式设备上有人问是否能支持。我自己买了树苺派，在上面运行成功，改了st的一个bug。从这个时候开始，是功能爆发的时期，得到群里童鞋们的反馈。转码，转发，采集，录制都是这个时期的工作。

2014.5，SRS功能冻结，测试和解决问题。我们公司扩大产品线，准备做VDN，视频分发网络，自然srs成为最佳选择。公司各位老大也一致认为srs的定位比较合适，一致商议决定直播服务器使用srs。SRS的功能都已经完善，VDN其他业务系统譬如监控和计费开始研发，我只有周末时间做SRS了。

2014.10，SRS1.0beta发布，坐等大家反馈bug，如果没有bug就在2014年底发布SRS1.0release。观止创想也准备在1.0release的基础上上研发下一代商用流媒体服务器。从0到1.0，SRS花了1年时间，17个里程碑，7个开发版，223个修订版，43700行功能代码，15616行utest代码，1803次提交，161个bug和功能，解决了117个，可在1个平台运行(linux)，支持4种cpu(x86/x64/arm/mips)，11个核心功能(origin、 edge、 vhost、 transcode、 ingest、 dvr、 forward、 http-api、 http-callback、 reload、 tracable-log)，35个功能点，58篇wiki，SRS的QQ群有245位成员，活跃成员141人，2位主作者，12位贡献者，14位捐赠者，至少有蓝汛、VeryCloud、VeryCDN、清华电视台在使用或基于SRS改自己的服务器，数百个各种行业的公司在使用SRS主要包含视频监控、移动端、在线教育、秀场和KTV、互动视频、电视台、物联网、学生。

2014.10启动SRS2.0研发，预计6个月左右的研发周期，主要目标是完全了解和掌握st，简化服务器的客户端模型，以及其他小功能的完善。比较大的方向在3.0+支持。

2017.3.3, SRS2.0 r0正式发布，足足延期了24个月，主要是工作太忙了，没有大块的时间维护SRS。2017年初换工作了，中间有2个月时间撸起袖子加油干的时间，就把r0给刨出来了。一共挣扎了869天(+100%)，234次(+5%)更新，新增1550次(+80%)提交，平均每天1.78次(-60%)提交，新增了2.69万行(+45%)代码，解决了229个(+27%)ISSUE。参考微信文章.

2019.4, 开始SRS3.0的发布工作，改进代码，提升稳定性。

Vision

SRS定位是运营级的互联网直播服务器集群，追求更好的概念完整性和最简单实现的代码。

• 运营级：商业运营追求极高的稳定性，良好的系统对接，以及错误排查和处理机制。譬如日志文件格式，reload，系统HTTP接口，提供init.d脚本，转发，转码，边缘回多源站，都是根据CDN运营经验作为判断这些功能作为核心的依据。
• 互联网：互联网最大的特征是变化，唯一不变的就是不断变化的客户要求，唯一不变的是基础结构的概念完整性和简洁性。互联网还意味着参与性，听取用户的需求和变更，持续改进和维护。
• 直播服务器：直播和点播这两种截然不同的业务类型，导致架构和目标完全不一致，从运营的设备组，应对的挑战都完全不同。两种都支持只能说明没有重心，或者低估了代价。
• 集群：FMS(AMS)的集群还是很不错的，虽然在运营容错很差。SRS支持完善的直播集群，Vhost分为源站和边缘，容错支持多源站切换、测速、可追溯日志等。
• 概念完整性：虽然代码甚至结构都在变化，但是结构的概念完整性是一直追求的目标。从SRS服务器，P2P，ARM监控产业，MIPS路由器，服务器监控管理，ARM智能手机，SRS的规模不再是一个服务器而已。
• 简单实现：对于过于复杂的实现，宁可不加入这个功能，也不牺牲前面提到的要求。对于已经实现的功能的代码，总会在一个版本release前给予充分的时间来找出最简答案。不求最高性能，最优雅，最牛逼，但求最简单易懂。

备注：概念完整性可以参考Brooks的相关文献，在宏观方面他还是很有造诣。

Release1.0

开发代号：HuKaiqun（胡开群）。感谢我的初中老师胡开群和高昂老师，教育我热爱自己所做的事情。

SRS release 1.0，预计研发周期为1年左右。主要的目标是：

• 提供互联网直播的核心业务功能，即RTMP/HLS直播。能对接任意的编码器和播放器，集群支持对接任意的源站服务器。
• 提供丰富的外围流媒体功能，譬如Forward，Transcode，Ingest，DVR。方便开展多种源站业务。
• 完善的运维接口，reload，HTTP API，完善和保持更新的wiki。另外，提供配套的商业监控和排错系统。
• 完备的utest机制，还有gperf（gmc，gmp，gcp）和gprof性能以及优化机制。提供c++层次足够满意的性能和内存错误查找机制。
• 在ARM/MIPS等嵌入式CPU设备Linux上运行。另外，提供配套的内网监控和排错，cubieboard/raspberry-pi的嵌入式服务器。
• 高性能服务器，支持2.7k并发。

SRS Release 1.0已经在2014.12.5如期发布。

Release2.0

开发代号：ZhouGuowen（周国文）。感谢我的高中老师周国文老师，教我成人自立，为我翻开一个新的篇章。

SRS release 2.0，预计研发周期为1年左右。主要的目标是：

• 翻译中文wiki为英文。
• 提升性能，支持10k+播放和4.5k+推流。参考：#194，#237和#251
• srs-librtmp支持发送h.264和aac裸码流。参考：#66和#212
• 学习和简化st，只保留linux/arm部分代码。参考：#182
• srs-librtmp支持windows平台。参考：bug #213, 以及srs-librtmp
• 简化握手，使用模板方法代替union。参考：#235
• srs-librtmp支持劫持IO，应用于srs-bench.
• 支持实时模式，最低支持0.1秒延迟。参考：#257
• 支持允许和禁止客户端推流或播放。参考：#211
• DVR支持自定义文件路径和DVR http callback.
• 可商用的内置HTTP服务器，参考GO的http模块。参考：#277.
• RTMP流转封装为HTTP Live flv/aac/mp3/ts流分发。参考：#293.
• 增强的DVR，支持Append/callback，参考：#179.
• 增强的HTTP API，支持stream/vhost查询，参考：#316.
• 支持HSTRS(HTTP流触发RTMP回源)，支持HTTP-FLV等待，支持边缘回源，参考：#324.
• [experimental]支持HDS，参考：#328.
• [experimental]支持Push MPEG-TS over UDP to SRS, 参考：#250.
• [experimental]支持Push RTSP to SRS，参考：#133.
• [experimental]支持远程控制台，链接： console.
• 其他小功能的完善。

SRS Release 2.0于2017.3.3正式发布。

Release3.0

开发代号：OuXuli（欧旭理）。感谢我的大学老师欧旭理老师(欧工)，他创建的中勤在线让我可以在大学学习软件理论时还能实践出真知。感谢中勤的同学们，陈哲、刘小婧、盛谢华、易念华、马琰以及中勤的其他同学，希望SRS能带着我们最初的梦想越行越远~

SRS release 3.0，研发阶段。主要的目标是：

• 支持NGINX-RTMP的EXEC功能。参考：#367.
• 支持NGINX-RTMP的dvr control module功能。参考：#459.
• 支持安全的可读写的HTTP API（HTTP Security Raw Api）。参考：#470, #319, #459.
• 支持DVR 为MP4文件。参考: #738.
• 支持截图，HttpCallback和Transcoder两种方式。参考：#502.
• [experimental]支持MPEG-DASH，可能的未来标准。参考：#299.
• 重写错误和日志处理，使用复杂错误，简化日志。参考：#913.
• 重写错误处理的工作流，准确定义异常情况。参考：#1043.
• 学习英语，重写English WIKI。参考：#967.
• 支持源站集群，负载均衡和热备。参考：#464，RTMP 302.
• 增加UTest，覆盖核心关键逻辑代码。参考：#1042.

SRS Release 3.0预计在2019年年底发布。

Release4.0

开发代号：Leo（付亮）。感谢我流媒体生涯和管理的Leader，蓝汛前VP付亮(Leo)，在当年研发流媒体时给了坚定的支持，在刚开始带团队时亲自辅导和交流。感谢我十几年职业生涯中遇到的Leader，包括大唐的何力和朱晖，微软的赵斌和舒适，蓝汛的付亮、张玮、刘岐、苗权和文杰，快手的于冰，观止的杨默涵和雷健，LVS的包研，阿里的叔度、华大、文景和星海。感谢一起成长和码代码的兄弟们，限于篇幅就不一一列举了。

Backlog

SRS 4.0+ 的功能列表，可能的方向：

• HTTP方向：HTTP API认证，HTTP访问时回调，HTTP-MP4流
• 增强的RTMP方向：转发调用，RTMP推流认证，支持AMF3，SharedObject和文本分发，一个连接多个流，Forward支持额外参数，Edge支持额外参数，支持RTMFP协议
• 超低延迟方向：FRSC百毫秒延迟，集群内部使用UDP
• 预研SRS.GO，GO语言的实现版本。参考：SRS.GO项目，以及GO性能评测

SRS对于所有新功能都持推延态度；有悖于系统一致性和概念完整性的功能绝对不做，譬如支持Windows系统就有悖于一致性和完整性（服务器系统的差异太大）；对于确定要做的功能SRS也会仔细斟酌最佳方案，譬如支持多进程就是在选最佳方案；对于已有方案要做到最好，譬如最低延迟方案。对于功能点，只要属于系统一致性和概念完整性范围内都会考虑添加，或者说，大部分都不做，要做就要做到最好，The best or nothing!

Beijing, 2014.3
Winlin