Ingest
- ONVIF CAMERA · Profile T / G
- RTSP · RTMP · IP camera / encoder
- NVR · VMS · SDK / uplink
- SRT · RTP · WAN / GB28181
AQPTECH · REAL-TIME VIDEO PLATFORM
Media Server — Live Video for Every Screen
Connect cameras, live sources and applications with a media server for WebRTC, HLS and video integration.
Overview
From Video Sources to Live Browser Experiences
Media Server connects IP cameras, NVRs, encoders and video sources with web or mobile applications. Development teams can focus on user experiences and business workflows while the media server handles ingestion, processing and delivery.
WebRTC serves use cases that need fast feedback, while HLS and HTML5 outputs support different delivery requirements. Recording, playback, snapshots and APIs connect video with monitoring systems, digital platforms and custom applications.
Deploy at the edge, on your own infrastructure or in a hybrid cloud design. Codecs, latency, viewer capacity and release-specific capabilities are validated against actual sources and configurations.
RTSPRTMPONVIFWebRTCHLSREST API
One Media Platform. Multiple Sources. Connected Video Experiences.
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.
Video Sources → Media Server → Your Application
Media Server
- Protocol ingest
- Relay & transcode
- Record & snapshot
- REST · Webhook · C API
Deliver and integrate
- WEB BROWSER · WebRTC / WebSocket
- MOBILE & WEB APP · HLS / fMP4 / HTTP-FLV
- VIDEO WALL · Multi-stream rendering
- VMS · SOC · GIS · Secure API integration
Latency and capacity depend on sources, codecs, transcoding, networks, TURN and viewing devices. Agree measurement criteria during the PoC before scaling.
Build Live Experiences Around Your Needs
Media Server provides the media layer. Business and interaction features are integrated or developed within each solution’s scope.
Live Video Monitoring
Bring cameras and NVRs into web dashboards, view multiple sources, use supported PTZ controls and review recordings around events.
Discuss this solution
Live Events and Media
Design encoder-to-player and recording workflows. Multi-destination delivery, CDN integration and multiple quality profiles are evaluated within the integration scope.
Discuss this solution
Webinars and Online Learning
Connect video with classrooms or training portals. Scheduling, attendance, chat, screen sharing and multi-party interaction need application development and suitable media configuration.
Discuss this solution
Live Shopping and Product Advice
Embed live video into product discovery. Product cards, chat, carts and checkout are connected in the application layer around the commerce platform.
Discuss this solution
Auctions and Real-Time Interaction
Assess video delivery for interactive sessions. Bids, timestamps, state synchronization and transaction logs need a dedicated business backend and clear test criteria.
Discuss this solution
Remote Consultation and Support
Build video sessions around accounts and support workflows. Access control, appointment integration and recording retention are designed for each deployment.
Discuss this solutionKey benefits
Connect Live Video with Operational Value
From monitoring to interactive platforms, build an integrated video layer validated on your infrastructure.
Bring video to the web without plugins
Connect camera sources to HTML5 players in modern browsers with compatible codecs.
Match delivery to the experience
Balance responsiveness, quality and bandwidth with a suitable WebRTC or HLS configuration.
Integrate with your own product
Use APIs to connect streams, recordings and events with existing interfaces and workflows.
Control where video is stored
Choose edge or on-premises designs according to data policies and connectivity needs.
Reuse sources and recordings
Combine live viewing, snapshots and playback for operations and event review.
Scale from validated workloads
Assess bitrate, transcoding, TURN and viewer counts before sizing servers and distribution.
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.
Request an Media Server Demo
Tell us about your video sources, audience, latency goals and deployment environment.
Loading form…
Deployment and System Integration
Expand each guide to review requirements and reference configurations.
Install Media Server 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 access
- Network routes to cameras and viewing clients
- Only the required ports opened for your architecture
- An NVIDIA GPU only when the AI pipeline is enabled
01 · Verify the download
SHA256
curl -LO https://github.com/AQ-VISION/html5stream/releases/download/v8.1.0/SHA256SUMS
sha256sum -c SHA256SUMS --ignore-missing02 · 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 html5streamRPM · 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 html5streamTGZ · 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-mediaserver03 · 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.
Check the service
sudo systemctl status html5stream
sudo journalctl -u html5stream -f
curl -I http://127.0.0.1:8080/04 · Open the console
Once the service is healthy, open the embedded admin console below. Replace SERVER_IP with the server IP or hostname.
http://SERVER_IP:8080/admin/05 · 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.
| Port | Protocol | Purpose |
|---|---|---|
| 8080 | TCP | HTTP console / API |
| 8443 | TCP | HTTPS console / API |
| 8554 | TCP | RTSP |
| 1935 | TCP | RTMP |
| 3000–3001 | TCP | WebRTC signaling |
| 8000 | TCP / UDP | WebRTC media |
| 3478 | TCP / UDP | ICE / TURN |
| 9000 | UDP | SRT |
| 10000 | TCP / UDP | RTP proxy |
06 · 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.shCross NAT with TURN. Optimize bandwidth with AV1.
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.
When relay is active, every viewing session traverses H5S. Size Internet capacity, NIC throughput, and data-centre egress for the aggregate concurrent bitrate.
TURN SIZING
2 Mbps × 100 viewers ≈ 200 Mbps outboundTURN relays data; it does not transcode codecs automatically. Protocol overhead and operational headroom are not included in this example.
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.
- Lower target bitrate at comparable quality
- Offload processing from the CPU to PCIe hardware
- Support 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.
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.
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.
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.
Frequently Asked Questions about Media Server
What is Media Server?
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.
What problem does it solve?
It provides the Camera/NVR → Media Server → 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.
Is Media Server 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.
Can 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.
Which 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.
Which protocols are supported?
Depending on version and configuration: RTSP, RTMP, ONVIF, WebRTC, HLS, HTTP/HTTPS, WebSocket, REST API, and MQTT for selected event flows.
Which 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.
Is 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.
Does Media Server 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.
What 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.
Are recording and playback supported?
Yes: continuous, scheduled, or event recording; time search; Web playback; clip export; snapshots; and links to AI events.
Can Media Server work with AI?
Yes. Media Server manages video while an AI Engine produces events such as people, vehicles, intrusion, smoke/fire, PPE, counting, plates, congestion, or abnormal behaviour.
Can it integrate with SCADA?
Yes, without replacing SCADA. Operational data comes from PLCs and gateways while Media Server supplies live video, snapshots, and playback around alarms.
Can it integrate with existing software?
Yes: VMS, ERP, SCADA, BMS, access control, parking, traffic, logistics, fleet, IoT, and command-centre applications.
Is 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.
Can it run on-premise?
Yes, including factories, offices, data centres, substations, buildings, warehouses, and command centres with video retained inside customer infrastructure.
Can 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.
Does 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.
Does 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.
Can it operate as a Video Gateway?
Yes. It normalizes Camera/NVR/VMS inputs into WebRTC, HLS, RTSP, snapshot, playback, and API outputs.
Can 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.
Is 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.
Can it fully replace an NVR?
It depends. Media Server offers recording and playback, while dedicated NVRs remain useful for simple standalone storage and same-vendor integration. Media Server is stronger for software integration.
Who is Media Server for?
System integrators, VMS developers, AI-camera and IoT vendors, SCADA/BMS teams, traffic and logistics providers, fleet operators, factories, and video-OEM builders.
Can the interface be white-labelled?
Yes. A custom Web/Mobile interface can use Media Server behind the scenes with branded UI, permissions, reports, workflows, and AI/IoT integrations.
How is Media Server licensed?
Licensing may reflect camera count, Media Nodes, software edition, recording, transcoding, OEM terms, and deployment scale.
What 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.
How is it different from consumer livestreaming?
Livestreaming distributes one programme to an audience. Media Server focuses on many independent surveillance streams, low latency, PTZ, recording, playback, permissions, APIs, AI events, NVR/VMS, and business integration.
