Restreams
Use Restreams to simulcast or deliver a live input to streaming platforms and private endpoints. Remux when formats match, or transcode, resize, adjust audio, and add overlays when they do not.
Choose this whenA live source must reach another platform or protocol, optionally with transcoding, resizing, audio changes, or overlays.
Use another module whenUse SRT Routes for unchanged SRT or UDP forwarding; use Web Players for viewer playback.
/api/restream/createBefore you start
All methods require a valid x-access-token. Create any referenced input module first and confirm that the output destination accepts the selected protocol, codec, resolution, bitrate, and credentials.
What you can do
createandupdateconfigure the input, output, transcoding, media modification, and overlay settings.getAll,getCount, andgetByIdinspect jobs.startandstopcontrol the live pipeline.getStatreports available bitrate, cadence, and process status.removedeletes a job.
Example workflow
- Select a managed input or a supported URL source.
- Set an RTMP, SRT, RIST, or other supported destination.
- Enable transcoding or media changes only when the output requires them.
- Start the job and use
getStatto confirm media is moving. - Stop the job before changing credentials or destination settings.
Common use cases
- Send one SRT contribution to an RTMP distribution destination.
- Receive or deliver a RIST feed as part of a live distribution workflow.
- Transcode, resize, adjust audio, or add an overlay before delivery.
- Keep the input stable while changing downstream destinations between events.
Limits and troubleshooting
A saved restream can still have an offline input or a destination that rejects the connection, so check its live status after starting it. Transcoding requires substantially more CPU or GPU capacity than remuxing. For RIST delivery, use a compatible RIST URL and MPEG-TS signal, then verify the selected RIST profile and security settings at both ends.
Next steps
Validate the destination, then add monitoring or connect browser delivery through Web players when required.
Send one live input to multiple destinations
Create one restream job per destination from the same reviewed input, start the jobs, and monitor each output independently.
- Create each destination jobReuse the input and provide the protocol, credentials, and URL required by each destination.
POST /api/restream/create - Start deliveryStart each saved job after its upstream source is healthy.
POST /api/restream/start - Monitor every outputCompare bitrate and process state per destination instead of treating the fan-out as one status.
POST /api/restream/getStat
A successful create response confirms configuration, not media health. Start the resource, then verify its runtime statistics before sending production traffic.
Transcode a live stream for its destination
Create a restream with the required codec, bitrate, resolution, or audio conversion, then confirm the worker keeps pace in runtime statistics.
- Define the transcodeChoose input and output presets, then set only the required transcoding and media-change fields.
POST /api/restream/create - Start processingStart after validating destination codecs, resolution, bitrate, and credentials.
POST /api/restream/start - Check worker healthWatch bitrate, frame cadence, and process state for stalls or insufficient capacity.
POST /api/restream/getStat
Enable only the processing required by the destination. Transcoding uses substantially more CPU or GPU than remuxing.
Run continuous file playout to a live destination
Register or upload the media asset, use it as an infinite file input for a restream job, and monitor the always-on output.
- Prepare the media fileUpload the source and keep the returned file id for the playout input.
POST /api/files/uploadFile - Create looping playoutUse the infinite file input and configure the live destination plus any required processing.
POST /api/restream/create - Monitor the channelCheck the running process and destination bitrate as part of the always-on health loop.
POST /api/restream/getStat
The verified looping input type is INPUT_TYPE_FILE_VIDEO_INFINITY and input_module_id must identify an existing managed file.
Create a managed media pipeline with a source, destination, optional transcoding, audio or video changes, overlays, and an initial active state. Send the dashboard-issued JWT in the x-access-token header.
For RIST URLs, use INPUT_TYPE_RIST_URL for input.input_type or OUTPUT_TYPE_RIST_URL for output.output_type. A RIST output sends MPEG-TS to output_stream_url.
Request examples
Choose the operational preset that matches the source and destination, then add only the processing fields required by that pipeline.
Common use cases
- Republish one contribution feed to a social or CDN destination.
- Bridge SRT, RTMP, RIST, HLS, or another supported transport.
- Transcode, overlay, or fan out one source to destination-specific outputs.
Use this preset when one incoming SRT contribution should be forwarded to an RTMP destination such as a social platform or another managed RTMP target.
This is the most recognizable restream workflow: ingest on SRT, keep transcoding disabled or minimal, and push the result to an RTMP output.
Use this preset when the job should bridge one SRT source into another SRT destination while preserving the pipeline as a managed process object.
This is useful when the ingest side and the delivery side should remain decoupled but still live inside one active restream job.
Use this preset when you want to read from HLS as an input and run the media pipeline for monitoring, testing, or measurement without forwarding the output to another delivery target.
Use this shape for controlled playback checks and probe workflows built from a restream job.
Human-readable job name. The dashboard validates this as a required field.
Input definition built by the dashboard InputSource controls. This object determines the source transport or module connection. URL-based RIST input uses INPUT_TYPE_RIST_URL with input_stream_url.
Output definition built by the dashboard OutputSource controls. This object determines where the pipeline pushes or exposes the result. URL-based RIST output uses OUTPUT_TYPE_RIST_URL with output_stream_url; the Engine emits MPEG-TS on this path.
Optional transcoding profile used by the FFmpeg pipeline. The dashboard always submits this block, even when transcoding is disabled.
Optional audio modification settings. The dashboard sends a disabled-state object when no audio modification is requested.
Optional video modification settings. This can remain in a disabled state for pass-through jobs.
Optional overlay settings. The create flow can still send an explicit disabled overlay object.
Controls whether the job should be active after provisioning.
Resource id returned when you create or list the restream job.
Convenience alias for _id.
Name stored for the restream job.
Populated linked input object or objects for the pipeline.
Populated linked output object or objects for the pipeline.
Processing settings stored on the job object.
Current enabled state of the restream job.
Timestamps managed by the backend.
The model exposes success: true as a virtual field in successful responses.