- Name
- Verified event recording
- Path
- Managed file path
- Visibility
- Example choice: Private
- Output format
- Keep current unless another format is required
Record a live input and verify the finished file.
Choose an input Callaba can receive, including SRT, RTMP, RTSP, NDI or a Video Room. Record one continuous file or timed segments to encrypted internal disk, then open the result in File Manager. Review visibility, create a separate converted copy if needed, and add connected Storage only when the workflow needs it.
Follow the selected source through the recording workflow
Select a source below. It remains visible while you choose the file mode, optional processing and file checks.
Recorder can use a Callaba SRT Server, Route or explicit SRT URL. The accepted stream enters the recording job without changing the contribution design.
- Input family
- Managed + URL
- Recorder state
- Ready to configure
Continue with SRTThis source remains selected until you choose another. The next step sets how Recorder creates the file. No intermediate protocol conversion is required.
One continuous file or timed segments
A continuous file and timed segments support different recovery and retention plans. The selected mode remains visible during file verification.
Continuous file selectedA continuous recording depends on clean stop and finalization. Check this with a short file before the same job stays open for hours or days.
Follow SRT from runtime progress to an open file
Runtime state is useful, but it does not verify the file. Four checks connect the input, Recorder process, finished media and its File Manager record.
- 01Source
The selected SRT input has the expected picture, audio, identity and bitrate.
- 02Recorder process
FPS, bitrate, media time, speed and progress show that recording continues.
- 03Finalized file
The Continuous file output opens with the expected duration, timestamps, picture and audio.
- 04File Manager record
The completed recording appears in File Manager with the expected name, managed path, visibility and format.
File Manager continues the workflow after recording
Recorder writes the finished result to internal disk and sends its managed file record to File Manager. There you can name it, review visibility and its path, keep the current format or create a separate converted copy. Connected Storage remains optional.
Continue with SRT and Continuous fileThe recording above is now a managed file on internal disk. Capture has finished; visibility and optional conversion remain separate choices, and connected Storage is added only when needed.
Create a separate copy for another format
Changing the output format or transcoding settings starts a background rewrite. This creates a separate converted copy, or derivative. The original remains unchanged in its own managed file record.
Connected Storage is optional
Recording works on internal disk without an external Storage. When a Storage is configured, Callaba registers object storage with its metadata service, formats the volume and mounts it in a POSIX-compatible namespace. File Manager can then copy a verified file through that familiar filesystem path and show copy progress.
Encryption applies to files on the default internal disk and in optional connected Storage. Raw access to physical disk or backing object-storage blocks alone does not expose a readable or playable media file.
Visibility is stored on the managed file record and should be reviewed before publishing or playback. The Private value shown here is an example, never an assumed default.
Recorder writes locally by default. Optional object-storage targets remain behind File Manager, and the installed interface is the authority for available Storage types.
Video Stream Recorder technical specification
This table describes the supported behavior. Capacity depends on the node, and some choices depend on the installed version. The installed Callaba interface remains the authority for selectable inputs and fields.
| Capability | Supported behavior | How to verify |
|---|---|---|
| Input families | Managed SRT and RTMP modules; SRT Routes; SRT, RTMP, RTSP, HLS, MPEG-DASH, RIST, UDP, RTP and HTTP paths; NDI; Video Rooms; file and generated test sources where available in the installed UI. | A short source test should show the expected picture, audio, identity and recovery before a long capture. |
| Recording modes | One continuous file or split-by-time recording. | A short continuous test should stop cleanly. Split mode also needs several consecutive files with intact boundaries. |
| Segment duration | Hours, minutes and seconds define the split interval. | The first finished segments should match the configured duration without unexplained gaps or drift. |
| Output families | MP4, growing MKV, growing MPEG-TS and HLS archive output; additional audio/file formats depend on the selected processing path and installed version. | The finished result should have the expected container, duration, tracks, timestamps and seek behavior where required. |
| Video processing | Optional codec, bitrate, frame-size, frame-rate, GOP and related transcoding controls. | The file should match the archive profile. Transcoding can remain disabled when compatible media should be preserved. |
| Audio processing | Optional audio codec/rate settings plus track and channel selection. | The finished file should contain the intended programme mix, audio tracks and channel layout. |
| Image overlay | Optional prepared image overlay with an explicit position. | The whole output frame should show the graphic in the intended position without covering required content. |
| Runtime statistics | FPS, bitrate, media time, speed and progress where returned by the running worker. | Media time and progress should continue to advance. Runtime statistics alone do not verify the file. |
| Default file location and retention | Recorder writes files to internal disk by default. Age-based automatic deletion of local recording files is optional. | Verify the finished local file before enabling deletion. If connected Storage is used, also complete its copy and read-back first. |
| File Manager | Completed recordings enter the managed file workflow with name, path, description, visibility, output-format and processing metadata. | The finished recording should have the correct File Manager record, duration, size and visibility, and its media should play. |
| Post-recording conversion | Changing output format or transcoding settings can start a background rewrite that creates a managed derivative, including MP4, HLS or audio-only workflows. | After rewrite progress completes, the derivative should match the requested format, tracks, duration and timestamps. |
| Optional POSIX-compatible storage | When connected Storage is configured, its object storage and metadata service are formatted and mounted as a managed POSIX-compatible filesystem namespace. Recorder does not require this layer to write to internal disk. | If used, a mounted Storage should accept a non-critical File Manager copy and return the same file through the managed path. |
| Encryption at rest | Managed files on the default internal disk and in optional connected Storage are encrypted at rest; raw disk or backing object access alone does not expose playable media. | Normal and recovery access should use Callaba's managed file path; raw storage blocks are not media files. |
| Optional storage handoff | File Manager can copy a verified internal-disk file to a configured object-storage-backed volume and expose copy progress. | When this optional handoff is used, the copy should complete and read back from the intended Storage before local deletion applies. |
| Lifecycle control | Create, update, list/count, get by id, start, stop, get statistics, remove file and remove job through UI/API workflows. | A non-critical source can establish start, stop, restart and clean removal behavior. |
| Deployment | Callaba cloud deployment or self-hosted Linux, with capacity determined by source media, processing, concurrent jobs and storage design. | The selected node needs a load test with the real source mix, recording modes, processing and disk behavior. |
Keep recording and file handling in the same deployment
Run Recorder in a Callaba cloud deployment or on self-hosted Linux. In either case, recording starts on encrypted internal disk and connected Storage remains optional.
Callaba in AWS
Start a managed Callaba node with Recorder and File Manager in the same operational surface, then size compute and disk for the real source and processing mix.
Deploy Callaba on AWSSelf-hosted Callaba
Keep the application, network paths and encrypted media on infrastructure operated by your team, with optional connected Storage added only when required.
Install Callaba self-hostedUse the same Recorder lifecycle through REST
Create or update a recording, start and stop it, read runtime statistics, list the resulting files and remove a file or job. The Files API continues the workflow after capture ends; the Storages API is available when connected Storage is added.
Video Stream Recorder FAQ
Which sources can Video Stream Recorder use?
Recorder uses Callaba's shared input model. The current production version includes managed and URL-based live protocols, NDI and Video Rooms. The exact source selector remains the authority for the installed version.
Can Callaba record a Video Room?
Yes. A Video Room can provide a grid or speaker-composite programme to the recording workflow. Before a full session, make a short recording with the intended layout and check participant audio.
Can recordings be split automatically?
Yes. Select timed-segment mode and set the segment duration. Check the first completed files for gaps before segment boundaries are used for retention or downstream automation.
Can File Manager change a recording's format?
Yes. A managed file can be saved in another output format with optional video or audio transcoding. A background rewrite creates a separate converted copy, called a derivative, and File Manager shows its progress.
Does Recorder require an S3 bucket or connected Storage?
No. Recorder writes to internal disk by default, and File Manager manages the resulting file there. Connected Storage is optional. When configured, Callaba mounts it as a POSIX-compatible filesystem backed by object storage and metadata, and File Manager can copy a verified file into that namespace. Public and private are separate visibility options on the file record.
Are files encrypted on internal disk and connected Storage?
Yes. Callaba stores managed files encrypted at rest on the default internal disk and in optional connected Storage. Raw disk or object-storage blocks alone do not expose a readable or playable media file; the managed access path is required.
Can the recording lifecycle be automated?
Yes. The Recordings API controls capture, the Files API manages metadata, format rewrites and copies, and the Storages API registers destinations. File playback and storage read-back remain separate checks.
Check one source with one short file.
Use the real input, make a short recording to internal disk and stop it cleanly. Open its File Manager record and review visibility and format. If the workflow uses connected Storage, copy the verified file and read it back before increasing duration or source count.