A Stream represents a livestream object that can be identified, recorded, and processed within Livepeer. A livestream is a video feed that is broadcast in real-time. Livepeer is responsible for the lifecycle management (CRUD) of a livestream. A livestream is uniquely identified by its Stream ID, and associated with a defined metadata describing its characteristics.
A livestream can be created with the
Create livestream API endpoint. Once a
livestream is created, there are set of webhook events to notify its state
A livestream is composed of one or more sessions. A session is a period of time during which a livestream is active. A livestream can have multiple sessions, but only one session can be active at a time. A session is uniquely identified by its Session ID and is associated with defined metadata. You can use the sessions API to get a list of sessions for a given stream.
If recording is enabled, there are a set of webhook events which can notify your
backend of a recording’s state transitions, including:
recording.waiting. The recording is stored as an
A livestream can be directed to multiple livestream targets, such as YouTube or Twitter, using multistream.
RTMP is the default ingest protocol for streaming. WebRTC and SRT ingest are also supported. See the in-browser broadcasting guide on how to use WebRTC ingest.
When a livestream is live, livestream health provides a set of metrics about its performance and ingest health. This provides tangible feedback for creators who want better livestream performance.
Also, Livepeer provides viewership metrics, which allow a more comprehensive look into viewer behavior using the livepeer viewership API. Reporting is enabled by default in the Livepeer Player, and can be integrated into any third party player.
A livestream can be easily viewed by passing a
playbackId to the
Livepeer Player. If using a third
party player, the full playback url is required. This can be fetched from the
Playback Info API endpoint.
The Livepeer Player will default to WebRTC playback. WebRTC ensures low latency that is sub-second on source and around 2-5 seconds on transcoded renditions. This means that (depending on livestream settings) users will often have a sub-second viewing experience.
The Livepeer Player will fall back to HLS playback using HLS.js if b-frames are detected in the livestream or there is a transient network error with WebRTC initiation.