Since our initial launch of the Livepeer Player and in-browser Broadcast libraries, the Livepeer Studio team has been collecting feedback and iterating on developer experience, performance, and customizability. Today we’re ringing in February with the launch of the Livepeer Kit - a ground-up rewrite of our React library.

🗺 𝐈𝐦𝐩𝐥𝐞𝐦𝐞𝐧𝐭𝐚𝐭𝐢𝐨𝐧 𝐆𝐮𝐢𝐝𝐞𝐬 𝐚𝐧𝐝 𝐑𝐞𝐟𝐞𝐫𝐞𝐧𝐜𝐞:

🎁 𝐌𝐚𝐣𝐨𝐫 𝐂𝐡𝐚𝐧𝐠𝐞𝐬

𝐅𝐞𝐞𝐝𝐛𝐚𝐜𝐤: The Player and Broadcast components are not very composable

𝐒𝐡𝐢𝐩𝐩𝐞𝐝: We’ve decomposed the previous livepeer-react monolith into libraries of primitives, so that you have full control over your users’ experience. You can use Player primitives to build a media playback experience, and Broadcast primitives to build an in-browser broadcasting experience.

𝐅𝐞𝐞𝐝𝐛𝐚𝐜𝐤: livepeer-react encapsulates a lot of application logic (fetching data from the backend, auto-upload, etc), leading to confusing integration pathways

𝐒𝐡𝐢𝐩𝐩𝐞𝐝: We’ve decoupled data fetching from the Player and Broadcast with a shared helper library and improved the interaction between the Player and Livepeer SDKs, to provide a more flexible and cohesive experience. The only web requests are for pure playback or broadcasting (WHEP/WHIP and metrics reporting) - there are no more API requests to Livepeer Studio from any components. This means that you do not need to configure a LivepeerProvider with an API key. Keep those keys on the backend.

𝐅𝐞𝐞𝐝𝐛𝐚𝐜𝐤: The styling is difficult and hard to rework (and not compatible with Server Components)

𝐒𝐡𝐢𝐩𝐩𝐞𝐝: The components are now completely unstyled, and the docs will provide examples of how to style them similarly to how they were in the previous releases. You can copy-pasta and then tweak from there.

💡 𝐎𝐭𝐡𝐞𝐫 𝐈𝐦𝐩𝐫𝐨𝐯𝐞𝐦𝐞𝐧𝐭𝐬

𝐂𝐨𝐦𝐩𝐨𝐬𝐚𝐛𝐥𝐞 𝐜𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭𝐬 - all components are extremely narrow in their scope, and support the asChild pattern popularized by Radix UI. When asChild is set to true, we will not render a default DOM element, instead cloning the part's child and passing it the props and behavior required to make it functional.

𝐀𝐮𝐭𝐨𝐦𝐚𝐭𝐢𝐜 𝐩𝐨𝐬𝐭𝐞𝐫 𝐢𝐦𝐚𝐠𝐞𝐬 - if you pass in the playback info response directly into getSrc, it will automatically parse the thumbnail image and pass it into the poster for the video.

𝐑𝐞𝐬𝐮𝐦𝐞 𝐩𝐫𝐨𝐠𝐫𝐞𝐬𝐬 𝐨𝐧 𝐟𝐚𝐥𝐥𝐛𝐚𝐜𝐤 - when an error happens during playback for any reason, we resume playback where it left off.

𝐁𝐫𝐢𝐧𝐠 𝐲𝐨𝐮𝐫 𝐨𝐰𝐧 𝐜𝐨𝐦𝐩𝐨𝐧𝐞𝐧𝐭𝐬 - useMediaContext is now much easier to use - since the <Player.Root /> is now just a simple React Context provider, you can build out your own components inside of it which consume the video controller.

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.