Repository navigation
Technical Live Streaming
Audience: developers and advanced administrators. Baseline reviewed: 2026-10-29.
| Stage | Evidence |
|---|---|
| Ingest | RTMP publish/end callbacks, actual Nginx listeners and live-session history |
| Live conversion | Relevant FFmpeg process/log, input/output codecs, speed and continuity |
| Playback | Master and variant HLS playlists, segments, keys and actual client playback |
| Restream | Separate process/log/progress and destination state for each configured target |
| Recording | Physical file, start/end/duration, recording callback and storage location |
| Post-processing | Encoder job, transfer/completion result and published video variants |
The Live plugin coordinates the external server; it does not itself implement RTMP ingest. Discover the real Nginx binary/configuration. A custom installation can use /usr/local/nginx; the distribution service unit is not sufficient evidence of that installation's health.
plugin/Live/on_publish.php processes an incoming publish and invokes Live::_on_publish(). The latter can request automatic restream via restreamInBackground() and dispatch the on_publish plugin hook. SendRecordedToEncoder can start recording with Live::controlRecordingAsync().
Background restream startup matters because destination checks/startup can delay the recording hook when executed synchronously. The current background helper has platform/exec fallbacks; trace the actual server platform rather than assuming the same scheduling behavior everywhere.
Recording control, record completion and subsequent encoding are distinct events. A reconnect can belong to an existing history session while producing a separate physical recording. Compare files with publish events rather than assuming one history row equals exactly one recording.
Restream sources can remain reloadable after ingest stops. Distinguish a normal source-end condition from a failure during an active broadcast. Process cleanup must identify the current relay and its actively written log; a stale log for the same source URL can belong to an older process.
Each destination needs its own assessment. A local FFmpeg process proves that sending was attempted, not that a remote platform accepted/playable/archived the broadcast. Playlist-scheduled relays are separate from individual restream destinations and must retain their own process identity.
WebRTC controls a separate WebRTC2RTMP service. Check its listener, served certificate and child conversion processes. Certificate files renewed on disk can differ from what a long-running process serves. Thread listings are not a reliable count of independent service instances.
Identify the actual session from history, normalize application/host/database time zones and correlate the complete chain. Record start/end/reconnect times and concrete gaps. For recordings, compare duration and beginning/tail coverage with the live; validate stored media and final variants.
Inspection does not authorize restarting services or stopping broadcasts. Authenticated playback, destination viewing/archive and full audiovisual review must be reported as untested when unavailable. See troubleshooting.
