Protocols Are Product Decisions, Not Just Transport Details
In private video projects, protocol choice affects camera compatibility, browser playback, latency, firewall rules, recording workflows, operational diagnostics, and long-term maintenance.
A reliable design starts by separating the path: what enters the system, how the gateway or SDK manages it, what must be delivered to browsers or platforms, and where recording or replay is required.
Practical Protocol Roles
| Protocol | Typical role | Best fit | Watchouts |
|---|---|---|---|
| RTSP | Camera or NVR input | LAN camera pull and low-latency preview | Browsers usually need a gateway |
| ONVIF | Discovery and device control | Finding cameras and resolving stream URLs | It is not the media playback protocol |
| RTMP | Publishing or encoder input | Existing encoder and live-publishing workflows | Browser support is no longer native |
| HTTP-FLV / WS-FLV | Browser output | Low-latency web preview in controlled networks | Requires a player and gateway |
| HLS | Browser and mobile output | High compatibility and replay | Usually higher latency |
| WebRTC | Low-latency browser output | Real-time preview and display walls | More sensitive to certificates, NAT, and ports |
| SRT | Backhaul and transport | Remote sites and unstable networks | Both sides need SRT support |
| GB28181 | China video networking | Registration, catalog, media request, and cascading | Requires real platform validation |
Camera Ingest Usually Starts with RTSP, ONVIF, and GB28181
Most IP cameras and NVRs expose RTSP streams. ONVIF helps discover devices, read profiles, obtain RTSP URLs, and perform selected control operations. GB28181 is required when the project must register to or interoperate with an upper video platform in China.
Browser Playback Needs a Gateway Path
Standard browsers do not directly play typical RTSP camera streams. A gateway usually ingests RTSP, ONVIF, GB28181, or existing streams and exposes WebRTC, HTTP-FLV, HLS, or playback URLs to users and business systems.
How HBRun Products Map to Protocol Workflows
Use StreamCore SDK when the protocol capability must be embedded in your own application. Use StreamGate when you need an on-prem gateway for camera onboarding, channel management, browser playback, recording replay, and APIs.
Selection Rules
Choose protocols by workflow rather than by popularity: RTSP and ONVIF for camera ingest, WebRTC or FLV for low-latency browser playback, HLS for broad playback compatibility, SRT for remote backhaul, and GB28181 for platform interconnection.
Implementation Checklist
Before choosing a protocol, split the workflow into ingest, processing, output, and operations. Confirm device protocols, credentials, stream profiles, codec, bitrate, recording needs, browser targets, platform interconnection, exposed ports, certificate requirements, and diagnostics.
Acceptance Focus
Protocol acceptance should not stop at a successful first frame. Validate reconnect behavior, long playback, network jitter, H.264/H.265, audio, timestamps, first-frame time, recording replay, port exposure, and logs. GB28181 projects should separately verify registration, keepalive, catalog, INVITE, media direction, and upper-platform compatibility.
FAQ
RTSP is common for camera pull but is not normally browser-native. ONVIF is for discovery and device control, not direct playback. SRT is useful for backhaul and weak networks. GB28181 is a platform interconnection workflow and needs role-specific validation.
Delivery Advice
Start with the smallest production workflow, such as RTSP/ONVIF ingest, browser playback, and recording replay. Add SRT, GB28181, or API integrations only after the base path is observable and stable.