Web players
Use Web players to publish live or recorded media for browser playback with access control, adaptive delivery, embeds, and viewer-facing URLs.
Choose this whenOne live or recorded source needs an HLS or DASH viewer URL or embed with access control or pay-per-view.
Use another module whenUse Multiview for operators; use Web Player Groups when viewers need several existing players.
/api/vod/createBefore you start
All management methods require a valid x-access-token. Prepare the input resource first and decide whether playback is open, password-protected, grouped, or connected to pay-per-view.
What you can do
createandupdateconfigure input, playback type, packaging, adaptive bitrate, access, grouping, and pay-per-view settings.getAll,getCount, andgetByIdinspect players.startandstopcontrol playback availability.getStatreports available input bitrate and cadence for the player process.removedeletes a player.
Example workflow
- Create a player from an SRT server, RTMP server, or supported media input.
- Choose HLS or DASH playback and tune segment duration and adaptive bitrate for the required latency and resilience.
- Apply open, password, group, or pay-per-view access settings.
- Start the player and check
getStatbefore testing the viewer URL. - Validate playback and the embed in representative browsers and networks.
Common use cases
- Publish an SRT or RTMP contribution as embedded live playback.
- Protect a partner review stream with viewer credentials.
- Deliver a paid event through configured pay-per-view access.
- Create language variants that belong to one web player group.
Limits and troubleshooting
A healthy page does not prove that the upstream media process is healthy; check getStat. Smaller fragments can reduce latency but increase request overhead and sensitivity to network variation. Test authorization, payment, embed policy, codecs, and adaptive variants before publishing.
Next steps
Open the player in a browser, verify access and playback, then use Web player groups when viewers need several selectable feeds.
Publish a managed file for browser playback
Prepare the media file, create a web player from the matching file input preset, and validate the generated HLS or DASH playback.
- Upload the sourceCreate the managed file record and keep its id for the player input.
POST /api/files/uploadFile - Create VOD playbackChoose the file input preset, delivery format, access policy, and presentation settings.
POST /api/vod/create - Start and test the playerStart the resource and test its viewer URL in representative browsers.
POST /api/vod/start
The player is a delivery resource; keep the source file managed separately and verify authorization, codecs, and browser playback before publishing its URL.
See the Video on Demand productCreate a web player through POST /api/vod/create. Send the dashboard-issued JWT in the x-access-token header.
The request combines a live input with HLS or DASH delivery settings, optional adaptive bitrate, transcoding, overlays, viewer authorization, pay-per-view, group assignment, and presentation fields.
Request examples
Choose the preset that matches the desired playback and access policy, then add only the optional fields that the viewer experience requires.
Common use cases
- Publish a public event stream as browser-ready HLS playback.
- Embed a restricted review player with password or viewer authorization.
- Prepare language, angle, or commentary players for a grouped viewing experience.
After starting a live player, use its playback URL and monitor viewer count, bitrate, and FPS.
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.
Resource id returned when you create or list 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.