Skip to main content

Publishing Parameters

Broadcast URL Parameters allow you to customize the behavior of an individual source feed by modifying the URL used of specific sources when establishing a connection.

Broadcast Protocols

There are some variations depending on which protocol is being used to broadcast.

  • WebRTC: The query parameter string is appended at the end of a WHIP URL https endpoint.
  • RTMP: The query parameter string is appended to the end of a RTMP URL rtmp or rtmps endpoint. Depending on the encoder, this may be appended as a single URL or a two-part server and path.
  • SRT: The query parameter string requires special handling to encode it within the SRT stream id.

How-to Add Publishing Parameters to the URL

Parameters allow modifying broadcasting preferences to customize the streaming experience. This is particularly helpful when using Multi-Source that share a common publishing token configuration but may be using a feature that requires modification to only specific input streams.

To use these parameters, add them to the end of the protocol URI as a query string component.

  • All broadcast parameters are added after the ?token={token}
  • Parameters are delimited using an ampersand (&)

For example, to distinguish different sources you can add a sourceId and priority parameter to the URL. The result might look like:

?token={token}&sourceId=1&priority=1

Any parameters that are boolean type can be used without a value. For example, the audioOnly and noRecord parameters:

?token={token}&audioOnly&noRecord

Available Parameters

The OptiView Real-time Streaming APIs platform provides the following parameters:

Parameter nameTypeDescription
audioOnlyBooleanIndicates whether the platform should broadcast only audio.
enableUTCInsertionBooleanInserts an unregistered SEI timestamp carrying the server's UTC receive time (Unix epoch milliseconds) into H.264 video, for both passthrough and transcoded layers, without re-encoding the passthrough media. It is only applied when the ingest does not already provide a sender time (onFi/AMF); existing timestamps are never overwritten. Supported for RTMP and SRT H.264 ingest (not WebRTC ingest passthrough, and not H.265). The timestamp is delivered to players as frame metadata. For passthrough output, setting the seiKeyFrameOnly parameter (also in this table) limits the inserted timestamp to keyframes; transcoded layers always carry it on every frame (see Server-Inserted UTC Timecode for details). Enable this only on streams that do not already carry onFi/AMF metadata: if the ingest provides a sender time on only some frames, the delivered timestamps will alternate between the encoder clock and the server clock. This can also be configured at the publishing-token level and as an account-level default; when present, this URL parameter takes precedence over the token setting, which in turn overrides the account-level default. enableUTCInsertion defaults to false.
intraOnlyForwardingBooleanIndicates whether the platform should forward only intra frames while transmitting video.
noAudioBooleanInstructs the server to ignore any audio tracks from this source. This is often used with Multi-Bitrate (MBR) contribution streams to only stream the audio of the main feed.
noRecordBooleanWhen given will not record the given ingest source feed. This overrides the publishing token to avoid recording multiple sources that might only be streaming as a backup or for MBR.
noRestreamBooleanWhen broadcasting multiple streams you can choose which sources to re-stream and exclude any others from being forwarding to additional media platforms.
priorityNumberA priority for redundant streams indicates the order in which backup streams should be broadcasted in the case of any problems with the primary stream.
recordBooleanIndicates whether the platform should record a stream.
seiKeyFrameOnlyBooleanWhen using SEI or AMF onFi or onTextData, only send metadata on keyframes to clients even if the stream contains metadata more frequently. This is a workaround for a Chrome bug where SEI data on delta frames could lead to packetloss. It was fixed in Chrome M131). The default is false.
simulcastIdStringAn identifier that assigns feeds produced by a single camera as Simulcast layers. All feeds that have the same simulcastId are published together as different quality layers. You can identify each layer using a different sourceId.
sourceIdStringA unique identifier for a specific feed. Two feeds can have the same sourceId only when they are the same and used as backup feeds in Redundant Ingest .
streamNameStringA name for the stream of your broadcast. This must match the streamName(s) allowed by your publishing token.
tStringA publish token in the base64url format that is supported only when using SRT or RTMP. We recommend using this parameter to reduce the length of the query parameter string for encoders with low limits. It is not possible to use the t and token parameters at the same time.
tokenStringA publish token in the hexadecimal format that is supported only when using SRT or RTMP. It is not possible to use the t and token parameters at the same time.
videoOnlyBooleanIndicates whether the platform should broadcast only video even if the contribution stream contains an audio track. This is required when you are doing Multi-Bitrate Publishing on layers that do not contain an audio stream or contain a silent audio stream.
videoTargetBitrateNumberThe target bitrate of the streamed video content, in kbps. The parameter helps the service determine what layer to send to viewers while using multi-bitrate RTMP or SRT to deliver simulcast, or multiple-quality viewer experience. This parameter is supported only when using SRT or RTMP.
extraLatencyNumberWhen specified adds extra latency to an ingest from [0 - 3000] in milliseconds.