Development direction: SRS4 is on the way...

[winlinvip]

About the Development Direction of SRS

SRS3 is currently being enhanced for stability and is being released intensively. This means that SRS3 will not support major changes but will only focus on improving stability, indicating that SRS4 is coming.

SRS4's codename is Leo. Thanks to all the brothers and sisters who have been fighting together for over a decade. You can find the story about the codename Leo here.

This issue is to discuss what SRS4 should support. I understand that there is a strong demand for new protocols such as WebRTC, SRT, QUIC, and KCP. However, I have already decided that supporting new protocols will not be the focus. SRS4 will probably support some new protocols, but the main focus will be on usability and ease of use, in simple terms, it will be more stable and user-friendly.

Is SRS unstable? For an open-source project, it may meet the requirements. There are very few open-source projects with a core protocol coverage rate of over 95% and an overall coverage rate of around 50% (of course, stability has many more aspects that are not discussed here). However, the requirements for SRS are to directly provide services on industrial servers, requiring even higher stability. There are many areas that need careful handling, especially in cases of inconsistency, such as player timeouts, source cleaning, race conditions, and cooperation among multiple coroutines. Stability is a fundamental capability that cannot be compromised. The more investment, the more stability.

Is SRS difficult to use? Based on feedback and continuous observations, it should not be considered difficult to use. However, the requirements for SRS are to directly provide services on commercial servers, so usability needs to be further improved. This mainly involves Dockerization, integration with cloud services, HTTP protocol enhancements such as monitoring the online audience of HLS, and providing operational data solutions through JSON-structured logs. Currently, the HTTP part of SRS mainly refers to the implementation of HTTP 1.1 in Go. In the future, consideration will be given to porting more underlying capabilities from NGINX. For example, it may be possible to directly run NGINX modules on SRS, which gives us something to look forward to. See reference #1657.

In addition, security and licensing have always been the focal points of SRS. In terms of security, it mainly involves anti-leeching measures, enhanced restrictions such as rate limiting and client limitations, encryption and decryption, and code vulnerability detection. As for licensing, the only issue currently is replacing ST with at least one optional version that does not have licensing limitations.

So, dear reader, what key capabilities do you expect SRS4 to support? Please reply to this issue 😄 😄

Make sure to maintain the markdown structure.

TRANS_BY_GPT3

[wanghuan578]

kcp应该支持下呢？

[cgoder]

你能做得到吗？做不到就用Go吧，用CPU换稳定性。

是不是go的版本已经处于放弃状态了？

在webrtc风口之上，go对网络的亲和性相对比ST更好。从团队维护产品及自动化运维的角度来说也是更优的（单从效率来说）。 最在在看pion/ion这俩项目，用go 实现的rtc比c++的更易让团队成员理解和掌握。

SRS现在的release版本已经是非常稳定且生产可用的了。

是不是有团队可以继续维护go的版本？

[likunde]

监控上云是现在监控行业想摆脱设备厂商的痛点，28181 解决痛点的关键技术

[likunde]

监控上云是现在监控行业想摆脱设备厂商的痛点，28181 解决痛点的关键技术。