{"id":12947,"date":"2026-09-09T07:35:00","date_gmt":"2026-09-09T05:35:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=12947"},"modified":"2026-10-24T06:04:55","modified_gmt":"2026-10-24T04:04:55","slug":"tutorial-building-and-testing-rtsp-stream-urls-for-ip-cameras","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/cctv\/tutorials-en-cctv\/tutorial-building-and-testing-rtsp-stream-urls-for-ip-cameras\/","title":{"rendered":"Tutorial: Building and Testing RTSP Stream URLs for IP Cameras"},"content":{"rendered":"

An RTSP address identifies a media service and the requested stream. RTSP controls the session; video is commonly carried in RTP packets. Camera support, paths, authentication and transport options depend on the model and firmware. A successful connection is only the first check, not proof of reliable recording.<\/p>\n

1. Identify the actual server<\/h2>\n

The host can be a camera, recorder, Protect console or restreamer. The address must point to the component that serves this particular stream. A camera account is not automatically a recorder account. Port 554 is the conventional RTSP default, but the configured port is decisive.<\/p>\n

\"RTSP:
A status code is evidence, not a complete diagnosis<\/figcaption><\/figure>\n

The following invented address illustrates the components. Credentials in the URL are a client convention that needs compatibility checks; separate credential fields are preferable where supported.<\/p>\n

rtsp:\/\/viewer:Example%402026@192.0.2.10:554\/Streaming\/Channels\/102\nscheme | user:password       | host      | port | path<\/code><\/pre>\n
Neither host, credentials nor port is identical across cameras. IPv6 literals require brackets, for example rtsp:\/\/[2001:db8::10]:554\/stream<\/code>. A query string can select additional settings. Its exact meaning comes from the device documentation.<\/p>\n
2. Obtain the path from the device or its documentation<\/h2>\n\n\n\n\n\n\n\n\n
Device family<\/th>\nIllustrative path<\/th>\n<\/tr>\n<\/thead>\n
Hikvision<\/td>\n\/Streaming\/channels\/101 \u00b7 \/Streaming\/channels\/102<\/code><\/td>\n<\/tr>\n
Amcrest IP<\/td>\n\/cam\/realmonitor?channel=1&subtype=0<\/code><\/td>\n<\/tr>\n
Reolink<\/td>\n\/Preview_01_main \u00b7 \/Preview_01_sub<\/code><\/td>\n<\/tr>\n
Axis<\/td>\n\/axis-media\/media.amp?streamprofile=PROFILE<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
These are examples, not universal addresses. In the Hikvision pattern, the channel precedes a two-digit stream suffix: channel 12 with stream 02 becomes 1202. A channel does not universally identify a physical lens. An Axis resolution parameter requests a supported size; it does not inherently name a fixed \u201csubstream\u201d.<\/p>\n
For a compatible ONVIF Media service, GetProfiles<\/code> identifies available media profiles and GetStreamUri<\/code> requests a URI for the selected profile and transport. Authentication, reachability and client compatibility still need testing. A returned private address is not automatically reachable through a different network.<\/p>\n
UniFi Protect\u2019s official port reference lists both RTSPS on 7441 and RTSP on 7447. The earlier claim that Protect always refuses plain RTSP was too broad. The configured, supported export address and console version take priority over guessed URL conversions.<\/p>\n
3. Encode credentials without confusing encoding with encryption<\/h2>\n
Reserved characters can change how a URL is parsed. Username and password components should be encoded separately: @ \u2192 %40<\/code>, \/ \u2192 %2F<\/code>, # \u2192 %23<\/code>, ? \u2192 %3F<\/code>, % \u2192 %25<\/code> and space \u2192 %20<\/code>. Encoding a colon as %3A<\/code> avoids ambiguity, but a colon inside user information does not universally terminate that field. An already encoded value must not be encoded again.<\/p>\n
Percent-encoding is reversible and provides no secrecy. Digest authentication does not send the password itself as plaintext, but that does not encrypt the video or guarantee that every camera uses Digest. Basic authentication without transport protection exposes recoverable credentials. RTSPS protects the control connection with TLS; media protection depends on the negotiated transport.<\/p>\n
A dedicated viewing account limits privileges. URLs and aliases remain sensitive in process arguments, logs and configuration. Local encoding avoids sending a real password to an online encoder.<\/p>\n
4. Run a bounded metadata check<\/h2>\n
This Bash example needs ffprobe and GNU timeout<\/code>. It reads the URL without terminal echo, requests interleaved TCP transport and reports the first video stream\u2019s metadata. The local URL input does not become a literal history command, but the expanded argument can still be visible to permitted process inspection and may appear in errors.<\/p>\n
IFS= read -r -s -p 'RTSP URL: ' RTSP_URL\nprintf '\\n'\ntimeout -k 2s 15s ffprobe -v error \\\n  -rtsp_transport tcp -timeout 5000000 \\\n  -select_streams v:0 \\\n  -show_entries stream=codec_name,width,height,avg_frame_rate \\\n  -of json "$RTSP_URL"\nprobe_status=$?\nunset RTSP_URL\nprintf 'Exit status: %s\\n' "$probe_status"<\/code><\/pre>\n
-timeout 5000000<\/code> limits RTSP socket I\/O waits to five seconds in the tested FFmpeg 7.1.5. The outer command sets a separate 15-second wall-clock limit and a further two-second kill grace period. GNU timeout normally returns 124 on expiry. There is no promise that a valid camera responds within two seconds.<\/p>\n
A codec and size in JSON confirm useful metadata, not sustained packet delivery or successful decoding. A missing video entry is not a successful video test. A player and a representative recording test should then check actual frames, motion, day\/night changes and reconnect behavior.<\/p>\n\n\n\n\n\n\n
401 Unauthorized<\/th>\nAuthentication is requested or failed. An initial challenge can be normal; path correctness is not established.<\/td>\n<\/tr>\n
404 Not Found<\/th>\nThe requested resource was not found. This alone does not prove that credentials were accepted.<\/td>\n<\/tr>\n
Connection refused<\/th>\nThe endpoint or an intermediary rejected the TCP connection. The target, configured port, service and firewall need checking.<\/td>\n<\/tr>\n
Timeout<\/th>\nThe particular connection or read did not finish in time. Investigation needs the stage, transport, route, load and logs.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n
TCP interleaving can avoid separate UDP media ports. It cannot repair a wrong path, unsupported codec, missing permission or lost connectivity. UDP can also be appropriate; packet loss and buffering determine the practical latency trade-off.<\/p>\n
5. Separate detection and recording deliberately<\/h2>\n
Frigate allows a detect<\/code> input and a record<\/code> input. This fragment illustrates the roles for a confirmed Hikvision-style path. The complete configuration also needs the relevant recording settings and validation for the installed Frigate version.<\/p>\n
cameras:\n  driveway:\n    ffmpeg:\n      inputs:\n        - path: "rtsp:\/\/{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@192.0.2.10:554\/Streaming\/Channels\/102"\n          input_args: preset-rtsp-generic\n          roles: [detect]\n        - path: "rtsp:\/\/{FRIGATE_RTSP_USER}:{FRIGATE_RTSP_PASSWORD}@192.0.2.10:554\/Streaming\/Channels\/101"\n          input_args: preset-rtsp-generic\n          roles: [record]<\/code><\/pre>\n
Environment substitution is supported only in documented configuration fields. Here the password variable contains the URL-encoded value. A protected environment file reduces accidental sharing; runtime values are not a secret vault.<\/p>\n
A smaller detection stream can reduce decoding load, but distant targets may become too small. With the same field of view, reducing width from 3840 to 640 pixels reduces linear pixel density to one sixth. If an idealized target spans 172.8 pixels initially, the scaled image contains only 28.8 pixels. Cropping, perspective and encoding can change the practical result; this is not a detection guarantee.<\/p>\n
\n
Questions and answers<\/h2>\n
Does go2rtc always need only one camera connection?<\/h3>\n
Several consumers can share one upstream stream. Different main and substream sources can still require separate upstream connections. Device session limits vary by model; a universal two- or four-session limit is not justified.<\/p>\n
Does a DHCP reservation solve every later failure?<\/h3>\n
A reservation helps keep an address predictable. Address conflicts, routing, power, firmware, service settings and account changes remain possible. A router restart does not necessarily change a lease.<\/p>\n
What causes a stream to stop after some time?<\/h3>\n
Logs should distinguish transport loss, session expiry and client or device restarts. A supported RTSP keepalive and the server\u2019s session timeout matter; missing RTCP feedback is not the sole explanation. Automatic reconnect can restore service without identifying the original cause.<\/p>\n<\/div>\n
\n
Sources<\/h2>\n