LIVE

IDLE

); }; ``` ## Embeddable broadcast This is one of the easiest ways to broadcast video from your website/applications. You can embed the iframe on your website/applications by using the below code snippet. You can replace the `STREAM_KEY` with your stream key for the stream. ```html theme={"theme":{"light":"github-light","dark":"dark-plus"}} ``` This will automatically stream from the browser with a fully composed UI, using STUN/TURN servers to avoid network firewall issues. ## Adding custom broadcasting If you want to add custom broadcasting to your app and handle the WebRTC SDP negotiation without using the Livepeer React primitives, you can follow the steps below. ### Get the SDP Host First, you will need to make a request to get the proper ingest URL for the region which your end user is in. We have a global presence, and we handle redirects based on GeoDNS to allow users to get the lowest latency server. To do this make a `HEAD` request to the WebRTC redirect endpoint: ```bash theme={"theme":{"light":"github-light","dark":"dark-plus"}} curl -I 'https://livepeer.studio/webrtc/{STREAM_KEY}' ... > Location: https://lax-prod-catalyst-2.lp-playback.studio/webrtc/{STREAM_KEY} ``` We are only interested in getting the redirect URL from the response, so that we can set up the correct ICE servers. From the above response headers, the best WebRTC ingest URL for the user is `https://lax-prod-catalyst-2.lp-playback.studio/webrtc/{STREAM_KEY}`. We will use this in the next step. The process will change in the future to remove the need for this extraneous `HEAD` request - please check back later. ### Broadcast Now that we have the endpoint for the ICE servers, we can start SDP negotiation following the [WHIP spec](https://www.ietf.org/archive/id/draft-ietf-wish-whip-01.html) and kick off a livestream. The outline of the steps are: 1. Create a new `RTCPeerConnection` with the ICE servers from the redirect URL. 2. Construct an SDP offer using the library of your choice. 3. Wait for ICE gathering. 4. Send the SDP offer to the server and get the response. 5. Use the response to set the remote description on the `RTCPeerConnection`. 6. Get a local media stream and add the track to the peer connection, and set the video element `src` to the `srcObject`. ```tsx theme={"theme":{"light":"github-light","dark":"dark-plus"}} // the redirect URL from the above GET request const redirectUrl = `https://lax-prod-catalyst-2.lp-playback.studio/webrtc/{STREAM_KEY}`; // we use the host from the redirect URL in the ICE server configuration const host = new URL(redirectUrl).host; const iceServers = [ { urls: `stun:${host}`, }, { urls: `turn:${host}`, username: "livepeer", credential: "livepeer", }, ]; // get user media from the browser (which are camera/audio sources) const mediaStream = await navigator.mediaDevices.getUserMedia({ video: true, audio: true, }); const peerConnection = new RTCPeerConnection({ iceServers }); // set the media stream on the video element element.srcObject = mediaStream; const newVideoTrack = mediaStream?.getVideoTracks?.()?.[0] ?? null; const newAudioTrack = mediaStream?.getAudioTracks?.()?.[0] ?? null; if (newVideoTrack) { videoTransceiver = peerConnection?.addTransceiver(newVideoTrack, { direction: "sendonly", }) ?? null; } if (newAudioTrack) { audioTransceiver = peerConnection?.addTransceiver(newAudioTrack, { direction: "sendonly", }) ?? null; } /** * https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/createOffer * We create an SDP offer here which will be shared with the server */ const offer = await peerConnection.createOffer(); /** https://developer.mozilla.org/en-US/docs/Web/API/RTCPeerConnection/setLocalDescription */ await peerConnection.setLocalDescription(offer); /** Wait for ICE gathering to complete */ const ofr = await new Promise((resolve) => { /** Wait at most five seconds for ICE gathering. */ setTimeout(() => { resolve(peerConnection.localDescription); }, 5000); peerConnection.onicegatheringstatechange = (_ev) => { if (peerConnection.iceGatheringState === "complete") { resolve(peerConnection.localDescription); } }; }); if (!ofr) { throw Error("failed to gather ICE candidates for offer"); } /** * This response contains the server's SDP offer. * This specifies how the client should communicate, * and what kind of media client and server have negotiated to exchange. */ const sdpResponse = await fetch(redirectUrl, { method: "POST", mode: "cors", headers: { "content-type": "application/sdp", }, body: ofr.sdp, }); if (sdpResponse.ok) { const answerSDP = await sdpResponse.text(); await peerConnection.setRemoteDescription( new RTCSessionDescription({ type: "answer", sdp: answerSDP }) ); } ``` We just negotiated following the WHIP spec (which outlines the structure for the POST requests seen above) and we did SDP negotiation to create a new livestream. We then retrieved a local camera source and started a broadcast! To make the above process clearer, here is the flow (credit to the authors of the WHIP spec): The final HTTP DELETE is not needed for our media server, since we detect the end of broadcast by the lack of incoming packets from the gateway. ```txt WHIP Outline theme={"theme":{"light":"github-light","dark":"dark-plus"}} +-----------------+ +---------------+ +--------------+ +----------------+ | WebRTC Producer | | WHIP endpoint | | Media Server | | WHIP Resource | +---------+-------+ +-------+- -----+ +------+-------+ +--------|-------+ | | | | | | | | |HTTP POST (SDP Offer) | | | +------------------------>+ | | |201 Created (SDP answer) | | | +<------------------------+ | | | ICE REQUEST | | +----------------------------------------->+ | | ICE RESPONSE | | <------------------------------------------+ | | DTLS SETUP | | <==========================================> | | RTP/RTCP FLOW | | +------------------------------------------> | | HTTP DELETE | +------------------------------------------------------------>+ | 200 OK | <-------------------------------------------------------------x ``` # Managing Projects Source: https://docs.livepeer.org/v1/developers/guides/managing-projects Explore best practices for managing multiple environments in Livepeer Studio Create a project

## Overview Projects in Livepeer Studio allow for the organization of streams, assets, API keys, and usage within dedicated environments. This feature is helpful for separating staging and production environments, managing multiple applications, and ensuring efficient workflow within a single account. ## Why Use Projects? * **Separation of Environments**: Keep your staging and production environments separate to avoid conflicts and ensure reliable testing. * **Centralized Management for Multiple Applications**: Instead of juggling multiple accounts, you can build and manage separate applications from within the same account. This is ideal for developers and companies that operate multiple apps or brands and wish to streamline their management in one place. ## Getting Started with Projects ### Creating a New Project To start building with separate environments or applications, you'll need to create a new project. Here's how: 1. In the sidebar, click on the project dropdown at the top of the menu. 2. Choose **+ New project** from the dropdown list. 3. Enter a name for your new project when prompted. 4. Confirm the creation to set up your new environment. ### Renaming a Project 1. Within a project, navigate to the **Settings** section in the sidebar. 2. Find the project name field, make your changes, and save. ### Deleting a Project In the current version of Livepeer Studio, you **cannot** delete a project. But we are working on adding this feature soon. ## Conclusion With the introduction of Projects, Livepeer Studio provides you with a powerful way to manage your application's live and on-demand streams. By leveraging the ability to create separate projects for staging and production, you can streamline your workflows and ensure a clean separation of your streaming environments. # Monitor stream health Source: https://docs.livepeer.org/v1/developers/guides/monitor-stream-health Learn how to monitor stream metrics on Livepeer This guide provides instructions and information about using stream metrics to: * Monitor any active stream for issues that may impact the quality of your stream * Understand the metrics for operating a livestreaming or user generated content platform * View health status of your livestream (API and Dashboard No-Code Option) ## Metrics with Source Segments Duration The value of `sourceSegmentsDuration` returned is the duration in seconds of the asset source processed by Livepeer Studio. On the parent stream object, this value equates to the total amount of source video ingested by Livepeer Studio all time. On the session object, this value is the length of the livestream session (or the session recording). ### Request Use the [get stream](/api-reference/stream/get) endpoint to retrieve a stream, or ```javascript theme={"theme":{"light":"github-light","dark":"dark-plus"}} import { Livepeer } from "livepeer"; const apiKey = 'YOUR_API_KEY'; const streamId = 'STREAM_ID'; const livepeer = new Livepeer({apiKey}); livepeer.stream.get(streamId) .then((response) => { console.log("Stream details:", response); }) .catch((error) => { console.error("Error fetching stream details:", error); }); ``` ```python theme={"theme":{"light":"github-light","dark":"dark-plus"}} import livepeer // Initialize the Livepeer client with your API key client = livepeer.Livepeer( api_key="", ) // Replan with the stream ID you want to retrieve res = client.stream.get(id='') if res.stream is not None: # handle response pass ``` ```go theme={"theme":{"light":"github-light","dark":"dark-plus"}} package main import( livepeergo "github.com/livepeer/livepeer-go" "context" "log" ) func main() { // Initialize the Livepeer client with your API key client := livepeergo.New( livepeergo.WithSecurity(""), ) // Define the stream ID you want to retrieve var id string = "" ctx := context.Background() res, err := client.Stream.Get(ctx, id) if err != nil { log.Fatal(err) } if res.Stream != nil { // handle response } } ``` **`GET /session/{id}` to retrieve a session object** ```javascript theme={"theme":{"light":"github-light","dark":"dark-plus"}} import { Livepeer } from "livepeer"; const apiKey = 'YOUR_API_KEY'; const sessionId = 'SESSION_ID'; const livepeer = new Livepeer({apiKey}); livepeer .session.get(sessionId) .then((response) => { console.log("Session details:", response); }) .catch((error) => { console.error("Error fetching session details:", error); }); ``` ```python theme={"theme":{"light":"github-light","dark":"dark-plus"}} import livepeer client = livepeer.Livepeer( api_key="", ) res = client.session.get(id='') if res.session is not None: # handle response pass ``` ```go theme={"theme":{"light":"github-light","dark":"dark-plus"}} package main import( livepeergo "github.com/livepeer/livepeer-go" "context" "log" ) func main() { client := livepeergo.New( livepeergo.WithSecurity(""), ) var id string = "" ctx := context.Background() res, err := client.Session.Get(ctx, id) if err != nil { log.Fatal(err) } if res.Session != nil { // handle response } } ``` ### Response * Returns a `200` response with the following object: ```json theme={"theme":{"light":"github-light","dark":"dark-plus"}} { "name": "test_stream", "id": "ijkl61f3-95bd-4971-a7b1-4dcb5d39e78a", "createdAt": 1596081229373, "streamKey": "abcd-uimq-jtgy-x98v", "playbackId": "efghb2mxupongp5k", "isActive": "true", "lastSeen": 1596119750455, "sourceSegments": 1360, "transcodedSegments": 5480, "sourceSegmentsDuration": 2630.53200000000004, "transcodedSegmentsDuration": 10620.1280000000004 // other asset object keys, like profiles and parentId } ``` ### Global Health Status * `Healthy` indicates that all the Health Checks are in a `Healthy` state. * `Unhealthy` indicates that one or more of the Health Checks are in an `Unhealthy` state * `Idle` indicates that the stream is not currently active ### Health Checks * ***Transcoding*** — A `Healthy` status indicates that video transcoding is occurring, and the multiple profiles of your stream are available for playback. An `Unhealthy` status indicates that we have failed to generate the profiles, so only the original video will be available. Check the event log below for any actionable errors, or check the [Status page](https://livepeer.statuspage.io/) for platform-wide issues. * ***Real-time —*** This indicates whether our system transcoded the stream faster than in real-time. In other words, if the video transcodes, latency is lower than the video duration. Unconventional configurations may cause an `Unhealthy` status. * ***Multistreaming —*** This health check indicates whether all configured `multistream targets` are connected. If no targets exist, this will appear blank and not be considered for the global health state. If this shows up as `Unhealthy`, you can also check the status of the individual `multistream targets` in the `Overview` tab, where the targets can be either `Idle`, `Pending`, `Online'or' Offline`: * An `Idle` status indicates that the stream is not currently active, so neither is multistreaming. * A `Pending` status indicates that our system tries connecting to the respective `multistream target`. * An `Online` status indicates that the `multistream target` is successfully connected. * An `Offline` status means that we've received an error when trying to connect to the target. To try again, check the ingest URL and stream key of your destination service, re-configure your `multistream target` and restart your stream. ### Logs Logs will surface informational alerts (ex., stream has started/stopped, multistream destinations have connected/disconnected) or any fatal errors from the transcoding process. Here is an example of a fatal error: ```bash theme={"theme":{"light":"github-light","dark":"dark-plus"}} Transcode error from ewr-prod-livepeer-orchestrator-0 for segment 0: **Unsupported input pixel format** ``` If you run into this or any similar errors, check the configuration in your streaming software (e.g., OBS) and restart the stream. ### Session Ingest Rate Session ingest rate tells you the bitrate of the video received by Livepeer ingest servers, updated every 10 seconds. A high bitrate is suggestive that streams into the Livepeer system are high quality, your encoder is working correctly, and your internet connection is good. A fluctuating or low bitrate may suggest that your encoder is misconfigured or that the streamer internet connection isn't as strong as it should be to deliver high-quality streams to your viewers. ### Monitoring in the Dashboard In the dashboard, there will be a `health` tab on the right side: ![image](https://user-images.githubusercontent.com/79172645/135450248-bf3edea4-e666-4927-8114-f972cd2879fe.png) During any Active stream, components on this page will display a variety of health indicators. ![image](https://user-images.githubusercontent.com/79172645/135450296-168bd797-fafb-4371-af8a-86b346bbaa18.png)
![image](https://user-images.githubusercontent.com/79172645/135450340-4abed968-df77-473d-b926-88c11b5799d2.png) At the bottom of the page, a chart will show the ingest rate of a livestream: ![image](https://user-images.githubusercontent.com/79172645/135467197-08ec63ab-4c44-4cad-a0d5-95a76b80e5c5.png) ### Monitor with the API We are working on building a first-class solution to monitor stream health using the API. Please reach out to us on Discord if you have any input. # Set up a multistream Source: https://docs.livepeer.org/v1/developers/guides/multistream Learn how to add multistreaming [Multistreaming](/developers/core-concepts/core-api/multistream) allows a source stream and transcoded renditions to be pushed to multiple RTMP(S) targets, such as Twitch, Facebook Live, and YouTube Live. ## Multistream targets with the API You can manage multistream target objects from the API - see the [API reference](/api-reference/multistream/create). Each target represents a specific endpoint where a stream could be multistreamed to. Note that the creation of a multistream target itself is not enough - you also need to reference the target from the stream object that should be multistreamed. To avoid managing the separate multistream target objects, you can also create the targets inlined in the stream [creation](/api-reference/stream/create) and [update](/api-reference/stream/update) APIs. You can also create and remove multistream targets individually from a given stream using the [Create Multistream Target](/api-reference/stream/add-multistream-target) and [Delete Multistream Target](/api-reference/stream/delete-multistream-target) APIs. Any changes to multistream targets, including creating new targets, will apply only to the next active session. If you make changes while a stream is active, those changes will not apply until the current session has ended and a new session begins. ## Multistream targets in the Studio dashboard To add, manage, and delete multistream targets, navigate to the [Streams page](https://livepeer.studio/dashboard/streams) and click on a stream name. On the stream detail page, on the Overview tab, you can view all configured targets. You must configure new multistream targets for each stream. This will apply the multistream configuration to that stream. Multistream targets **do not carry over when you create new streams.** To add a new target, click `Create` on the right side of the multistream targets section. You'll be asked to name your target, provide the Ingest URL and a stream key, Ingest URL being the only required value. The Ingest URL and stream key should be provided by the platform that you're streaming into and can one of: RTMP, RTMPS, or SRT protocols. Select the rendition profile that you'd like to send to that target and click `Create Target`. Once created, you can toggle the targets on and off. To edit a multistream target, click on the three dots to the right of the target name and then on `Edit` to open up the target settings. Select `Update Target` when you've completed your changes. To delete a multistream target, click on the three dots to the right of the target name and then on `Delete`. Any changes to multistream targets, including creating new targets, will apply only to the next active session. If you make changes while a stream is active, those changes will not apply until the current session has ended and a new session begins. ## Understanding Multistream Performance ### Dashboard While a session is active that has multistream targets configured, you'll be able to see if a destination is `Active` or `Offline`. There may be a slight delay between starting the stream and the push destinations connecting. When starting to stream to multistream targets, use these indicators to understand whether it has connected to its target(s). On the stream page where you've configured your multistream targets, select the Health tab at the top. While a session is active, you'll see the ingest rate of the source stream. ### Webhooks There are three webhooks to help you monitor the state of your multistream targets: * `multistream.connected`: When Studio has successfully connected to the multistream target and you're also online in the other service you are multistreaming to. * `multistream.error`: In case any error has occurred during connection to the multistream target. This means some kind of problem with the configuration or the other service you are multistreaming to. * `multistream.disconnected`: Sent after a stream is ended to indicate that Multistream has also ended for the respective target. # Optimize latency Source: https://docs.livepeer.org/v1/developers/guides/optimize-latency-of-a-livestream Learn how to optimize latency for your Livepeer Studio workflow. One of the first questions that many developers ask during Livepeer Studio onboarding is: "How do we optimize for low latency?" Many live streaming apps and sites rely on low latency to promote engagement and interaction between viewers and streamers. Latency refers to the lapse in time between a camera capturing an action in real life and viewers of a livestream seeing it happen on their screen. Ultra-low latency is when that time is short enough, typically 0.5 - 3 seconds, so viewers of a live-streaming application can interact with what's happening in the stream in a way that feels natural. There’s a range of latencies to support a variety of use cases; low or ultra-low latency is a common goal, but it is one of many viable latency choices. The right latency depends on what you’re trying to achieve. In this primer, we provide an overview of Livepeer Studio’s approach to latency. By the end of the primer, you should have an understanding of how to achieve the right latency / quality balance for your workflow. ## Understanding Protocols Livepeer Studio delivers video using several protocols. The most common (though not the only) delivery protocols supported by Livepeer Studio are **HLS** and **WebRTC**. ### Delivering video with HLS HLS (HTTP Live Streaming), initially developed by Apple for iOS devices, serves video with a series of segmented `.ts` files. It is broadly supported across many device types and is extremely well-optimized for serving multiple renditions; these characteristics position HLS as the default choice for many gateways. However, HLS has very high overhead and latency. Specifically, its chunked segment delivery means that viewers must wait for the current segment to finish downloading before they can start viewing it. Similarly, HLS players often buffer a few segments in advance to ensure smooth playback and to handle network fluctuations. This buffer introduces additional latency, as the player waits to accumulate enough data before starting playback. Buffer behavior is heavily dependent on client implementation. **HLS delivers video with standard latency of 10-20 seconds. Streaming HLS with Livepeer Studio’s recommended low-latency settings lead to \~10s latency.** ### Delivering video with WebRTC WebRTC (Web Real-Time Communication) is a streaming protocol known for its low-latency capabilities, making it suitable for real-time communication applications like video conferencing, online gaming, and live streaming. Unlike HLS, which is designed for adaptive streaming and on-demand content, WebRTC focuses on minimizing latency. WebRTC offers low latency by prioritizing real-time communication, direct peer-to-peer connections, UDP transport, and adaptive streaming while minimizing intermediaries. It is a preferred choice for applications where minimizing delay is critical, such as video conferencing and live interactive streaming. **WebRTC delivers video with ultra-low latency of 0.5 - 3 seconds.** # Optimizing Playback for Low Latency ## Lowest possible latency (WebRTC playback) WebRTC is available as a delivery protocol for all streams regardless of input protocol; to achieve the lowest possible latency of 0.5 - 3 seconds, use of WebRTC delivery is required. We implement the WHIP/WHEP spec with [a few minor nuances around SDP negotiation](/v1/developers/guides/livestream-from-browser#adding-custom-broadcasting). To play back a WebRTC rendition, you will need to use a WebRTC-compatible player, such as the Livepeer Player. * [Playing WebRTC livestreams with the Livepeer Player](/v1/developers/guides/playback-a-livestream) * [Playing WebRTC livestreams with other players](/v1/developers/guides/playback-a-livestream#using-your-own-player) Please note that **if b-frames are present in a livestream, WebRTC renditions will not be available**. This is because in WebRTC video playback, b-frames will appear out-of-order on most systems. ## Optimizing for Lower Latency (HLS and WebRTC ingest and playback) Depending on your goals, you may or may not want to optimize for the lowest latency; for example, if your user base has a high percentage of low-bandwidth mobile users, it may be preferable to optimize for bandwidth efficiency over latency. ### Streaming with OBS Achieving the right balance between low latency and stream quality is essential for providing the best possible user experience. Two settings that significantly impact your stream quality, latency, and user experience are: * **Rate Control:** This setting dictates the bitrate or "quality" of the stream. A high amount of bandwidth usually means better quality, but keep in mind that your output can never improve the quality of your stream beyond your input. * **Keyframe Interval:** Video streams consist of full frames and data relative to the full frames. This setting determines how often a full frame appears, which heavily influences latency. To allow streamers to easily configure OBS for best performance with Livepeer Studio, we’ve created an OBS preset that can be selected in the OBS Settings panel. You can read more about configuring OBS here * [Selecting the Livepeer Studio preset](/v1/developers/guides/stream-via-obs#update-stream-settings) * [Optimizing OBS for low latency](/v1/developers/guides/stream-via-obs#optimizing-for-low-latency) * [Optimizing for Stream Quality](/v1/developers/guides/stream-via-obs#optimizing-for-stream-quality-and-user-experience) Finally, we’ve compiled a set of recommended settings to achieve specific experience goals (e.g., highest quality but high latency, average quality but lower latency, or a balanced approach): * [Sample settings](/v1/developers/guides/stream-via-obs#recommended-obs-settings) ## In-browser broadcasting Livepeer Studio allows users to broadcast from within their browser using WebRTC broadcast. **These broadcasts are optimized for low latency by default** and can play back in HLS (8-10s latency) or WebRTC (0.5 - 3s latency). You can leverage this capability in three ways: * [Implement the customizable React component](/v1/developers/guides/livestream-from-browser) * [Embed a hosted version](/v1/developers/guides/livestream-from-browser#embeddable-broadcast) * [Roll your own broadcasting experience with plain WebRTC](/v1/developers/guides/livestream-from-browser#adding-custom-broadcasting) # Smoke testing your workflow When you first implement your livestreaming workflow, you may see higher-than-expected latency. This is common and likely means that a few settings need to be tweaked. ### Check latency using the Livepeer Player Go to `https://lvpr.tv/?v=` and observe the latency. This will help isolate the cause of the latency. If you are seeing higher-than-expected latency on the Livepeer Player (>15s for HLS or >4s for WebRTC), it suggests something about the incoming stream is causing high latency. Check your keyframe interval, bitrate, and b-frame settings. Viewers changing the resolution will also impact the latency for WebRTC, since this will necessarily incur transcode latency. ### If you’re using another HLS player, compare your HLS config to the Livepeer Player Our defaults can be found [here](https://github.com/livepeer/react/blob/47e572880224739f538e75ef192bb290b85a852f/packages/core-web/src/media/browser/hls/index.ts#L55-L61). Please note that this config is a starting point that we feel is a good balance for latency, quality, rebuffering, etc. ### Reach out to the Livepeer Studio team We will be happy to help troubleshoot so that you are able to achieve 0.5-3s latency with WebRTC or \~10s latency with HLS for the bulk of your users. Often, we achieve improvements by helping you tweak broadcasting settings or optimizing HLS configs. # Overview Source: https://docs.livepeer.org/v1/developers/guides/overview Practical step-by-step guides to help you achieve a specific goal. These guides are designed to help you get started with a specific task or feature. ### Video On Demand Upload a video asset to Livepeer Play a video asset with Player Upload and store encrypted videos. Set up webhook to receive notifications. Transcode videos programmatically Retrieve analytics via Livepeer API. Visualize analytics using Grafana. Visualize analytics using Timeplus. ### Livestream Start a live video broadcast. Watch live broadcasts in real-time. Broadcast using OBS Go live directly from your web browser. Keep track of the livestream's health Set up webhook to receive notifications. Livestream to multiple platforms at once. Clip a livestream ### Access control Control access using webhooks Control access using JWTs ### Webhooks Set up webhook to receive notifications. # Play a livestream Source: https://docs.livepeer.org/v1/developers/guides/playback-a-livestream Learn how to use a media player with Livepeer In this guide, we demonstrate how to play livestreams in your application. We do not recommend using ["CORS-enabled" API keys](/api-reference/overview/authentication) - they will be deprecated in an upcoming release. We recommend making requests from your backend to the Livepeer Studio API. ## Using the UI Kit Player The example below show to use the UI Kit [`Player`](/sdks/react/player/Root) to play a livestream. ``` ### Low Latency In the embeddable player, livestreams will, by default, play back with low-latency WebRTC. If this does not succeed in playing back (rarely, usually due to a slow network or connectivity issues), the embeddable player will automatically fall back to HLS playback. Also, if the stream contains B-frames (or bidirectional frames, which are common for users streaming with OBS or other streaming apps), the Player will automatically fall back to HLS, so that out-of-order frames are not displayed. *This only applies to users who are playing livestreams.* If you do not want to use WebRTC, you can pass `&lowLatency=false` in the query string, or if you want *only* low latency, you can pass `&lowLatency=force`. OBS users should be instructed to use the Livepeer Studio stream profile, or to manually turn off B-frames in their stream. See our [Stream from OBS](/developers/guides/stream-via-obs) docs for more information. ### Clipping To enable clipping, `&clipLength={seconds}` can be passed, which will allow viewers to clip livestreams. The length in seconds **must be less than 120 seconds**. ### Constant Playback The embed supports "constant" playback with `constant=true`, which means that audio will not be distorted if the playhead falls behind the livestream. This is usually used for music applications, where audio quality/consistency is more important than latency. ### Other Configs You can also override the default `muted` and `autoplay` behavior with `&muted=false` and/or `&autoplay=false`. These are set to true by default. Looping can also be set with `&loop=true`. ``` ### Configuration If you are using the iframe for livestreams as well as assets, see the livestream embed docs for how to set up low latency, clipping, and other configs for streams. You can override the default `muted` and `autoplay` behavior with `&muted=false` and/or `&autoplay=false`. These are set to true by default. Looping can also be set with `&loop=true`.