We are fixing a bug that caused webhooks to be triggered across projects. As a result, webhooks in a project named B were incorrectly receiving events from a project named A. As of September 5th, 2024 webhooks will only receive events from the project they belong to. Please be aware of this change if any user relied on the previous behavior.

There is no implementation required.

If any user is relying on events from project A coming to a webhook from project B, they should instead configure the webhook in the same project of the content from which they want to receive the event from.

As of July 15th, 2024, our pay-as-you-go rates and allotments will be adjusted as follows:

As part of our commitment to providing high-quality service at the lowest possible prices, we’re pleased to announce that we’re decreasing our Pay-As-You-Go storage rate by 50%. Transcode and Delivery rates are unchanged. This change applies to all customers and will take effect for all billing cycles starting on or after July 15th.

For reference, our rates will be updated to:

These changes do not affect current customers but will apply to all new customers with immediate effect, as well as customers who change their plan.

All new Sandbox accounts will be subject to the following limits:

These changes do not affect current customers but will apply to all new customers, as well as customers who change their plan.

To better align our pricing structure with customer usage, we are converting the existing Growth plan into a pay-as-you-go option with a $100 minimum, and eliminating fixed minute allotments. If usage is below $100 in a given month, we will round up to $100.

These changes do not affect current customers.

For new customers as well as customers who change their plan, this tier is eliminated; instead, we will offer tiered volume discounts for every level of scale. These tiers will require a discussion with Sales, rather than being publicly documented. Discounts start at $2,500 monthly spend, with a 15% minimum discount and more as you scale.

As always, please reach out to support@livepeer.studio with any questions or concerns.

We are excited to announce the launch of our new Real-Time Engagement and Performance API. This enhancement significantly improves our existing Engagement and Performance APIs by providing real-time data in addition to historical data, enabling better support for interactive live streams.

This solution has a median latency of 4 seconds from when an event occurs until it's queryable as aggregated data with rich dimensionality such as geography and device type.

The Real-Time Engagement and Performance API offers immediate insights into viewer interactions and stream performance metrics as they happen. This real-time data capability is designed to enhance your live streaming experience by allowing you to create dynamic engagement feedback loops and respond more rapidly to viewer behavior patterns and stream performance issues.

Key benefits and functionalities include:

This data is designed to enable a more responsive and engaging live streaming experience, especially when used in conjunction with other real-time services like Pubnub's Live chat. It is also suitable for use in monitoring pipelines.

All in all, this update empowers you to deliver a more responsive and engaging live streaming experience, with the ability to make data-driven decisions on the fly.

This feature is the foundation for our real-time Analytics capabilities. In the coming months, we will add:

For more information on integrating the Real-Time Engagement and Performance Data feature into your platform, please refer to our API documentation and developer guide.

You can also use our existing Historical Engagement and Performance Data API to retrieve and aggregate historical information.

We are excited to introduce the ability for developers to manage multiple Projects within a single Livepeer Studio Workspace. This enhancement is designed to streamline development workflows and improve efficiency, especially for teams handling multiple environments.

We are introducing two new concepts: Workspaces and Projects. A Workspace, much like a Discord server, is a single Livepeer Studio account and can be associated with an individual or an organization. Projects are siloed environments; everything associated with a given Project (assets, streams, webhooks, etc) is accessible only through that project.

Projects are suitable for managing different internal environments (Staging, Production) or for managing multiple standalone production apps.

A Workspace can contain many Projects; Billing and Usage are tracked at the Workspace level. In the future, you will be able to add additional users to a Workspace.

When you log into your account, you will see your account Workspace and the option to select a project.

and no action is required.

As described in the guide below, you can create new projects to suit your specific workflow and easily switch between those Projects.

When you create a new Project you can also create new API keys, which will have access to that Project only.

If you currently maintain multiple Livepeer Studio accounts for multiple environments, you may consider creating Projects to manage those environments, so that billing is consolidated in a single account.

For detailed instructions and further information on managing multiple siloed projects within a single workspace, please refer to our comprehensive User Guide. If you encounter any issues or need additional assistance, our support team is available to help.

Developers can now specify an array of desired renditions for live stream recordings. For example, a developer could choose to specify a comprehensive profile set for a live stream itself to ensure a great live experience, but request a different, slimmer profile set for the resulting recording. They could even choose to store rather than creating and storing additional renditions.

This workflow enables more granular control over both transcoding and storage costs.

Developers can now specify a list of allowed site origins in stream-level Playback Policies, to control the sites where their streams can be played back. If no allowed origin is specified, the stream will be playable on any site, subject to the other criteria of the Playback Policy

In the future, Livepeer Studio will allow developers to set global origin control policies to dictate access for all streams in a given account or project.

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.