We demonstrate below how to broadcast from the web using Livepeer’s low latency WebRTC broadcast. Developers can either use the Livepeer Broadcast React component, or build their own WebRTC solution.

​
Using Livepeer React Broadcast

The example below show to use the Livepeer React Broadcast component to broadcast from the web.

​
Configuring providers

First, we create a new React client and wrap the app with LivepeerConfig.

​
Broadcast

Now that our providers are set up, we use the Broadcast with a stream key, from a stream we created. We also override some of the custom styling to match the flow of our app!

Broadcast.tsx
import { Broadcast } from "@livepeer/react";

const streamKey = "your-stream-key";

export const DemoBroadcast = () => {
  return (
    <Broadcast
      streamKey={streamKey}
      controls={{
        autohide: 3000,
      }}
      theme={{
        borderStyles: { containerBorderStyle: "hidden" },
        radii: { containerBorderRadius: "10px" },
      }}
    />
  );
};

​
Embeddable broadcast

This is one of the easiest way 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.

<iframe
  src="https://lvpr.tv/broadcast/{STREAM_KEY}"
  allowfullscreen
  allow="autoplay; encrypted-media; picture-in-picture; camera; microphone"
  sandbox="allow-same-origin allow-scripts"
>
</iframe>

This will automatically stream from the browser, using the STUN/TURN servers to ensure that network connectivity issues are rare.

​
Adding custom broadcasting

If you want to add custom broadcasting to your app and handle the WebRTC SDP negotiation, 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 GET request to the WebRTC redirect endpoint:

curl -L 'https://livepeer.studio/webrtc/{STREAM_KEY}'
...
> Location: https://lax-prod-catalyst-2.lp-playback.studio/webrtc/{STREAM_KEY}

You may safely ignore any errors returned from the GET request - we are only interested in getting the redirect URL from the final response, so that we can set up the correct ICE servers.

We know from the above response headers that the WebRTC ingest URL 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 GET 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 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.
// 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 webcam source and started a broadcast!

To make the above process clearer, here is the flow (credit to the authors of the WHIP spec):

WHIP Outline
+-----------------+         +---------------+ +--------------+ +----------------+
 | 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

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 broadcaster.

Was this page helpful?

Livestream via OBSOptimize latency