Please note that the proxy server is a new architecture or the next
version of the Origin Cluster, which allows the publication of multiple
streams. The SRS origin cluster consists of a group of origin servers
designed to handle a large number of streams.
```text
+-----------------------+
+---+ SRS Proxy(Deployment) +------+---------------------+
+-----------------+ | +-----------+-----------+ + +
| LB(K8s Service) +--+ +(Redis/MESH) + SRS Origin Servers +
+-----------------+ | +-----------+-----------+ + (Deployment) +
+---+ SRS Proxy(Deployment) +------+---------------------+
+-----------------------+
```
The new origin cluster is designed as a collection of proxy servers. For
more information, see [Discussion
#3634](https://github.com/ossrs/srs/discussions/3634). If you prefer to
use the old origin cluster, please switch to a version before SRS 6.0.
A proxy server can be used for a set of origin servers, which are
isolated and dedicated origin servers. The main improvement in the new
architecture is to store the state for origin servers in the proxy
server, rather than using MESH to communicate between origin servers.
With a proxy server, you can deploy origin servers as stateless servers,
such as in a Kubernetes (K8s) deployment.
Now that the proxy server is a stateful server, it uses Redis to store
the states. For faster development, we use Go to develop the proxy
server, instead of C/C++. Therefore, the proxy server itself is also
stateless, with all states stored in the Redis server or cluster. This
makes the new origin cluster architecture very powerful and robust.
The proxy server is also an architecture designed to solve multiple
process bottlenecks. You can run hundreds of SRS origin servers with one
proxy server on the same machine. This solution can utilize multi-core
machines, such as servers with 128 CPUs. Thus, we can keep SRS
single-threaded and very simple. See
https://github.com/ossrs/srs/discussions/3665#discussioncomment-6474441
for details.
```text
+--------------------+
+-------+ SRS Origin Server +
+ +--------------------+
+
+-----------------------+ + +--------------------+
+ SRS Proxy(Deployment) +------+-------+ SRS Origin Server +
+-----------------------+ + +--------------------+
+
+ +--------------------+
+-------+ SRS Origin Server +
+--------------------+
```
Keep in mind that the proxy server for the Origin Cluster is designed to
handle many streams. To address the issue of many viewers, we will
enhance the Edge Cluster to support more protocols.
```text
+------------------+ +--------------------+
+ SRS Edge Server +--+ +-------+ SRS Origin Server +
+------------------+ + + +--------------------+
+ +
+------------------+ + +-----------------------+ + +--------------------+
+ SRS Edge Server +--+-----+ SRS Proxy(Deployment) +------+-------+ SRS Origin Server +
+------------------+ + +-----------------------+ + +--------------------+
+ +
+------------------+ + + +--------------------+
+ SRS Edge Server +--+ +-------+ SRS Origin Server +
+------------------+ +--------------------+
```
With the new Origin Cluster and Edge Cluster, you have a media system
capable of supporting a large number of streams and viewers. For
example, you can publish 10,000 streams, each with 100,000 viewers.
---------
Co-authored-by: Jacob Su <suzp1984@gmail.com>
The heartbeat of SRS is a timer that requests an HTTP URL. We can use
this heartbeat to report the necessary information for registering the
backend server with the proxy server.
```text
SRS(backend) --heartbeat---> Proxy server
```
A proxy server is a specialized load balancer for media servers. It
operates at the application level rather than the TCP level. For more
information about the proxy server, see issue #4158.
Note that we will merge this PR into SRS 5.0+, allowing the use of SRS
5.0+ as the backend server, not limited to SRS 7.0. However, the proxy
server is introduced in SRS 7.0.
It's also possible to implement a registration service, allowing you to
use other media servers as backend servers. For example, if you gather
information about an nginx-rtmp server and register it with the proxy
server, the proxy will forward RTMP streams to nginx-rtmp. The backend
server is not limited to SRS.
---------
Co-authored-by: Jacob Su <suzp1984@gmail.com>
For #3369 to support an external powerful SIP server, do not use the
embedded SIP server of SRS.
For more information, detailed steps, system architecture, and
background explanation, please see
https://ossrs.net/lts/zh-cn/docs/v6/doc/gb28181#external-sip
---------
Co-authored-by: Jacob Su <suzp1984@gmail.com>
Co-authored-by: winlin <winlinvip@gmail.com>
1. Add live benchmark support in srs-bench, which only connects and
disconnects without any media transport, to test source creation and
disposal and verify source memory leaks.
2. SmartPtr: Support cleanup of HTTP-FLV stream. Unregister the HTTP-FLV
handler for the pattern and clean up the objects and resources.
3. Support benchmarking RTMP/SRT with srs-bench by integrating the gosrt
and oryx RTMP libraries.
4. Refine SRT and RTC sources by using a timer to clean up the sources,
following the same strategy as the Live source.
---------
Co-authored-by: Haibo Chen <495810242@qq.com>
Co-authored-by: Jacob Su <suzp1984@gmail.com>
1. When converting RTC to RTMP, it is necessary to synchronize the audio
and video timestamps. When the synchronization status changes, whether
it is unsynchronized or synchronized, print logs to facilitate
troubleshooting of such issues.
2. Chrome uses the STAP-A packet, which means a single RTP packet
contains SPS/PPS information. OBS WHIP, on the other hand, sends SPS and
PPS in separate RTP packets. Therefore, SPS and PPS are in two
independent RTP packets, and SRS needs to cache these two packets.
---------
Co-authored-by: john <hondaxiao@tencent.com>
In pure audio mode, there are no keyframes. Therefore, we can only rely
on the length of the slice to determine whether it should be output.
`hls_aof_ratio` is the coefficient that, once reached, will generate a
new slice.
In scenarios with video, if the `hls_aof_ratio` is too small, for
example 1.2, and the GOP (Group of Pictures) is 10 seconds, then a slice
will definitely be generated at 12 seconds. At this point, if there are
no keyframes, it will cause the next slice to start with a non-keyframe.
A safer coefficient is twice the GOP (Group of Pictures). This way, it
won't trigger incorrectly and prevent the individual transcoding of a ts
segment file.
---------
Co-authored-by: Haibo Chen <495810242@qq.com>
Follow the example in FFmpeg's doc, before calling the API
`avcodec_send_frame`, always use `av_frame_alloc` to create a new frame.
---------
Co-authored-by: Haibo Chen <495810242@qq.com>
1. The comment on the ratio configuration says it can affect the slice
duration, but there is no effect after configuring it.
2. The default hls_td_ratio is 1.5, and after setting it to 1, the
duration is still slightly more than 10 seconds.
3. Even if the GOP is an integer, like 1 second, the slice is still a
non-integer, like 0.998 seconds, which seems a bit unreliable.
4. In the duration of the TS in the m3u8 file, it is one frame less than
the duration of the slice.
5. Set hls_dispose to 120s to dispose HLS files when no stream.
6. Use docker.conf for docker.
Before this patch:
```
#EXTINF:10.983, no desc
livestream-0.ts?hls_ctx=3p095hq0
```
After this patch:
```
#EXTINF:10.000, no desc
livestream-0.ts?hls_ctx=3p095hq0
```
Note: If the fragment is set to 10 seconds, but the GOP size cannot be
divided by 10, such as not 1, 2, 5, or 10, then the duration of ts will
still be more than 10 seconds.
---------
Co-authored-by: john <hondaxiao@tencent.com>
ISO_IEC_14496-10-AVC-2012.pdf, page 65
7.4.1.1 Encapsulation of an SODB within an RBSP (informative)
... 00 00 03 xx, the 03 byte should be drop where xx represents any 2
bit pattern: 00, 01, 10, or 11.
---------
Co-authored-by: john <hondaxiao@tencent.com>
Co-authored-by: chundonglinlin <chundonglinlin@163.com>
Co-authored-by: winlin <winlin@vip.126.com>
## Reload Error Ignore
During a Reload, several stages will be passed through:
1. Parsing new configurations: Parse.
2. Transforming configurations: Transform.
3. Applying configurations: Apply.
Previously, any error at any stage would result in a direct exit, making
the system completely dependent on configuration checks:
```bash
./objs/srs -c conf/srs.conf -t
echo $?
#0
```
Optimized to: If an error occurs before applying the configuration, it
can be ignored. If an error occurs during the application of the
configuration, some of the configuration may have already taken effect,
leading to unpredictable behavior, so SRS will exit directly.
## Reload Fetch API
Added a new HTTP API to query the result of the reload.
```nginx
http_api {
enabled on;
raw_api {
enabled on;
allow_reload on;
}
}
```
```bash
curl http://localhost:1985/api/v1/raw?rpc=reload-fetch
```
```json
{
"code": 0,
"data": {
"err": 0,
"msg": "Success",
"state": 0,
"rid": "0s6y0n9"
}
}
{
"code": 0,
"data": {
"err": 1023,
"msg": "code=1023(ConfigInvalid) : parse file : parse buffer containers/conf/srs.release-local.conf : root parse : parse dir : parse include buffer containers/data/config/srs.vhost.conf : read token, line=0, state=0 : line 3: unexpected end of file, expecting ; or \"}\"",
"state": 1,
"rid": "0g4z471"
}
}
```
This way, you can know if the last reload of the system was successful.
---------
Co-authored-by: Haibo Chen <495810242@qq.com>
* Improve README with AI and add new features
1. Update README file with AI to make it more informative and user-friendly
2. Add a detailed table of contents (TOC) with an introduction for easy navigation
3. Introduce an auto-detecting Automake feature that displays the correct installation command
4. Add support for SRT to HTTP-TS config file
5. Refine the WHIP delete location URL
6. Add support for disabling encryption for WHIP or WHEP
This pull request aims to enhance the quality of the project by introducing innovative features and making the necessary updates. These updates will help users navigate the project more efficiently while also improving the overall project's quality.
---------
Co-authored-by: ChenGH <chengh_math@126.com>
Co-authored-by: john <hondaxiao@tencent.com>
In dockerfile, we can set the default RTC candidate to env:
```
ENV SRS_RTC_SERVER_CANDIDATE=\$CANDIDATE
CMD ["./objs/srs", "-e"]
```
When starts a docker container, user can setup the candidate by env:
```
docker run --rm -it --env CANDIDATE=1.2.3.4 ossrs/srs:5
```
We should parse the content of SRS_RTC_SERVER_CANDIDATE as env variable name and parse it again.
---------
Co-authored-by: chundonglinlin <chundonglinlin@163.com>
Co-authored-by: pengfei.ma <pengfei.ma@ctechm.com>
For some use scenario, the publisher is invited when player want to view the stream:
1. Publisher connect to system, but does not publish any stream to SRS yet.
2. Player connect to system and start to request the stream.
3. System notifies publisher to publish stream to SRS.
4. Player play the stream from SRS.
Please notice that `system` means your business system, not SRS.
This is what we called `on-demand-live-streaming`, so when the last player stop to view the stream, what happends?
1. System needs to notify publisher to stop publish.
2. Or, SRS disconnect the publisher when idle(the last player stops playing).
This PR is for the solution 2, so that the cleanup is very simple, your system does not need to notify publisher to stop publish, because SRS has already disconnected the publihser.
---------
Co-authored-by: winlin <winlin@vip.126.com>
Co-authored-by: chundonglinlin <chundonglinlin@163.com>
1. Build regression test tool for gb28181.
2. Run regression test for gb28181.
3. Format go code and eliminate logs.
4. Change base docker to ubuntu20.
PICK 7750bdae10
1. Docker use srs.conf and env variables.
2. Show help if run SRS without any options.
3. Do not guess config file, use whatever from user.
PICK 07a9a005d5
1. SRT: Fix srt to rtmp crash when sps or pps empty. v5.0.112 (#3323)
2. GB28181: Fix memory overlap for small packets. v5.0.111 (#3315)
3. FLV: Support set default has_av and disable guessing. v5.0.110 (#3311)
4. FLV: Drop packet if header flag is not matched. v5.0.109 (#3306)
5. FLV: Reset has_audio or has_video if only sequence header. (#3310)
* FLV: Support set default has_av and disable guessing. v5.0.110
1. Support config default has_audio and has_video.
2. Support disable guessing has_audio or has_video.
* FLV: Reset to false if start to guess has_av.
* FLV: Add regression test for FLV header av metadata.
1. Ignore audo or video packets if FLV header disable it.
2. Run: Add regression test config and run for IDEA.
3. Test: Refine regression test to allow no audio/video for FLV
4. Config: Whether drop packet if not match header.
* Add utc time utility
* Fix calculate duration in fmp4
* Refine dash code, use segment template timeline
* Shrink m4s file and cleanup
* Support play by dash.js
* Use SegmentTemplate timeline mode with $Number$
Co-authored-by: winlin <winlin@vip.126.com>
* Add utc time utility
* Fix calculate duration in fmp4
* Refine dash code, use segment template timeline
* Shrink m4s file and cleanup
* Support play by dash.js
* Use SegmentTemplate timeline mode with $Number$
Co-authored-by: winlin <winlin@vip.126.com>
1. Support configure with --h265=on.
2. Parse HEVC(H.265) from FLV or RTMP packet.
3. Support HEVC over RTMP or HTTP-FLV.
Co-authored-by: runner365 <shi.weibd@hotmail.com>
1. Support Java/log4j log level text.
2. Support configuring by `--log-new-level=on` which is enabled by default.
3. Support `--log-new-level=off` to use SRS 4.0 log level for compatibility.
