diff --git a/README.md b/README.md index c50329c6..05198058 100644 --- a/README.md +++ b/README.md @@ -1,34 +1,44 @@

- MediaMTX / rtsp-simple-server + MediaMTX / rtsp-simple-server + +
+
+ + [![Test](https://github.com/bluenviron/mediamtx/workflows/test/badge.svg)](https://github.com/bluenviron/mediamtx/actions?query=workflow:test) + [![Lint](https://github.com/bluenviron/mediamtx/workflows/lint/badge.svg)](https://github.com/bluenviron/mediamtx/actions?query=workflow:lint) + [![CodeCov](https://codecov.io/gh/bluenviron/mediamtx/branch/main/graph/badge.svg)](https://app.codecov.io/gh/bluenviron/mediamtx/branch/main) + [![Release](https://img.shields.io/github/v/release/bluenviron/mediamtx)](https://github.com/bluenviron/mediamtx/releases) + [![Docker Hub](https://img.shields.io/badge/docker-bluenviron/mediamtx-blue)](https://hub.docker.com/r/bluenviron/mediamtx) + [![API Documentation](https://img.shields.io/badge/api-documentation-blue)](https://bluenviron.github.io/mediamtx)


-_MediaMTX_ / [_rtsp-simple-server_](#note-about-rtsp-simple-server) is a ready-to-use and zero-dependency server and proxy that allows users to publish, read and proxy live video and audio streams. +_MediaMTX_ (formerly _rtsp-simple-server_) is a ready-to-use and zero-dependency real-time media server and media proxy that allows users to publish, read and proxy live video and audio streams. It has been conceived as a "media broker", a message broker that routes media streams. Live streams can be published to the server with: |protocol|variants|video codecs|audio codecs| |--------|--------|------------|------------| -|WebRTC|Browser-based, WHIP|AV1, VP9, VP8, H264|Opus, G722, G711| -|RTSP clients|UDP, TCP, RTSPS|AV1, VP9, VP8, H265, H264, MPEG-4 Video (H263, Xvid), MPEG-1/2 Video, M-JPEG and any RTP-compatible codec|Opus, MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3), G722, G711, LPCM and any RTP-compatible codec| -|RTSP servers and cameras|UDP, UDP-Multicast, TCP, RTSPS|AV1, VP9, VP8, H265, H264, MPEG-4 Video (H263, Xvid), MPEG-1/2 Video, M-JPEG and any RTP-compatible codec|Opus, MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3), G722, G711, LPCM and any RTP-compatible codec| -|RTMP clients (OBS Studio)|RTMP, RTMPS, Enhanced RTMP|AV1, H265, H264|MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3)| -|RTMP servers and cameras|RTMP, RTMPS, Enhanced RTMP|H264|MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3)| -|HLS servers and cameras|Low-Latency HLS, MP4-based HLS, legacy HLS|H265, H264|Opus, MPEG-4 Audio (AAC)| -|UDP/MPEG-TS streams|Unicast, broadcast, multicast|H265, H264|Opus, MPEG-4 Audio (AAC)| -|Raspberry Pi Cameras||H264|| +|[WebRTC](#webrtc)|Browser-based, WHIP|AV1, VP9, VP8, H264|Opus, G722, G711| +|[RTSP clients](#rtsp-clients)|UDP, TCP, RTSPS|AV1, VP9, VP8, H265, H264, MPEG-4 Video (H263, Xvid), MPEG-1/2 Video, M-JPEG and any RTP-compatible codec|Opus, MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3), G722, G711, LPCM and any RTP-compatible codec| +|[RTSP cameras and servers](#rtsp-cameras-and-servers)|UDP, UDP-Multicast, TCP, RTSPS|AV1, VP9, VP8, H265, H264, MPEG-4 Video (H263, Xvid), MPEG-1/2 Video, M-JPEG and any RTP-compatible codec|Opus, MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3), G722, G711, LPCM and any RTP-compatible codec| +|[RTMP clients](#rtmp-clients)|RTMP, RTMPS, Enhanced RTMP|AV1, H265, H264|MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3)| +|[RTMP cameras and servers](#rtmp-cameras-and-servers)|RTMP, RTMPS, Enhanced RTMP|H264|MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3)| +|[HLS cameras and servers](#hls-cameras-and-servers)|Low-Latency HLS, MP4-based HLS, legacy HLS|H265, H264|Opus, MPEG-4 Audio (AAC)| +|[UDP/MPEG-TS](#udpmpeg-ts)|Unicast, broadcast, multicast|H265, H264|Opus, MPEG-4 Audio (AAC)| +|[Raspberry Pi Cameras](#raspberry-pi-cameras)||H264|| And can be read from the server with: |protocol|variants|video codecs|audio codecs| |--------|--------|------------|------------| -|WebRTC|Browser-based, WHEP|AV1, VP9, VP8, H264|Opus, G722, G711| -|RTSP|UDP, UDP-Multicast, TCP, RTSPS|AV1, VP9, VP8, H265, H264, MPEG-4 Video (H263, Xvid), MPEG-1/2 Video, M-JPEG and any RTP-compatible codec|Opus, MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3), G722, G711, LPCM and any RTP-compatible codec| -|RTMP|RTMP, RTMPS, Enhanced RTMP|H264|MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3)| -|HLS|Low-Latency HLS, MP4-based HLS, legacy HLS|H265, H264|Opus, MPEG-4 Audio (AAC)| +|[WebRTC](#webrtc-1)|Browser-based, WHEP|AV1, VP9, VP8, H264|Opus, G722, G711| +|[RTSP](#rtsp)|UDP, UDP-Multicast, TCP, RTSPS|AV1, VP9, VP8, H265, H264, MPEG-4 Video (H263, Xvid), MPEG-1/2 Video, M-JPEG and any RTP-compatible codec|Opus, MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3), G722, G711, LPCM and any RTP-compatible codec| +|[RTMP](#rtmp)|RTMP, RTMPS, Enhanced RTMP|H264|MPEG-4 Audio (AAC), MPEG-1/2 Audio (MP3)| +|[HLS](#hls)|Low-Latency HLS, MP4-based HLS, legacy HLS|H265, H264|Opus, MPEG-4 Audio (AAC)| -Features: +**Features** * Publish live streams to the server * Read live streams from the server @@ -37,22 +47,15 @@ Features: * Serve multiple streams at once in separate paths * Authenticate users; use internal or external authentication * Redirect readers to other RTSP servers (load balancing) -* Query and control the server through an HTTP API +* Query and control the server through the API * Reload the configuration without disconnecting existing clients (hot reloading) * Read Prometheus-compatible metrics * Run external commands when clients connect, disconnect, read or publish streams * Compatible with Linux, Windows and macOS, does not require any dependency or interpreter, it's a single executable -[![Test](https://github.com/bluenviron/mediamtx/workflows/test/badge.svg)](https://github.com/bluenviron/mediamtx/actions?query=workflow:test) -[![Lint](https://github.com/bluenviron/mediamtx/workflows/lint/badge.svg)](https://github.com/bluenviron/mediamtx/actions?query=workflow:lint) -[![CodeCov](https://codecov.io/gh/bluenviron/mediamtx/branch/main/graph/badge.svg)](https://app.codecov.io/gh/bluenviron/mediamtx/branch/main) -[![Release](https://img.shields.io/github/v/release/bluenviron/mediamtx)](https://github.com/bluenviron/mediamtx/releases) -[![Docker Hub](https://img.shields.io/badge/docker-bluenviron/mediamtx-blue)](https://hub.docker.com/r/bluenviron/mediamtx) -[![API Documentation](https://img.shields.io/badge/api-documentation-blue)](https://bluenviron.github.io/mediamtx) +**Note about rtsp-simple-server** -## Note about rtsp-simple-server - -_rtsp-simple-server_ has been rebranded as _MediaMTX_. The reason is pretty obvious: this project started as a RTSP server but has evolved into a much more versatile media server (i like to call it a "media broker", a message broker for media streams), that is not tied to the RTSP protocol anymore. Nothing will change regarding license, features and backward compatibility. +_rtsp-simple-server_ has been rebranded as _MediaMTX_. The reason is pretty obvious: this project started as a RTSP server but has evolved into a much more versatile product that is not tied to the RTSP protocol anymore. Nothing will change regarding license, features and backward compatibility. ## Table of contents @@ -62,56 +65,52 @@ _rtsp-simple-server_ has been rebranded as _MediaMTX_. The reason is pretty obvi * [Arch Linux package](#arch-linux-package) * [OpenWRT package](#openwrt-package) * [Basic usage](#basic-usage) -* [General](#general) +* [Publish to the server](#publish-to-the-server) + * [By software](#by-software) + * [FFmpeg](#ffmpeg) + * [GStreamer](#gstreamer) + * [OBS Studio](#obs-studio) + * [OpenCV](#opencv) + * [Web browsers](#web-browsers) + * [By device](#by-device) + * [Generic webcam](#generic-webcam) + * [Raspberry Pi Cameras](#raspberry-pi-cameras) + * [By protocol](#by-protocol) + * [WebRTC](#webrtc) + * [RTSP clients](#rtsp-clients) + * [RTSP cameras and servers](#rtsp-cameras-and-servers) + * [RTMP clients](#rtmp-clients) + * [RTMP cameras and servers](#rtmp-cameras-and-servers) + * [HLS cameras and servers](#hls-cameras-and-servers) + * [UDP/MPEG-TS](#udpmpeg-ts) +* [Read from the server](#read-from-the-server) + * [By software](#by-software-1) + * [FFmpeg](#ffmpeg-1) + * [GStreamer](#gstreamer-1) + * [VLC](#vlc) + * [Web browsers](#web-browsers-1) + * [By protocol](#by-protocol-1) + * [WebRTC](#webrtc-1) + * [RTSP](#rtsp) + * [RTMP](#rtmp) + * [HLS](#hls) +* [Features](#features) * [Configuration](#configuration) * [Authentication](#authentication) * [Encrypt the configuration](#encrypt-the-configuration) - * [Proxy mode](#proxy-mode) * [Remuxing, re-encoding, compression](#remuxing-re-encoding-compression) * [Save streams to disk](#save-streams-to-disk) * [On-demand publishing](#on-demand-publishing) * [Start on boot](#start-on-boot) - * [Linux](#linux) - * [Windows](#windows) - * [HTTP API](#http-api) + * [RTSP-specific features](#rtsp-specific-features) + * [RTMP-specific features](#rtmp-specific-features) + * [WebRTC-specific features](#webrtc-specific-features) + * [API](#api) * [Metrics](#metrics) * [pprof](#pprof) - * [Compile from source](#compile-from-source) -* [Publish to the server](#publish-to-the-server) - * [From a webcam](#from-a-webcam) - * [From a Raspberry Pi Camera](#from-a-raspberry-pi-camera) - * [From OBS Studio](#from-obs-studio) - * [From OpenCV](#from-opencv) - * [From a UDP stream](#from-a-udp-stream) - * [From the browser](#from-the-browser) -* [Read from the server](#read-from-the-server) - * [From VLC and Ubuntu](#from-vlc-and-ubuntu) -* [RTSP protocol](#rtsp-protocol) - * [General usage](#general-usage) - * [TCP transport](#tcp-transport) - * [UDP-multicast transport](#udp-multicast-transport) - * [Encryption](#encryption) - * [Redirect to another server](#redirect-to-another-server) - * [Fallback stream](#fallback-stream) - * [Corrupted frames](#corrupted-frames) - * [Decrease latency](#decrease-latency) -* [RTMP protocol](#rtmp-protocol) - * [General usage](#general-usage-1) - * [Encryption](#encryption-1) -* [HLS protocol](#hls-protocol) - * [General usage](#general-usage-2) - * [Browser support](#browser-support) - * [Embedding](#embedding) - * [Low-Latency variant](#low-latency-variant) - * [HLS on Apple devices](#hls-on-apple-devices) - * [Decrease latency](#decrease-latency-1) -* [WebRTC protocol](#webrtc-protocol) - * [General usage](#general-usage-3) - * [WHIP and WHEP](#whip-and-whep) - * [Usage inside a container or behind a NAT](#usage-inside-a-container-or-behind-a-nat) - * [Embedding](#embedding-1) +* [Compile from source](#compile-from-source) * [Standards](#standards) -* [Links](#links) +* [Related projects](#related-projects) ## Installation @@ -123,7 +122,7 @@ There are several installation methods available: standalone binary, Docker imag 2. Start the server: - ``` + ```sh ./mediamtx ``` @@ -142,7 +141,7 @@ Available images: |bluenviron/mediamtx:latest|:x:|:x:| |bluenviron/mediamtx:latest-ffmpeg|:heavy_check_mark:|:x:| |bluenviron/mediamtx:latest-rpi|:x:|:heavy_check_mark:| -|bluenviron/mediamtx:latest-ffmpeg-rpi|:heavy_check_mark:|:heavy_check_mark: +|bluenviron/mediamtx:latest-ffmpeg-rpi|:heavy_check_mark:|:heavy_check_mark:| The `--network=host` flag is mandatory since Docker can change the source port of UDP packets for routing reasons, and this doesn't allow the RTSP server to identify the senders of the packets. This issue can be avoided by disabling the UDP transport protocol: @@ -160,7 +159,7 @@ bluenviron/mediamtx If you are running the Arch Linux distribution, run: -``` +```sh git clone https://aur.archlinux.org/mediamtx.git cd mediamtx makepkg -si @@ -172,7 +171,7 @@ makepkg -si 2. Open a terminal in the SDK folder and setup the SDK: - ``` + ```sh ./scripts/feeds update -a ./scripts/feeds install -a make defconfig @@ -180,7 +179,7 @@ makepkg -si 3. Download the server Makefile and set the server version inside the file: - ``` + ```sh mkdir package/mediamtx wget -O package/mediamtx/Makefile https://raw.githubusercontent.com/bluenviron/mediamtx/main/openwrt.mk sed -i "s/v0.0.0/$(git ls-remote --tags --sort=v:refname https://github.com/bluenviron/mediamtx | tail -n1 | sed 's/.*\///; s/\^{}//')/" package/mediamtx/Makefile @@ -188,7 +187,7 @@ makepkg -si 4. Compile the server: - ``` + ```sh make package/mediamtx/compile -j$(nproc) ``` @@ -196,7 +195,7 @@ makepkg -si 6. Install it with: - ``` + ```sh opkg install [ipk-file-name].ipk ``` @@ -204,471 +203,245 @@ makepkg -si 1. Publish a stream. For instance, you can publish a video/audio file with _FFmpeg_: - ``` + ```sh ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://localhost:8554/mystream ``` or _GStreamer_: - ``` + ```sh gst-launch-1.0 rtspclientsink name=s location=rtsp://localhost:8554/mystream filesrc location=file.mp4 ! qtdemux name=d d.video_0 ! queue ! s.sink_0 d.audio_0 ! queue ! s.sink_1 ``` - To publish from other hardware / software, take a look at the [Publish to the server](#publish-to-the-server) section. - 2. Open the stream. For instance, you can open the stream with _VLC_: - ``` + ```sh vlc --network-caching=50 rtsp://localhost:8554/mystream ``` or _GStreamer_: - ``` + ```sh gst-play-1.0 rtsp://localhost:8554/mystream ``` or _FFmpeg_: - ``` + ```sh ffmpeg -i rtsp://localhost:8554/mystream -c copy output.mp4 ``` -## General - -### Configuration +## Publish to the server -All the configuration parameters are listed and commented in the [configuration file](mediamtx.yml). +### By software -There are 3 ways to change the configuration: +#### FFmpeg -1. By editing the `mediamtx.yml` file, that is +FFmpeg can publish a stream to the server in multiple ways (RTSP client, RTMP client, UDP/MPEG-TS, WebRTC with WHIP). The recommended one consists in publishing as a [RTSP client](#rtsp-clients): - * included into the release bundle - * available in the root folder of the Docker image (`/mediamtx.yml`); it can be overridden in this way: +``` +ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://localhost:8554/mystream +``` - ``` - docker run --rm -it --network=host -v $PWD/mediamtx.yml:/mediamtx.yml bluenviron/mediamtx - ``` +The RTSP protocol supports multiple underlying transport protocols, each with its own characteristics (see [RTSP-specific features](#rtsp-specific-features)). You can set the transport protocol by using the `rtsp_transport` flag, for instance, in order to use TCP: - The configuration can be changed dynamically when the server is running (hot reloading) by writing to the configuration file. Changes are detected and applied without disconnecting existing clients, whenever it's possible. +```sh +ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp -rtsp_transport tcp rtsp://localhost:8554/mystream +``` -2. By overriding configuration parameters with environment variables, in the format `MTX_PARAMNAME`, where `PARAMNAME` is the uppercase name of a parameter. For instance, the `rtspAddress` parameter can be overridden in the following way: +The resulting stream will be available in path `/mystream`. - ``` - MTX_RTSPADDRESS="127.0.0.1:8554" ./mediamtx - ``` +#### GStreamer - Parameters that have array as value can be overriden by setting a comma-separated list. For example: - ``` - MTX_PROTOCOLS="tcp,udp" - ``` +GStreamer can publish a stream to the server in multiple ways (RTSP client, RTMP client, UDP/MPEG-TS, WebRTC with WHIP). The recommended one consists in publishing as a [RTSP client](#rtsp-clients): - Parameters in maps can be overridden by using underscores, in the following way: +```sh +gst-launch-1.0 rtspclientsink name=s location=rtsp://localhost:8554/mystream filesrc location=file.mp4 ! qtdemux name=d d.video_0 ! queue ! s.sink_0 d.audio_0 ! queue ! s.sink_1 +``` - ``` - MTX_PATHS_TEST_SOURCE=rtsp://myurl ./mediamtx - ``` +If the stream is video only: - This method is particularly useful when using Docker; any configuration parameter can be changed by passing environment variables with the `-e` flag: +```sh +gst-launch-1.0 filesrc location=file.mp4 ! qtdemux name=d d.video_0 ! rtspclientsink name=s location=rtsp://localhost:8554/mystream +``` - ``` - docker run --rm -it --network=host -e MTX_PATHS_TEST_SOURCE=rtsp://myurl bluenviron/mediamtx - ``` +The RTSP protocol supports multiple underlying transport protocols, each with its own characteristics (see [RTSP-specific features](#rtsp-specific-features)). You can set the transport protocol by using the `protocols` flag: -3. By using the [HTTP API](#http-api). +```sh +gst-launch-1.0 filesrc location=file.mp4 ! qtdemux name=d d.video_0 ! rtspclientsink protocols=tcp name=s location=rtsp://localhost:8554/mystream +``` -### Authentication +The resulting stream will be available in path `/mystream`. -Edit `mediamtx.yml` and replace everything inside section `paths` with the following content: +#### OBS Studio -```yml -paths: - all: - publishUser: myuser - publishPass: mypass -``` +OBS Studio can publish to the server as a [RTMP client](#rtmp-clients). In `Settings -> Stream` (or in the Auto-configuration Wizard), use the following parameters: -Only publishers that provide both username and password will be able to proceed: +* Service: `Custom...` +* Server: `rtmp://localhost` +* Stream key: `mystream` -``` -ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://myuser:mypass@localhost:8554/mystream -``` +If credentials are in use, use the following parameters: -It's possible to setup authentication for readers too: +* Service: `Custom...` +* Server: `rtmp://localhost` +* Stream key: `mystream?user=myuser&pass=mypass` -```yml -paths: - all: - publishUser: myuser - publishPass: mypass +Save the configuration and click `Start streaming`. - readUser: user - readPass: userpass -``` +If you want to generate a stream that can be read with WebRTC, open `Settings -> Output -> Recording` and use the following parameters: -If storing plain credentials in the configuration file is a security problem, username and passwords can be stored as sha256-hashed strings; a string must be hashed with sha256 and encoded with base64: +* FFmpeg output type: `Output to URL` +* File path or URL: `rtsp://localhost:8554/mystream` +* Container format: `rtsp` +* Check `show all codecs (even if potentically incompatible` +* Video encoder: `h264_nvenc (libx264)` +* Video encoder settings (if any): `bf=0` +* Audio track: `1` +* Audio encoder: `libopus` -``` -echo -n "userpass" | openssl dgst -binary -sha256 | openssl base64 -``` +Then use the button `Start Recording` (instead of `Start Streaming`) to start streaming. -Then stored with the `sha256:` prefix: +Latest versions of OBS Studio can publish to the server with the [WebRTC / WHIP protocol](#webrtc). Use the following parameters: -```yml -paths: - all: - readUser: sha256:j1tsRqDEw9xvq/D7/9tMx6Jh/jMhk3UfjwIB2f1zgMo= - readPass: sha256:BdSWkrdV+ZxFBLUQQY7+7uv9RmiSVA8nrPmjGjJtZQQ= -``` +* Service: `WHIP` +* Server: `http://localhost:8889/mystream/whip` -**WARNING**: enable encryption or use a VPN to ensure that no one is intercepting the credentials. +Save the configuration and click `Start streaming`. -Authentication can be delegated to an external HTTP server: +The resulting stream will be available in path `/mystream`. -```yml -externalAuthenticationURL: http://myauthserver/auth -``` +#### OpenCV -Each time a user needs to be authenticated, the specified URL will be requested with the POST method and this payload: +OpenCV can publish to the server as a [RTSP client](#rtsp-clients). It must be compiled with GStreamer support, by following this procedure: -```json -{ - "ip": "ip", - "user": "user", - "password": "password", - "path": "path", - "protocol": "rtsp|rtmp|hls|webrtc", - "id": "id", - "action": "read|publish", - "query": "query" -} +```sh +sudo apt install -y libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev gstreamer1.0-plugins-ugly gstreamer1.0-rtsp python3-dev python3-numpy +git clone --depth=1 -b 4.5.4 https://github.com/opencv/opencv +cd opencv +mkdir build && cd build +cmake -D CMAKE_INSTALL_PREFIX=/usr -D WITH_GSTREAMER=ON .. +make -j$(nproc) +sudo make install ``` -If the URL returns a status code that begins with `20` (i.e. `200`), authentication is successful, otherwise it fails. - -Please be aware that it's perfectly normal for the authentication server to receive requests with empty users and passwords, i.e.: +You can check that OpenCV has been installed correctly by running: -```json -{ - "user": "", - "password": "", -} +```sh +python3 -c 'import cv2; print(cv2.getBuildInformation())' ``` -This happens because a RTSP client doesn't provide credentials until it is asked to. In order to receive the credentials, the authentication server must reply with status code `401`, then the client will send credentials. +Check that the output contains `GStreamer: YES`. -### Encrypt the configuration +Videos can be published with `VideoWriter`: -The configuration file can be entirely encrypted for security purposes. +```python +import cv2 +import numpy as np +from time import sleep, time -An online encryption tool is [available here](https://play.golang.org/p/rX29jwObNe4). +fps = 15 +width = 800 +height = 600 +colors = [ + (0, 0, 255), + (255, 0, 0), + (0, 255, 0), +] -The encryption procedure is the following: +out = cv2.VideoWriter('appsrc ! videoconvert' + \ + ' ! x264enc speed-preset=ultrafast bitrate=600 key-int-max=' + str(fps * 2) + \ + ' ! video/x-h264,profile=baseline' + \ + ' ! rtspclientsink location=rtsp://localhost:8554/mystream', + cv2.CAP_GSTREAMER, 0, fps, (width, height), True) +if not out.isOpened(): + raise Exception("can't open video writer") -1. NaCL's `crypto_secretbox` function is applied to the content of the configuration. NaCL is a cryptographic library available for [C/C++](https://nacl.cr.yp.to/secretbox.html), [Go](https://pkg.go.dev/golang.org/x/crypto/nacl/secretbox), [C#](https://github.com/somdoron/NaCl.net) and many other languages; +curcolor = 0 +start = time() -2. The string is prefixed with the nonce; +while True: + frame = np.zeros((height, width, 3), np.uint8) -3. The string is encoded with base64. + # create a rectangle + color = colors[curcolor] + curcolor += 1 + curcolor %= len(colors) + for y in range(0, int(frame.shape[0] / 2)): + for x in range(0, int(frame.shape[1] / 2)): + frame[y][x] = color -After performing the encryption, put the base64-encoded result into the configuration file, and launch the server with the `MTX_CONFKEY` variable: + out.write(frame) + print("frame written to the server") + now = time() + diff = (1 / fps) - now - start + if diff > 0: + sleep(diff) + start = now ``` -MTX_CONFKEY=mykey ./mediamtx -``` - -### Proxy mode -_MediaMTX_ is also a proxy, that is usually deployed in one of these scenarios: +The resulting stream will be available in path `/mystream`. -* when there are multiple users that are reading a stream and the bandwidth is limited; the proxy is used to receive the stream once. Users can then connect to the proxy instead of the original source. -* when there's a NAT / firewall between a stream and the users; the proxy is installed on the NAT and makes the stream available to the outside world. +#### Web browsers -Edit `mediamtx.yml` and replace everything inside section `paths` with the following content: +Web browsers can publish a stream to the server by using the [WebRTC protocol](#webrtc). Start the server and open the web page: -```yml -paths: - proxied: - # url of the source stream, in the format rtsp://user:pass@host:port/path - source: rtsp://original-url +``` +http://localhost:8889/mystream/publish ``` -After starting the server, users can connect to `rtsp://localhost:8554/proxied`, instead of connecting to the original url. The server supports any number of source streams, it's enough to add additional entries to the `paths` section: +The resulting stream will be available in path `/mystream`. -```yml -paths: - proxied1: - source: rtsp://url1 +This web page can be embedded into another web page by using an iframe: - proxied2: - source: rtsp://url1 +```html + ``` -It's possible to save bandwidth by enabling the on-demand mode: the stream will be pulled only when at least a client is connected: +For more advanced setups, you can create and serve a custom web page by starting from the [source code of the publish page](internal/core/webrtc_publish_index.html). -```yml -paths: - proxied: - source: rtsp://original-url - sourceOnDemand: yes -``` +### By device -### Remuxing, re-encoding, compression +#### Generic webcam -To change the format, codec or compression of a stream, use _FFmpeg_ or _GStreamer_ together with _MediaMTX_. For instance, to re-encode an existing stream, that is available in the `/original` path, and publish the resulting stream in the `/compressed` path, edit `mediamtx.yml` and replace everything inside section `paths` with the following content: +If the OS is Linux-based, edit `mediamtx.yml` and replace everything inside section `paths` with the following content: ```yml paths: - all: - original: - runOnReady: ffmpeg -i rtsp://localhost:$RTSP_PORT/$MTX_PATH -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k -max_muxing_queue_size 1024 -f rtsp rtsp://localhost:$RTSP_PORT/compressed - runOnReadyRestart: yes + cam: + runOnInit: ffmpeg -f v4l2 -i /dev/video0 -pix_fmt yuv420p -preset ultrafast -b:v 600k -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH + runOnInitRestart: yes ``` -### Save streams to disk - -To save available streams to disk, you can use the `runOnReady` parameter and _FFmpeg_: +If the OS is Windows: ```yml paths: - mypath: - runOnReady: ffmpeg -i rtsp://localhost:$RTSP_PORT/$MTX_PATH -c copy -f segment -strftime 1 -segment_time 60 -segment_format mpegts saved_%Y-%m-%d_%H-%M-%S.ts - runOnReadyRestart: yes + cam: + runOnInit: ffmpeg -f dshow -i video="USB2.0 HD UVC WebCam" -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH + runOnInitRestart: yes ``` -In the configuratio above, streams are saved into TS files, that can be read even if the system crashes, while MP4 files can't. - -### On-demand publishing - -Edit `mediamtx.yml` and replace everything inside section `paths` with the following content: +Where `USB2.0 HD UVC WebCam` is the name of a webcam, that can be obtained with: -```yml -paths: - ondemand: - runOnDemand: ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH - runOnDemandRestart: yes +```sh +ffmpeg -list_devices true -f dshow -i dummy ``` -The command inserted into `runOnDemand` will start only when a client requests the path `ondemand`, therefore the file will start streaming only when requested. +The resulting stream will be available in path `/cam`. -### Start on boot +#### Raspberry Pi Cameras -#### Linux +_MediaMTX_ natively supports the Raspberry Pi Camera, enabling high-quality and low-latency video streaming from the camera to any user, for any purpose. There are a couple of requirements: -Systemd is the service manager used by Ubuntu, Debian and many other Linux distributions, and allows to launch _MediaMTX_ on boot. +1. The server must run on a Raspberry Pi, with Raspberry Pi OS bullseye or newer as operative system. Both 32 bit and 64 bit operative systems are supported. -Download a release bundle from the [release page](https://github.com/bluenviron/mediamtx/releases), unzip it, and move the executable and configuration in the system: +2. Make sure that the legacy camera stack is disabled. Type `sudo raspi-config`, then go to `Interfacing options`, `enable/disable legacy camera support`, choose `no`. Reboot the system. -``` -sudo mv mediamtx /usr/local/bin/ -sudo mv mediamtx.yml /usr/local/etc/ -``` +If you want to run the standard (non-Docker) version of the server: -Create the service: - -``` -sudo tee /etc/systemd/system/mediamtx.service >/dev/null << EOF -[Unit] -Wants=network.target -[Service] -ExecStart=/usr/local/bin/mediamtx /usr/local/etc/mediamtx.yml -[Install] -WantedBy=multi-user.target -EOF -``` - -Enable and start the service: - -``` -sudo systemctl daemon-reload -sudo systemctl enable mediamtx -sudo systemctl start mediamtx -``` - -#### Windows - -Download the [WinSW v2 executable](https://github.com/winsw/winsw/releases/download/v2.11.0/WinSW-x64.exe) and place it into the same folder of `mediamtx.exe`. - -In the same folder, create a file named `WinSW-x64.xml` with this content: - -```xml - - mediamtx - mediamtx - - %BASE%/mediamtx.exe - -``` - -Open a terminal, navigate to the folder and run: - -``` -WinSW-x64 install -``` - -The server is now installed as a system service and will start at boot time. - -### HTTP API - -The server can be queried and controlled with an HTTP API, that must be enabled by setting the `api` parameter in the configuration: - -```yml -api: yes -``` - -The API listens on `apiAddress`, that by default is `127.0.0.1:9997`; for instance, to obtain a list of active paths, run: - -``` -curl http://127.0.0.1:9997/v2/paths/list -``` - -Full documentation of the API is available on the [dedicated site](https://bluenviron.github.io/mediamtx/). - -### Metrics - -A metrics exporter, compatible with [Prometheus](https://prometheus.io/), can be enabled with the parameter `metrics: yes`; then the server can be queried for metrics with Prometheus or with a simple HTTP request: - -``` -wget -qO- localhost:9998/metrics -``` - -Obtaining: - -```ini -# metrics of every path -paths{name="[path_name]",state="[state]"} 1 -paths_bytes_received{name="[path_name]",state="[state]"} 1234 - -# metrics of every HLS muxer -hls_muxers{name="[name]"} 1 -hls_muxers_bytes_sent{name="[name]"} 187 - -# metrics of every RTSP connection -rtsp_conns{id="[id]"} 1 -rtsp_conns_bytes_received{id="[id]"} 1234 -rtsp_conns_bytes_sent{id="[id]"} 187 - -# metrics of every RTSP session -rtsp_sessions{id="[id]",state="idle"} 1 -rtsp_sessions_bytes_received{id="[id]",state="[state]"} 1234 -rtsp_sessions_bytes_sent{id="[id]",state="[state]"} 187 - -# metrics of every RTSPS connection -rtsps_conns{id="[id]"} 1 -rtsps_conns_bytes_received{id="[id]"} 1234 -rtsps_conns_bytes_sent{id="[id]"} 187 - -# metrics of every RTSPS session -rtsps_sessions{id="[id]",state="[state]"} 1 -rtsps_sessions_bytes_received{id="[id]",state="[state]"} 1234 -rtsps_sessions_bytes_sent{id="[id]",state="[state]"} 187 - -# metrics of every RTMP connection -rtmp_conns{id="[id]",state="[state]"} 1 -rtmp_conns_bytes_received{id="[id]",state="[state]"} 1234 -rtmp_conns_bytes_sent{id="[id]",state="[state]"} 187 - -# metrics of every WebRTC session -webrtc_sessions{id="[id]"} 1 -webrtc_sessions_bytes_received{id="[id]",state="[state]"} 1234 -webrtc_sessions_bytes_sent{id="[id]",state="[state]"} 187 -``` - -### pprof - -A performance monitor, compatible with pprof, can be enabled with the parameter `pprof: yes`; then the server can be queried for metrics with pprof-compatible tools, like: - -``` -go tool pprof -text http://localhost:9999/debug/pprof/goroutine -go tool pprof -text http://localhost:9999/debug/pprof/heap -go tool pprof -text http://localhost:9999/debug/pprof/profile?seconds=30 -``` - -### Compile from source - -#### Standard - -Install Go ≥ 1.20, download the repository, open a terminal in it and run: - -```sh -go build . -``` - -The command will produce the `mediamtx` binary. - -#### Raspberry Pi - -The server can be compiled with native support for the Raspberry Pi Camera. Compilation must happen on a Raspberry Pi Device, with the following dependencies: - -* Go ≥ 1.20 -* `libcamera-dev` -* `libfreetype-dev` -* `xxd` -* `patchelf` - -Download the repository, open a terminal in it and run: - -```sh -cd internal/rpicamera/exe -make -cd ../../../ -go build -tags rpicamera . -``` - -The command will produce the `mediamtx` binary. - -#### Compile for all supported platforms - -Compilation for all supported platform can be launched by using: - -```sh -make binaries -``` - -The command will produce tarballs in folder `binaries/`. - -## Publish to the server - -### From a webcam - -To publish the video stream of a generic webcam to the server, edit `mediamtx.yml` and replace everything inside section `paths` with the following content: - -```yml -paths: - cam: - runOnInit: ffmpeg -f v4l2 -i /dev/video0 -pix_fmt yuv420p -preset ultrafast -b:v 600k -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH - runOnInitRestart: yes -``` - -If the platform is Windows: - -```yml -paths: - cam: - runOnInit: ffmpeg -f dshow -i video="USB2.0 HD UVC WebCam" -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH - runOnInitRestart: yes -``` - -Where `USB2.0 HD UVC WebCam` is the name of your webcam, that can be obtained with: - -``` -ffmpeg -list_devices true -f dshow -i dummy -``` - -After starting the server, the webcam can be reached on `rtsp://localhost:8554/cam`. - -### From a Raspberry Pi Camera - -_MediaMTX_ natively support the Raspberry Pi Camera, enabling high-quality and low-latency video streaming from the camera to any user. There are a couple of requirements: - -1. The server must run on a Raspberry Pi, with Raspberry Pi OS bullseye or newer as operative system. Both 32 bit and 64 bit operative systems are supported. - -2. Make sure that the legacy camera stack is disabled. Type `sudo raspi-config`, then go to `Interfacing options`, `enable/disable legacy camera support`, choose `no`. Reboot the system. - -If you want to run the standard (non-containerized) version of the server: - -1. Make sure that the following packages are installed: +1. Make sure that the following packages are installed: * `libcamera0` (at least version 0.0.2) * `libfreetype6` @@ -683,9 +456,11 @@ If you want to run the standard (non-containerized) version of the server: source: rpiCamera ``` -If you want to run the server with Docker, you need to use the `latest-rpi` image (that already contains libcamera) and set some additional flags: +The resulting stream will be available in path `/cam`. -``` +If you want to run the server inside Docker, you need to use the `latest-rpi` image (that already contains libcamera) and launch the container with some additional flags: + +```sh docker run --rm -it \ --network=host \ --privileged \ @@ -695,8 +470,6 @@ docker run --rm -it \ bluenviron/mediamtx:latest-rpi ``` -After starting the server, the camera can be reached on path `/cam` (`http://raspberry-pi:8889/cam`, `http://raspberry-pi:8888/cam`, `rtsp://raspberry-pi:8554/cam` or `rtmp://raspberry-pi:1935/cam`). - Camera settings can be changed by using the `rpiCamera*` parameters: ```yml @@ -747,108 +520,101 @@ paths: cam_with_audio: ``` -Stream with video and audio will be available in path `/cam_with_audio`. +The resulting stream will be available in path `/cam_with_audio`. -### From OBS Studio +### By protocol -OBS Studio can publish to the server by using the RTMP protocol. In `Settings -> Stream` (or in the Auto-configuration Wizard), use the following parameters: +#### WebRTC -* Service: `Custom...` -* Server: `rtmp://localhost` -* Stream key: `mystream` +WebRTC is an API that makes use of a set of protocols and methods to connect two clients together and allow them to exchange real-time media or data streams. You can publish a stream with WebRTC and a web browser by visiting: -If credentials are in use, use the following parameters: +``` +http://localhost:8889/mystream/publish +``` -* Service: `Custom...` -* Server: `rtmp://localhost` -* Stream key: `mystream?user=myuser&pass=mypass` +The resulting stream will be available in path `/mystream`. -If you want to generate a stream that can be read with WebRTC, open `Settings -> Output -> Recording` and use the following parameters: +WHIP is a WebRTC extensions that allows to publish streams by using a URL, without passing through a web page. This allows to use WebRTC as a general purpose streaming protocol. If you are using a software that supports WHIP (for instance, latest versions of OBS Studio), you can publish a stream to the server by using this URL: -* FFmpeg output type: `Output to URL` -* File path or URL: `rtsp://localhost:8554/mystream` -* Container format: `rtsp` -* Check `show all codecs (even if potentically incompatible` -* Video encoder: `h264_nvenc (libx264)` -* Video encoder settings (if any): `bf=0` -* Audio track: `1` -* Audio encoder: `libopus` +``` +http://localhost:8889/mystream/whip +``` -The use the button `Start Recording` (instead of `Start Streaming`) to start streaming. +Depending on the network it may be difficult to establish a connection between server and clients, see [WebRTC-specific features](#webrtc-specific-features) for remediations. -### From OpenCV +#### RTSP clients -To publish a video stream from OpenCV to the server, OpenCV must be compiled with GStreamer support, by following this procedure: +RTSP is a protocol that allows to publish and read streams. It supports different underlying transport protocols and allows to encrypt streams in transit (see [RTSP-specific features](#rtsp-specific-features)). In order to publish a stream with the RTSP protocol, you can use this URL: ``` -sudo apt install -y libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev gstreamer1.0-plugins-ugly gstreamer1.0-rtsp python3-dev python3-numpy -git clone --depth=1 -b 4.5.4 https://github.com/opencv/opencv -cd opencv -mkdir build && cd build -cmake -D CMAKE_INSTALL_PREFIX=/usr -D WITH_GSTREAMER=ON .. -make -j$(nproc) -sudo make install +rtsp://localhost:8554/mystream ``` -You can check that OpenCV has been installed correctly by running: +The resulting stream will be available in path `/mystream`. + +#### RTSP cameras and servers +Most IP cameras expose their video stream by using a RTSP server that is embedded into the camera itself. You can use _MediaMTX_ to connect to one or multiple existing RTSP servers and read their video streams: + +```yml +paths: + proxied: + # url of the source stream, in the format rtsp://user:pass@host:port/path + source: rtsp://original-url ``` -python3 -c 'import cv2; print(cv2.getBuildInformation())' + +The resulting stream will be available in path `/proxied`. + +The server supports any number of source streams (count is just limited by hardware capability) it's enough to add additional entries to the paths section: + +```yml +paths: + proxied1: + source: rtsp://url1 + + proxied2: + source: rtsp://url1 ``` -And verifying that the output contains `GStreamer: YES`. +#### RTMP clients -Videos can be published with `VideoWriter`: +RTMP is a protocol that allows to read and publish streams, but is less versatile and less efficient than RTSP and WebRTC (doesn't support UDP, doesn't support most RTSP codecs, doesn't support feedback mechanism). Streams can be published to the server by using the URL: -```python -import cv2 -import numpy as np -from time import sleep, time +``` +rtmp://localhost/mystream +``` -fps = 15 -width = 800 -height = 600 -colors = [ - (0, 0, 255), - (255, 0, 0), - (0, 255, 0), -] +The resulting stream will be available in path `/mystream`. -out = cv2.VideoWriter('appsrc ! videoconvert' + \ - ' ! x264enc speed-preset=ultrafast bitrate=600 key-int-max=' + str(fps * 2) + \ - ' ! video/x-h264,profile=baseline' + \ - ' ! rtspclientsink location=rtsp://localhost:8554/mystream', - cv2.CAP_GSTREAMER, 0, fps, (width, height), True) -if not out.isOpened(): - raise Exception("can't open video writer") +#### RTMP cameras and servers -curcolor = 0 -start = time() +You can use _MediaMTX_ to connect to one or multiple existing RTMP servers and read their video streams: -while True: - frame = np.zeros((height, width, 3), np.uint8) +```yml +paths: + proxied: + # url of the source stream, in the format rtmp://user:pass@host:port/path + source: rtmp://original-url +``` - # create a rectangle - color = colors[curcolor] - curcolor += 1 - curcolor %= len(colors) - for y in range(0, int(frame.shape[0] / 2)): - for x in range(0, int(frame.shape[1] / 2)): - frame[y][x] = color +The resulting stream will be available in path `/proxied`. - out.write(frame) - print("frame written to the server") +#### HLS cameras and servers - now = time() - diff = (1 / fps) - now - start - if diff > 0: - sleep(diff) - start = now +HLS is a streaming protocol that works by splitting streams into segments, and by serving these segments and a playlist with the HTTP protocol. You can use _MediaMTX_ to connect to one or multiple existing HLS servers and read their video streams: + +```yml +paths: + proxied: + # url of the playlist of the stream, in the format http://user:pass@host:port/path + source: http://original-url/stream/index.m3u8 ``` -### From a UDP stream +The resulting stream will be available in path `/proxied`. -The server supports ingesting UDP/MPEG-TS packets (i.e. MPEG-TS packets sent with UDP). Packets can be unicast, broadcast or multicast. For instance, you can generate a multicast UDP/MPEG-TS stream with: +#### UDP/MPEG-TS + +The server supports ingesting UDP/MPEG-TS packets (i.e. MPEG-TS packets sent with UDP). Packets can be unicast, broadcast or multicast. For instance, you can generate a multicast UDP/MPEG-TS stream with GStreamer: ``` gst-launch-1.0 -v mpegtsmux name=mux alignment=1 ! udpsink host=238.0.0.1 port=1234 \ @@ -864,157 +630,150 @@ paths: source: udp://238.0.0.1:1234 ``` -After starting the server, the stream can be reached on `rtsp://localhost:8554/udp`. +The resulting stream will be available in path `/udp`. -### From the browser +## Read from the server -Open the page into the browser: +### By software -``` -http://localhost:8889/mystream/publish +#### FFmpeg + +FFmpeg can read a stream from the server in multiple ways (RTSP, RTMP, HLS, WebRTC with WHEP). The recommended one consists in reading with [RTSP](#rtsp): + +```sh +ffmpeg -i rtsp://localhost:8554/mystream -c copy output.mp4 ``` -## Read from the server +The RTSP protocol supports multiple underlying transport protocols, each with its own characteristics (see [RTSP-specific features](#rtsp-specific-features)). You can set the transport protocol by using the `rtsp_transport` flag: -### From VLC and Ubuntu +```sh +ffmpeg -rtsp_transport tcp -i rtsp://localhost:8554/mystream -c copy output.mp4 +``` -The VLC shipped with Ubuntu 21.10 doesn't support playing RTSP due to a license issue (see [here](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982299) and [here](https://stackoverflow.com/questions/69766748/cvlc-cannot-play-rtsp-omxplayer-instead-can)). +#### GStreamer -To overcome the issue, remove the default VLC instance and install the snap version: +GStreamer can read a stream from the server in multiple ways (RTSP, RTMP, HLS, WebRTC with WHEP). The recommended one consists in reading with [RTSP](#rtsp): -``` -sudo apt purge -y vlc -snap install vlc +```sh +gst-launch-1.0 rtspsrc location=rtsp://127.0.0.1:8554/mystream latency=0 ! decodebin ! autovideosink ``` -Then use it to read the stream: +The RTSP protocol supports multiple underlying transport protocols, each with its own characteristics (see [RTSP-specific features](#rtsp-specific-features)). You can change the transport protocol by using the `protocols` flag: +```sh +gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://127.0.0.1:8554/mystream latency=0 ! decodebin ! autovideosink ``` -vlc rtsp://localhost:8554/mystream -``` - -## RTSP protocol -### General usage +If encryption is enabled, set `tls-validation-flags` to `0`: -RTSP is a standardized protocol that allows to publish and read streams; in particular, it supports different underlying transport protocols, that are chosen by clients during the handshake with the server: +```sh +gst-launch-1.0 rtspsrc tls-validation-flags=0 location=rtsps://ip:8322/... +``` -* UDP: the most performant, but doesn't work when there's a NAT/firewall between server and clients. It doesn't support encryption. -* UDP-multicast: allows to save bandwidth when clients are all in the same LAN, by sending packets once to a fixed multicast IP. It doesn't support encryption. -* TCP: the most versatile, does support encryption. +#### VLC -The default transport protocol is UDP. To change the transport protocol, you have to tune the configuration of your client of choice. +VLC can read a stream from the server in multiple ways (RTSP, RTMP, HLS). The recommended one consists in reading with [RTSP](#rtsp): -### TCP transport +```sh +vlc --network-caching=50 rtsp://localhost:8554/mystream +``` -The RTSP protocol supports the TCP transport protocol, that allows to receive packets even when there's a NAT/firewall between server and clients, and supports encryption (see [Encryption](#encryption)). +The RTSP protocol supports multiple underlying transport protocols, each with its own characteristics (see [RTSP-specific features](#rtsp-specific-features)). -You can use _FFmpeg_ to publish a stream with the TCP transport protocol: +In order to use the TCP transport protocol, use the `--rtsp_tcp` flag: -``` -ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp -rtsp_transport tcp rtsp://localhost:8554/mystream +```sh +vlc --network-caching=50 --rtsp-tcp rtsp://localhost:8554/mystream ``` -You can use _FFmpeg_ to read that stream with the TCP transport protocol: +In order to use the UDP-multicast transport protocol, append `?vlcmulticast` to the URL: -``` -ffmpeg -rtsp_transport tcp -i rtsp://localhost:8554/mystream -c copy output.mp4 +```sh +vlc --network-caching=50 rtsp://localhost:8554/mystream?vlcmulticast ``` -You can use _GStreamer_ to read that stream with the TCP transport protocol: +You can change the transport protocol by using the `--rtsp_` flag: -``` -gst-launch-1.0 rtspsrc protocols=tcp location=rtsp://localhost:8554/mystream ! fakesink -``` +##### Ubuntu bug -You can use _VLC_ to read that stream with the TCP transport protocol: +The VLC shipped with Ubuntu 21.10 doesn't support playing RTSP due to a license issue (see [here](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=982299) and [here](https://stackoverflow.com/questions/69766748/cvlc-cannot-play-rtsp-omxplayer-instead-can)). To fix the issue, remove the default VLC instance and install the snap version: ``` -vlc --rtsp-tcp rtsp://localhost:8554/mystream +sudo apt purge -y vlc +snap install vlc ``` -### UDP-multicast transport +##### Encrypted streams -The RTSP protocol supports the UDP-multicast transport protocol, that allows a server to send packets once, regardless of the number of connected readers, saving bandwidth. +At the moment VLC doesn't support reading encrypted RTSP streams. However, you can use a proxy like [stunnel](https://www.stunnel.org) or [nginx](https://nginx.org/) to decrypt streams before reading them. -This mode must be requested by readers when handshaking with the server; once a reader has completed a handshake, the server will start sending multicast packets. Other readers will be instructed to read existing multicast packets. When all multicast readers have disconnected from the server, the latter will stop sending multicast packets. +#### Web browsers -If you want to use the UDP-multicast protocol in a Wireless LAN, please be aware that the maximum bitrate supported by multicast is the one that corresponds to the lowest enabled WiFi data rate. For instance, if the 1 Mbps data rate is enabled on your router (and it is on most routers), the maximum bitrate will be 1 Mbps. To increase the maximum bitrate, use a cabled LAN or change your router settings. +Web browsers can read a stream from the server in multiple ways (WebRTC or HLS). -To request and read a stream with UDP-multicast, you can use _FFmpeg_: +You can read a stream by using the [WebRTC protocol](#webrtc-1) by visiting the web page: ``` -ffmpeg -rtsp_transport udp_multicast -i rtsp://localhost:8554/mystream -c copy output.mp4 +http://localhost:8889/mystream ``` -or _GStreamer_: +This web page can be embedded into another web page by using an iframe: -``` -gst-launch-1.0 rtspsrc protocols=udp-mcast location=rtsps://ip:8554/... +```html + ``` -or _VLC_ (append `?vlcmulticast` to the URL): +For more advanced setups, you can create and serve a custom web page by starting from the [source code of the read page](internal/core/webrtc_read_index.html). + +Web browsers can also read a stream with the [HLS protocol](#hls). Latency is higher but there are less problems related to connectivity between server and clients, furthermore the server load can be balanced by using a common HTTP CDN (like CloudFront or Cloudflare), and this allows to handle readers in the order of millions. Visit the web page: ``` -vlc rtsp://localhost:8554/mystream?vlcmulticast +http://localhost:8888/mystream ``` -### Encryption - -Incoming and outgoing RTSP streams can be encrypted with TLS (obtaining the RTSPS protocol). A TLS certificate is needed and can be generated with OpenSSL: +This web page can be embedded into another web page by using an iframe: -``` -openssl genrsa -out server.key 2048 -openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650 +```html + ``` -Edit `mediamtx.yml`, and set the `protocols`, `encryption`, `serverKey` and `serverCert` parameters: +### By protocol -```yml -protocols: [tcp] -encryption: optional -serverKey: server.key -serverCert: server.crt -``` +#### WebRTC -Streams can be published and read with the `rtsps` scheme and the `8322` port: +WebRTC is an API that makes use of a set of protocols and methods to connect two clients together and allow them to exchange real-time media or data streams. You can read a stream with WebRTC and a web browser by visiting: ``` -ffmpeg -i rtsps://ip:8322/... +http://localhost:8889/mystream ``` -If the client is _GStreamer_, disable the certificate validation: +WHEP is a WebRTC extensions that allows to read streams by using a URL, without passing through a web page. This allows to use WebRTC as a general purpose streaming protocol. If you are using a software that supports WHEP, you can read a stream from the server by using this URL: ``` -gst-launch-1.0 rtspsrc tls-validation-flags=0 location=rtsps://ip:8322/... +http://localhost:8889/mystream/whep ``` -At the moment _VLC_ doesn't support reading encrypted RTSP streams. A workaround consists in launching an instance of _MediaMTX_ on the same machine in which _VLC_ is running, using it for reading the encrypted stream with the proxy mode, and reading the proxied stream with _VLC_. +Depending on the network it may be difficult to establish a connection between server and clients, see [WebRTC-specific features](#webrtc-specific-features) for remediations. -### Redirect to another server +#### RTSP -To redirect to another server, use the `redirect` source: +RTSP is a protocol that allows to publish and read streams. It supports different underlying transport protocols and allows to encrypt streams in transit (see [RTSP-specific features](#rtsp-specific-features)). In order to read a stream with the RTSP protocol, you can use this URL: -```yml -paths: - redirected: - source: redirect - sourceRedirect: rtsp://otherurl/otherpath +``` +rtsp://localhost:8554/mystream ``` -### Fallback stream +##### Latency -If no one is publishing to the server, readers can be redirected to a fallback path or URL that is serving a fallback stream: +The RTSP protocol doesn't introduce any latency by itself. Latency is usually introduced by clients, that put frames in a buffer to compensate network fluctuations. In order to decrease latency, the best way consists in tuning the client. For instance, latency can be decreased with VLC by decreasing the Network caching parameter, that is available in the Open network stream dialog or alternatively ca be set with the command line: -```yml -paths: - withfallback: - fallback: /otherpath +``` +vlc --network-caching=50 rtsp://... ``` -### Corrupted frames +##### Corrupted frames -In some scenarios, when reading RTSP from the server, decoded frames can be corrupted or incomplete. This can be caused by multiple reasons: +In some scenarios, when reading from the server with RTSP, decoded frames can be corrupted or incomplete. This can be caused by multiple reasons: * the packet buffer of the server is too small and can't keep up with the stream throughput. A solution consists in increasing its size: @@ -1035,197 +794,399 @@ In some scenarios, when reading RTSP from the server, decoded frames can be corr test: source: rtsp://.. sourceProtocol: tcp - ``` + ``` * The stream throughput is too big to be handled by the network between server and readers. Upgrade the network or decrease the stream bitrate by re-encoding it. -### Decrease latency +#### RTMP -The RTSP protocol doesn't introduce any latency by itself. Latency is usually introduced by clients, that put frames in a buffer to compensate network fluctuations. In order to decrease latency, the best way consists in tuning the client. For instance, latency can be decreased with VLC by decreasing the `Network caching` parameter, that is available in the `Open network stream` dialog or alternatively ca be set with the command line: +RTMP is a protocol that allows to read and publish streams, but is less versatile and less efficient than RTSP and WebRTC ((doesn't support UDP, doesn't support most RTSP codecs, doesn't support feedback mechanism)). Streams can be read from the server by using the URL: ``` -vlc --network-caching=50 rtsp://... +rtmp://localhost/mystream ``` -## RTMP protocol +#### HLS -### General usage +HLS is a protocol that works by splitting streams into segments, and by serving these segments and a playlist with the HTTP protocol. You can use _MediaMTX_ to generate a HLS stream, that is accessible through a web page: -RTMP is a protocol that allows to read and publish streams, but is less versatile and less efficient than RTSP (doesn't support UDP, encryption, doesn't support most RTSP codecs, doesn't support feedback mechanism). It is used when there's need of publishing or reading streams from a software that supports RTMP only (for instance, OBS Studio and DJI drones). +``` +http://localhost:8888/mystream +``` -Streams can be published or read with the RTMP protocol, for instance with _FFmpeg_: +and can also be accessed without using the browsers, by software that supports the HLS protocol (for instance VLC or _MediaMTX_ itself) by using this URL: ``` -ffmpeg -re -stream_loop -1 -i file.ts -c copy -f flv rtmp://localhost/mystream +http://localhost:8888/mystream/index.m3u8 +``` + +Although the server can produce HLS with a variety of video and audio codecs (that are listed at the beginning of the README), not all browsers can read all codecs. You can check what codecs your browser can read by visiting this page: + + + +If you want to support most browsers, you can to re-encode the stream by using the H264 and AAC codecs, for instance by using FFmpeg: + +```sh +ffmpeg -i rtsp://original-source -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k -c:a aac -b:a 160k -f rtsp rtsp://localhost:8554/mystream ``` -or _GStreamer_: +##### LL-HLS + +Low-Latency HLS is a recently standardized variant of the protocol that allows to greatly reduce playback latency. It works by splitting segments into parts, that are served before the segment is complete. LL-HLS is enabled by default. If the stream is not shown correctly, try tuning the hlsPartDuration parameter, for instance: + +```yml +hlsPartDuration: 500ms +``` + +##### Compatibility with Apple devices + +In order to correctly display Low-Latency HLS streams in Safari running on Apple devices (iOS or macOS), a TLS certificate is needed and can be generated with OpenSSL: + +```sh +openssl genrsa -out server.key 2048 +openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650 +``` + +Set the `hlsEncryption`, `hlsServerKey` and `hlsServerCert` parameters in the configuration file: +```yml +hlsEncryption: yes +hlsServerKey: server.key +hlsServerCert: server.crt ``` -gst-launch-1.0 -v flvmux name=s ! rtmpsink location=rtmp://localhost/mystream filesrc location=file.mp4 ! qtdemux name=d d.video_0 ! queue ! s.video d.audio_0 ! queue ! s.audio + +Keep also in mind that not all H264 video streams can be played on Apple Devices due to some intrinsic properties (distance between I-Frames, profile). If the video can't be played correctly, you can either: + +* re-encode it by following instructions in this README +* disable the Low-latency variant of HLS and go back to the legacy variant: + + ```yml + hlsVariant: mpegts + ``` + +##### Latency + +in HLS, latency is introduced since a client must wait for the server to generate segments before downloading them. This latency amounts to 500ms-3s when the low-latency HLS variant is enabled (and it is by default), otherwise amounts to 1-15secs. + +To decrease the latency, you can: + +* try decreasing the hlsPartDuration parameter +* try decreasing the hlsSegmentDuration parameter +* The segment duration is influenced by the interval between the IDR frames of the video track. An IDR frame is a frame that can be decoded independently from the others. The server changes the segment duration in order to include at least one IDR frame into each segment. Therefore, you need to decrease the interval between the IDR frames. This can be done in two ways: + + * if the stream is being hardware-generated (i.e. by a camera), there's usually a setting called Key-Frame Interval in the camera configuration page + * otherwise, the stream must be re-encoded. It's possible to tune the IDR frame interval by using ffmpeg's -g option: + + ```sh + ffmpeg -i rtsp://original-stream -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k -max_muxing_queue_size 1024 -g 30 -f rtsp rtsp://localhost:$RTSP_PORT/compressed + ``` + +## Features + +### Configuration + +All the configuration parameters are listed and commented in the [configuration file](mediamtx.yml). + +There are 3 ways to change the configuration: + +1. By editing the `mediamtx.yml` file, that is + + * included into the release bundle + * available in the root folder of the Docker image (`/mediamtx.yml`); it can be overridden in this way: + + ``` + docker run --rm -it --network=host -v $PWD/mediamtx.yml:/mediamtx.yml bluenviron/mediamtx + ``` + + The configuration can be changed dynamically when the server is running (hot reloading) by writing to the configuration file. Changes are detected and applied without disconnecting existing clients, whenever it's possible. + +2. By overriding configuration parameters with environment variables, in the format `MTX_PARAMNAME`, where `PARAMNAME` is the uppercase name of a parameter. For instance, the `rtspAddress` parameter can be overridden in the following way: + + ``` + MTX_RTSPADDRESS="127.0.0.1:8554" ./mediamtx + ``` + + Parameters that have array as value can be overriden by setting a comma-separated list. For example: + + ``` + MTX_PROTOCOLS="tcp,udp" + ``` + + Parameters in maps can be overridden by using underscores, in the following way: + + ``` + MTX_PATHS_TEST_SOURCE=rtsp://myurl ./mediamtx + ``` + + This method is particularly useful when using Docker; any configuration parameter can be changed by passing environment variables with the `-e` flag: + + ``` + docker run --rm -it --network=host -e MTX_PATHS_TEST_SOURCE=rtsp://myurl bluenviron/mediamtx + ``` + +3. By using the [API](#api). + +### Authentication + +Edit `mediamtx.yml` and replace everything inside section `paths` with the following content: + +```yml +paths: + all: + publishUser: myuser + publishPass: mypass ``` -Credentials can be provided by appending to the URL the `user` and `pass` parameters: +Only publishers that provide both username and password will be able to proceed: ``` -ffmpeg -re -stream_loop -1 -i file.ts -c copy -f flv rtmp://localhost:8554/mystream?user=myuser&pass=mypass +ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://myuser:mypass@localhost:8554/mystream ``` -### Encryption +It's possible to setup authentication for readers too: -RTMP connections can be encrypted with TLS, obtaining the RTMPS protocol. A TLS certificate is needed and can be generated with OpenSSL: +```yml +paths: + all: + publishUser: myuser + publishPass: mypass + readUser: user + readPass: userpass ``` -openssl genrsa -out server.key 2048 -openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650 + +If storing plain credentials in the configuration file is a security problem, username and passwords can be stored as sha256-hashed strings; a string must be hashed with sha256 and encoded with base64: + +``` +echo -n "userpass" | openssl dgst -binary -sha256 | openssl base64 ``` -Edit `mediamtx.yml`, and set the `rtmpEncryption`, `rtmpServerKey` and `rtmpServerCert` parameters: +Then stored with the `sha256:` prefix: ```yml -rtmpEncryption: optional -rtmpServerKey: server.key -rtmpServerCert: server.crt +paths: + all: + readUser: sha256:j1tsRqDEw9xvq/D7/9tMx6Jh/jMhk3UfjwIB2f1zgMo= + readPass: sha256:BdSWkrdV+ZxFBLUQQY7+7uv9RmiSVA8nrPmjGjJtZQQ= +``` + +**WARNING**: enable encryption or use a VPN to ensure that no one is intercepting the credentials in transit. + +Authentication can be delegated to an external HTTP server: + +```yml +externalAuthenticationURL: http://myauthserver/auth ``` -Streams can be published and read with the `rtmps` scheme and the `1937` port: +Each time a user needs to be authenticated, the specified URL will be requested with the POST method and this payload: + +```json +{ + "ip": "ip", + "user": "user", + "password": "password", + "path": "path", + "protocol": "rtsp|rtmp|hls|webrtc", + "id": "id", + "action": "read|publish", + "query": "query" +} +``` + +If the URL returns a status code that begins with `20` (i.e. `200`), authentication is successful, otherwise it fails. + +Please be aware that it's perfectly normal for the authentication server to receive requests with empty users and passwords, i.e.: +```json +{ + "user": "", + "password": "", +} ``` -rtmps://localhost:1937/... -``` - -Please be aware that RTMPS is currently unsupported by _VLC_, _FFmpeg_ and _GStreamer_. However, you can use a proxy like [stunnel](https://www.stunnel.org/) or [nginx](https://nginx.org/) to allow RTMP clients to access RTMPS resources. -## HLS protocol +This happens because a RTSP client doesn't provide credentials until it is asked to. In order to receive the credentials, the authentication server must reply with status code `401`, then the client will send credentials. -### General usage +### Encrypt the configuration -HLS is a protocol that allows to embed live streams into web pages. It works by splitting streams into segments, and by serving these segments with the HTTP protocol. Every stream published to the server can be accessed by visiting: +The configuration file can be entirely encrypted for security purposes. -``` -http://localhost:8888/mystream -``` +An online encryption tool is [available here](https://play.golang.org/p/rX29jwObNe4). -where `mystream` is the name of a stream that is being published. +The encryption procedure is the following: -### Browser support +1. NaCL's `crypto_secretbox` function is applied to the content of the configuration. NaCL is a cryptographic library available for [C/C++](https://nacl.cr.yp.to/secretbox.html), [Go](https://pkg.go.dev/golang.org/x/crypto/nacl/secretbox), [C#](https://github.com/somdoron/NaCl.net) and many other languages; -Although the server can produce HLS with a variety of video and audio codecs (that are listed at the beginning of the README), not all browsers can read all codecs. You can check what codecs your browser can read by visiting this page: +2. The string is prefixed with the nonce; -https://jsfiddle.net/4msrhudv +3. The string is encoded with base64. -If you want to increase the compatibility of the stream in order to support most browsers, you have to re-encode it by using the H264 and AAC codecs, for instance by using _FFmpeg_: +After performing the encryption, put the base64-encoded result into the configuration file, and launch the server with the `MTX_CONFKEY` variable: ``` -ffmpeg -i rtsp://original-source -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k -c:a aac -b:a 160k -f rtsp rtsp://localhost:8554/mystream +MTX_CONFKEY=mykey ./mediamtx ``` -### Embedding +### Remuxing, re-encoding, compression -The simples way to embed a HLS stream into a web page consists in using an iframe tag: +To change the format, codec or compression of a stream, use _FFmpeg_ or _GStreamer_ together with _MediaMTX_. For instance, to re-encode an existing stream, that is available in the `/original` path, and publish the resulting stream in the `/compressed` path, edit `mediamtx.yml` and replace everything inside section `paths` with the following content: -```html - +```yml +paths: + all: + original: + runOnReady: ffmpeg -i rtsp://localhost:$RTSP_PORT/$MTX_PATH -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k -max_muxing_queue_size 1024 -f rtsp rtsp://localhost:$RTSP_PORT/compressed + runOnReadyRestart: yes ``` -For more advanced options, you can create and serve a custom web page by starting from the [source code of the default page](internal/core/hls_index.html). +### Save streams to disk -### Low-Latency variant +To save available streams to disk, you can use the `runOnReady` parameter and _FFmpeg_: -Low-Latency HLS is a [recently standardized](https://datatracker.ietf.org/doc/html/draft-pantos-hls-rfc8216bis) variant of the protocol that allows to greatly reduce playback latency. It works by splitting segments into parts, that are served before the segment is complete. +```yml +paths: + mypath: + runOnReady: ffmpeg -i rtsp://localhost:$RTSP_PORT/$MTX_PATH -c copy -f segment -strftime 1 -segment_time 60 -segment_format mpegts saved_%Y-%m-%d_%H-%M-%S.ts + runOnReadyRestart: yes +``` -LL-HLS is enabled by default. Every stream published to the server can be read with LL-HLS by visiting: +In the configuratio above, streams are saved into TS files, that can be read even if the system crashes, while MP4 files can't. -``` -https://localhost:8888/mystream -``` +### On-demand publishing -If the stream is not shown correctly, try tuning the `hlsPartDuration` parameter, for instance: +Edit `mediamtx.yml` and replace everything inside section `paths` with the following content: ```yml -hlsPartDuration: 500ms +paths: + ondemand: + runOnDemand: ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://localhost:$RTSP_PORT/$MTX_PATH + runOnDemandRestart: yes ``` -### HLS on Apple devices +The command inserted into `runOnDemand` will start only when a client requests the path `ondemand`, therefore the file will start streaming only when requested. -In order to correctly display Low-Latency HLS streams in Safari running on Apple devices (iOS or macOS), a TLS certificate is needed and can be generated with OpenSSL: +### Start on boot -``` -openssl genrsa -out server.key 2048 -openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650 +#### Linux* + +Systemd is the service manager used by Ubuntu, Debian and many other Linux distributions, and allows to launch _MediaMTX_ on boot. + +Download a release bundle from the [release page](https://github.com/bluenviron/mediamtx/releases), unzip it, and move the executable and configuration in the system: + +```sh +sudo mv mediamtx /usr/local/bin/ +sudo mv mediamtx.yml /usr/local/etc/ ``` -Set the `hlsEncryption`, `hlsServerKey` and `hlsServerCert` parameters in the configuration file: +Create the service: -```yml -hlsEncryption: yes -hlsServerKey: server.key -hlsServerCert: server.crt +```sh +sudo tee /etc/systemd/system/mediamtx.service >/dev/null << EOF +[Unit] +Wants=network.target +[Service] +ExecStart=/usr/local/bin/mediamtx /usr/local/etc/mediamtx.yml +[Install] +WantedBy=multi-user.target +EOF ``` -Keep also in mind that not all H264 video streams can be played on Apple Devices due to some intrinsic properties (distance between I-Frames, profile). If the video can't be played correctly, you can either: +Enable and start the service: -* re-encode it by following the [guide](#remuxing-re-encoding-compression) +```sh +sudo systemctl daemon-reload +sudo systemctl enable mediamtx +sudo systemctl start mediamtx +``` -* disable the Low-latency variant of HLS and go back to the legacy variant: +#### Windows* - ```yml - hlsVariant: mpegts - ``` +Download the [WinSW v2 executable](https://github.com/winsw/winsw/releases/download/v2.11.0/WinSW-x64.exe) and place it into the same folder of `mediamtx.exe`. -### Decrease latency +In the same folder, create a file named `WinSW-x64.xml` with this content: -in HLS, latency is introduced since a client must wait for the server to generate segments before downloading them. This latency amounts to 500ms-3s when the low-latency HLS variant is enabled (and it is by default), otherwise amounts to 1-15secs. +```xml + + mediamtx + mediamtx + + %BASE%/mediamtx.exe + +``` -To decrease the latency, you can: +Open a terminal, navigate to the folder and run: -* try decreasing the `hlsPartDuration` parameter; +``` +WinSW-x64 install +``` -* try decreasing the `hlsSegmentDuration` parameter; +The server is now installed as a system service and will start at boot time. -* The segment duration is influenced by the interval between the IDR frames of the video track. An IDR frame is a frame that can be decoded independently from the others. The server changes the segment duration in order to include at least one IDR frame into each segment. Therefore, you need to decrease the interval between the IDR frames. This can be done in two ways: +### RTSP-specific features - * if the stream is being hardware-generated (i.e. by a camera), there's usually a setting called _Key-Frame Interval_ in the camera configuration page +#### Transport protocols - * otherwise, the stream must be re-encoded. It's possible to tune the IDR frame interval by using ffmpeg's `-g` option: +The RTSP protocol supports different underlying transport protocols, that are chosen by clients during the handshake with the server: - ``` - ffmpeg -i rtsp://original-stream -pix_fmt yuv420p -c:v libx264 -preset ultrafast -b:v 600k -max_muxing_queue_size 1024 -g 30 -f rtsp rtsp://localhost:$RTSP_PORT/compressed - ``` +* UDP: the most performant, but doesn't work when there's a NAT/firewall between server and clients. It doesn't support encryption. +* UDP-multicast: allows to save bandwidth when clients are all in the same LAN, by sending packets once to a fixed multicast IP. It doesn't support encryption. +* TCP: the most versatile, does support encryption. -## WebRTC protocol +The default transport protocol is UDP. To change the transport protocol, you have to tune the configuration of your client of choice. -### General usage +#### Encryption -You can publish a stream from the browser to the server with WebRTC by visiting: +Incoming and outgoing RTSP streams can be encrypted with TLS (obtaining the RTSPS protocol). A TLS certificate is needed and can be generated with OpenSSL: +```sh +openssl genrsa -out server.key 2048 +openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650 ``` -http://localhost:8889/mystream/publish + +Edit `mediamtx.yml`, and set the `protocols`, `encryption`, `serverKey` and serverCert parameters: + +```yml +protocols: [tcp] +encryption: optional +serverKey: server.key +serverCert: server.crt ``` -You can read a stream from the browser with WebRTC by visiting: +Streams can be published and read with the `rtsps` scheme and the `8322` port: ``` -http://localhost:8889/mystream +rtsps://localhost:8322/mystream ``` -### WHIP and WHEP +### RTMP-specific features -WHIP and WHEP are two WebRTC extensions that allow to publish and read streams with WebRTC without passing through a web page. This allows to use WebRTC as a general purpose streaming protocol. +#### Encryption -If you are using a software that supports WHIP, you can publish a stream to the server by using this WHIP URL: +RTMP connections can be encrypted with TLS, obtaining the RTMPS protocol. A TLS certificate is needed and can be generated with OpenSSL: +```yml +openssl genrsa -out server.key 2048 +openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650 ``` -http://localhost:8889/mystream/whip + +Edit mediamtx.yml, and set the `rtmpEncryption`, `rtmpServerKey` and `rtmpServerCert` parameters: + +```yml +rtmpEncryption: optional +rtmpServerKey: server.key +rtmpServerCert: server.crt ``` -If you are using a software that supports WHEP, you can read a stream from the server by using this WHEP URL: +Streams can be published and read with the rtmps scheme and the 1937 port: ``` -http://localhost:8889/mystream/whep +rtmps://localhost:1937/... ``` -### Usage inside a container or behind a NAT +Be aware that RTMPS is currently unsupported by all major players. However, you can use a proxy like [stunnel](https://www.stunnel.org) or [nginx](https://nginx.org/) to decrypt streams before reading them. + +### WebRTC-specific features + +#### 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 (the browser and the server) to establish a connection (WebRTC/ICE connection). @@ -1240,7 +1201,7 @@ webrtcICEUDPMuxAddress: :8189 The NAT / container must then be configured in order to route all incoming UDP packets on port 8189 to the server. If you're using Docker, this can be achieved with the flag: -``` +```sh docker run --rm -it \ -p 8189:8189/udp .... @@ -1256,16 +1217,16 @@ webrtcICEHostNAT1To1IPs: [192.168.x.x] webrtcICETCPPMuxAddress: :8189 ``` -The NAT / container must then be configured in order to redirect all incoming TCP packets on port 8189 to the server. If you're using Docker, this can be achieved with the flag: +The NAT / container must then be configured in order to redirect all incoming TCP packets on port 8189 to the server. If you're using Docker, this can be achieved with the flag: -``` +```sh docker run --rm -it \ -p 8189:8189 .... bluenviron/mediamtx ``` -Finally, if none of these methods work, 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: +Finally, if none of these methods work, you can force all WebRTC/ICE connections to pass through a TURN server, like coturn, that must be configured externally. The server address and credentials must be set in the configuration file: ```yml webrtcICEServers2: @@ -1274,9 +1235,9 @@ webrtcICEServers2: password: password ``` -Where `user` and `pass` are the username and password of the server. Note that `port` is not optional. +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: @@ -1285,22 +1246,131 @@ 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. -### Embedding +### API -The simples way to embed a WebRTC stream into a web page consists in using an iframe tag: +The server can be queried and controlled with its API, that must be enabled by setting the `api` parameter in the configuration: -```html - +```yml +api: yes +``` + +The API listens on `apiAddress`, that by default is `127.0.0.1:9997`; for instance, to obtain a list of active paths, run: + +``` +curl http://127.0.0.1:9997/v2/paths/list +``` + +Full documentation of the API is available on the [dedicated site](https://bluenviron.github.io/mediamtx/). + +### Metrics + +A metrics exporter, compatible with [Prometheus](https://prometheus.io/), can be enabled with the parameter `metrics: yes`; then the server can be queried for metrics with Prometheus or with a simple HTTP request: + +``` +curl localhost:9998/metrics +``` + +Obtaining: + +```ini +# metrics of every path +paths{name="[path_name]",state="[state]"} 1 +paths_bytes_received{name="[path_name]",state="[state]"} 1234 + +# metrics of every HLS muxer +hls_muxers{name="[name]"} 1 +hls_muxers_bytes_sent{name="[name]"} 187 + +# metrics of every RTSP connection +rtsp_conns{id="[id]"} 1 +rtsp_conns_bytes_received{id="[id]"} 1234 +rtsp_conns_bytes_sent{id="[id]"} 187 + +# metrics of every RTSP session +rtsp_sessions{id="[id]",state="idle"} 1 +rtsp_sessions_bytes_received{id="[id]",state="[state]"} 1234 +rtsp_sessions_bytes_sent{id="[id]",state="[state]"} 187 + +# metrics of every RTSPS connection +rtsps_conns{id="[id]"} 1 +rtsps_conns_bytes_received{id="[id]"} 1234 +rtsps_conns_bytes_sent{id="[id]"} 187 + +# metrics of every RTSPS session +rtsps_sessions{id="[id]",state="[state]"} 1 +rtsps_sessions_bytes_received{id="[id]",state="[state]"} 1234 +rtsps_sessions_bytes_sent{id="[id]",state="[state]"} 187 + +# metrics of every RTMP connection +rtmp_conns{id="[id]",state="[state]"} 1 +rtmp_conns_bytes_received{id="[id]",state="[state]"} 1234 +rtmp_conns_bytes_sent{id="[id]",state="[state]"} 187 + +# metrics of every WebRTC session +webrtc_sessions{id="[id]"} 1 +webrtc_sessions_bytes_received{id="[id]",state="[state]"} 1234 +webrtc_sessions_bytes_sent{id="[id]",state="[state]"} 187 +``` + +### pprof + +A performance monitor, compatible with pprof, can be enabled with the parameter `pprof: yes`; then the server can be queried for metrics with pprof-compatible tools, like: + +``` +go tool pprof -text http://localhost:9999/debug/pprof/goroutine +go tool pprof -text http://localhost:9999/debug/pprof/heap +go tool pprof -text http://localhost:9999/debug/pprof/profile?seconds=30 +``` + +## Compile from source + +### Standard + +Install Go ≥ 1.20, download the repository, open a terminal in it and run: + +```sh +go build . +``` + +The command will produce the `mediamtx` binary. + +### Raspberry Pi + +The server can be compiled with native support for the Raspberry Pi Camera. Compilation must be performed on a Raspberry Pi, with the following dependencies: + +* Go ≥ 1.20 +* `libcamera-dev` +* `libfreetype-dev` +* `xxd` +* `patchelf` + +Download the repository, open a terminal in it and run: + +```sh +cd internal/rpicamera/exe +make +cd ../../../ +go build -tags rpicamera . +``` + +The command will produce the `mediamtx` binary. + +### Compile for all supported platforms + +Install Docker and launch: + +```sh +make binaries ``` -For more advanced options, you can create and serve a custom web page by starting from the [source code of the default read page](internal/core/webrtc_read_index.html) and [source code of the publish page](internal/core/webrtc_publish_index.html). +The command will produce tarballs in folder `binaries/`. ## Standards * RTSP - * [RTSP/RTP/RTCP standards](https://github.com/bluenviron/gortsplib#standards) + * [RTSP / RTP / RTCP standards](https://github.com/bluenviron/gortsplib#standards) * HLS * [HLS standards](https://github.com/bluenviron/gohlslib#standards) @@ -1320,12 +1390,11 @@ For more advanced options, you can create and serve a custom web page by startin * Other * [Golang project layout](https://github.com/golang-standards/project-layout) -## Links - -Related projects +## Related projects * [gortsplib (RTSP library used internally)](https://github.com/bluenviron/gortsplib) * [gohlslib (HLS library used internally)](https://github.com/bluenviron/gohlslib) +* [mediacommon (codecs and formats library used internally)](https://github.com/bluenviron/mediacommon) * [pion/webrtc (WebRTC library used internally)](https://github.com/pion/webrtc) * [pion/sdp (SDP library used internally)](https://github.com/pion/sdp) * [pion/rtp (RTP library used internally)](https://github.com/pion/rtp) diff --git a/logo.png b/logo.png index 5effe08b..56390831 100644 Binary files a/logo.png and b/logo.png differ