SRS is a simple and efficient real-time video server that can be scaled into clusters and supports multiple protocols and scenarios
RTMP/WebRTC/HLS/HTTP-FLV/SRT/GB28181。 For novices, the threshold for audio and video is really very high, and the goal of SRS is to lower (but not eliminate) the threshold for audio and video.

Overview of features

The image below is a large overview map of SRS:

A simple and efficient real-time video server that supports multiple protocols such as RTMP插图1

Let’s take a look at the big picture above from a few typical application scenarios, please refer to more scenarios:
https://github.com/ossrs/srs/wiki/v4_CN_Sample

Live streaming on all platforms: Only the Encoders (FFmpeg/OBS) shown above need to push RTMP to SRS; An SRS Origin (no cluster required) can be transencapsulated into HTTP-FLV streams and HLS. Players can choose HTTP-FLV or HLS streaming depending on the platform player
WebRTC calling: one-to-one calls, multi-person calls, conference rooms, etc. WebRTC is the key and core capability introduced by SRS4, from 1 to 3 seconds of latency, to 100 to 300 milliseconds of latency, definitely not a change in numbers, but a change in essence
Monitoring and broadcasting to the cloud: In addition to using FFmpeg to actively pull streams to SRS, you can also push streams using the SRT protocol of the broadcast and television industry, or push streams using the GB28181 protocol of the monitoring industry, and convert SRS to the Internet protocol for viewing
Low latency and interaction for live streaming: RTMP to WebRTC playback reduces playback latency, and can also be used for live streaming or WebRTC streaming, and WebTransport live streaming will be supported in the future
Large-scale services: If your business grows rapidly, you can use Edge Cluster to support a large number of players, or Origin Cluster to support a large number of Encoders, and of course, you can directly migrate to the video cloud. In the future, it will also support RTC cascading and clustering

Scenario Deployment Reference:
https://github.com/ossrs/srs/wiki/v4_CN_K8s#srs-edge-cluster-for-high-concurrency-streaming

Each scenario may use some common capabilities, such as:

Generally, it needs to be recorded to FLV/MP4, transcoded in RTMP, and screenshotted
It also needs to be integrated with existing business systems, such as HTTP callbacks, or query stream and client information through HTTP API interfaces
You can use FFmpeg to actively pull streams to SRS, forward the streams and forward them to other services, or push RTSP/UDP/FLV to SRS
In terms of security, you can use the security policy to set access, or use the HTTP API to kick streams
Use VHOST virtual servers to isolate different services, use domain names as scheduling units, and apply different configurations

If you prefer to watch videos, you can check out the video column below:

Bilibili column (video): SRS open source server

srs-server’s personal space_Bilibili_Bilibili

Zero Sound Academy (Video): SRS4.0 Starter Series

[Free]
FFmpeg/WebRTC/RTMP/NDK/Android Audio and Video Streaming Advanced Development-Learning Video Tutorials-Tencent Classroom

Zero Sound Academy (video): SRS streaming server in action

SRS Streaming Media Server Actual Combat (Part I)_Bilibili_bilibili

资源下载此资源为免费资源立即下载

Telegram:@John_Software

collect(0) Like (0)

Disclaimer: This article is published by a third party and represents the views of the author only and has nothing to do with this website. This site does not make any guarantee or commitment to the authenticity, completeness and timeliness of this article and all or part of its content, please readers for reference only, and please verify the relevant content. The publication or republication of articles by this website for the purpose of conveying more information does not mean that it endorses its views or confirms its description, nor does it mean that this website is responsible for its authenticity.

Ictcoder Free Source Code A simple and efficient real-time video server that supports multiple protocols such as RTMP https://ictcoder.com/a-simple-and-efficient-real-time-video-server-that-supports-multiple-protocols-such-as-rtmp/

lllll

Share free open-source source code

Previous article： An OS-free MCU utility software management system

Next article： A Python tool for adding and extracting blind watermarks from images

Q&A

Ordering Process

1. Automatic: After making an online payment, click the (Download) link to download the source code; 2. Manual: Contact the seller or the official to check if the template is consistent. Then, place an order and make payment online. The seller ships the goods, and both parties inspect and confirm that there are no issues. ICTcoder will then settle the payment for the seller. Note: Please ensure to place your order and make payment through ICTcoder. If you do not place your order and make payment through ICTcoder, and the seller sends fake source code or encounters any issues, ICTcoder will not assist in resolving them, nor can we guarantee your funds!

View details

Transactions and Disputes

1. Default transaction cycle for source code: The seller manually ships the goods within 1-3 days. The amount paid by the user will be held in escrow by ICTcoder until 7 days after the transaction is completed and both parties confirm that there are no issues. ICTcoder will then settle with the seller. In case of any disputes, ICTcoder will have staff to assist in handling until the dispute is resolved or a refund is made! If the buyer places an order and makes payment not through ICTcoder, any issues and disputes have nothing to do with ICTcoder, and ICTcoder will not be responsible for any liabilities!

View details

Matters needing attention

1. ICTcoder will permanently archive the transaction process between both parties and snapshots of the traded goods to ensure the authenticity, validity, and security of the transaction! 2. ICTcoder cannot guarantee services such as "permanent package updates" and "permanent technical support" after the merchant's commitment. Buyers are advised to identify these services on their own. If necessary, they can contact ICTcoder for assistance; 3. When both website demonstration and image demonstration exist in the source code, and the text descriptions of the website and images are inconsistent, the text description of the image shall prevail as the basis for dispute resolution (excluding special statements or agreements); 4. If there is no statement such as "no legal basis for refund" or similar content, any indication on the product that "once sold, no refunds will be supported" or other similar declarations shall be deemed invalid; 5. Before the buyer places an order and makes payment, the transaction details agreed upon by both parties via WhatsApp or email can also serve as the basis for dispute resolution (in case of any inconsistency between the agreement and the description of the conflict, the agreement shall prevail); 6. Since chat records and email records can serve as the basis for dispute resolution, both parties should only communicate with each other through the contact information left on the system when contacting each other, in order to prevent the other party from denying their own commitments. 7. Although the probability of disputes is low, it is essential to retain important information such as chat records, text messages, and email records, in case a dispute arises, so that ICTcoder can intervene quickly.

View details

ICTcoder reminds and declares

1. As a third-party intermediary platform, ICTcoder solely protects transaction security and the rights and interests of both buyers and sellers based on the transaction contract (product description, agreed content before the transaction); 2. For online trading projects not on the ICTcoder platform, any consequences are unrelated to this platform; regardless of the reason why the seller requests an offline transaction, please contact the administrator to report.

View details