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 through various protocols:
protocol | description | publish | read | proxy |
---|---|---|---|---|
RTSP | fastest way to publish and read streams | ✔️ | ✔️ | ✔️ |
RTMP | allows to interact with legacy software | ✔️ | ✔️ | ✔️ |
HLS | allows to embed streams into a web page | ❌ | ✔️ | ✔️ |
Features:
- Publish live streams to the server
- Read live streams from the server
- Act as a proxy and serve streams from other servers or cameras, always or on-demand
- Each stream can have multiple video and audio tracks, encoded with any codec, including H264, H265, VP8, VP9, MPEG2, MP3, AAC, Opus, PCM, JPEG
- Streams are automatically converted from a protocol to another. For instance, it's possible to publish a stream with RTSP and read it with HLS
- Compatible with Linux, Windows and macOS, does not require any dependency or interpreter, it's a single executable
Plus:
- Serve multiple streams at once in separate paths
- Authenticate readers and publishers
- Query and control the server through an HTTP API
- Read Prometheus-compatible metrics
- Redirect readers to other RTSP servers (load balancing)
- Run custom commands when clients connect, disconnect, read or publish streams
- Reload the configuration without disconnecting existing clients (hot reloading)
- Installation
- Basic usage
- General FAQs
- Publish to the server
- RTSP protocol FAQs
- RTMP protocol FAQs
- HLS protocol FAQs
- Links
-
Download and extract a precompiled binary from the release page.
-
Start the server:
./rtsp-simple-server
Download and launch the image:
docker run --rm -it --network=host aler9/rtsp-simple-server
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 server to find out the author of the packets. This issue can be avoided by disabling the UDP transport protocol:
docker run --rm -it -e RTSP_PROTOCOLS=tcp -p 8554:8554 -p 1935:1935 -p 8888:8888 aler9/rtsp-simple-server
Please keep in mind that the Docker image doesn't include FFmpeg. if you need to use FFmpeg for a custom command or anything else, you need to build a Docker image that contains both rtsp-simple-server and FFmpeg, by following instructions here.
-
Publish a stream. For instance, you can publish a video/audio file with FFmpeg:
ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://localhost:8554/mystream
or GStreamer:
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 section.
-
Open the stream. For instance, you can open the stream with VLC:
vlc rtsp://localhost:8554/mystream
or GStreamer:
gst-play-1.0 rtsp://localhost:8554/mystream
or FFmpeg:
ffmpeg -i rtsp://localhost:8554/mystream -c copy output.mp4
All the configuration parameters are listed and commented in the configuration file.
There are 3 ways to change the configuration:
-
By editing the
rtsp-simple-server.yml
file, that is-
included into the release bundle
-
available in the root folder of the Docker image (
/rtsp-simple-server.yml
); it can be overridden in this way:docker run --rm -it --network=host -v $PWD/rtsp-simple-server.yml:/rtsp-simple-server.yml aler9/rtsp-simple-server
The configuration can be changed dinamically 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.
-
-
By overriding configuration parameters with environment variables, in the format
RTSP_PARAMNAME
, wherePARAMNAME
is the uppercase name of a parameter. For instance, thertspAddress
parameter can be overridden in the following way:RTSP_RTSPADDRESS="127.0.0.1:8554" ./rtsp-simple-server
Parameters in maps can be overridden by using underscores, in the following way:
RTSP_PATHS_TEST_SOURCE=rtsp://myurl ./rtsp-simple-server
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 RTSP_PATHS_TEST_SOURCE=rtsp://myurl aler9/rtsp-simple-server
-
By using the HTTP API.
Edit rtsp-simple-server.yml
and replace everything inside section paths
with the following content:
paths:
all:
publishUser: myuser
publishPass: mypass
Only publishers that provide both username and password will be able to proceed:
ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://myuser:mypass@localhost:8554/mystream
It's possible to setup authentication for readers too:
paths:
all:
publishUser: myuser
publishPass: mypass
readUser: user
readPass: userpass
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
Then stored with the sha256:
prefix:
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.
The configuration file can be entirely encrypted for security purposes.
An online encryption tool is available here.
The encryption procedure is the following:
-
NaCL's
crypto_secretbox
function is applied to the content of the configuration. NaCL is a cryptographic library available for C/C++, Go, C# and many other languages; -
The string is prefixed with the nonce;
-
The string is encoded with base64.
After performing the encryption, put the base64-encoded result into the configuration file, and launch the server with the RTSP_CONFKEY
variable:
RTSP_CONFKEY=mykey ./rtsp-simple-server
rtsp-simple-server is also a proxy, that is usually deployed in one of these scenarios:
- 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.
Edit rtsp-simple-server.yml
and replace everything inside section paths
with the following content:
paths:
proxied:
# url of the source stream, in the format rtsp://user:pass@host:port/path
source: rtsp://original-url
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:
paths:
proxied1:
source: rtsp://url1
proxied2:
source: rtsp://url1
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:
paths:
proxied:
source: rtsp://original-url
sourceOnDemand: yes
To change the format, codec or compression of a stream, use FFmpeg or Gstreamer together with rtsp-simple-server. 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 rtsp-simple-server.yml
and replace everything inside section paths
with the following content:
paths:
all:
original:
runOnPublish: ffmpeg -i rtsp://localhost:$RTSP_PORT/$RTSP_PATH -c:v libx264 -preset ultrafast -b:v 500k -max_muxing_queue_size 1024 -f rtsp rtsp://localhost:$RTSP_PORT/compressed
runOnPublishRestart: yes
To Save published videos to disk, put an FFmpeg command inside runOnPublish
:
paths:
all:
original:
runOnPublish: ffmpeg -i rtsp://localhost:$RTSP_PORT/$RTSP_PATH -c copy -f segment -strftime 1 -segment_time 60 -segment_format mp4 saved_%Y-%m-%d_%H-%M-%S.mp4
runOnPublishRestart: yes
Edit rtsp-simple-server.yml
and replace everything inside section paths
with the following content:
paths:
ondemand:
runOnDemand: ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://localhost:$RTSP_PORT/$RTSP_PATH
runOnDemandRestart: yes
The command inserted into runOnDemand
will start only when a client requests the path ondemand
, therefore the file will start streaming only when requested.
Systemd is the service manager used by Ubuntu, Debian and many other Linux distributions, and allows to launch rtsp-simple-server on boot.
Download a release bundle from the release page, unzip it, and move the executable and configuration in the system:
sudo mv rtsp-simple-server /usr/local/bin/
sudo mv rtsp-simple-server.yml /usr/local/etc/
Create the service:
sudo tee /etc/systemd/system/rtsp-simple-server.service >/dev/null << EOF
[Unit]
After=network.target
[Service]
ExecStart=/usr/local/bin/rtsp-simple-server /usr/local/etc/rtsp-simple-server.yml
[Install]
WantedBy=multi-user.target
EOF
Enable and start the service:
sudo systemctl enable rtsp-simple-server
sudo systemctl start rtsp-simple-server
The server can be queried and controlled with an HTTP API, that must be enabled by setting the api
parameter in the configuration:
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/v1/paths/list
Full documentation of the API is available on the dedicated site.
A metrics exporter, compatible with Prometheus, 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:
paths{name="<path_name>",state="ready"} 1
rtsp_sessions{state="idle"} 0
rtsp_sessions{state="read"} 0
rtsp_sessions{state="publish"} 1
rtsps_sessions{state="idle"} 0
rtsps_sessions{state="read"} 0
rtsps_sessions{state="publish"} 0
rtmp_conns{state="idle"} 0
rtmp_conns{state="read"} 0
rtmp_conns{state="publish"} 1
hls_muxers{name="<name>"} 1
where:
paths{name="<path_name>",state="ready"} 1
is replicated for every path and shows the name and state of every pathrtsp_sessions{state="idle"}
is the count of RTSP sessions that are idlertsp_sessions{state="read"}
is the count of RTSP sessions that are readingrtsp_sessions{state="publish"}
is the counf ot RTSP sessions that are publishingrtsps_sessions{state="idle"}
is the count of RTSPS sessions that are idlertsps_sessions{state="read"}
is the count of RTSPS sessions that are readingrtsps_sessions{state="publish"}
is the counf ot RTSPS sessions that are publishingrtmp_conns{state="idle"}
is the count of RTMP connections that are idlertmp_conns{state="read"}
is the count of RTMP connections that are readingrtmp_conns{state="publish"}
is the count of RTMP connections that are publishinghls_muxers{name="<name>"}
is replicated for every HLS muxer and shows the name and state of every HLS muxer
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
Install Go 1.17, download the repository, open a terminal in it and run:
go run .
You can perform the entire operation inside Docker:
make run
To publish the video stream of a generic webcam to the server, edit rtsp-simple-server.yml
and replace everything inside section paths
with the following content:
paths:
cam:
runOnInit: ffmpeg -f v4l2 -i /dev/video0 -c:v libx264 -preset ultrafast -tune zerolatency -b:v 600k -f rtsp rtsp://localhost:$RTSP_PORT/$RTSP_PATH
runOnInitRestart: yes
If the platform is Windows:
paths:
cam:
runOnInit: ffmpeg -f dshow -i video="USB2.0 HD UVC WebCam" -c:v libx264 -preset ultrafast -tune zerolatency -b:v 600k -f rtsp rtsp://localhost:$RTSP_PORT/$RTSP_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
.
To publish the video stream of a Raspberry Pi Camera to the server, install a couple of dependencies:
-
Gstreamer and h264parse:
sudo apt install -y gstreamer1.0-tools gstreamer1.0-rtsp gstreamer1.0-plugins-bad
-
gst-rpicamsrc, by following instruction here
Then edit rtsp-simple-server.yml
and replace everything inside section paths
with the following content:
paths:
cam:
runOnInit: gst-launch-1.0 rpicamsrc preview=false bitrate=2000000 keyframe-interval=50 ! video/x-h264,width=1920,height=1080,framerate=25/1 ! h264parse ! rtspclientsink location=rtsp://localhost:$RTSP_PORT/$RTSP_PATH
runOnInitRestart: yes
After starting the server, the camera is available on rtsp://localhost:8554/cam
.
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:
- Service:
Custom...
- Server:
rtmp://localhost
- Stream key:
mystream
If credentials are in use, use the following parameters:
- Service:
Custom...
- Server:
rtmp://localhost
- Stream key:
mystream?user=myuser&pass=mypass
To publish a video stream from OpenCV to the server, OpenCV must be compiled with GStreamer support, by following this procedure:
sudo apt install -y libgstreamer1.0-dev libgstreamer-plugins-base1.0-dev
git clone --depth=1 -b 4.5.4 https://github.com/opencv/opencv
cd opencv
mkdir build && cd build
cmake -D WITH_GSTREAMER=ON ..
make -j$(nproc)
sudo make install
Videos can then be published with VideoWriter
:
import cv2
import numpy as np
from time import sleep
fps = 20
width = 800
height = 600
out = cv2.VideoWriter('appsrc ! videoconvert' + \
' ! x264enc speed-preset=veryfast tune=zerolatency bitrate=800' + \
' ! 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")
while True:
frame = np.zeros((height, width, 3), np.uint8)
# create a red rectangle
for y in range(0, int(frame.shape[0] / 2)):
for x in range(0, int(frame.shape[1] / 2)):
frame[y][x] = (0, 0, 255)
out.write(frame)
print("frame written to the server")
sleep(1 / fps)
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:
- 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.
The default transport protocol is UDP. To change the transport protocol, you have to tune the configuration of your client of choice.
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).
You can use FFmpeg to publish a stream with the TCP transport protocol:
ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp -rtsp_transport tcp rtsp://localhost:8554/mystream
You can use FFmpeg to read that stream with the TCP transport protocol:
ffmpeg -re -rtsp_transport tcp -i rtsp://localhost:8554/mystream -c copy output.mp4
You can use Gstreamer to read that stream with the TCP transport protocol:
gst-launch-1.0 rtspsrc protocols=tcp rtsp://localhost:8554/mystream ! fakesink
You can use VLC to read that stream with the TCP transport protocol:
vlc --rtsp-tcp rtsp://localhost:8554/mystream
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.
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.
To request and read a stream with UDP-multicast, you can use FFmpeg:
ffmpeg -re -rtsp_transport udp_multicast -i rtsp://localhost:8554/mystream -c copy output.mp4
or GStreamer:
gst-launch-1.0 rtspsrc protocols=udp-mcast location=rtsps://ip:8555/...
or VLC (append ?vlcmulticast
to the URL):
vlc rtsp://localhost:8554/mystream?vlcmulticast
Incoming and outgoing RTSP streams can be encrypted with TLS (obtaining the RTSPS protocol). A self-signed TLS certificate is needed and can be generated with openSSL:
openssl genrsa -out server.key 2048
openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650
Edit rtsp-simple-server.yml
, and set the protocols
, encryption
, serverKey
and serverCert
parameters:
protocols: [tcp]
encryption: optional
serverKey: server.key
serverCert: server.crt
Streams can then be published and read with the rtsps
scheme and the 8555
port:
ffmpeg -i rtsps://ip:8555/...
If the client is GStreamer, disable the certificate validation:
gst-launch-1.0 rtspsrc tls-validation-flags=0 location=rtsps://ip:8555/...
At the moment VLC doesn't support reading encrypted RTSP streams. A workaround consists in launching an instance of rtsp-simple-server 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.
To redirect to another server, use the redirect
source:
paths:
redirected:
source: redirect
sourceRedirect: rtsp://otherurl/otherpath
If no one is publishing to the server, readers can be redirected to a fallback path or URL that is serving a fallback stream:
paths:
withfallback:
fallback: /otherpath
In some scenarios, when reading RTSP from the server, 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 handle the stream throughput. A solution consists in increasing its size:
readBufferCount: 1024
-
The stream throughput is too big and the stream can't be sent correctly with the UDP transport. UDP is more performant, faster and more efficient than TCP, but doesn't have a retransmission mechanism, that is needed in case of streams that need a large bandwidth. A solution consists in switching to TCP:
protocols: [tcp]
In case the source is a camera:
paths: test: source: rtsp://.. sourceProtocol: tcp
-
the software that is generating the stream (a camera or FFmpeg) is generating non-conformant RTP packets, with a payload bigger than the maximum allowed (that is 1460 due to the UDP MTU). A solution consists in increasing the buffer size:
readBufferSize: 8192
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 only RTMP (for instance, OBS Studio and DJI drones).
At the moment, only the H264 and AAC codecs can be used with the RTMP protocol.
Streams can be published or read with the RTMP protocol, for instance with FFmpeg:
ffmpeg -re -stream_loop -1 -i file.ts -c copy -f flv rtmp://localhost/mystream
or GStreamer:
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
Credentials can be provided by appending to the URL the user
and pass
parameters:
ffmpeg -re -stream_loop -1 -i file.ts -c copy -f flv rtmp://localhost:8554/mystream?user=myuser&pass=mypass
HLS is a media format that allows to embed live streams into web pages. Every stream published to the server can be accessed with a web browser by visiting:
http://localhost:8888/mystream
where mystream
is the name of a stream that is being published.
The direct HLS URL, that can be used to read the stream with players (VLC) or Javascript libraries (hls.js) can be obtained by appending /index.m3u8
:
http://localhost:8888/mystream/index.m3u8
Please note that most browsers don't support HLS directly (except Safari); a Javascript library, like hls.js, must be used to load the stream.
HLS works by splitting the stream into segments and serving these segments with the standard HTTP protocol. Delay is introduced since a client must wait for the server to generate segments before downloading them. This delay amounts to 1-15 seconds depending on some factors:
- the number of segments
- the duration of each segment
To decrease the delay, it's possible to decrease the number of segments by editing the hlsSegmentCount
parameter (decreasing stream stability) and decrease the duration of each segment. The duration of each segments depends on the hlsSegmentDuration
, but also on the original stream, since the duration is prolonged to include at least one IDR frame (complete frame that can be decoded independently from the others) into each segment. Therefore, the stream must be tuned by either acting on the original hardware (for instance, there's a setting Key-Frame Interval in most cameras, that must be reduced) or re-encoding the stream, setting a low IDR frame interval (-g
option):
ffmpeg -i rtsp://original-stream -c:v libx264 -preset ultrafast -b:v 500k -max_muxing_queue_size 1024 -g 30 -f rtsp rtsp://localhost:$RTSP_PORT/compressed
Related projects
- https://github.com/aler9/gortsplib (RTSP library used internally)
- https://github.com/pion/sdp (SDP library used internally)
- https://github.com/pion/rtcp (RTCP library used internally)
- https://github.com/pion/rtp (RTP library used internally)
- https://github.com/notedit/rtmp (RTMP library used internally)
- https://github.com/flaviostutz/rtsp-relay
IETF Standards
- RTSP 1.0 https://tools.ietf.org/html/rfc2326
- RTSP 2.0 https://tools.ietf.org/html/rfc7826
- HTTP 1.1 https://tools.ietf.org/html/rfc2616
Conventions