SRT
Accept live feeds from SRT-capable cameras and encoders. AES encryption can be enabled with a separate passphrase for each stream.
Streaming Protocols
Choose the right streaming protocol for the source and the viewer
Connecting a camera or encoder is a different decision from delivering video to viewers. CreekX accepts WebRTC, SRT, RTSP and RTMP inputs, then delivers live video using WebRTC, low-latency HLS or standard HLS from your own server.
CreekX Media Server
Ingest and delivery are separate choices
Use the input your source supports, then choose how viewers receive the stream according to acceptable delay and playback requirements. An RTSP camera or SRT encoder, for example, does not require viewers to use that same protocol. CreekX can receive the source and provide a browser-facing WebRTC, LL-HLS or HLS stream.
Protocols for bringing live video into CreekX
RTSP
Bring video into CreekX from RTSP cameras and other compatible sources. CreekX Cameras uses ONVIF for camera discovery and RTSP for the video feed.
RTMP
Connect existing live encoders and production tools that publish an RTMP stream.
WebRTC
Send live video from supported browser-based or WebRTC sources when the workflow needs a real-time path into the server.
Protocols for delivering video to viewers
WebRTC
Use WebRTC when staying close to the live event is the priority, such as remote bidding, sports viewing or control-room monitoring. WebRTC media is encrypted in transit using DTLS-SRTP.
Low-latency HLS
Use LL-HLS when you need a low-delay stream with broader HTTP-based playback. It sits between WebRTC and standard HLS in CreekX's measured delay results.
Standard HLS
Use HLS where broader playback compatibility matters more than keeping delay as low as possible.
Match the protocol path to the application
Auctions and live sports
Send video from a browser or encoder using a supported input, then use WebRTC for viewers who need to see the action close to real time.
IP cameras and remote sites
Connect ONVIF and RTSP cameras through CreekX Cameras, or pull an RTSP or SRT address directly into Media Server. Deliver the feed to browsers using WebRTC, LL-HLS or HLS according to the acceptable delay.
Encrypted contribution feeds
Use SRT ingest with a per-stream AES passphrase when the source must send an encrypted feed to the CreekX server.
Mixed viewer requirements
Use WebRTC for the viewers who need the lowest delay and an HLS path where playback compatibility takes priority.
Measured delay for each delivery path
CreekX measured these results on 13 October 2026 using CreekX 2026.10.13 and the standard installer. The server ran Ubuntu 24.04 with 4 vCPU, 8 GB memory, a 100 GB NVMe disk and about 890 Mbit/s upload bandwidth. The source was a 1080p, 25 fps H.264 video at 5 Mbit/s; each step ran for 60 seconds. Delay was measured on a laptop over the local network with OBS as the sender. These results describe that test setup, not every network or deployment.
WebRTC
Median delay was 0.49 seconds. The worst result was 0.68 seconds.
Low-latency HLS
Median delay ranged from 1.23 to 1.28 seconds. The worst result was 1.40 seconds.
Standard HLS
Median delay ranged from 3.4 to 3.8 seconds. The worst result was 4.4 seconds.
Current compatibility and capacity boundaries
- CreekX delivers WebRTC, HLS and LL-HLS. MPEG-DASH and WebM delivery are not available.
- Camera support currently covers ONVIF and RTSP cameras. Support for cameras that rely only on ONVIF Media2 is being added, and physical-camera validation remains outstanding.
- Server capacity depends on the hardware, video quality, number of streams, transcoding work, storage speed and available network bandwidth. It should be sized for the deployment rather than assumed from a fixed count.
- CreekX currently runs on one server per installation. Deployments involving several servers, more than 50 live streams or thousands of viewers should be reviewed with CreekX before installation.
What protocol encryption does and does not cover
HTTPS protects the application and supported video paths in transit, WebRTC media uses DTLS-SRTP, and SRT ingest can use AES encryption. Recorded video and library files are stored without application-level encryption on the customer's disks; deployments that require encryption at rest need disk encryption on the server. Enabling off-site backups, external storage or another outbound integration also changes where data can travel. These are CreekX product features covered by its own automated tests, not an external security assessment or compliance approval.
Test your ingest and delivery path
The 14-day Media Server trial requires no credit card and lets you evaluate the supported input and delivery protocols on your own server. Internet access is required during trial installation. The CreekX Cameras portal is not included, although you can pull a camera feed into Media Server using its RTSP or SRT address. Speak to CreekX first if you need the Cameras portal, a fully offline installation, a large deployment or tender documentation.