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 does not re-encode, so sending an already-encoded H.264 file costs almost nothing at either end.

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.

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.

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"}'

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.