RTSP Recording: Segments, Retention & Recovery | Callaba
More live video workflow notes and product updates.
RTSP recording turns a live session into files that can be found, decoded, retained and deleted predictably. The recorder first has to negotiate the RTSP resource and receive its RTP media. It then preserves or transforms the tracks, writes a container, closes each segment cleanly and exposes evidence that the output actually advanced. A connected input alone is not a valid recording.
A recording is a lifecycle, not a long-running socket
Callaba already records RTSP inputs as a managed workflow
The Callaba Recording API accepts an RTSP URL input, supports continuous or timed file clips, retention and automatic deletion, an optional backup source, optional media processing and live statistics. Completed files appear with the recording job and can be managed through File Manager. This is an existing RTSP recording path. It is not a promise that every camera codec, RTSP authentication method, storage mount or damaged source will work without validation.
| Recording stage | Existing Callaba action | Acceptance evidence |
|---|---|---|
| Source | Create the Recording with the approved RTSP URL and selected input type | Bitrate, FPS and output time advance from the expected tracks |
| File production | Select output format, continuous or timed clips and only required processing | A closed file has expected duration, codecs, tracks and seek behavior |
| Lifecycle | Apply retention and use recordedFiles or File Manager for produced assets | Inventory, storage and deletion state converge under the stated policy |
The adjacent improvement is a source-to-file incident timeline that correlates RTSP control, RTP continuity, recorder progress, segment close, storage commit and retention action. The recording feature itself should remain visible as implemented rather than described as a future integration.
Validate the RTSP source before choosing file settings
Resolve the exact resource, credential owner, permitted client count and transport mode. Capture the presentation description, selected video and audio tracks, codec profiles, frame and sample rates, and timestamp behavior. The RTSP camera workflow covers acquisition; the recorder begins where a stable, authorized source is available.
RTSP 2.0 controls the session, while negotiated media commonly uses RTP. Record control responses and packet arrival separately. A successful PLAY does not prove that UDP packets reach the recording host.
Copy tracks when compatible; transcode for a named reason
Stream copy avoids a new lossy generation and reduces compute, but the selected container must accept the source codecs, timing and track layout. Transcode only for an explicit output requirement: codec compatibility, normalized dimensions or frame rate, audio layout, overlay, bitrate or damaged timing that a defined process can repair.
Keep the decision per track. Video may be copied while audio is transcoded, or an unwanted metadata track may be excluded. After start, compare the actual output probe with the declared map. A configuration field is intent; the file is evidence.
Segment length determines the recovery and operations unit
Short clips bound the amount of material at risk when a process or host fails and let downstream systems consume finished assets sooner. They also create more files, metadata operations and boundary opportunities. Long clips reduce object count but enlarge the unclosed interval and delay validation.
Choose segment duration from recovery point, archive workflow and programme boundaries rather than a convenient round number. Define filename uniqueness across restarts and daylight-saving changes. Record timestamps in an unambiguous clock domain and preserve the source-to-file relationship.
Closed files and partial files need different policy
A container may need final indexes or metadata written at close. If the recorder stops abruptly, the newest file may be absent, truncated or require repair. Do not present it beside verified assets until the selected format passes a probe. Keep partial output in an isolated state with a bounded repair or deletion process.
For each completed segment, check non-zero size, duration range, expected tracks, monotonic timestamps and a representative decode. File creation time alone cannot distinguish usable content from a header-only artifact.
Retention starts from an explicit event
Name whether age begins at segment open, close, inventory registration or programme end. State whether retention applies to local working files, archives and derived copies. Legal hold and incident preservation must override ordinary deletion through an authorized, auditable path.
Callaba can apply recording retention and automatic deletion within the documented job lifecycle. When files are copied elsewhere, the receiving storage and catalog need their own verified expiry. The File Manager guide owns managed asset operations; it does not prove deletion from untracked copies.
Example: the recorder is running, but the newest file is frozen
The job remains active and its RTSP connection has not closed, yet the latest clip duration stops growing after a camera reboot. The first comparison is recorder out_time_ms and file size beside RTP packet arrival and timestamps from the same interval. If packets resumed with a discontinuous clock that the muxer did not accept, the root cause is at the source-timestamp-to-container boundary—not storage capacity merely because no new bytes appear.
Design backup and reconnect behavior before the incident
A backup source must represent the same intended programme and a compatible track contract. Decide how the recorder detects primary failure, whether a switch opens a new file, how it marks discontinuity and when primary service may return. “Backup configured” does not imply seamless media.
Test source loss, credential denial, UDP blockage, camera restart, recorder restart and storage interruption separately. Observe time to new bytes, damaged interval, segment naming and which source produced each file. Keep the result with the runbook.
Commission recording through file deletion
- Create one controlled job. Use the Recording API with an approved source, format, segment and retention contract.
- Verify live progress. Check bitrate, FPS, speed and output time; do not rely on active state alone.
- Probe completed files. Validate duration, tracks, codecs, timestamps, seek and representative decode.
- Interrupt the source. Bound the missing interval and prove reconnect and partial-file behavior.
- Exercise the backup. Identify the selected source and validate the first closed file after transition.
- Prove retention. Let a test asset expire and confirm it leaves the managed inventory and intended storage boundary.
RTSP recording FAQ
Does RTSP itself define the recording file format?
No. RTSP controls a media session. The recorder chooses a compatible output container, track mapping and processing policy for the received media.
Should every RTSP recording be transcoded?
No. Copy compatible tracks when that meets the output contract. Transcode only when a codec, media property, overlay or destination requirement demands it.
What segment duration is best?
There is no universal value. Balance recoverable loss, time to a closed asset, file count, archive behavior and programme boundaries, then test failure at a segment transition.
Can active status prove that recording is healthy?
No. Confirm that output time and bytes advance, then probe a completed file. A process can remain active while its input, timestamps or storage output has stalled.