Search the module, then move faster through the API
Find the exact module, copy the working request shape, and move from product workflow to API call without getting buried in the tree.
AI workflow helperDescribe what you want to buildOptional tool
Write the workflow in plain language. We will turn it into a GPT-ready brief you can use to generate requests, module order, and starter payloads.
Web players
Find an endpoint
Web players are the delivery and playback control layer for browser viewing in Callaba Engine. Use this API to create a viewer-facing endpoint from an existing live input, publish browser-ready HLS or DASH output, configure embed and access settings, and control when the player is available.
Keep the responsibilities separate: ingest APIs handle source-side reliability and transport continuity, while Web players handle viewer experience tuning and playback operations. In this module, you assign the source signal, tune packaging and adaptive bitrate behavior, optionally enable authorization or pay-per-view, and use methods such as start, stop, and getStat to operate live delivery.
Live playback playground
For this module, it helps to see both delivery surfaces in one place: direct browser playback against a public HLS manifest and the hosted Callaba player as an iframe embed. The playground below gives you both, together with live viewer-side stats so you can inspect what the playback layer is actually doing.
Use the player first when the question is viewer experience. Use getStat when the question is whether the playback process still has believable bitrate and cadence upstream.
Runtime playback signals
getStat for Web players answers the source-side question first: is the playback process still receiving media with believable bitrate and cadence. That makes it the fastest operational check before you blame embed logic, branding, access control, or the viewer browser itself.
The preview below mirrors the same runtime fields documented for getStat. Use it when playback quality looks wrong and you want to confirm whether the player process still has a healthy upstream signal to package.
Preview the runtime shape behind a live web player
For web players, getStat answers both sides of the first operational question: is the player process still receiving believable source media, and are viewers actually connected right now. Together these fields tell you whether playback still has a healthy upstream signal and whether the audience is actively watching.
bitrate_kbits
Previewing the same runtime signal operators usually inspect first.
4,700 kbits/s
This is the source-side signal the player process still has something healthy to package.
30.0
The fastest way to tell whether playback quality issues already started before the viewer layer.
8
Current connected audience reported by the same getStat response used for the live player process.
continue
3:00 packaged · 1.00x worker speed
Use this runtime check before you blame the viewer layer. If bitrate and cadence already look wrong here, the issue is usually upstream of branding, access control, or embed logic.
Examples by preset
The most useful presets for this module are playback workflow shapes rather than transport families alone: expose one live source as one public player, protect the player behind authorization, group related players together, or prepare the player for adaptive bitrate playback.
SRT server to public web player
{
"vod_name": "Main stage player",
"vod_type": "VOD_TYPE_LIVE_STREAM",
"input": {
"input_type": "INPUT_TYPE_SRT_SOFTWARE",
"input_module_id": "SRT_SERVER_ID",
"input_stream_id": "",
"entity_name": "Main stage player",
"module_name": "MODULE_VOD"
},
"authorization": {
"authorization_type": "VOD_PASSWORD_DISABLED",
"credentials": []
},
"adaptive_bitrate_settings": {
"input_resolution": "MAX_RESOLUTION_UNSET"
},
"hls_fragment_size": 3,
"hls_fragment_length": 60,
"dash_fragment_size": 3,
"dash_fragment_length": 60,
"initial_live_manifest_size": 4,
"live_sync_duration_count": 5,
"pay_per_view_settings": {
"type": "PAY_PER_VIEW_DISABLED",
"client_id": ""
},
"active": true
}RTMP server to public web player
{
"vod_name": "RTMP browser player",
"vod_type": "VOD_TYPE_LIVE_STREAM",
"input": {
"input_type": "INPUT_TYPE_RTMP_SOFTWARE",
"input_module_id": "RTMP_SERVER_ID",
"input_stream_id": "",
"entity_name": "RTMP browser player",
"module_name": "MODULE_VOD"
},
"authorization": {
"authorization_type": "VOD_PASSWORD_DISABLED",
"credentials": []
},
"adaptive_bitrate_settings": {
"input_resolution": "MAX_RESOLUTION_UNSET"
},
"hls_fragment_size": 3,
"hls_fragment_length": 60,
"dash_fragment_size": 3,
"dash_fragment_length": 60,
"initial_live_manifest_size": 4,
"live_sync_duration_count": 5,
"pay_per_view_settings": {
"type": "PAY_PER_VIEW_DISABLED",
"client_id": ""
},
"active": true
}Password-protected web player
{
"vod_name": "Partner review player",
"vod_type": "VOD_TYPE_LIVE_STREAM",
"input": {
"input_type": "INPUT_TYPE_SRT_SOFTWARE",
"input_module_id": "SRT_SERVER_ID",
"input_stream_id": "",
"entity_name": "Partner review player",
"module_name": "MODULE_VOD"
},
"authorization": {
"authorization_type": "VOD_PASSWORD_ONLY_MANUALLY",
"credentials": [
{
"email": "[email protected]",
"password": "guest-password"
}
]
},
"adaptive_bitrate_settings": {
"input_resolution": "MAX_RESOLUTION_UNSET"
},
"hls_fragment_size": 3,
"hls_fragment_length": 60,
"dash_fragment_size": 3,
"dash_fragment_length": 60,
"initial_live_manifest_size": 4,
"live_sync_duration_count": 5,
"pay_per_view_settings": {
"type": "PAY_PER_VIEW_DISABLED",
"client_id": ""
},
"active": true
}Grouped variant player
{
"vod_name": "Main stage EN",
"vod_type": "VOD_TYPE_LIVE_STREAM",
"input": {
"input_type": "INPUT_TYPE_SRT_SOFTWARE",
"input_module_id": "SRT_SERVER_ID",
"input_stream_id": "",
"entity_name": "Main stage EN",
"module_name": "MODULE_VOD"
},
"authorization": {
"authorization_type": "VOD_PASSWORD_DISABLED",
"credentials": []
},
"adaptive_bitrate_settings": {
"input_resolution": "MAX_RESOLUTION_UNSET"
},
"hls_fragment_size": 3,
"hls_fragment_length": 60,
"dash_fragment_size": 3,
"dash_fragment_length": 60,
"initial_live_manifest_size": 4,
"live_sync_duration_count": 5,
"group_settings": {
"group_id": "VOD_GROUP_ID",
"name": "English",
"selected": true
},
"pay_per_view_settings": {
"type": "PAY_PER_VIEW_DISABLED",
"client_id": ""
},
"active": true
}Workflow examples
These scenarios frame why a web player exists in a production design, not only how the request body is shaped.
Use a web player when a live source should become a browser playback endpoint
Create a web player when the operational goal is not just to receive a stream, but to expose it as a viewer-facing browser experience with a stable player URL and a generated HLS output.
- Why it helps: one API object covers ingest hookup, playback packaging, and viewer-facing delivery settings.
- Typical fit: event pages, internal monitoring players, embedded live playback, and browser viewing for SRT or RTMP sources.
Use a web player when access control belongs in the playback layer
The web player module is also where playback access is shaped. That includes password-based access, optional pay-per-view settings, and player grouping for multi-variant or multi-language viewing experiences.
- Key controls:
authorization,group_settings, andpay_per_view_settings - Typical fit: partner review rooms, restricted event streams, grouped language feeds, and managed viewer onboarding.
Use a web player when delivery tuning matters as much as the source
The playback side is shaped by fragment size, playlist length, and adaptive bitrate settings, not only by the input source. That makes this module the right place to tune viewer experience rather than only ingest reliability.
- Key controls:
adaptive_bitrate_settings,hls_fragment_size,hls_fragment_length,initial_live_manifest_size, andlive_sync_duration_count - Operational fit: player startup tuning, buffering reduction, and ABR-oriented playback preparation.
Creates a new web player in Callaba Engine.
The backend exposes this method as POST /api/vod/create. The payload combines a live input definition with playback-specific controls such as HLS and DASH fragment settings, adaptive bitrate configuration, optional authorization, optional pay-per-view, optional group assignment, and optional presentation fields.
The create flow follows the same shape in the product UI. In practice, the request body is assembled from source settings, playback delivery settings, optional transcoding, optional audio or video modifications, optional overlay settings, and access-control choices.
In the dashboard, operators see this through labels such as Player name, Input type, Web player URL, HLS fragment size, and authorization controls for restricted playback.
Although the examples below focus on live playback, the same module also supports on-demand-style player types and group-driven viewer experiences.
Authentication uses the dashboard-issued JWT token in the x-access-token header.
Examples by preset
The examples below are grouped by playback presets rather than by one oversized payload. That makes them easier to reuse for real viewer-facing workflows.
Workflow-oriented use cases
Use a web player when a live source should become a browser playback endpoint with stable URLs, delivery settings, and viewer-facing access rules.
- Good fit for: public event pages, partner review players, embedded live playback, grouped language feeds, and browser-ready HLS delivery.
- Not the same as: an ingest boundary like
SRT serversor a processing pipeline likeRestreams.
Once a player is live, operators usually care about three things first: whether viewers can open the player, what viewer count the playback layer currently sees, and what live bitrate and FPS the process is reporting.
Use this preset when one managed SRT source should become one public browser playback endpoint with no access barrier.
This is the cleanest live-player setup for open browser viewing. The player layer handles packaging and playback while the source remains managed upstream.
This keeps the playback contract stable even if the ingest transport on the source side remains RTMP.
Use this preset when the player should exist, but not as a public page. The browser endpoint is still generated, but access is gated by player-side credentials.
This is a good fit for partner review, internal screenings, premium previews, or any case where access control belongs in the playback layer itself.
Use this preset when one player should join a group of related browser endpoints, for example different languages, programs, or alternate event views.
The grouped-player path is useful when the browser experience is bigger than one isolated URL and the viewer should move between related player variants.
Use this preset when the browser side should be prepared for adaptive bitrate playback rather than a single unscaled rendition.
The real product ties adaptive bitrate to playback tuning and transcoding. This makes it useful when startup stability and viewer-side quality adaptation matter more than one fixed rendition.
Dashboard label: Player name.
Human-readable playback endpoint name. The create form validates it as required.
Player type. The default live workflow uses VOD_TYPE_LIVE_STREAM, while the product also supports on-demand styles.
Optional media type descriptor stored on the player object.
Dashboard label: Input type.
Input definition built from the shared source form. Real product-facing inputs include SRT servers, RTMP servers, SRT routes, and URL-based live sources.
Adaptive bitrate settings for the player. The product uses input_resolution as the key delivery decision and ties ABR to the transcoding layer.
Dashboard label: HLS fragment size.
The UI guidance recommends 3 seconds for a good HLS experience.
Dashboard label: HLS fragment length.
The UI guidance recommends 60 seconds.
DASH-side fragment sizing controls stored with the player object.
Dashboard label: Minimal HLS fragment count.
Controls how many fragments are preloaded before playback begins.
Dashboard label: Edge of live delay.
Controls how far from the latest fragment playback should start for live viewing.
Player-side authorization settings. The UI uses this to require viewer authorization before the web player can be opened.
Optional group assignment block with group_id, per-group display name, and selected default state.
Optional monetization block. The disabled state remains the normal default for most players.
Optional presentation and branding settings for the browser-facing player experience.
Optional event and support metadata stored with the player object.
Optional media processing blocks used when the player should do more than simple pass-through packaging.
Dashboard label: Enable once created.
Controls whether the player should be active right after provisioning.
Mongo-style identifier of the web player.
Convenience alias for _id.
Name stored for the player object.
Player type and media-type fields stored on the object.
Generated internal port used by the player delivery runtime.
Linked input object or objects used by the playback pipeline.
Playback-delivery settings stored on the player object.
Access, monetization, group, and viewer-authorization state stored on the player.
Presentation and visibility settings returned with the player object.
Current running-state flag for the player.
Timestamps managed by the backend.
The model exposes success: true as a virtual field in successful responses.