docs: improve (#5277)

This commit is contained in:
Alessandro Ros 2025-12-27 13:55:13 +01:00 committed by GitHub
parent 6407721807
commit 20e7f1db75
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
32 changed files with 34 additions and 31 deletions

View file

@ -2,7 +2,7 @@
Welcome to the MediaMTX documentation!
MediaMTX is a ready-to-use and zero-dependency live media server and media proxy. It has been conceived as a "media router" that routes media streams from one end to the other.
_MediaMTX_ is a ready-to-use and zero-dependency live media server and media proxy. It has been conceived as a "media router" that routes media streams from one end to the other.
Main features:

View file

@ -6,7 +6,7 @@ There are several installation methods available: standalone binary, Docker imag
1. Visit the [Releases page](https://github.com/bluenviron/mediamtx/releases) on GitHub, download and extract a standalone binary that corresponds to your operating system and architecture (example: `mediamtx_{version_tag}_linux_amd64.tar.gz`).
2. Start the server:
2. Start the server by double clicking on `mediamtx` (`mediamtx.exe` on Windows) or writing in the terminal:
```sh
./mediamtx

View file

@ -1,6 +1,6 @@
# Upgrade
If you have an existing MediaMTX installation, you can upgrade it to the latest version. The procedure depends on how MediaMTX was installed.
If you have an existing _MediaMTX_ installation, you can upgrade it to the latest version. The procedure depends on how _MediaMTX_ was installed.
## Standalone binary
@ -10,7 +10,7 @@ The standalone binary comes with a upgrade utility that can be launched with:
./mediamtx --upgrade
```
This will replace the MediaMTX executable with its latest version. Privileges to write to the executable location are required.
This will replace the _MediaMTX_ executable with its latest version. Privileges to write to the executable location are required.
## Docker image

View file

@ -13,7 +13,7 @@
! qtdemux name=d d.video_0 ! queue ! s.sink_0 d.audio_0 ! queue ! s.sink_1
```
2. Open the stream. For instance, you can open the stream with _VLC_:
2. Read the stream. For instance, you can read the stream with _VLC_:
```sh
vlc --network-caching=50 rtsp://localhost:8554/mystream

View file

@ -94,7 +94,7 @@ paths:
source: wheps://host:port/path
```
If the remote server is a MediaMTX instance, remember to add a `/whep` suffix after the stream name, since in MediaMTX [it's part of the WHEP URL](read#webrtc):
If the remote server is a _MediaMTX_ instance, remember to add a `/whep` suffix after the stream name, since in _MediaMTX_ [it's part of the WHEP URL](read#webrtc):
```yml
paths:
@ -452,7 +452,7 @@ ffmpeg -re -stream_loop -1 -i file.ts -c copy -f flv rtmp://localhost:1935/mystr
#### FFmpeg and MPEG-TS over UDP
In MediaMTX configuration, add a path with `source: udp+mpegts://238.0.0.1:1234`. Then:
In _MediaMTX_ configuration, add a path with `source: udp+mpegts://238.0.0.1:1234`. Then:
```sh
ffmpeg -re -stream_loop -1 -i file.ts -c copy -f mpegts 'udp://127.0.0.1:3356?pkt_size=1316'
@ -468,7 +468,7 @@ ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 \
#### FFmpeg and RTP over UDP
In MediaMTX configuration, add a path with `source: udp+rtp://238.0.0.1:1234` and a valid `rtpSDP` (see [RTP](#rtp)). Then:
In _MediaMTX_ configuration, add a path with `source: udp+rtp://238.0.0.1:1234` and a valid `rtpSDP` (see [RTP](#rtp)). Then:
```sh
ffmpeg -re -f lavfi -i testsrc=size=1280x720:rate=30 \

View file

@ -2,6 +2,8 @@
All the configuration parameters are listed and commented in the [configuration file](/docs/references/configuration-file) (`mediamtx.yml`).
## Change the configuration
There are several ways to change the configuration:
1. By editing the configuration file, that is
@ -46,3 +48,13 @@ There are several ways to change the configuration:
```
3. By using the [Control API](control-api).
## Encrypt the configuration
The configuration file can be entirely encrypted for security purposes by using the `crypto_secretbox` function of the NaCL function. An online tool for performing this operation is [available here](https://play.golang.org/p/rX29jwObNe4).
After performing the encryption, put the base64-encoded result into the configuration file, and launch the server with the `MTX_CONFKEY` variable:
```
MTX_CONFKEY=mykey ./mediamtx
```

View file

@ -2,7 +2,7 @@
## Overview
MediaMTX can be configured to ask clients for credentials, either in the form of username/password or a string-based token. These credentials are then validated through a chosen method.
_MediaMTX_ can be configured to ask clients for credentials, either in the form of username/password or a string-based token. These credentials are then validated through a chosen method.
## Credential validation
@ -306,6 +306,6 @@ Authorization: Bearer MY_JWT
In OBS Studio, this is the "Bearer Token" field.
If the `Authorization: Bearer` token cannot be directly provided (for instance, with web browsers that directly access MediaMTX and show a credential dialog), you can pass the token as password, using an arbitrary user.
If the `Authorization: Bearer` token cannot be directly provided (for instance, with web browsers that directly access _MediaMTX_ and show a credential dialog), you can pass the token as password, using an arbitrary user.
In web browsers, if you need to automatically fill credentials from a parent web page, see [Embed streams in a website](embed-streams-in-a-website).

View file

@ -1,9 +0,0 @@
# Encrypt the configuration
The configuration file can be entirely encrypted for security purposes by using the `crypto_secretbox` function of the NaCL function. An online tool for performing this operation is [available here](https://play.golang.org/p/rX29jwObNe4).
After performing the encryption, put the base64-encoded result into the configuration file, and launch the server with the `MTX_CONFKEY` variable:
```
MTX_CONFKEY=mykey ./mediamtx
```

View file

@ -1,6 +1,6 @@
# Expose the server in a subfolder
HTTP-based services (WebRTC, HLS, Control API, Playback Server, Metrics, pprof) can be exposed in a subfolder of an existing HTTP server or reverse proxy. The reverse proxy must be able to intercept HTTP requests addressed to MediaMTX and corresponding responses, and perform the following changes:
HTTP-based services (WebRTC, HLS, Control API, Playback Server, Metrics, pprof) can be exposed in a subfolder of an existing HTTP server or reverse proxy. The reverse proxy must be able to intercept HTTP requests addressed to _MediaMTX_ and corresponding responses, and perform the following changes:
- The subfolder path must be stripped from request paths. For instance, if the server is exposed behind `/subpath` and the reverse proxy receives a request with path `/subpath/mystream/index.m3u8`, this has to be changed into `/mystream/index.m3u8`.

View file

@ -20,7 +20,7 @@ The iframe can be controlled by adding query parameters to the URL (example: `ht
The iframe method is fit for most use cases, but it has some limitations:
- it doesn't allow to pass credentials (username, password or token) from the website to MediaMTX; credentials are asked directly to users.
- it doesn't allow to pass credentials (username, password or token) from the website to _MediaMTX_; credentials are asked directly to users.
- it doesn't allow to directly access the video tag, to extract data from it, or to perform dynamic actions.
In order to overcome these limitations, it is possible to load the stream directly inside a `<video>` tag in the web page, through a JavaScript library.
@ -94,7 +94,7 @@ The iframe can be controlled by adding query parameters to the URL (example: `ht
The iframe method is fit for most use cases, but it has some limitations:
- it doesn't allow to pass credentials (username, password or token) from the website to MediaMTX; credentials are asked directly to users.
- it doesn't allow to pass credentials (username, password or token) from the website to _MediaMTX_; credentials are asked directly to users.
- it doesn't allow to directly access the video tag, to extract data from it, or to perform dynamic actions.
In order to overcome these limitations, it is possible to load the stream directly inside a `<video>` tag in the web page, through the _hls.js_ library.

View file

@ -1,6 +1,6 @@
# Extract metrics
MediaMTX provides several metrics through a dedicated HTTP server, in a format compatible with [Prometheus](https://prometheus.io/).
_MediaMTX_ provides several metrics through a dedicated HTTP server, in a format compatible with [Prometheus](https://prometheus.io/).
This server can be enabled by setting `metrics: yes` in the configuration.

View file

@ -82,7 +82,7 @@ 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:

View file

@ -25,7 +25,7 @@ Streams can be published and read with the rtmps scheme and the 1937 port:
rtmps://localhost:1937/...
```
Be aware that RTMPS is currently unsupported by all major players. However, you can use a local _MediaMTX_ instance to decrypt streams before reading them, or alternatively a proxy like [stunnel](https://www.stunnel.org) or [nginx](https://nginx.org/). For instance, you can launch a local MediaMTX instance with this configuration:
Be aware that RTMPS is currently unsupported by all major players. However, you can use a local _MediaMTX_ instance to decrypt streams before reading them, or alternatively a proxy like [stunnel](https://www.stunnel.org) or [nginx](https://nginx.org/). For instance, you can launch a local _MediaMTX_ instance with this configuration:
```yml
paths:

View file

@ -3,11 +3,11 @@
MediaMTX is meant for routing live streams, and makes use of a series of protocols and techniques which try to preserve the real-time aspect of streams and minimize latency at cost of losing packets in transmit, in particular:
- most protocols are built on UDP, which is an "unreliable transport", specifically picked because it allows to drop late packets in case of network congestions.
- there's a circular buffer that stores outgoing packets and starts dropping packets when full.
- there's a circular buffer that stores outgoing packets and drops packets if full.
Packet losses are usually detected and printed in MediaMTX logs.
Packet losses are usually detected and printed in _MediaMTX_ logs.
If you need to improve the stream reliability and decrease packet losses, the first thing to do is to check whether the network between the MediaMTX instance and the intended publishers and readers has sufficient bandwidth for transmitting the media stream. Most of the times, packet losses are caused by a network which is not fit for this scope. This limitation can be overcome by either recompressing the stream with a lower bitrate, or by upgrading the network physical infrastructure (routers, cables, Wi-Fi, firewalls, topology, etc).
If you need to improve the stream reliability and decrease packet losses, the first thing to do is to check whether the physical network between the _MediaMTX_ instance and the intended publishers and readers has sufficient bandwidth for transmitting the media stream. Most of the times, packet losses are caused by a network which is not fit for this scope. This limitation can be overcome by either recompressing the stream with a lower bitrate, or by upgrading the network infrastructure (routers, cables, Wi-Fi, firewalls, topology, etc).
There are however some parameters that can be tuned to improve the situation, at cost of increasing RAM consumption:

View file

@ -1,3 +1,3 @@
# Configuration file reference
This is a copy of the configuration file (`mediamtx.yml`) of the latest MediaMTX release ({version_tag}), that contains all available parameters. Check the [Configuration usage page](/docs/usage/configuration) for instructions on how to change it.
This is a copy of the configuration file (`mediamtx.yml`) of the latest _MediaMTX_ release ({version_tag}), that contains all available parameters. Check the [Configuration usage page](/docs/usage/configuration) for instructions on how to change it.

View file

@ -1,3 +1,3 @@
# Control API reference
This is the reference of the Control API of the latest MediaMTX release ({version_tag}), generated automatically from the [OpenAPI / Swagger file](https://github.com/bluenviron/mediamtx/blob/{version_tag}/api/openapi.yaml) available in the repository. Check the [Control API usage page](/docs/usage/control-api) for instructions on how to use the API.
This is the reference of the Control API of the latest _MediaMTX_ release ({version_tag}), generated automatically from the [OpenAPI / Swagger file](https://github.com/bluenviron/mediamtx/blob/{version_tag}/api/openapi.yaml) available in the repository. Check the [Control API usage page](/docs/usage/control-api) for instructions on how to use the API.

View file

@ -1,6 +1,6 @@
# License
All the code in the main MediaMTX repository is released under the [MIT License](https://github.com/bluenviron/mediamtx/blob/{version_tag}/LICENSE). Compiled binaries include some third-party dependencies:
All the code in the main _MediaMTX_ repository is released under the [MIT License](https://github.com/bluenviron/mediamtx/blob/{version_tag}/LICENSE). Compiled binaries include some third-party dependencies:
- all the Golang dependencies listed into the [go.mod file](https://github.com/bluenviron/mediamtx/blob/{version_tag}/go.mod), which are all released under either the MIT license, BSD 3-Clause license or Apache License 2.0.
- hls.js, released under the [Apache License 2.0](https://github.com/video-dev/hls.js/blob/master/LICENSE).