rtsp-simple-serverは、ユーザーがさまざまなプロトコルを介してライブビデオおよびオーディオストリームを公開、読み取り、およびプロキシできるようにする、すぐに使用できるゼロ依存のサーバーおよびプロキシです。
議定書 | 形容 | バリアント | 著す | 読む | プロキシ |
---|---|---|---|---|---|
ティッカー | ストリームを公開して読むための最速の方法 | RTSP, RTSPS | |||
ティッカー | レガシーソフトウェアとの対話を可能にします | RTMP, RTMPS | |||
ティッカー | ストリームをWebページに埋め込むことができます | 低レイテンシー HLS、標準 HLS |
顔立ち:
リリース ページからプリコンパイル済みバイナリをダウンロードして抽出します。
サーバーを起動します。
./rtsp-simple-server
イメージをダウンロードして起動します。
docker run --rm -it --network=host aler9/rtsp-simple-server
Dockerはルーティング上の理由でUDPパケットの送信元ポートを変更でき、これによりサーバーはパケットの作成者を見つけることができないため、フラグは必須です。この問題は、UDP トランスポートプロトコルを無効にすることで回避できます。
--network=host
docker run --rm -it -e RTSP_PROTOCOLS=tcp -p 8554:8554 -p 1935:1935 -p 8888:8888 aler9/rtsp-simple-server
Docker イメージには FFmpeg が含まれていないことに注意してください。外部コマンドなどに FFmpeg を使用する必要がある場合は、こちらの手順に従って、rtsp-simple-server と FFmpeg の両方を含む Docker イメージをビルドする必要があります。
ストリームを公開します。たとえば、FFmpegを使用してビデオ/オーディオファイルを公開できます。
ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://localhost:8554/mystream
または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
他のハードウェア/ソフトウェアから公開するには、「サーバーに公開する」セクションを参照してください。
ストリームを開きます。たとえば、VLCでストリームを開くことができます。
vlc rtsp://localhost:8554/mystream
またはGStreamer:
gst-play-1.0 rtsp://localhost:8554/mystream
または FFmpeg:
ffmpeg -i rtsp://localhost:8554/mystream -c copy output.mp4
すべての構成パラメーターが構成ファイルにリストされ、コメント化されます。
構成を変更するには、次の 3 つの方法があります。
ファイルを編集することで、つまり
rtsp-simple-server.yml
リリースバンドルに含まれています
Docker イメージのルート フォルダーで使用可能 ();これは、次の方法でオーバーライドできます。
/rtsp-simple-server.yml
docker run --rm -it --network=host -v $PWD/rtsp-simple-server.yml:/rtsp-simple-server.yml aler9/rtsp-simple-server
構成は、構成ファイルに書き込むことによって、サーバーの実行中 (ホット・リロード) に動的に変更できます。可能な場合は常に、既存のクライアントを切断することなく変更が検出され、適用されます。
構成パラメーターを環境変数でオーバーライドする。ここで、 はパラメーターの大文字の名前です。たとえば、パラメーターは次の方法でオーバーライドできます。
RTSP_PARAMNAME
PARAMNAME
rtspAddress
RTSP_RTSPADDRESS="127.0.0.1:8554" ./rtsp-simple-server
値として配列を持つパラメーターは、コンマ区切りのリストを設定することでオーバーライドできます。例えば:
RTSP_PROTOCOLS="tcp,udp"
マップ内のパラメーターは、次の方法でアンダースコアを使用してオーバーライドできます。
RTSP_PATHS_TEST_SOURCE=rtsp://myurl ./rtsp-simple-server
このメソッドは、Docker を使用する場合に特に便利です。構成パラメーターは、フラグを指定して環境変数を渡すことで変更できます。
-e
docker run --rm -it --network=host -e RTSP_PATHS_TEST_SOURCE=rtsp://myurl aler9/rtsp-simple-server
HTTP API を使用する。
セクション内のすべてを編集し、次のコンテンツに置き換えます。
rtsp-simple-server.yml
paths
paths:
all:
publishUser: myuser
publishPass: mypass
ユーザー名とパスワードの両方を提供するサイト運営者のみが続行できます。
ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://myuser:mypass@localhost:8554/mystream
リーダーの認証を設定することもできます。
paths:
all:
publishUser: myuser
publishPass: mypass
readUser: user
readPass: userpass
プレーンな資格情報を設定ファイルに格納することがセキュリティ上の問題である場合は、ユーザ名とパスワードを sha256 ハッシュ文字列として格納できます。文字列はSHA256でハッシュし、base64でエンコードする必要があります。
echo -n "userpass" | openssl dgst -binary -sha256 | openssl base64
次に、プレフィックスで格納されます。
sha256:
paths:
all:
readUser: sha256:j1tsRqDEw9xvq/D7/9tMx6Jh/jMhk3UfjwIB2f1zgMo=
readPass: sha256:BdSWkrdV+ZxFBLUQQY7+7uv9RmiSVA8nrPmjGjJtZQQ=
警告:暗号化を有効にするか、VPNを使用して、誰も資格情報を傍受していないことを確認してください。
認証は外部 HTTP サーバーに委任できます。
externalAuthenticationURL: http://myauthserver/auth
ユーザーを認証する必要があるたびに、指定されたURLがPOSTメソッドと次のペイロードで要求されます。
{
"ip": "ip",
"user": "user",
"password": "password",
"path": "path",
"action": "read|publish"
}
URL が (つまり、) で始まるステータス コードを返す場合は認証に成功し、それ以外の場合は失敗します。
20
200
認証サーバーが空のユーザーとパスワードを含む要求を受信することは完全に正常であることに注意してください。
{
"user": "",
"password": "",
}
これは、RTSP クライアントが求められるまで資格情報を提供しないために発生します。資格情報を受信するには、認証サーバーはステータスコードで応答する必要があり、クライアントは資格情報を送信します。
401
構成ファイルは、セキュリティ上の理由から完全に暗号化できます。
オンライン暗号化ツールはこちらから入手できます。
暗号化の手順は次のとおりです。
NaCLの機能は、構成の内容に適用されます。NaCLは、C / C ++、Go、C#、および他の多くの言語で利用できる暗号化ライブラリです。
crypto_secretbox
文字列の先頭には nonce が付きます。
文字列は base64 でエンコードされます。
暗号化を実行した後、base64でエンコードされた結果を構成ファイルに入れ、変数を使用してサーバーを起動します。
RTSP_CONFKEY
RTSP_CONFKEY=mykey ./rtsp-simple-server
RTSP-simple-Server もプロキシであり、通常は次のいずれかのシナリオで展開されます。
セクション内のすべてを編集し、次のコンテンツに置き換えます。
rtsp-simple-server.yml
paths
paths:
proxied:
# url of the source stream, in the format rtsp://user:pass@host:port/path
source: rtsp://original-url
サーバを起動すると、ユーザは元の URL に接続する代わりに に接続できます。サーバーは任意の数のソースストリームをサポートしているため、セクションにエントリを追加するだけで十分です。
rtsp://localhost:8554/proxied
paths
paths:
proxied1:
source: rtsp://url1
proxied2:
source: rtsp://url1
オンデマンドモードを有効にすることで帯域幅を節約できます:ストリームは、少なくともクライアントが接続されている場合にのみプルされます。
paths:
proxied:
source: rtsp://original-url
sourceOnDemand: yes
ストリームのフォーマット、コーデック、または圧縮を変更するには、FFmpeg または GStreamer を rtsp-simple-server と一緒に使用します。たとえば、パスで使用可能な既存のストリームを再エンコードし、結果のストリームをパスに公開するには、セクション内のすべてのものを編集して次のコンテンツに置き換えます。
/original
/compressed
rtsp-simple-server.yml
paths
paths:
all:
original:
runOnReady: ffmpeg -i rtsp://localhost:$RTSP_PORT/$RTSP_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
使用可能なストリームをディスクに保存するには、パラメーターと FFmpeg を使用できます。
runOnReady
paths:
all:
original:
runOnReady: ffmpeg -i rtsp://localhost:$RTSP_PORT/$RTSP_PATH -c copy -f segment -strftime 1 -segment_time 60 -segment_format mpegts saved_%Y-%m-%d_%H-%M-%S.ts
runOnReadyRestart: yes
構成例では、ストリームは TS ファイルに保存され、システムがクラッシュした場合でも読み取ることができますが、MP4 ファイルは読み取ることができません。
セクション内のすべてを編集し、次のコンテンツに置き換えます。
rtsp-simple-server.yml
paths
paths:
ondemand:
runOnDemand: ffmpeg -re -stream_loop -1 -i file.ts -c copy -f rtsp rtsp://localhost:$RTSP_PORT/$RTSP_PATH
runOnDemandRestart: yes
に挿入されたコマンドは、クライアントがパスを要求したときにのみ開始されるため、ファイルは要求された場合にのみストリーミングを開始します。
runOnDemand
ondemand
systemd は Ubuntu, Debian および他の多くの Linux ディストリビューションで使用されるサービスマネージャであり、起動時に rtsp-simple-server を起動することができます。
リリースページからリリースバンドルをダウンロードして解凍し、システム内の実行可能ファイルと設定を移動します。
sudo mv rtsp-simple-server /usr/local/bin/ sudo mv rtsp-simple-server.yml /usr/local/etc/
サービスを作成します。
sudo tee /etc/systemd/system/rtsp-simple-server.service >/dev/null << EOF [Unit] Wants=network.target [Service] ExecStart=/usr/local/bin/rtsp-simple-server /usr/local/etc/rtsp-simple-server.yml [Install] WantedBy=multi-user.target EOF
サービスを有効にして開始します。
sudo systemctl enable rtsp-simple-server sudo systemctl start rtsp-simple-server
WinSW v2 実行可能ファイルをダウンロードし、の同じフォルダーに配置します。
rtsp-simple-server.exe
同じフォルダーに、次の内容の名前のファイルを作成します。
WinSW-x64.xml
<service>
<id>rtsp-simple-server</id>
<name>rtsp-simple-server</name>
<description></description>
<executable>%BASE%/rtsp-simple-server.exe</executable>
</service>
ターミナルを開き、フォルダに移動して次のコマンドを実行します。
WinSW-x64 install
これで、サーバーはシステムサービスとしてインストールされ、ブート時に起動します。
サーバーは HTTP API を使用して照会および制御できますが、構成でパラメーターを設定することで有効にする必要があります。
api
api: yes
API は をリッスンしますが、デフォルトでは です。たとえば、アクティブなパスのリストを取得するには、次のコマンドを実行します。
apiAddress
127.0.0.1:9997
curl http://127.0.0.1:9997/v1/paths/list
APIの完全なドキュメントは、専用サイトで入手できます。
プロメテウスと互換性のあるメトリックエクスポーターは、パラメーターを使用して有効にできます。次に、Prometheusまたは単純なHTTPリクエストを使用して、サーバーにメトリックを照会できます。
metrics: yes
wget -qO- localhost:9998/metrics
入手:
# metrics of every path
paths{name="[path_name]",state="[state]"} 1
paths_bytes_received{name="[path_name]",state="[state]"} 1234
# 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 HLS muxer
hls_muxers{name="[name]"} 1
hls_muxers_bytes_sent{name="[name]"} 187
pprofと互換性のあるパフォーマンスモニターは、パラメーターを使用して有効にできます。次に、次のようなpprof互換ツールを使用してサーバーにメトリックを照会できます。
pprof: yes
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
Go 1.18をインストールし、リポジトリをダウンロードし、その中のターミナルを開いて実行します。
go run .
サポートされているすべてのプラットフォームのコンパイルは、次を使用して起動できます。
make binaries
ラズベリーパイカメラのサポートでコンパイルして実行するには:
cd internal/rpicamera/exe
make
cd ../../../
go build -tags rpicamera
./rtsp-simple-server
汎用Webカメラのビデオストリームをサーバーに公開するには、セクション内のすべてを編集して、次のコンテンツに置き換えます。
rtsp-simple-server.yml
paths
paths:
cam:
runOnInit: ffmpeg -f v4l2 -i /dev/video0 -pix_fmt yuv420p -preset ultrafast -b:v 600k -f rtsp rtsp://localhost:$RTSP_PORT/$RTSP_PATH
runOnInitRestart: yes
プラットフォームが Windows の場合:
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/$RTSP_PATH
runOnInitRestart: yes
あなたのウェブカメラの名前はどこにありますか、それは以下で得ることができます:
USB2.0 HD UVC WebCam
ffmpeg -list_devices true -f dshow -i dummy
サーバーを起動すると、 で Web カメラに到達できます。
rtsp://localhost:8554/cam
rtsp-simple-serverはラズベリーパイカメラをネイティブにサポートしており、カメラからすべてのユーザーへの高品質で低遅延のビデオストリーミングを可能にします。いくつかの前提条件があります。
サーバーは、オペレーティングシステムとしてRaspberry Pi OSブルズアイ以降を搭載したRaspberry Piで実行する必要があります。32ビットと64ビットの両方のオペレーティングシステムがサポートされています。
従来のカメラスタックが無効になっていることを確認します。と入力し、 に移動し、 を選択します。システムを再起動します。
sudo raspi-config
Interfacing options
enable/disable legacy camera support
no
サーバーの標準 (コンテナー化されていない) バージョンを実行する場合:
パッケージのバージョンが 少なくとも であることを確認してください 、それ以外の場合は でアップグレードします。
libcamera0
0.0.2
sudo apt update && sudo apt install libcamera0
サーバーの実行可能ファイルをダウンロードします。64ビットバージョンのオペレーティングシステムを使用している場合は、必ずバリアントを選択してください。
arm64
セクション内のすべてを編集し、次のコンテンツに置き換えます。
rtsp-simple-server.yml
paths
paths:
cam:
source: rpiCamera
Dockerでサーバーを実行する場合は、イメージ(すでにlibcameraが含まれている)を使用し、いくつかの追加のフラグを設定する必要があります。
latest-rpi
docker run --rm -it \ --network=host \ --privileged \ --tmpfs /dev/shm:exec \ -v /run/udev:/run/udev:ro \ -e RTSP_PATHS_CAM_SOURCE=rpiCamera \ aler9/rtsp-simple-server:latest-rpi
サーバーを起動すると、カメラまたは に到達できます。
rtsp://raspberry-pi:8554/cam
http://raspberry-pi:8888/cam
カメラの設定は、次のパラメータを使用して変更できます。
rpiCamera*
paths:
cam:
source: rpiCamera
rpiCameraWidth: 1920
rpiCameraHeight: 1080
使用可能なすべてのパラメーターは、サンプル構成ファイルに一覧表示されます。
OBS Studio は、RTMP プロトコルを使用してサーバーに公開できます。(または自動構成ウィザード) で、次のパラメーターを使用します。
Settings -> Stream
Custom...
rtmp://localhost
mystream
資格情報が使用されている場合は、次のパラメーターを使用します。
Custom...
rtmp://localhost
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 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
Videos can 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=ultrafast bitrate=600 key-int-max=40' + \
' ! 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)
The VLC shipped with Ubuntu 21.10 doesn't support playing RTSP due to a license issue (see here and here).
To overcome the issue, remove the default VLC instance and install the snap version:
sudo apt purge -y vlc snap install vlc
Then use it to read the stream:
vlc rtsp://localhost:8554/mystream
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:
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 -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 location=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.
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.
To request and read a stream with UDP-multicast, you can use FFmpeg:
ffmpeg -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:8554/...
or VLC (append to the URL):
?vlcmulticast
vlc rtsp://localhost:8554/mystream?vlcmulticast
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:
openssl genrsa -out server.key 2048 openssl req -new -x509 -sha256 -key server.key -out server.crt -days 3650
Edit , and set the , , and parameters:
rtsp-simple-server.yml
protocols
encryption
serverKey
serverCert
protocols: [tcp]
encryption: optional
serverKey: server.key
serverCert: server.crt
Streams can be published and read with the scheme and the port:
rtsps
8322
ffmpeg -i rtsps://ip:8322/...
If the client is GStreamer, disable the certificate validation:
gst-launch-1.0 rtspsrc tls-validation-flags=0 location=rtsps://ip:8322/...
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 source:
redirect
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 keep up with 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
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 and parameters:
user
pass
ffmpeg -re -stream_loop -1 -i file.ts -c copy -f flv rtmp://localhost:8554/mystream?user=myuser&pass=mypass
RTMP connections can be encrypted with TLS, obtaining the RTMPS protocol. A 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 , and set the , and parameters:
rtsp-simple-server.yml
rtmpEncryption
rtmpServerKey
rtmpServerCert
rtmpEncryption: optional
rtmpServerKey: server.key
rtmpServerCert: server.crt
Streams can be published and read with the scheme and the port:
rtmps
1937
rtmps://localhost:1937/...
Please be aware that RTMPS is currently unsupported by VLC, FFmpeg and GStreamer. However, you can use a proxy like stunnel or nginx to allow RTMP clients to access RTMPS resources.
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:
http://localhost:8888/mystream
where is the name of a stream that is being published.
mystream
Please be aware that HLS only supports a single H264 video track and a single AAC audio track due to limitations of most browsers. If you want to use HLS with streams that use other codecs, you have to re-encode them, for instance by using FFmpeg:
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
The simples way to embed a live stream into a web page consists in using an iframe tag:
<iframe src="http://rtsp-simple-server-ip:8888/mystream" scrolling="no"></iframe>
Alternatively you can create a video tag that points directly to the stream playlist:
<video src="http://localhost:8888/mystream/index.m3u8"></video>
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. You can find a working example by looking at the source code of the HLS muxer.
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 disabled by default. To enable it, a 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
Set the , , and parameters in the configuration file:
hlsVariant
hlsEncryption
hlsServerKey
hlsServerCert
hlsVariant: lowLatency
hlsEncryption: yes
hlsServerKey: server.key
hlsServerCert: server.crt
Every stream published to the server can be read with LL-HLS by visiting:
https://localhost:8888/mystream
If the stream is not shown correctly, try tuning the parameter, for instance:
hlsPartDuration
hlsPartDuration: 500ms
in HLS, latency is introduced since a client must wait for the server to generate segments before downloading them. This latency amounts to 1-15secs depending on the duration of each segment, and to 500ms-3s if the Low-Latency variant is enabled.
To decrease the latency, you can:
enable the Low-Latency variant of the HLS protocol, as explained in the previous section;
if Low-latency is enabled, try decreasing the parameter;
hlsPartDuration
try decreasing the parameter;
hlsSegmentDuration
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:
ストリームがハードウェアで生成されている場合(つまり、カメラによって生成されている場合)、通常、カメラ構成ページにキーフレーム間隔と呼ばれる設定があります。
それ以外の場合は、ストリームを再エンコードする必要があります。ffmpegのオプションを使用してIDRフレーム間隔を調整することができます。
-g
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
関連プロジェクト
スタンダーズ