Stream from the Browser
We demonstrate below how to broadcast from the web using Livepeer's low latency WebRTC broadcast.
Using Livepeer.js Broadcast
The example below show to use Livepeer.js Broadcast
to broadcast from the web.
Configuring Providers
First, we create a new livepeer.js client with a gateway provider and a CORS-protected API key, as well as a theme to use for all livepeer.js React components.
import {
LivepeerConfig,
createReactClient,
studioProvider,
} from '@livepeer/react';
import * as React from 'react';
const livepeerClient = createReactClient({
provider: studioProvider({
apiKey: process.env.NEXT_PUBLIC_STUDIO_API_KEY,
}),
});
function App() {
return (
<LivepeerConfig client={livepeerClient}>
<CreateAndViewAsset />
</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!
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
The embeddable broadcast is currently in beta and some elements may change as we mature the product. For a production-grade application consider using Livepeer.js instead.
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"
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 broadcasting with plain WebRTC
Using livepeer.js is the recommended way to add easy broadcasting via WebRTC. If you want to add broadcasting to your app and handle the WebRTC 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 (opens in a new tab) and kick off a livestream.
The outline of the steps are:
- Create a new
RTCPeerConnection
with the ICE servers from the redirect URL. - Construct an SDP offer using the library of your choice.
- Wait for ICE gathering.
- Send the SDP offer to the server and get the response.
- Use the response to set the remote description on the
RTCPeerConnection
. - Get a local media stream and add the track to the peer connection, and set the video element
src
to thesrcObject
.
// 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):
+-----------------+ +---------------+ +--------------+ +----------------+
| 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.