From 1987572b67715315666338efdd5127f8e559a342 Mon Sep 17 00:00:00 2001
From: aler9 <46489434+aler9@users.noreply.github.com>
Date: Sat, 7 Aug 2021 19:31:09 +0200
Subject: [PATCH] update readme

---
 README.md | 68 +++++++++++++++++++++++++------------------------------
 1 file changed, 31 insertions(+), 37 deletions(-)

diff --git a/README.md b/README.md
index 37f8b09a..e7c7d30b 100644
--- a/README.md
+++ b/README.md
@@ -55,8 +55,8 @@ Plus:
   * [Redirect to another server](#redirect-to-another-server)
   * [Fallback stream](#fallback-stream)
   * [Start on boot with systemd](#start-on-boot-with-systemd)
-  * [Monitoring](#monitoring)
   * [Corrupted frames](#corrupted-frames)
+  * [Monitoring](#monitoring)
   * [HTTP API](#http-api)
   * [Command-line usage](#command-line-usage)
   * [Compile and run from source](#compile-and-run-from-source)
@@ -466,17 +466,42 @@ sudo systemctl enable rtsp-simple-server
 sudo systemctl start rtsp-simple-server
 ```
 
-### Monitoring
+### Corrupted frames
 
-There are multiple ways to monitor the server usage over time:
+In some scenarios, the server can send incomplete or corrupted frames. 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:
+
+  ```yml
+  readBufferCount: 1024
+  ```
+
+* The stream throughput is too big and the stream can't be sent correctly with the UDP stream protocol. 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:
+
+  ```yml
+  protocols: [tcp]
+  ```
 
-* The current number of clients, publishers and readers is printed in each log line; for instance, the line:
+  In case the source is a camera:
 
+  ```yml
+  paths:
+    test:
+      source: rtsp://..
+      sourceProtocol: tcp
   ```
-  2020/01/01 00:00:00 [3/2] [conn 127.0.0.1:44428] OPTION
+
+* 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:
+
+  ```yml
+  readBufferSize: 8192
   ```
 
-  means that there are 3 publishers and 2 readers.
+### Monitoring
+
+There are multiple ways to monitor the server usage over time:
+
+* Use the [HTTP API](#http-api), described below.
 
 * 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:
 
@@ -512,37 +537,6 @@ There are multiple ways to monitor the server usage over time:
   go tool pprof -text http://localhost:9999/debug/pprof/profile?seconds=30
   ```
 
-### Corrupted frames
-
-In some scenarios, the server can send incomplete or corrupted frames. 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:
-
-  ```yml
-  readBufferCount: 1024
-  ```
-
-* The stream throughput is too big and the stream can't be sent correctly with the UDP stream protocol. 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:
-
-  ```yml
-  protocols: [tcp]
-  ```
-
-  In case the source is a camera:
-
-  ```yml
-  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:
-
-  ```yml
-  readBufferSize: 8192
-  ```
-
 ### 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: