Streams

A stream is the live object you broadcast into and viewers watch. It owns three things you will use in most integrations:

Field	What it is	Safe to expose?
id	GraphQL object ID for API mutations and queries	Backend only
streamKey	Secret ingest credential for push streams	No
playbackId	Public viewer identifier for /play and Player	Yes

Use streamKey only where media is being uploaded. Use playbackId everywhere viewers need to watch. An API token reads streamKey only with the streams:write scope; see Token scopes.

Stream Types

FrameWorks exposes three source models. Builders create push and pull streams; deployment operators can also declare managed local sources for loops, playlists, and site-local workflows.

Model	How media arrives	Creation path
Push	Your encoder opens RTMP/E-RTMP, SRT, or WHIP to FrameWorks	Dashboard or GraphQL createStream
Pull	FrameWorks opens RTSP, SRT, RIST, HLS, DTSC, or TS to you	Dashboard or GraphQL createStream
Managed	The deployment supplies a local file, playlist, or controlled process	Operator bootstrap configuration only

Most builders start with push streams. Pull-input streams are useful for cameras, venue feeds, and upstream origins that cannot push into FrameWorks. See Pull-input streams for supported source schemes, private-source rules, and lifecycle visibility. Note that RTMP and FLV-over-HTTP pull are not supported today — open a ticket if you need them.

Experimental media-engine discovery exists locally today. On the roadmap: packaging that into FrameWorks Edge, Tray, CLI, API, and dashboard workflows for venues and studios that want camera pickup without hand-wiring RTSP URLs.

Pull streams are not push streams with a URL

A pull stream has no usable streamKey, because nothing is allowed to push into it. Its upstream URI is stored server-side, encrypted at rest, and resolved only by the media plane when a viewer wakes the stream.

Managed streams also have no usable streamKey. Their literal source paths and process arguments are deployment secrets and are never returned by the tenant API. The API exposes only a safe summary: source kind, always-on state, placement count, and allowed source clusters.

Create a Push Stream in the Dashboard

1. Open Content -> Streams.
2. Click Create Stream.
3. Give it a name and optional description.
4. Copy the Stream Key for your encoder.
5. Copy the Playback ID for players and embeds.

For the fastest end-to-end setup, follow Quick Start.

Create a Push Stream with GraphQL

Most mutations return a union. Always check __typename.

mutation {
  createStream(input: { name: "Main Stage", record: true }) {
    __typename
    ... on Stream {
      id
      name
      streamKey
      playbackId
      record
    }
    ... on ValidationError {
      field
      message
    }
    ... on AuthError {
      message
    }
  }
}

record: true records every broadcast. While live, late viewers can rewind within the live rewind window; after the broadcast, the saved recording is replayable as chapters, which by default are as long as the live rewind window. For 24/7 channels the live stream keeps running while replay is served from those chapters, with no forced stream restart at a duration boundary. You can also toggle recording later with updateStream, and choose how the saved recording is split with dvrChapterMode (see DVR Chapters). See Live and DVR Streams for what recording creates.

Live and DVR Streams

Setting record: true at create time (or calling startDVR(streamId) later) creates a separate stream entity for the recording, with its own internal name and playbackId, distinct from the live stream:

• Live stream — segments live in a shared-memory ring buffer of about 2 minutes. Right for real-time playback and CLIP_NOW of recent moments.
• DVR stream — segments are written to disk and archived under one recording artifact. Right for seek-back, longer clips, and post-event playback. The live rewind window is bounded for player performance; the saved recording is replayed through finalized chapters over the same segment archive.

The live ring is configurable — private deployments often want a longer window — but every extra second costs cluster RAM, so the default stays tight. Open an in-app ticket if your deployment needs a non-default size.

Practical consequences:

• Players use the DVR playbackId (with contentType="dvr") to seek back beyond the live ring within the live rewind window. After the broadcast, the same playbackId plays the recording’s most recent finalized chapter.
• Clip creation runs against the entity that holds the moment you want — see Clips. Use the live stream for the live ring and the DVR recording for archived ranges.
• Access control, multistream targets, thumbnails, and analytics attach per stream entity.

The optional liveVideoAbr stream setting controls live video renditions. INHERIT follows the tier policy; OFF removes live video renditions from the next ingest while preserving audio conversion, thumbnails, and recording. RTMP restream targets can independently request automatic, source, or processed video selection; see Multistreaming.

For 24/7-style streams, the recording can continue as one DVR artifact for the full stream session. Replay viewers navigate that archive through chapters or explicit time ranges, while the live player still receives a bounded seekback window. See Recordings, Clips & VOD.

Go Live

After creating a push stream, send media to one of the ingest endpoints shown on the stream detail page:

Protocol	Typical use	Guide
RTMP/E-RTMP	OBS, hardware encoders, FFmpeg	Encoder Setup
SRT	Unreliable or long-haul networks	Encoder Setup
WHIP	Browser or WebRTC-native broadcast	StreamCrafter

The stream becomes live once the media edge accepts the input and MistServer reports an active session.

Watch the Stream

Use playbackId with the FrameWorks Player or raw /play URLs:

import { Player } from "@livepeer-frameworks/player-react";

<Player contentType="live" contentId="<PLAYBACK_ID>" options={{ autoplay: true, muted: true }} />;

https://foghorn.frameworks.network/play/<PLAYBACK_ID>/hls/index.m3u8
https://foghorn.frameworks.network/play/<PLAYBACK_ID>/webrtc

See Playback & Embedding for protocols, players, and custom source resolution.

Lifecycle

• Offline - The stream exists, but no encoder or pull input is currently active.
• Live - The media edge is receiving or pulling source media.
• Recording - If recording is enabled, each broadcast is recorded: viewers can rewind while it is live, and it is saved as chapters after it ends.
• Idle pull input - Pull streams do not fetch upstream media until a viewer requests playback.
• Managed source - The deployment reconciler owns the source; an always-on source can remain active without a viewer.

Playback access policies, multistream targets, recordings, thumbnails, and analytics attach to the stream regardless of source mode. Push streams alone accept publisher credentials. Pull and managed streams expose source state instead of encoder URLs or stream-key controls.

Related Guides

Quick Start

Encoder Setup

StreamCrafter

Playback

Pull-input Streams

Recordings

API Reference