mirror of
https://github.com/aler9/rtsp-simple-server
synced 2026-04-22 23:17:11 +08:00
docs: update (#5567)
This commit is contained in:
Alessandro Ros
@@ -1,4 +1,4 @@
|
||||
# Always-available streams
|
||||
# Always-available
|
||||
|
||||
When the publisher or source of a stream is offline, the server can be configured to fill gaps in the stream with an offline segment that is played on repeat until a publisher comes back online. This allows readers to stay connected regardless of the state of the stream. The offline segment and online stream are concatenated without re-encoding any frame, using the original codec.
|
||||
|
||||
|
||||
@@ -8,14 +8,8 @@ The server can ingest and broadcast with WebRTC a wide variety of video and audi
|
||||
|
||||
In particular, reading and publishing H265 tracks with WebRTC was not possible until some time ago due to lack of browser support. The situation improved recently and can be described as following:
|
||||
|
||||
- Safari on iOS and macOS fully support publishing and reading H265 tracks
|
||||
- Chrome on Windows supports publishing and reading H265 tracks when a GPU is present and when the browser is launched with the following flags:
|
||||
|
||||
```
|
||||
chrome.exe --enable-features=PlatformHEVCEncoderSupport,WebRtcAllowH265Receive,WebRtcAllowH265Send --force-fieldtrials=WebRTC-Video-H26xPacketBuffer/Enabled
|
||||
```
|
||||
|
||||
We are expecting these flags to become redundant in the future and the feature to be turned on by default.
|
||||
- Safari on iOS and macOS fully support publishing and reading H265 tracks.
|
||||
- Chrome on Windows supports publishing and reading H265 tracks when a capable GPU is present.
|
||||
|
||||
You can check what codecs your browser can publish or read with WebRTC by [using this tool](https://jsfiddle.net/v24s8q1f/).
|
||||
|
||||
@@ -30,9 +24,16 @@ ffmpeg -i rtsp://original-source \
|
||||
|
||||
## Solving WebRTC connectivity issues
|
||||
|
||||
If the server is hosted inside a container or is behind a NAT, additional configuration is required in order to allow the two WebRTC parts (server and client) to establish a connection.
|
||||
In WebRTC, the handshake between server and clients happens through standard HTTP requests and responses, while media streaming takes place inside a dedicated communication channel (peer connection) that is set up shortly after the handshake. The server supports establishing peer connections through the following methods (ordered by efficiency and simplicity):
|
||||
|
||||
Make sure that `webrtcAdditionalHosts` includes your public IPs, that are IPs that can be used by clients to reach the server. If clients are on the same LAN as the server, add the LAN address of the server. If clients are coming from the internet, add the public IP address of the server, or alternatively a DNS name, if you have one. You can add several values to support all scenarios:
|
||||
1. using a static UDP server port (`webrtcLocalUDPAddress` must be filled, it is by default)
|
||||
2. using a static TCP server port (`webrtcLocalTCPAddress` must be filled, it is not by default)
|
||||
3. using a random UDP server port and UDP client port with the hole-punching technique (`webrtcICEServers2` must contain a STUN server, not present by default)
|
||||
4. using a relay (TURN server) that exposes a TCP port that is accessed by both server and clients (`webrtcICEServers2` must contain a TURN server, not present by default)
|
||||
|
||||
Establishing the peer connection might get difficult when the server is hosted inside a container or there is a NAT / firewall between server and clients.
|
||||
|
||||
The first thing to do is making sure that `webrtcAdditionalHosts` includes your public IPs, that are IPs that can be used by clients to reach the server. If clients are on the same LAN as the server, add the LAN address of the server. If clients are coming from the internet, add the public IP address of the server, or alternatively a DNS name, if you have one. You can add several values to support all scenarios:
|
||||
|
||||
```yml
|
||||
webrtcAdditionalHosts: [192.168.x.x, 1.2.3.4, my-dns.example.org, ...]
|
||||
@@ -47,7 +48,7 @@ docker run --rm -it \
|
||||
bluenviron/mediamtx:1
|
||||
```
|
||||
|
||||
If you still have problems, the UDP protocol might be blocked by a firewall. Enable the TCP protocol by enabling the local TCP listener:
|
||||
If you still have problems, the UDP protocol might be blocked by a firewall. Switch to the TCP protocol by enabling the TCP server port:
|
||||
|
||||
```yml
|
||||
webrtcLocalTCPAddress: :8189
|
||||
@@ -55,14 +56,14 @@ webrtcLocalTCPAddress: :8189
|
||||
|
||||
If there's a NAT / container between server and clients, it must be configured to route all incoming TCP packets on port 8189 to the server.
|
||||
|
||||
If you still have problems, add a STUN server. When a STUN server is in use, server IP is obtained automatically and connections are established with the "UDP hole punching" technique, that uses a random UDP port that does not need to be open. For instance:
|
||||
If you still have problems, add a STUN server, that is used by both server and clients to find out their public IP. Connections are then established with the "UDP hole punching" technique, that uses a random UDP port that does not need to be explicitly opened. For instance:
|
||||
|
||||
```yml
|
||||
webrtcICEServers2:
|
||||
- url: stun:stun.l.google.com:19302
|
||||
```
|
||||
|
||||
If you really still have problems, you can force all WebRTC/ICE connections to pass through a TURN server, like [coturn](https://github.com/coturn/coturn), that must be configured externally. The server address and credentials must be set in the configuration file:
|
||||
If you really still have problems, you can force all WebRTC/ICE connections to pass through a TURN server. The server address and credentials must be set in the configuration file:
|
||||
|
||||
```yml
|
||||
webrtcICEServers2:
|
||||
@@ -73,7 +74,7 @@ webrtcICEServers2:
|
||||
|
||||
Where user and pass are the username and password of the server. Note that port is not optional.
|
||||
|
||||
If the server uses a secret-based authentication (for instance, coturn with the use-auth-secret option), it must be configured by using AUTH_SECRET as username, and the secret as password:
|
||||
If the server uses a secret-based authentication (for instance, Coturn with the use-auth-secret option), it must be configured by using AUTH_SECRET as username, and the secret as password:
|
||||
|
||||
```yml
|
||||
webrtcICEServers2:
|
||||
@@ -82,9 +83,9 @@ webrtcICEServers2:
|
||||
password: secret
|
||||
```
|
||||
|
||||
where secret is the secret of the TURN server. _MediaMTX_ will generate a set of credentials by using the secret, and credentials will be sent to clients before the WebRTC/ICE connection is established.
|
||||
Where secret is the secret of the TURN server. _MediaMTX_ will generate a set of credentials by using the secret, and credentials will be sent to clients before the WebRTC/ICE connection is established.
|
||||
|
||||
In some cases you may want the browser to connect using TURN servers but have mediamtx not using TURN (for example if the TURN server is on the same network as mediamtx). To allow this you can configure the TURN server to be client only:
|
||||
In some cases you may want the browser to connect using TURN servers but have _MediaMTX_ not using TURN (for example if the TURN server is on the same network as mediamtx). To allow this you can configure the TURN server to be client only:
|
||||
|
||||
```yml
|
||||
webrtcICEServers2:
|
||||
@@ -93,3 +94,35 @@ webrtcICEServers2:
|
||||
password: password
|
||||
clientOnly: true
|
||||
```
|
||||
|
||||
## Coturn setup
|
||||
|
||||
Here's how to setup the [Coturn](https://github.com/coturn/coturn) TURN server and use it with _MediaMTX_. This is needed only if all other WebRTC connectivity methods have failed. Start Coturn with Docker:
|
||||
|
||||
```sh
|
||||
docker run --rm -it \
|
||||
--network=host \
|
||||
coturn/coturn \
|
||||
--log-file=stdout -v \
|
||||
--no-udp --no-dtls --no-tls \
|
||||
--min-port=49152 --max-port=65535 \
|
||||
--use-auth-secret --static-auth-secret=mysecret -r myrealm
|
||||
```
|
||||
|
||||
We are suggesting and using the following settings:
|
||||
|
||||
- enable the TCP transport only. We are assuming you are setupping Coturn because other connectivity methods have failed, thus TCP is more reliable.
|
||||
- toggle `--network=host` since Coturn allocates a TCP port for each peer connection.
|
||||
- set `min-port` and `max-port` to specify the range of TCP ports.
|
||||
- enable secret-based authentication, that prevents clients from storing permanently valid credentials.
|
||||
|
||||
Configure MediaMTX to use the TURN server:
|
||||
|
||||
```yml
|
||||
webrtcICEServers2:
|
||||
- url: turn:REPLACE_WITH_COTURN_IP:3478?transport=tcp
|
||||
username: AUTH_SECRET
|
||||
password: mysecret
|
||||
```
|
||||
|
||||
The `?transport=tcp` suffix is needed to force TCP usage. Use `AUTH_SECRET` as username and the shared secret as the password.
|
||||
|
||||
+1
-1
@@ -2,7 +2,6 @@ kickoff/installation: kickoff/install
|
||||
|
||||
usage/publish: publish/overview
|
||||
usage/read: read/overview
|
||||
|
||||
usage/log-management: other/logging
|
||||
usage/basic-usage: other/basic-usage
|
||||
usage/configuration: other/configuration
|
||||
@@ -35,3 +34,4 @@ other/license: misc/license
|
||||
other/security: misc/security
|
||||
other/specifications: misc/specifications
|
||||
other/related-projects: misc/related-projects
|
||||
other/route-absolute-timestamps: other/absolute-timestamps
|
||||
|
||||
Reference in New Issue
Block a user