RTMP-to-HLS is a handoff from encoder-facing ingest to HTTP-based playback. Receive and verify the RTMP publisher first; package or transcode it for HLS second; then test the playlist and player endpoint a viewer actually uses. An RTMP connection alone is not browser playback.
The RTMP-to-HLS path
At minimum, the path is source → RTMP listener → media processing or packaging → HLS playlist and segments → player. Each stage can be healthy while a later stage is not. This is why an operator should keep ingest proof and viewer proof as separate checks.
Decide whether the media can be copied
Packaging may be possible without video transcoding only when the incoming codecs, audio, timestamps, keyframe cadence, and packaging contract fit the target HLS path. If they do not, transcode deliberately and document the output ladder. Do not call this a universal copy path without checking the configured output.
Validate in order
- Publish a known RTMP source and confirm the listener reports activity and usable media.
- Open the generated HLS playlist URL and confirm it updates while the source is live.
- Check that the listed segments can be fetched by the intended player environment.
- Listen for audio, inspect video, and measure the actual viewer delay for the deployed path.
- Stop and restart the publisher; confirm that the playlist and player recover as your operations plan expects.
Keyframes, segments, and latency
HLS groups media into segments referenced by a playlist. Apple’s HLS overview and RFC 8216 describe the playlist-and-segment delivery model. Segment duration, encoder keyframes, player buffering, origin behavior, and any CDN configuration all contribute to viewer delay. Reducing one buffer does not establish a latency result for the complete path; measure the path you intend to operate.
When RTMP is healthy but HLS fails
| Observed result | Next check |
|---|---|
| Publisher active, no playlist | Inspect the RTMP-to-HLS job and its output configuration. |
| Playlist loads, player stalls | Check segment delivery, player errors, codec compatibility, and access policy. |
| Playback starts late | Measure encoder, packaging, playlist, player, and delivery buffers before changing a setting. |
Callaba can receive a configured RTMP source and hand it to the selected downstream workflow. The listener is not itself a public browser player. For the browser diagnosis, use RTMP player and browser playback; for ingest configuration, use RTMP Server.
Related configuration
Use the RTMP Server operator guide to prove ingest, then review Web Player documentation for the viewer-facing module. Keep the RTMP protocol guide for the source-side transport question.
Local diagnostics: package HLS with FFmpeg
mkdir -p hls-out && ffmpeg -re -i input.mp4 -c:v libx264 -pix_fmt yuv420p -g 60 -c:a aac -f hls -hls_time 2 -hls_list_size 6 -hls_flags delete_segments hls-out/live.m3u8Expected result: live.m3u8 changes as the input runs and references recent media segments in hls-out. Serve that directory through an HTTP server for a browser test; opening a filesystem path is not an HLS origin test. At 30 fps, -g 60 gives a two-second keyframe cadence aligned with the example segment duration. Adjust it with the real frame rate.
Safari has platform HLS playback; many other browser implementations use Media Source Extensions through a player library rather than treating every .m3u8 as a native HTML video source. Test the actual browser/player pair. Callaba’s documented UI flow is to create a Web Player from the selected RTMP Server or other supported input, open the resulting player URL, and verify access and playback; see Web Player documentation.
Next steps
Use the RTMP Server operator guide to prove ingest, then review Web Player documentation for the viewer-facing module.
