> For the complete documentation index, see [llms.txt](https://portal-integracao.intelbras.com.br/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://portal-integracao.intelbras.com.br/defense-ia-and-lite/defense-ia-english/implementation-tips/implementation-guide-rtsp-for-web-front-ends.md). # Implementation guide: RTSP for web front ends Architecture for displaying RTSP in browsers without exposing credentials. Covers low-latency HTTPS delivery, WebRTC and HTTP-FLV/MPEG-TS, requirements, security, and operations. **Goal:** Display RTSP camera video in a web application **without exposing RTSP credentials or URLs to the front end**, with **low latency** and **HTTPS delivery**. *** ## Architecture overview #### **Option A — RTSP → WebRTC (recommended for latency under 1–2 seconds)** **Pros:** Very low latency, from sub-second to \~1–2 seconds. Supports modern browsers. Uses no playlists or segments. **Cons:** Requires signaling and ICE with STUN/TURN. Infrastructure is slightly more complex. ```mermaid --- config: look: neo theme: neo layout: dagre --- flowchart TB A["RTSP camera"] L_A_B_0@-- RTSP (internal network) --> B["MediaMTX
Media gateway"] B L_B_C_0@-- WHEP / WebRTC --> C["Java back end
Authentication / Tokenization / Proxy"] C L_C_D_0@-- Temporary URL / token --> D["Angular app
WebRTC player"] D L_D_E_0@--> E["Browser user"] A@{ shape: rect} B@{ shape: rect} C@{ shape: rect} D@{ shape: rect} E@{ shape: tag-proc} style A stroke:#00C853 style B stroke:#00C853 style C stroke:#00C853 style D stroke:#00C853 style E stroke:#00C853,stroke-width:1px,stroke-dasharray: 0 L_A_B_0@{ animation: slow } L_B_C_0@{ animation: slow } L_C_D_0@{ animation: slow } L_D_E_0@{ animation: slow } ``` #### Option B — RTSP → HTTP-FLV or MPEG-TS (through MSE) ```mermaid --- config: look: neo theme: neo layout: dagre --- flowchart TB A["RTSP camera/Defense"] L_A_B_0@-- RTSP (internal network) --> B["Media server for encoding (SRS / Nginx-RTMP/ etc)"] B L_B_C_0@-- "Https://Live/..." --> C["Java back end
Authentication / Tokenization / Proxy"] C L_C_D_0@--
--> D["App Angular (MSE player: FLV or TS through WS/HTTP)
"] D L_D_E_0@--> E["Browser user"] A@{ shape: rect} B@{ shape: rect} C@{ shape: rect} D@{ shape: rect} E@{ shape: tag-proc} style A stroke:#00C853 style B stroke:#00C853 style C stroke:#00C853 style D stroke:#00C853 style E stroke:#00C853,stroke-width:1px,stroke-dasharray: 0 L_A_B_0@{ animation: slow } L_B_C_0@{ animation: slow } L_C_D_0@{ animation: slow } L_D_E_0@{ animation: slow } ``` **Pros:** Simple architecture and low-to-moderate latency of 1–3 seconds. No WebRTC signaling. **Cons:** Mobile compatibility depends on the MSE player. {% hint style="info" %} **Security tip:** Keep RTSP **internal** through LAN or VPN. Browsers only access **WebRTC** or **HTTP-FLV/MPEG-TS** through **HTTPS**. Do not expose error codes, to prevent banner-grabbing attacks. {% endhint %} *** ### Requirements and prerequisites * Access RTSP cameras or Defense channels, including network, credentials, and ports. * **Video:** Prefer **H.264 (8-bit)**. This avoids transcoding. * **Audio:** Browsers prefer **AAC**. Change G.711 or PCM at the device. * Use a low-resolution, low-bitrate **substream** for web delivery. * Provide a server, VM, or container for the **media gateway**. * Use **HTTPS** for all front-end delivery. Prefer the same origin. *** #### Design decisions (baseline) * **Delivery:** WebRTC through WHEP, or HTTP-FLV/MPEG-TS through MSE. * **Target latency:** WebRTC under 1–2 seconds. HTTP-FLV/TS \~1–3 seconds, depending on buffer settings. * **Transcoding:** **Avoid it**. Use H.264/AAC **copy** mode for transmuxing. * **Isolation:** Never expose RTSP to the front end. Use HTTPS endpoints with **temporary tokens**. * **Scale:** Use one ingest per camera. Avoid re-encoding. Use **VAAPI/NVENC** when necessary. *** ## Media gateway deployment **WebRTC (WHEP/WHIP)** * Provision **MediaMTX / Janus / SRS** with per-camera RTSP pull ingest and a dedicated path. * Enable **TLS** on the gateway. Prefer the application's domain. * Configure **ICE** with public **STUN** and **TURN** for restrictive NATs. * **Camera:** H.264, a **GOP** of \~1–2 seconds, and audience-appropriate bitrate. **HTTP-FLV / MPEG-TS** * Ingest RTSP and output **HTTP-FLV** or **MPEG-TS through WebSocket/HTTP**. * Use **transmuxing** with H.264 and AAC when possible. This avoids transcoding. * Publish through **HTTPS**, ideally on the application origin. **Common operations** * Use a supervisor such as systemd, supervisord, or Docker with **automatic restart**. * Add a **health check** that reconnects after RTSP failures. * Collect logs and metrics for connections, bitrate, and interruptions. *** ## Java back-end responsibilities * **Never expose RTSP or credentials**. * Issue short-lived **signed or temporary URLs** for playback, such as **WHEP** or **/live/flv**. * Authorize access by camera and role. Audit **who, when, which camera, and duration**. * Optionally reverse-proxy media endpoints through Spring. This supports a same-origin model and auditing. * Protect endpoints with rate limits, user or session throttling, and Referer/IP checks. * Set the correct `Content-Type`, such as `video/x-flv` or `video/mp2t`. Use short-lived caching. * Monitor active sessions, 4xx/5xx errors, session duration, and WebRTC handshake failures. *** ## Angular front-end responsibilities * **WebRTC player:** Use native WHEP APIs or a lightweight offer/answer library. * **MSE player for HTTP-FLV/TS:** Use a client that demultiplexes **FLV/TS** into an MSE `SourceBuffer`. * **Autoplay:** Start **muted** to meet browser policies. * **UI states:** Loading → playing → reconnecting → error, with **retry**. * **Common errors:** CORS, incorrect MIME, mixed content, blocked autoplay, and ICE failures. * **Accessibility:** Support focus and keyboard control. Provide audio controls when applicable. *** ## Security and compliance * Keep RTSP secrets outside source code. Use a vault or environment variables. * Block RTSP access from the internet. Allow access only through LAN or VPN. * Use end-to-end **TLS**, including the gateway. * Authorize per camera and support immediate token revocation. * Audit stream access through **logs** correlated with users and sessions. * Optionally use WAF/CDN, rate limits, and IP restrictions. *** ## Observability and operations * **Logs:** Gateway ingest and playback, web server or proxy, and back end tokens and sessions. * **Metrics:** Concurrent viewers, effective bitrate, dropped frames, ICE failures, and reconnections. * **Alerts:** Ingest interruptions, publishing errors, and high disk or CPU usage. * **NTP:** Synchronize cameras and servers. * **Cleanup:** Rotate logs and avoid unnecessary retention. *** ## Performance and sizing * **Web bitrate:** 800 kbps–3 Mbps per camera. Prefer an **H.264 substream**. * **CPU:** Transmuxing and copy mode use few resources. **Transcoding** is expensive. Use **VAAPI/NVENC** when unavoidable. * **Scale:** Distribute by network zone, isolate problematic cameras, and limit viewers per instance. * **Network:** Monitor jitter and packet loss. Keep gateways close to cameras. *** ## Tests and acceptance criteria (DoR/DoD) **Functional** * Plays in target browsers: Chrome, Firefox, Edge, and Safari, on desktop and mobile. * Meets the **latency** target: WebRTC under 2 seconds; HTTP-FLV/TS \~1–3 seconds. * Supports **automatic recovery** after an RTSP interruption. * Does not expose RTSP or credentials to the front end or external network. **Non-functional** * End-to-end **HTTPS**. * Visible **logs and metrics** in Grafana, ELK, or cloud tooling. * Supports N concurrent viewers without noticeable degradation. * Configured **runbook** and alerts. **Definition of Done (summary)** * ✅ Playback protected by **temporary tokens**. * ✅ Angular player with states and error handling. * ✅ Validated latency and stability. * ✅ Active observability and alerts. * ✅ Published operational documentation. *** ### Runbooks **Add a new camera** 1. Validate RTSP and **codecs**: H.264 and AAC. 2. Configure the camera's **substream**, **GOP**, and bitrate. 3. Create a gateway **path** for WebRTC or HTTP-FLV/TS. 4. Publish an **HTTPS** endpoint and issue a **signed URL**. 5. Register it in the back end catalog and roles, and in the Angular player. 6. Test latency and stability before release. **Common incidents** * **Video does not load:** Check HTTPS, CORS, MIME, token, origin, and firewall. * **Partial compatibility:** Validate MSE/WebRTC player support and autoplay policies. * **No audio:** The source uses G.711. Convert it to **AAC** at the gateway. * **Stuttering:** Reduce bitrate or resolution. Adjust GOP. Check network, NTP, and packet loss. * **WebRTC ICE failure:** Configure **TURN** and check ports and routing. *** ### Future roadmap * **ABR in WebRTC** through simulcast or SVC. * **Recording and time-shift** with NVR or object storage. * **CDN and edge relays** for global viewer scaling. * **PTZ and talkback** through WebRTC DataChannel or audio. * **Dynamic QoS** with adaptive gateway bitrate. *** **Final notes** * Choose **WebRTC** when **latency** is critical and signaling/ICE is acceptable. * Choose **HTTP-FLV/MPEG-TS through MSE** for HTTP simplicity and \~1–3 second latency. * In both cases, **do not expose RTSP**. Use **TLS**, short-lived tokens, and observability from the start. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://portal-integracao.intelbras.com.br/defense-ia-and-lite/defense-ia-english/implementation-tips/implementation-guide-rtsp-for-web-front-ends.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.