This update allows builders to easily retrieve thumbnails for ongoing livestreams, as well as on-demand assets. Thumbnails are frequently used as poster images when displaying livestreams or assets within an application, and can also enable timeline hover previews (i.e., hovering over the player's timeline bar and seeing a preview image for a portion of the video).

For livestreams, we provide a single updating thumbnail URL - it will return the first frame of the most recent segment of video.

For on-demand assets we provide a way to retrieve a list of thumbnails for your video assets. Thumbnails will be generated as part of the asset processing step, with each “segment” (roughly 2-3 seconds) of video resulting in one image. These images are stored in a WebVTT file that is suitable for use in timeline hover previews in addition to retrieval of single images.

Thumbnail URLs for both Live and VOD assets will be accessible through the existing playback info API endpoint.

For more information, please refer to the guides linked below.

This update allows builders to easily create clips of ongoing livestreams. Currently, builders can create clips from the most recent N seconds of a given stream, or clip arbitrary sections of a long-running stream, such as a particular session from a live-streamed conference.

This release includes:To access these features:

This release of clipping is an expressive API to enable sophisticated livestream clipping workflows. By specifying arbitrary start and end times from a given viewer's perspective, application developers can create clips of ongoing livestreams to capture and share exciting moments.

These updates only allow clipping of livestreams; asset clipping will be included in a future release.

We've just released version 3.0.0 of the npm package. This includes renaming the package to .

If you are using functionality like from that library, we recommend you move to importing from .

If you use as a NodeJS library, please prepare to migrate to the new version which is one-to-one with the API. Keep an eye out for our announcement soon regarding the next version of the library.

With this update, builders and creators can change multistream targets at any time before or during an ongoing stream.

The previous implementation of multistream was unstable and did not allow builders to change multistream targets mid-stream. No implementation details have changed, and developers do not need to change existing integrations to access these features.

go-livepeer v0.6.0 was just released!

In addition to several bugfixes and performance improvements, this release adds a configurable blocklist allowing B nodes to include or exclude specific Orchestrator addresses according to their requirements. For example, Broadcasters using only VOD may prioritize price over performance; Broadcasters who run their own Os may choose to exclude all addresses but their own.

The blocklist is a first step towards an open marketplace for selection configuration, and we expect all sorts of configurations to become available for different use cases.

The hosted gateway’s current policy can be viewed here.

This update allows builders to create in-browser broadcasting experiences, so that they can create innovative livestreaming experiences and so that creators are not required to download and configure 3rd-party broadcasting software unless they desire.

This release includes:To access these features:

This release of in-browser broadcasting is a drop-in solution for a basic livestreaming workflow. It is intended to enable creators and social app users (who may not be familiar with the ins and outs of third-party broadcasting software like OBS) to easily livestream.

This release is not intended to be a full replacement for OBS, and does not include complex editing and compositing tools. Instead, it is meant to (1) unlock livestreaming for less technically sophisticated creators and (2) give builders the tools to create novel livestreaming experiences.

With this update, builders gain access to more detail from the Viewership Engagement API and receive a quick-start tutorial for how to get started.

To access these features, please follow the guides linked in the Resources section below. Please note that these updates alter behavior for some API requests (see note on playbackId). Existing builders leveraging Engagement Analytics should check that their integration behaves as expected and update it accordingly.

Additional Breakdowns:Time window defaults:

We've created a tutorial to help you get started with the API quickly. The tutorial uses Grafana and includes a dashboard template. You can use a free Grafana account and should be able to complete it in about 10 minutes.

This release offers a public API to enable inspection of Broadcaster logs, so that Orchestrators and other API users can understand the selection algorithms used to assign work to Orchestrator nodes.

To access these logs, builders should query the Broadcaster Introspection API as described here.

This is the initial release of the API, and only a few log lines have been enabled in the public logs. Orchestrators are encouraged to open pull requests to enable additional logs, which will be closely reviewed by the Livepeer team. Additionally, Livepeer core contributors will publish more logs from Livepeer Inc Broadcasters that may aid in understanding the selection algorithms.

At present, these logs are available for Livepeer Inc broadcasters (though other broadcasters could choose to spin up their own Loki instance to serve their logs). In the future, we may consider collecting logs from other Bs on an opt-in basis.

With this update, builders and viewers can expect 95 - 99% faster time-to-ready for VOD assets, so that videos are playable as soon as file upload completes. This is particularly important for recordings of live events (where it's important to make the recording available as soon as possible) and for social applications (where fast uploads improve posting experience).

Builders do not need to take any action to access these improvements. Under the hood, source video is made playable as soon as upload completes. In the background video processing (including transcoding) continues as usual, and transcoded renditions are made available when ready.

For rapid processing of assets that will also be archived on IPFS or Arweave, we strongly encourage either (1) uploading to Livepeer with the IPFS storage option enabled, or (2) uploading the raw file to Livepeer via or the API prior to archiving on dStorage, rather than passing the IPFS / Arweave gateway URL. The gateway URL will work, but may incur longer-than-usual processing time.

With this update, builders and viewers can expect drastically improved latency for browser-based applications, with a target range of 3-5s for transcoded renditions and sub-second for the source.

To access this feature, builders must either:If you choose to use another player, we strongly recommend that you incorporate fallback logic, whereby the player reverts to HLS in cases where network conditions may not support WebRTC.

WebRTC playback is not implemented in the Livepeer React Native player. This is tracked as follow-up work.