Create and operate SRT and RTMP ingest, routing, Multiview, recording, web playback, storage, and video calls in one product. Configure the workflow visually first, then automate the same modules through REST on AWS or your own Linux infrastructure.
The API configures modules and reads their current state; SRT and RTMP carry the live video. Create ingest once, then monitor, route, record, and publish without sending the media through your application.
RESTStart from controlled ingest, then package and deliver through players, CDN-friendly outputs, and viewer-facing surfaces. This is especially useful when the same source has to feed operators, viewers, recordings, and downstream destinations at once.
Keep the live output running while Callaba creates a recording in parallel. Use the resulting file for clipping, replay, or later VOD publishing without rebuilding the live path around a separate recorder. Retention and storage follow the destination you configure.
The API configures modules and reads their current state; SRT and RTMP carry the live video. Create ingest once, then monitor, route, record, and publish without sending the media through your application.
Start from controlled ingest, then package and deliver through players, CDN-friendly outputs, and viewer-facing surfaces. This is especially useful when the same source has to feed operators, viewers, recordings, and downstream destinations at once.
REST exposes documented configuration, lifecycle calls, and the current active state. The authenticated operator UI shows live SRT transport telemetry while a session runs. Recordings, files, and storage destinations remain explicit workflow modules.
The platform is organized around operational modules such as SRT servers, routes, restreams, recordings, players, rooms, storages, and files. That gives your developers a cleaner mental model than a vague all-in-one endpoint surface.
Your team does not just get method references. It gets presets, workflow examples, language tabs, vMix snippets where they matter, and module-specific examples that reflect how the platform is actually used in production.
REST exposes documented configuration, lifecycle calls, and the current active state. The authenticated operator UI shows live SRT transport telemetry while a session runs. Recordings, files, and storage destinations remain explicit workflow modules.
Supported behavior sits beside a practical acceptance check. The installed Callaba interface and the real source, destination, and infrastructure profile remain authoritative.
| Capability | Supported behavior | Acceptance check |
|---|---|---|
| Record a live stream without stopping delivery | Keep the live output running while Callaba creates a recording in parallel. Use the resulting file for clipping, replay, or later VOD publishing without rebuilding the live path around a separate recorder. Retention and storage follow the destination you configure. | Yes. Keep live playback or routing running while Callaba creates a recording in parallel. Use the resulting file for clipping, replay, or later VOD publishing, and define retention through the storage destination you configure. Automate the workflow through the Recordings module when needed. |
| Use modules instead of one giant black box | The platform is organized around operational modules such as SRT servers, routes, restreams, recordings, players, rooms, storages, and files. That gives your developers a cleaner mental model than a vague all-in-one endpoint surface. | You can build much more than playback. The product is organized into modules for ingest, routing, restreaming, recording, players, calls, files, and storages, so teams can assemble the workflow they actually need instead of forcing everything through one narrow surface. |
| Control the workflow without carrying video through your app | The API configures modules and reads their current state; SRT and RTMP carry the live video. Create ingest once, then monitor, route, record, and publish without sending the media through your application. | Yes. The main workflow modules such as SRT servers , Restreams , Recordings , Web players , and Video calls expose start and stop methods where that lifecycle matters. |
| Move from ingest to global playback without changing products | Start from controlled ingest, then package and deliver through players, CDN-friendly outputs, and viewer-facing surfaces. This is especially useful when the same source has to feed operators, viewers, recordings, and downstream destinations at once. | Create a web player from the ingest source you want to expose. The player module handles packaging and viewer-facing playback, and you can place a CDN such as CloudFront in front of it when you need wider distribution. |
| Choose cloud or self-hosted without changing the product model | The same API-oriented mindset works whether you want a fast cloud proof of value or a self-hosted deployment with full control over infrastructure, data, and rollout decisions. | Yes. The deployment choice changes how you operate the infrastructure, but the product model stays the same. That means your team can prototype in cloud, move to self-hosted when needed, and continue using the same module-oriented API surface. |
| Built for production operations, not just demos | REST exposes documented configuration, lifecycle calls, and the current active state. The authenticated operator UI shows live SRT transport telemetry while a session runs. Recordings, files, and storage destinations remain explicit workflow modules. | Use the SRT servers module for documented REST configuration and the current active-stream snapshot. Operators monitor live bitrate, RTT, and transport health in the authenticated Callaba UI while the session runs. Treat that telemetry as live operational context, not a durable history or event-log archive. |
You have seen what the product does. These three guides take you into the exact controls, show what to connect next, and give you a practical check before the workflow goes live.
The same API-oriented mindset works whether you want a fast cloud proof of value or a self-hosted deployment with full control over infrastructure, data, and rollout decisions.
The pay-as-you-go cloud tariff supports fast Callaba Video API deployment, regional placement, scaling, and product operations without a self-hosted installation. Configure recording destinations and retention explicitly for your workflow.
Deploy Callaba on AWSThe unlimited tariff is a good fit for actively growing broadcasting organizations of medium and large size that would like to have no limitations like those in the bundled tariff, while also maintaining full control over their data.
Install Callaba self-hostedStart with one quick live-player path, then expand into ingest, routing, recording, playback, calls, storage, and operational control using the module examples below. The goal is not a demo-only request, but a realistic map of the product surface your engineers will actually use.
Start by creating an SRT server or RTMP server. That gives your encoder, OBS, vMix, or field unit a stable ingest destination that the rest of the workflow can build around.
Create a web player from the ingest source you want to expose. The player module handles packaging and viewer-facing playback, and you can place a CDN such as CloudFront in front of it when you need wider distribution.
Yes. DVR behavior is controlled on the Web players side. In practice, teams tune fragment and manifest settings to decide how much recent history a viewer can rewind during a live event.
Yes. Keep live playback or routing running while Callaba creates a recording in parallel. Use the resulting file for clipping, replay, or later VOD publishing, and define retention through the storage destination you configure. Automate the workflow through the Recordings module when needed.
Use the SRT servers module for documented REST configuration and the current active-stream snapshot. Operators monitor live bitrate, RTT, and transport health in the authenticated Callaba UI while the session runs. Treat that telemetry as live operational context, not a durable history or event-log archive.
Yes. The main workflow modules such as SRT servers, Restreams, Recordings, Web players, and Video calls expose start and stop methods where that lifecycle matters.
You can build much more than playback. The product is organized into modules for ingest, routing, restreaming, recording, players, calls, files, and storages, so teams can assemble the workflow they actually need instead of forcing everything through one narrow surface.
Yes. The deployment choice changes how you operate the infrastructure, but the product model stays the same. That means your team can prototype in cloud, move to self-hosted when needed, and continue using the same module-oriented API surface.
Start with Callaba Engine documentation for the product map, then go straight to the module closest to your first workflow boundary: SRT servers, Restreams, Web players, Recordings, or Video calls.
The same API-oriented mindset works whether you want a fast cloud proof of value or a self-hosted deployment with full control over infrastructure, data, and rollout decisions.