Closed winlinvip closed 3 years ago
Can srs3 be used in production now?
TRANS_BY_GPT3
@smellycat
Can SRS3 be used in a production environment now?
SRS3 is currently in alpha-4, and it will be available for production use once it reaches beta stage.
TRANS_BY_GPT3
The milestone plan has almost covered everything, and there are no new expected abilities to propose. If used for production, stability should be the most important indicator. I hope stability can be further improved. Additionally, I would like to give you a thumbs up for your efforts. This project is a great work. 👍
TRANS_BY_GPT3
Don't you plan to support RTSP? For example: input RTSP and output RTMP/RTSP.
TRANS_BY_GPT3
The milestone plan is already comprehensive, and everything I wanted to say is included in it. However, if there is energy available, I suggest introducing support for protocols like WebRTC. After all, supporting a new protocol means meeting the demands of more platforms and commercial servers, and the usage range of SRS will also be broader. But this should indeed be discussed after stability, CI/CD, and data monitoring. Finally, I am extremely grateful to the author for developing and consistently maintaining such a fantastic project! Thumbs up! Keep up the good work, author!
TRANS_BY_GPT3
Don't you plan to support RTSP? For example, input RTSP and output RTMP/RTSP.
This is supported. Capture through RTSP, then use FFmpeg transcoding command to output RTMP. You can refer to the following configuration file: https://github.com/ossrs/srs/blob/3.0release/trunk/conf/ingest.rtsp.conf
TRANS_BY_GPT3
Webrtc is essential for streaming via browser. Rtmp without flash doesn't work well via browser (ex. I can't publish streaming). I believe webrtc is essential to create a server that can work in all scenarios.
Webrtc is essential for streaming via browser. Rtmp without flash doesn't work well via browser (ex. I can't publish streaming). I believe webrtc is essential to create a server that can work in all scenarios.
@ciaoamigoschat Agreed. I think RTC is one of the next extreme important things for live streaming. And I am sure SRS will support WebRTC in future, mabye in SRS4 or SRS5, it depends on how many time I have for working on this project, it also depends on whether it's stable enough to enable us to add more big/huge features like this.
This is the right time to implement webrtc. Many sites are abandoning flash and looking for a viable alternative. Giving this functionality is a great move to rapidly spread the product and to find valid supporters.
I wish we could support the conversion of WebRTC streams, so that we can play them directly on mobile devices. It would be more real-time compared to HLS.
TRANS_BY_GPT3
It would be great if we could support streaming via WebRTC, so we can play directly on mobile devices. It is more real-time compared to HLS.
WebRTC is mainly used natively on mobile devices, and it may not be readily available for use on mobile web pages. It is primarily stable on PCs, but it can also be integrated into native mobile applications.
TRANS_BY_GPT3
QUIC should be supported
TRANS_BY_GPT3
QUIC should be able to support it Dear, thank you for your attention. Could you please provide more details on why it needs support, what the use case is, and why it needs to be supported now instead of at a slower pace?
TRANS_BY_GPT3
You are losing sight of the problem. With mobile (Native application) streaming (Publish, Play) can be done in rtmp. With the browser for streaming (Publish, Play) the only solution is Webrtc.
As a complete novice in the field of live streaming, video processing, and streaming media, my expectations for SRS are "plug-and-play" and "enterprise-level application stability".
I used SRS2 before and encountered many problems during compilation. It was only when I used an "unofficial" Docker image that I was able to partially solve the "plug-and-play" issue. Of course, now that SRS has provided an official Docker image, I immediately switched to the official one.
As for stability, as it was my first attempt to use a streaming media solution for real-time access, I encountered many issues during the process. However, as long as the infrastructure (such as the network) is sufficiently reliable, I have not observed any "unstable" situations, which exceeded my expectations. I am very grateful to SRS for this.
Lastly, regarding the application scenario, the cameras are distributed in independent network environments in 20 cities. They are connected to the public cloud network through a VPN and ffmpeg is used to pull the camera's RTSP stream according to policies, and then push it to the SRS server in the public cloud for distribution.
TRANS_BY_GPT3
As a complete layman in the fields of live streaming, video processing, and streaming media, my expectations for SRS are "plug and play" and "enterprise-level stability".
Previously, I used SRS2 and encountered many problems during compilation. It wasn't until I used an "unofficial" Docker image that I was able to partially solve the "plug and play" issue. Of course, now SRS has provided an official Docker image, and I immediately switched to the official image.
As for stability, this is my first attempt to use a streaming media solution for "real-time access" scenarios. I encountered many problems during this process, but as long as the infrastructure (such as the network) is guaranteed, I haven't observed any "instability" situations, which has exceeded my expectations. I am very grateful to SRS.
Finally, let me talk about the application scenario. Cameras distributed in 20 different cities are connected to the public cloud through VPN, and ffmpeg is used to pull the RTSP streams from the cameras and push them to the public cloud's SRS server for distribution, based on certain policies."
Thank you for your recognition of SRS and sharing the application scenario, which is important for everyone. Docker is actually a mature open-source solution. It was through continuous learning that I realized the difference between Docker and installation packages, and I will continue to improve myself to ultimately improve the quality of the SRS open-source project.
Open-source is a closed loop of sharing and improvement. Everyone's feedback, whether it's a problem or a thumbs up, a solution or a pull request, an idea or a suggestion, can influence the entire community. The whole open-source community is like a big melting pot, and each of our participation will make this flame burn even brighter. Welcome everyone to join in, learn from each other, and progress together~
TRANS_BY_GPT3
ST may be replaced with https://github.com/tencent/libco, which is with Apache License. Easy of Use should be the first goal, which means an installer, a web UI and streaming pulling features.
@charlestamz I heard wechat libco before and I will do some research. We do need a new coroutine library to resolve the license issue, it doesn't mater whether it's wrote by ourself or others like libco.
I roughly looked at libco, and I cannot express complex ideas in English yet, so I will continue in Chinese:
I will look into the details when I have time. I will try using this library, examine the source code, and debug it. I am relatively familiar with the previous implementation by ST and have done complete debugging on it.
TRANS_BY_GPT3
I compared bsnes/libco and tencent/libco and found that the code differences are quite significant. If it is Apache License, it should be usable.
TRANS_BY_GPT3
https://github.com/AirenSoft/OvenMediaEngine
OvenMediaEngine (OME) is an Open Source, Ultra-Low Latency Streaming Server. OME receives video via RTMP from live encoders such as OBS, XSplit and transmits it on WebRTC. So, Ultra-Low Latency Streaming from OME can work seamlessly in your browser without plug-ins. Also, OME provides OvenPlayer, the HTML5 standard web player.
Our goal is to make it easier for you to build a stable broadcasting/streaming service with Ultra-Low Latency.
https://github.com/runner365/nginx-rtp-module The transmission part is basically written, the bandwidth estimation using the remb protocol is still being worked on.
TRANS_BY_GPT3
QUIC should be able to support it.
Dear, thank you for your concern. Can you please provide a detailed explanation of why it should be supported, what the use case is, and why it should be supported now instead of later?"
"QUIC can be supported, it is very suitable for the current live streaming scenario.
TRANS_BY_GPT3
QUIC should be able to support it.
Dear, thank you for your attention. Can you please provide more details on why it should be supported, what the scenario is, and why it should be supported now instead of later.
Quic can be supported, it is very suitable for the current scenario of live streaming.
For live streaming, you can learn about WebRTC, which supports H5 live streaming. Additionally, the protocol standard will soon be supported (or already supported) by various CDN providers.
TRANS_BY_GPT3
For the solution you mentioned about resolving the issue with ST, why not completely switch to using the Go language for development, as it seems SRS also has a Go version?
TRANS_BY_GPT3
Regarding the issue of solving ST, why not switch completely to using Go language for development, since it seems that SRS also has a Go version?
Language is not a sufficient condition for rewriting a product, just like open-source media servers are not sufficient for providing good media services. This is why many people ask which open-source media server Alibaba Cloud uses, which media server Tencent Cloud uses, and which media server ChinaNet uses - media services are not equivalent to media servers, let alone open-source media servers.
Explaining why we don't use Go language may be difficult, but explaining the difference between "media services" and "media servers" may be somewhat easier. For example, everyone knows that cloud computing uses Linux, even the famous AWS uses Linux. So why not use a new OS? I want to say that this question itself is a non-existent question. Why do people think that the Linux used by cloud computing vendors is the same as the Linux we know? Even if everyone is based on Linux to provide services, it does not mean that cloud computing only has one Linux. Moreover, each vendor has a Linux kernel team and will have customized Linux. So, can we consider the Linux used by cloud vendors as the Linux we know? Definitely not the same.
Aside from Linux, what else do cloud vendors have? Thousands of people in the team, and there are definitely not many who work on the kernel. So, by analogy, if someone provides media services, is it still the same SRS that we know? Is it still the same Nginx that we know even if they use it? How many people are actually working on media servers? Most of them are not directly involved in server development.
Why not use Go language? Media servers are not just a language issue, just like cloud computing is not just about the Linux kernel.
TRANS_BY_GPT3
For the issue you mentioned about solving the problem of ST, why not completely switch to using Go language for development, as there seems to be a Go version of srs as well.
Of course, I can also answer this question directly, and I have some mature thoughts on it, hahaha.
In short, there is no pain point that C/C++ cannot solve, and Go does not have an absolute advantage over SRS:
Of course, I'm not saying that Go cannot be used for streaming media servers. It can definitely be used, and in fact, I also recommend and prefer using Go in practice. I'm just saying that it is not necessary for SRS to use Go. I recommend Go because:
What is the optimal solution? It is not doing anything, for example, there was a lot of talk about H.265, but now it seems that more people are talking about AV1. I will wait for them to talk about it for a few more years before doing anything. Can you achieve this in the real world of product development? If not, then use Go, and use CPU to exchange for stability.
TRANS_BY_GPT3
If it supports WebRTC streaming, it would be great, then we can directly play it on mobile devices, which is more real-time than HLS.
WebRTC live streaming has already been put on the agenda and the discussion of solutions is currently ongoing. It will be implemented soon, so please wait patiently. 😄
TRANS_BY_GPT3
SRT has already been supported, thanks to the code provided by runner365, a talented coder. He will continue to maintain it. Please refer to #1147.
TRANS_BY_GPT3
Don't you plan to support RTSP, for example: input RTSP, output RTMP/RTSP?
Recently, I have been learning about the surveillance industry, and the more commonly used protocol than RTSP is GB28181. Of course, SRS can also handle it completely, especially now that the surveillance industry is becoming more internet-oriented. GB28181 is currently being discussed, but the specific time has not been determined yet. Please refer to #1500.
TRANS_BY_GPT3
我们目前实时监控就是用到这个 RTSP,摄像头厂家的方案,延迟有点大,但也基本满足要求,我们是在办公室监控实验室(本地和远程都有)的化学反应。因为要配合控制操作,想要更加实时的方式,移动端也十分需要,看了你们上面的讨论,WebRTC 似乎是目前最佳的应用。
srs3现在可以生产环境使用吗
SRS3 b0已经发布了,可以在生产环境中灰度了。
大致看了下libco,还不能用英文表达比较复杂的想法,就还是用中文吧:
- 应该是从bsnes/libco ISC项目fork出来的,LICENSE是Apache,看起来这两个协议可以互相转换,我发了一个Issue问这个问题待确认,Tencent/libco#134
- 它的逻辑是提供coroutine库,而不是网络IO的库,还需要在这个基础上再封装一层网络调用。比如example_poll,调用co_create创建一定数量的coroutine,然后co_eventloop启动epoll事件循环,在这个循环中进行事件调度。
- 有人说没有mock掉accept,我看是有做的(后续我会花时间确认这个),co_hook_sys_call.cpp用的dlsym还是啥办法,没仔细看,看起来像是个hook。
- 没有ARM实现,它并不是使用setjmp和longjmp,而是直接co_swap(a,b)交换两个协程上下文,也是差不多的实现。
其他的等我有空了详细看,我会用下这个库,看下源码和调试下。之前ST的实现相对比较了解一些,有完整调试过。
关于SRS是否需要以及怎么替换成libco, 我的提交在这里 https://github.com/xiaozhihong/srs/commit/7c8a35aea9b6108bffdc39390cdb00db525be2ac
通过对libco和state-thread的对比和替换state-thread的过程, 我觉得SRS短期内没必要替换成libco, 有以下几个原因
不打算支持一下RTSP吗,譬如:输入rtsp,输出rtmp/rtsp
最近了解了下,对于监控行业,比RTSP更常用的是GB28181,当然SRS完全也是可以搞定的,特别现在监控行业也在互联网化。GB28181目前已经在讨论了,但具体时间还没有定,请看 #1500
是的,监控行业基本都离不开GB28181,我们现在用SRS也都是接入的28181摄像头,再处理流推送到SRS
要是支持转webrtc流就好了,这样就可以直接在移动端播放了,比hls又要实时
WebRTC直播已经提上议程了,正在讨论方案,会很快实现出来的,待卿长发及腰时
期待,更期待28181的支持 哈哈
首先感谢作者和各位贡献者辛勤工作。。。 想请教下,mms流媒体,能通过srs直接转换成http么? 谢谢。。 在github搜了下,没相关issue。
首先感谢作者和各位贡献者辛勤工作。。。 想请教下,mms流媒体,能通过srs直接转换成http么? 谢谢。。 在github搜了下,没相关issue。
SRS聚焦在互联网流媒体,也就是浏览器可以支持的标准格式,可以考虑用FFMPEG做协议和编码的转换。
QUIC 应该可以支持下
亲呐,感谢你的关注,麻烦你要详细说明下为什么要支持,场景是什么,为什么要现在支持而不是再缓缓。
主要是在网络环境较差的情况下(如3/4G等弱网络环境下)可以提高推流质量
QUIC 应该可以支持下
亲呐,感谢你的关注,麻烦你要详细说明下为什么要支持,场景是什么,为什么要现在支持而不是再缓缓。
主要是在网络环境较差的情况下(如3/4G等弱网络环境下)可以提高推流质量
可以考虑用SRT或WebRTC推流,SRT已经支持,WebRTC在路上了。
I would live to contribute and help building the WevRTC support.
@itzikgili Thanks, SRS4 has supported publishing by RTMP and playing by WebRTC, please read #307 , welcome to join us to make it better. 😄
希望可以考虑下H265转码后在网页的播放
@itzikgili Thanks, SRS4 has supported publishing by RTMP and playing by WebRTC, please read #307 , welcome to join us to make it better.
Sure thing, I would love to!
Damn i will give a look at WebRTC too !
QUIC 应该可以支持下
亲呐,感谢你的关注,麻烦你要详细说明下为什么要支持,场景是什么,为什么要现在支持而不是再缓缓。
因为对直播来说,延迟至关重要。RTMP是基于TCP的,哪怕用商业CDN,延迟也在2~3s。这个延迟还是很大,对于一些连麦直播或在线游戏直播来说,还是大。所以,希望能够在SRS5支持QUIC。
@freeman1974 延迟问题,SRS已经支持了RTMP推流WebRTC播放,以及WebRTC推流和播放。
JT1078要是也能支持,那么srs在交通行业就完美了
要是支持转webrtc流就好了,这样就可以直接在移动端播放了,比hls又要实时
WebRTC在移动端以native为主,移动端网页可能基本没法用的。主要以PC比较稳定,移动端native当然也可以接入的。
* [red5/ant](https://github.com/ant-media/Ant-Media-Server) 说是支持了WebRTC转RTMP,看了下代码和wiki,貌似只有企业版才有,开源版本没有。
SRS 4.0会考虑支持webrtc推流转RTMP或者hls之类的播放不
@freeman1974 延迟问题,SRS已经支持了RTMP推流WebRTC播放,以及WebRTC推流和播放。
@winlinvip SRS 4.0会考虑支持webrtc推流转RTMP或者hls之类的播放不
SRS 4.0 会支持webrtc视频会议么?
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