Publishing

RTMP

The usual route, and what OBS, vMix, and FFmpeg speak.

rtmp://your-host:1935/<application>/<stream-or-key>

With OBS, the Server is rtmp://your-host:1935/<application> and the Stream Key is the last element. FFmpeg wants the whole thing:

ffmpeg -re -i input.mp4 -c copy -f flv \
  rtmp://your-host:1935/default/mystream

Note -c copy. Jadarit passes video through as published, so sending an already-encoded H.264 file costs almost nothing at either end.

Set a steady keyframe interval, 2 seconds being the usual choice (in OBS: Settings → Output → Keyframe Interval). HLS segments are cut at keyframes, and adaptive bitrate can only pass your original quality through untouched when keyframes arrive regularly.

Codecs

H.264 works everywhere. Enhanced RTMP is supported, so HEVC arrives intact rather than being refused or downgraded. Audio arrives as AAC and is converted per output.

SRT

The protocol for contribution over the internet: it resends lost packets instead of stalling, copes with long and lossy paths, and can be encrypted. vMix, OBS and most hardware encoders speak it.

srt://your-host:8890?streamid=<application>/<stream-or-key>

The stream ID is the same path an RTMP URL ends in, so publish keys work exactly as they do for RTMP: the application, then the stream name, or the stream’s publish key when the application uses StreamKey security. A bare mystream goes to the default application.

In OBS: Settings → Stream, Service Custom, Server srt://your-host:8890?streamid=default/mystream, and leave Stream Key empty. In vMix and most hardware encoders, give the host and port, choose Caller mode, and put default/mystream in the Stream ID field.

With FFmpeg:

ffmpeg -re -i input.mp4 -c copy -f mpegts \
  "srt://your-host:8890?streamid=default/mystream"

What it carries

H.264 or HEVC video and AAC audio, in MPEG-TS, which is what SRT encoders send. Jadarit reads the encoder’s own timestamps, so streams with B-frames are fine. The stream goes live as soon as video arrives and ends when the encoder hangs up, as with RTMP.

Latency and encryption

SRT waits a little for lost packets before giving up on them. The server waits latency_ms, 120 by default; raise it for long or lossy paths. If the encoder asks for more, the higher value is used.

To encrypt, set [srt].passphrase on the server (10 to 79 characters), and give the encoder the same passphrase; in a URL, add &passphrase=…. Any key length the encoder offers is accepted. Once a passphrase is set, publishers without it are refused, rather than let in unencrypted.

Reaching it from outside

SRT is UDP, on port 8890 by default. Forward that port on your router; jadarit doctor lists it with the other ports to forward. Like WebRTC, it does not pass through an HTTP proxy or a Cloudflare Tunnel.

A refused publisher is turned away during the SRT handshake with a standard SRT reason code, and the server log says why.

WHIP

WebRTC ingest, for publishing straight from a browser with no encoder installed.

POST http://your-host:9001/api/v1/whip/<application>/<stream>
Content-Type: application/sdp

The body is an SDP offer; the response is the answer. Any conforming WHIP client works. Authentication uses a publish key, not an API token, because the publisher is an encoder rather than an operator. Send it as a bearer token:

curl -X POST http://your-host:9001/api/v1/whip/default/webcam \
  -H "Authorization: Bearer <publish-key>" \
  -H "Content-Type: application/sdp" \
  --data-binary @offer.sdp

To stop, DELETE the same path.

The dashboard can publish your camera this way too, with Publish camera on an application’s streams. Browsers only allow camera access on secure pages, so for that the dashboard has to be opened over HTTPS: behind a reverse proxy with a certificate, or with [tls] enabled, which serves port 9443 with a self-signed certificate unless you give it one. On the server itself, http://localhost also counts as secure.

Pulling instead of receiving

Jadarit can also fetch a source rather than wait for one:

curl -b jar -X POST http://your-host:9001/api/v1/apps/default/streams/from-url \
  -H 'content-type: application/json' \
  -d '{"name":"camera","url":"rtsp://camera.lan/stream1"}'

srt:// sources work here too, in caller mode, for a gateway or encoder that serves its stream rather than pushing it. For an encoder that pushes, use SRT ingest above instead: it reads the stream’s own timestamps and needs no setup per stream.

For ONVIF cameras, POST /api/v1/onvif/discover finds them on the local network and POST /api/v1/onvif/stream-uri resolves the RTSP URL to pull.

When a publisher disconnects

The stream ends and is removed from the router, so the dashboard stops showing it as live rather than freezing on the last frame. Viewers on the watch page see that the broadcast ended, and the page reconnects on its own if it starts again.