OPEN VIDEO INFRASTRUCTURE · v8.1.0

Connect any camera.
Stream to any application.

HTML5STREAM connects cameras, NVRs, and VMS platforms with Web, Mobile, AI, IoT, and SCADA applications. Low-latency live view, recording, playback, PTZ, and APIs shorten the path to a production video solution.

Talk to us Technical documentation Request a demo

HTML5STREAM — Connect any camera. Stream to any application.

LIVE MEDIAONE STREAM · EVERY SCREEN

ONVIFRTSPWebRTCTURNAV1HTML5

CURRENT RELEASEv8.1.0

<400 msWebRTC latency target*

10+Input / output protocols

3Linux package formats

ONE MEDIA CORE

One open streaming layer for every video system

From ingest, conversion, and recording to browser playback, HTML5STREAM brings essential media capabilities into one API-ready service.

Multi-vendor sources

Ingest ONVIF Profile T/G cameras, RTSP, RTMP, SRT, RTP/GB28181, NVR/VMS systems, and MP4 files.

Unified media processing

Demux, mux, relay, protocol conversion, snapshots, and recording in a high-performance C++ media core.

Native HTML5 playback

Deliver video to Chrome, Edge, Safari, and Firefox through WebRTC, WebSocket, HLS, HTTP-FLV, or fMP4.

API-first integration

REST APIs, webhooks, and a C API embed streaming into VMS, SOC, video wall, GIS/eMap, or custom applications.

Flexible deployment

Run on an edge gateway, an on-premise server, or a centralized multi-site cluster.

Video-AI ready

Enable the optional CUDA/TensorRT pipeline for object detection while keeping AI outside the default streaming core.

PROGRAMMABLE ARCHITECTURE

Every video source, coordinated by one media core

This programmed diagram maps device ingest through the media core to browsers and business systems. It remains crisp and readable on every screen.

01 · VIDEO SOURCES

ONVIF CAMERAProfile T / G

RTSP · RTMPIP camera / encoder

NVR · VMSSDK / uplink

SRT · RTPWAN / GB28181

02 · MEDIA CORE

HTML5STREAMHIGH-PERFORMANCE VIDEO PLATFORM

Protocol ingestRelay & transcodeRecord & snapshotREST · Webhook · C API

ON-PREMISEEDGEHYBRID

03 · APPLICATIONS

WEB BROWSERWebRTC / WebSocket

MOBILE & WEB APPHLS / fMP4 / HTTP-FLV

VIDEO WALLMulti-stream rendering

VMS · SOC · GISSecure API integration

OPTIONAL AI RAIL · CUDA / TENSORRT / YOLOTENSORRTCUDAGPU

Native HTML5 deliveryEncrypted video transportBrowser GPU decodingEdge recording and snapshots

*Sub-400 ms is a WebRTC design target; actual results depend on codec, network, NAT/TURN, and viewer hardware.

WEBRTC NETWORKING & HARDWARE CODEC

Cross NAT with TURN. Optimize bandwidth with AV1.

These capabilities solve different layers of the delivery problem: TURN preserves a WebRTC path when direct connectivity fails; PCIe transcoding changes the codec before H5S distributes the video.

01 · WEBRTC TURN RELAY

Deliver WebRTC from a private LAN to the Internet

H5S coordinates signaling and can relay media through TURN. The browser still prefers a direct path; media is routed through H5S only when NAT or firewall policy prevents that connection.

CAMERA / VIDEO SOURCERTSP · ONVIF · H.265 / H.264

H5S WEBRTC SERVER192.168.100.123 · PRIVATE LAN

SIGNALING SERVERExchanges SDP, ICE candidates, and session setup information between the web client and H5S.TURN RELAYRelays media when both endpoints cannot establish a direct WebRTC transport path.

Preferred pathICE / P2P

Fallback pathTURN :3478

WEB BROWSERInternet / remote client

NAT / FIREWALL47.1.1.123

SIGNALING SERVER

Exchanges SDP, ICE candidates, and session setup information between the web client and H5S.

TURN RELAY

Relays media when both endpoints cannot establish a direct WebRTC transport path.

Reference IP and port mapping

PRIVATE NETWORK192.168.100.123PUBLIC INTERNET47.1.1.123

Public access URLshttp://47.1.1.123:9080https://47.1.1.123:9443

Internal serverPublic IP / portExpected purpose

192.168.100.123:808047.1.1.123:9080HTTP / WebRTC signaling

192.168.100.123:844347.1.1.123:9443HTTPS / WSS signaling

192.168.100.123:347847.1.1.123:3478TURN relay

TURN bandwidth scales with concurrent viewers

When relay is active, every viewing session traverses H5S. Size Internet capacity, NIC throughput, and data-centre egress for the aggregate concurrent bitrate.

TURN relays data; it does not transcode codecs automatically. Protocol overhead and operational headroom are not included in this example.

2 Mbps × 100 viewers ≈ 200 Mbps outbound

02 · HARDWARE AV1 TRANSCODING

Convert H.265 to AV1 before WebRTC delivery

An H.265 source is routed through a dedicated PCIe card. Hardware converts it to AV1, after which H5S distributes the AV1 stream to web clients.

01H.265 CAMERAInput video source

02PCIe TRANSCODERHardware H.265 → AV1

03H5S / WebRTCSignaling & distribution

04AV1 BROWSEREndpoint decoding

HARDWARE TRANSCODING<8 msVendor-stated transcoding latency

Lower target bitrate at comparable qualityOffload processing from the CPU to PCIe hardwareSupport large-scale WebRTC delivery patterns

The endpoint device and browser must decode AV1. Validate latency, quality, and channel density with the exact card, driver, and codec profile planned for deployment.

END-TO-END PIPELINE

Both capabilities can operate in one pipeline

H.265 camera → PCIe AV1 transcoder → H5S WebRTC Server → direct connection or TURN relay → AV1-capable browser.

H.265PCIe / AV1H5S / WebRTCDIRECT / TURNBROWSER

Production recommendation

Prefer HTTPS/WSS signaling and TURN over TLS when the network requires it. TCP port forwarding alone may be insufficient: design ICE/TURN, UDP/TCP fallback, TLS certificates, firewall policy, and public-IP advertisement together.

DEPLOY WHERE VIDEO LIVES

Three common deployment patterns

Start with a gateway near the cameras or scale into a multi-site media core without changing the integration surface.

EDGE GATEWAY

Ingest and convert close to cameras to reduce WAN bandwidth and preserve local viewing.

CENTRAL PLATFORM

Centralize streams, recording, and access control across sites or existing VMS deployments.

AI-READY NODE

Add NVIDIA GPUs and TensorRT when the use case requires real-time inference close to the video source.

INSTALLATION GUIDE

Install HTML5STREAM v8.1.0

Choose the package for your x86_64 Linux server. Commands download directly from the project's official GitHub Release.

GitHub Release v8.1.0

Before you begin

x86_64 Linux with sudo accessNetwork routes to cameras and viewing clientsOnly the required ports opened for your architectureAn NVIDIA GPU only when the AI pipeline is enabled

Verify the download

SHA256

curl -LO https://github.com/AQ-VISION/html5stream/releases/download/v8.1.0/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing

Choose a package

DEB · Ubuntu / Debian

curl -LO https://github.com/AQ-VISION/html5stream/releases/download/v8.1.0/html5stream_8.1.0_amd64.deb
sudo apt install ./html5stream_8.1.0_amd64.deb
sudo systemctl enable --now html5stream

RPM · RHEL / Rocky / AlmaLinux

curl -LO https://github.com/AQ-VISION/html5stream/releases/download/v8.1.0/html5stream-8.1.0-1.x86_64.rpm
sudo dnf install ./html5stream-8.1.0-1.x86_64.rpm
sudo systemctl enable --now html5stream

TGZ · Portable / no system service

curl -LO https://github.com/AQ-VISION/html5stream/releases/download/v8.1.0/html5stream-8.1.0-Linux-x86_64.tar.gz
tar -xzf html5stream-8.1.0-Linux-x86_64.tar.gz
./usr/bin/html5stream-mediaserver

Configure and start

System packages run the html5stream service. The default configuration is /usr/libexec/html5stream/config.ini; back it up before changing ports, TLS certificates, or recording policy.

CONFIG/usr/libexec/html5stream/config.ini

Check the service

sudo systemctl status html5stream
sudo journalctl -u html5stream -f
curl -I http://127.0.0.1:8080/

Open the console

Once the service is healthy, open the embedded admin console below. Replace SERVER_IP with the server IP or hostname.

ADMIN CONSOLEhttp://SERVER_IP:8080/admin/

Network port reference

Open only enabled services. For public Internet access, place HTTP APIs behind a TLS reverse proxy and constrain media ports with a firewall.

8080TCP

HTTP console / API

8443TCP

HTTPS console / API

8554TCP

RTSP

1935TCP

RTMP

3000–3001TCP

WebRTC signaling

8000TCP / UDP

WebRTC media

3478TCP / UDP

ICE / TURN

9000UDP

SRT

10000TCP / UDP

RTP proxy

Build from source

Use CMake for a minimal Release build. ENABLE_AI remains off by default so the streaming core stays lightweight.

CMAKE · RELEASE

git clone --recursive https://github.com/AQ-VISION/html5stream.git
cd html5stream
cmake -S . -B build \
  -DCMAKE_BUILD_TYPE=Release \
  -DENABLE_WEBRTC=ON \
  -DENABLE_API=ON \
  -DENABLE_AI=OFF \
  -DENABLE_TESTS=OFF
cmake --build build -j"$(nproc)"

Optional AI pipeline

The YOLO build script requires FFmpeg development libraries, CUDA, TensorRT, and CoreAI access. Enable it only on a prepared GPU node.

./scripts/build_yolov12.sh

FIRST STREAM

Put your first camera stream on the web

Once installed, the basic workflow has four steps. Normalize camera URLs and credentials before production use.

Register a source

Add an RTSP URL or ONVIF device through the REST API or admin console.

Validate ingest

Confirm codec, connection status, and media-server logs before enabling recording.

Choose delivery

Prefer WebRTC for low latency; use HLS or fMP4 when compatibility and caching matter more.

Embed the stream

Use the playback URL and APIs in a VMS, dashboard, GIS/eMap, or custom web app.

OPERATIONS NOTES

Four production checks

WebRTC through NAT

Set the correct public IP and TURN service for off-site clients; validate UDP and TCP fallback.

Browser codec support

H.264 has broad support. H.265 playback depends on browser, operating system, and decoding hardware.

ONVIF across VLANs

Multicast discovery may not cross VLANs; add devices by static IP and permit the required inter-VLAN traffic.

Service observability

Track the systemd journal, recording capacity, connections, and bandwidth before increasing camera density.

HTML5STREAM FAQ

Questions to answer before deployment

A practical reference for engineering teams, system integrators, and organisations evaluating HTML5STREAM as a Video Media Server or Video Data Plane.

01What is HTML5STREAM?

A Media Server platform that connects, normalizes, and delivers video from IP cameras, NVRs, recorders, and VMS platforms to Web, Mobile, and third-party software.

02What problem does it solve?

It provides the Camera/NVR → HTML5STREAM → Web, Mobile, AI, IoT, or SCADA layer so teams do not have to build a media server, WebRTC gateway, recording, and playback stack from scratch.

03Is HTML5STREAM a VMS?

It provides live view, recording, playback, snapshots, PTZ, stream management, and APIs, but is best positioned as the Video Media Server or Video Data Plane behind a broader VMS or business application.

04Can cameras be viewed directly in a browser?

Yes. WebRTC serves low-latency viewing while HLS is useful for stable distribution and larger audiences, without browser plugins.

05Which video sources are supported?

IP cameras, NVR/DVR, bodycam, DriveCam/MDVR, encoders, RTSP/RTMP streams, video files, ONVIF devices, and selected third-party VMS platforms, subject to protocol and codec compatibility.

06Which protocols are supported?

Depending on version and configuration: RTSP, RTMP, ONVIF, WebRTC, HLS, HTTP/HTTPS, WebSocket, REST API, and MQTT for selected event flows.

07Which codecs are supported?

Common formats include H.264, H.265/HEVC, AAC, and G.711. Suitable hardware or software can add AV1 and other transcoding targets.

08Is transcoding always required?

No. Streams can be relayed or repackaged when endpoints support the source codec. Transcoding is used for compatibility, lower bitrate/resolution, multiple profiles, or codec normalization.

09Does HTML5STREAM support WebRTC?

Yes, for operations centres, traffic, bodycam, industrial monitoring, PTZ, fleet tracking, and AI-event verification. TURN provides a fallback through restrictive NAT or firewalls.

10What does a TURN Server do?

TURN relays WebRTC media when a direct path cannot be established. Server bandwidth must be sized for camera bitrate and concurrent viewers.

11Are recording and playback supported?

Yes: continuous, scheduled, or event recording; time search; Web playback; clip export; snapshots; and links to AI events.

12Can HTML5STREAM work with AI?

Yes. HTML5STREAM manages video while an AI Engine produces events such as people, vehicles, intrusion, smoke/fire, PPE, counting, plates, congestion, or abnormal behaviour.

13Can it integrate with SCADA?

Yes, without replacing SCADA. Operational data comes from PLCs and gateways while HTML5STREAM supplies live video, snapshots, and playback around alarms.

14Can it integrate with existing software?

Yes: VMS, ERP, SCADA, BMS, access control, parking, traffic, logistics, fleet, IoT, and command-centre applications.

15Is there a developer API?

APIs can manage cameras and streams, live URLs, snapshots, PTZ, recording, search/playback, server health, and events. Exact scope depends on version and licence.

16Can it run on-premise?

Yes, including factories, offices, data centres, substations, buildings, warehouses, and command centres with video retained inside customer infrastructure.

17Can it run in the cloud?

Yes. A common design is branch cameras → local Media Node → Cloud Control Platform → Web/Mobile, with site upload and cloud egress assessed first.

18Does it support multiple sites?

Yes. Deploy a Media Node per site or centralize streams. Distributed nodes reduce WAN usage, retain local video, and preserve operation during Internet loss.

19Does it support bodycams and vehicle cameras?

Yes, when devices expose compatible streams or APIs, enabling live view, event recording, GPS linkage, maps, SOS video, route playback, and evidence export.

20Can it operate as a Video Gateway?

Yes. It normalizes Camera/NVR/VMS inputs into WebRTC, HLS, RTSP, snapshot, playback, and API outputs.

21Can many users watch concurrently?

Yes, within the limits of CPU/GPU, NIC, bandwidth, bitrate, resolution, codec, transcoding, TURN, and active stream count. Validate with load testing.

22Is a GPU required?

Not for every deployment. GPUs or accelerator cards help with H.265-to-H.264/AV1 conversion, resize, multiple profiles, dense camera workloads, and AI. Relay/remux is lighter.

23Can it fully replace an NVR?

It depends. HTML5STREAM offers recording and playback, while dedicated NVRs remain useful for simple standalone storage and same-vendor integration. HTML5STREAM is stronger for software integration.

24Who is HTML5STREAM for?

System integrators, VMS developers, AI-camera and IoT vendors, SCADA/BMS teams, traffic and logistics providers, fleet operators, factories, and video-OEM builders.

25Can the interface be white-labelled?

Yes. A custom Web/Mobile interface can use HTML5STREAM behind the scenes with branded UI, permissions, reports, workflows, and AI/IoT integrations.

26How is HTML5STREAM licensed?

Licensing may reflect camera count, Media Nodes, software edition, recording, transcoding, OEM terms, and deployment scale.

27What information is needed for sizing?

Camera count and models, codecs, resolution/bitrate, concurrent viewers, retention, Web/Mobile/API needs, deployment model, transcoding, and AI/SCADA/BMS integrations.

28How is it different from consumer livestreaming?

Livestreaming distributes one programme to an audience. HTML5STREAM focuses on many independent surveillance streams, low latency, PTZ, recording, playback, permissions, APIs, AI events, NVR/VMS, and business integration.

BUILD ON HTML5STREAM

Need a video architecture shaped around your system?

AQP Tech can help with sizing, network flow design, VMS/NVR integration, WebRTC through NAT, and use-case-specific Video AI.

Talk to an AQP engineer GitHub repository

Connect any camera.Stream to any application.