Short answer: receive the RTSP source, then write an M3U8 package
To convert an RTSP source to HLS in a reviewed Callaba path, create a Video Stream Recorder job with the verified RTSP URL as its input and select m3u8 as the output format. Keep video pass-through only when the source tracks satisfy the tested HLS playback profile; otherwise apply a supported transcode profile and verify the emitted playlist and media segments.
The result is an HLS package: an M3U8 playlist that refers to media segments. It is not automatically a public player, a CDN distribution, a low-latency HLS service, or proof that every browser can play the selected codecs.
Prove the source and output environment first
- A complete RTSP URL for the intended camera or media-server profile, tested from the Callaba network path.
- Credentials stored and transmitted as secrets, not pasted into screenshots, tickets, analytics, or public source code.
- The source video codec, resolution, frame rate, GOP behavior, audio codec, and audio layout.
- Enough local disk and I/O capacity for the bitrate, duration, and segment lifecycle.
- A tested HLS-capable player or probe that can retrieve both the playlist and its referenced segments.
If the RTSP source cannot be opened reliably from the deployment, stop there. Packaging does not repair camera authentication, route, firewall, packet-loss, or source-timestamp problems.
Create the RTSP-to-M3U8 recording path
- Verify the RTSP profile independently. Open the exact URL from the same network side as Callaba and confirm picture, audio, timestamps, and reconnect behavior. Use a least-privilege read-only camera account where the source supports one.
- Create a Video Stream Recorder job. Give the job an operational name that identifies the source and profile without exposing credentials.
- Select the RTSP URL input. Enter the tested URL and confirm that the job receives active media before changing the output profile.
- Select
m3u8as the output format. Treat this as the HLS packaging decision. The manifest is the index; the referenced media segments carry the presentation. - Choose pass-through or transcoding deliberately. Leave transcoding disabled only when the source codecs, level, frame cadence, audio, and segment behavior have already passed on the intended HLS player. Otherwise choose a reviewed video and audio profile supported by the deployment and downstream player.
- Start a bounded test. Watch input and recording statistics, locate the generated playlist, and keep the source running while several segments are produced.
Expected result: the job receives the RTSP source, writes an M3U8 playlist and referenced media segments, and the selected test client plays the package with the expected picture and audio. Whether the playlist remains live-updating or is finalized depends on the recording lifecycle and deployed output behavior.
Verify the manifest, segments, and playback separately
- Request the playlist from the intended client path. It should return successfully and begin with
#EXTM3U. - Check that its media-segment URIs resolve from that same client. A valid playlist with unavailable segments is not a working HLS output.
- Compare consecutive
#EXTINFdurations with the actual segment timing and inspect discontinuities after a source reconnect. - Play the output on a device representative of the real audience. Confirm video, audio, sync, start-up, ongoing reloads, and recovery after a controlled RTSP interruption.
- Inspect host load, disk growth, and retention. Then stop the test cleanly and verify the expected final playlist behavior for that recording mode.
RFC 8216 defines HLS playlists and segment responsibilities, but it does not certify a particular camera codec or Callaba deployment. Keep the test result attached to the exact source firmware, output profile, player, and software version.
Common failure points
| Symptom | What to inspect | Recovery |
|---|---|---|
| The job cannot open the RTSP source | URL encoding, credentials, camera profile, port, route, firewall, and RTSP transport behavior. | Re-test the same URL from the deployment network and repair source reachability before changing HLS settings. |
| The job is active but no useful playlist appears | Input media activity, selected output format, disk capacity, permissions, and worker statistics. | Run a short clean test with a known source and inspect the first generated files. |
| The playlist loads but video does not play | Segment URLs, HTTP status, codec and audio support, timestamps, MIME handling, authorization, and CORS at the serving layer. | Test the segments directly, then select a validated transcode profile if the media contract is incompatible. |
| Playback freezes after a camera reconnect | Playlist updates, discontinuity handling, source timestamp reset, and segment availability. | Verify the reconnect as a production test; do not infer recovery from the job's active flag. |
| Delay is higher than expected | RTSP buffering, transcode buffering, segment duration, playlist window, HTTP delivery, and player buffer. | Measure each stage. A different low-latency delivery design may be required; an M3U8 output alone is not LL-HLS. |
Keep packaging, serving, and playback as separate responsibilities
RTSP controls a media session between a source and a compatible receiver. HLS uses HTTP playlists and media segments for downstream delivery. Changing the output to m3u8 bridges those stages, but it does not make the RTSP camera an HLS origin or turn Callaba into an unqualified global CDN.
Browser support depends on the browser, player layer, media codecs, serving headers, access policy, and network path. Standard HLS output also carries no universal low-latency promise. If audience-scale delivery, token authorization, DRM, or LL-HLS is required, design and test those layers explicitly.
This task guide owns the concrete setup and verification path. Use the RTSP versus HLS guide for protocol selection and architecture rather than duplicating that comparison here.
Sources and related Callaba owners
- RFC 7826: Real-Time Streaming Protocol 2.0 — RTSP session and URI semantics.
- RFC 8216: HTTP Live Streaming — M3U8 playlists, media segments, and server/client responsibilities.
- Callaba Recordings API — current input, output-format, processing, and lifecycle fields.
- Callaba recording guide — source checks, output selection, statistics, storage, and retention.
- Callaba Live Video Recording — the product owner for managed live capture.
- Callaba Live Video Transcoding — the product owner when the HLS media profile must change.
Next steps
Save the tested RTSP profile, recording configuration, player result, and recovery notes together. Before exposing the playlist beyond the operator network, add the required HTTP access, authorization, retention, and delivery controls and repeat the test from the intended client path.
