Browser
Requests camera and microphone permission, sends the broadcast and plays the received stream. Closing the page or stopping access stops the browser-side capture.
TECHNICAL OVERVIEW
WebRTC architecture
A concise explanation of how a live image travels from a broadcaster’s browser to viewers and where Cloudflare fits in.
The path of a live stream
- 1
Broadcaster’s browser
After permission is granted, the browser captures camera and microphone data and establishes a WebRTC connection.
- 2
LiveSnap application
The application on Hostinger verifies the session and access rules, then prepares the connection setup. It does not receive or process the live video frames.
- 3
Cloudflare Realtime SFU
Cloudflare’s media relay receives the broadcast once and distributes it to connected viewers. This avoids the broadcaster sending a separate copy to every viewer.
- 4
Viewers’ browsers
Each viewer receives the stream through WebRTC. Their network and device affect the quality they can receive.
Hostinger application
Runs the LiveSnap application and database. It manages accounts, sessions and service rules; application secrets stay on the server.
Cloudflare Realtime
Provides the Serverless SFU used to relay live media between the broadcaster and viewers. It is the media layer, not the account database.
Connection and security boundaries
- Signalling and service pages use HTTPS.
- WebRTC media uses its standard encrypted transport (DTLS-SRTP).
- Keys used by the application to configure media delivery remain on the server and are not placed in public page code.
- Live video quality can change with network conditions; this overview is not a service-level guarantee.
What this means in practice
A current browser with WebRTC support and permission to use the camera is required to broadcast. A broadcaster can end a session or revoke camera permission at any time. The rules for data handling are described in the privacy policy; the terms of service remain the governing rules for use of LiveSnap.