Introduction
LiveKit Ingress lets you import video from another source into a LiveKit room. While WebRTC is a versatile and scalable transport protocol for both media ingestion and delivery, some applications require integrating with existing workflows or equipment that do not support WebRTC. Perhaps your users want to publish video from OBS Studio or a dedicated hardware device, or maybe they want to stream the content of media file hosted on a HTTP server to a room. LiveKit Ingress makes these integrations easy.
LiveKit Ingress can automatically transcode the source media to ensure compatibility with LiveKit clients. It can publish multiple layers with Simulcast. The parameters of the different video layers can be defined at ingress creation time. Presets are provided to make encoding settings configuration easy. The optional ability to provide custom encoding parameters enables more specialized use cases.
For LiveKit Cloud customers, Ingress is ready to use with your project without additional configuration. When self-hosting LiveKit, Ingress is deployed as a separate service.
Supported Sources
- RTMP/RTMPS
- WHIP
- Media files fetched from any HTTP server. The following media formats are supported:
- HTTP Live Streaming (HLS)
- ISO MPEG-4 (MP4)
- Apple Quicktime (MOV)
- Matroska (MKV/WEBM)
- OGG audio
- MP3 audio
- M4A audio
- Media served by a SRT server
Workflow
WHIP / RTMP
A typical push Ingress goes like this:
- Your app creates an Ingress with
CreateIngress
API, which returns a URL and stream key of the Ingress - Your user copies and pastes the URL and key into your streaming workflow
- Your user starts their stream
- The Ingress Service starts transcoding their stream, or forwards media unchanged if transcoding is disabled.
- The Ingress Service joins the LiveKit room and publishes the media for other Participants
- When the stream source disconnects from the Ingress service, the Ingress Service participant leaves the room.
- The Ingress remains valid, in a disconnected state, allowing it to be reused with the same stream key
URL Input
When pulling media from a HTTP or SRT server, Ingress has a slightly different lifecycle: it will start immediately after calling CreateIngress.
- Your app creates an Ingress with
CreateIngress
API - The Ingress Service starts fetching the file or media and transcoding it
- The Ingress Service joins the LiveKit room and publishes the transcoded media for other Participants
- When the media is completely consumed, or if
DeleteIngress
is called, the Ingress Service participant leaves the room.
API
CreateIngress
WHIP / RTMP example
To provision an Ingress with the Ingress Service, use the CreateIngress API. It returns an IngressInfo
object that describes the created Ingress, along with connection settings. These parameters can also be queried at any time using the ListIngress
API
Create a file at ingress.json
with the following content:
{"input_type": 0 for RTMP, 1 for WHIP"name": "Name of the Ingress goes here","room_name": "Name of the room to connect to","participant_identity": "Unique identity for the room participant the Ingress service will connect as","participant_name": "Name displayed in the room for the participant","enable_transcoding": true // Transcode the input stream. Can only be false for WHIP,}
Then create the Ingress using lk
:
export LIVEKIT_URL=https://my-livekit-hostexport LIVEKIT_API_KEY=livekit-api-keyexport LIVEKIT_API_SECRET=livekit-api-secretlk ingress create ingress.json
URL Input example
With URL Input, Ingress will begin immediately after CreateIngress
is called. URL_INPUT Ingress cannot be re-used.
Create a file at ingress.json
with the following content:
{"input_type": "URL_INPUT", // or 2"name": "Name of the Ingress goes here","room_name": "Name of the room to connect to","participant_identity": "Unique identity for the room participant the Ingress service will connect as","participant_name": "Name displayed in the room for the participant","url": "HTTP(S) or SRT url to the file or stream"}
Then create the Ingress using lk
:
export LIVEKIT_URL=https://my-livekit-hostexport LIVEKIT_API_KEY=livekit-api-keyexport LIVEKIT_API_SECRET=livekit-api-secretlk ingress create ingress.json
ListIngress
lk ingress list
The optional --room
option allows to restrict the output to the Ingress associated to a given room. The --id
option can check if a specific ingress is active.
UpdateIngress
The Ingress configuration can be updated using the UpdateIngress
API. This enables the ability to re-use the same Ingress URL to publish to different rooms. Only reusable Ingresses, such as RTMP or WHIP, can be updated.
Create a file at ingress.json
with the fields to be updated.
{"ingress_id": "Ingress ID of the Ingress to update","name": "Name of the Ingress goes here","room_name": "Name of the room to connect to","participant_identity": "Unique identity for the room participant the Ingress service will connect as","participant_name": "Name displayed in the room for the participant"}
The only required field is ingress_id
. Non provided fields are left unchanged.
lk ingress update ingress.json
DeleteIngress
An Ingress can be reused multiple times. When not needed anymore, it can be deleted using the DeleteIngress
API:
lk ingress delete <INGRESS_ID>
Using video presets
The Ingress service can transcode the media being received. This is the only supported behavior for RTMP and URL inputs. WHIP ingresses are not transcoded by default, but transcoding can be enabled by setting the enable_transcoding
parameter. When transcoding is enabled, The default settings enable video simulcast to ensure media can be consumed by all viewers, and should be suitable for most use cases. In some situations however, adjusting these settings may be desirable to match source content or the viewer conditions better. For this purpose, LiveKit Ingress defines several presets, both for audio and video. Presets define both the characteristics of the media (codec, dimesions, framerate, channel count, sample rate) and the bitrate. For video, a single preset defines the full set of simulcast layers.
A preset can be chosen at Ingress creation time from the constants in the Ingress protocol definition:
Create a file at ingress.json
with the following content:
{"name": "Name of the egress goes here","room_name": "Name of the room to connect to","participant_identity": "Unique identity for the room participant the Ingress service will connect as","participant_name": "Name displayed in the room for the participant""video": {"name": "track name","source": "SCREEN_SHARE","preset": "Video preset enum value"},"audio": {"name": "track name","source": "SCREEN_SHARE_AUDIO","preset": "Audio preset enum value"}}
Then create the Ingress using lk
:
lk ingress create ingress.json
Custom settings
For specialized use cases, it is also possible to specify fully custom encoding parameters. In this case, all video layers need to be defined if simulcast is desired.
Create a file at ingress.json
with the following content:
{"name": "Name of the egress goes here","room_name": "Name of the room to connect to","participant_identity": "Unique identity for the room participant the Ingress service will connect as","participant_name": "Name displayed in the room for the participant","video": {"options": {"video_codec": "video codec ID from the [VideoCodec enum](https://github.com/livekit/protocol/blob/main/protobufs/livekit_models.proto)","frame_rate": "desired framerate in frame per second","layers": [{"quality": "ID for one of the LOW, MEDIUM or HIGH VideoQualitu definitions","witdh": "width of the layer in pixels","height": "height of the layer in pixels","bitrate": "video bitrate for the layer in bit per second"}]}},"audio": {"options": {"audio_codec": "audio codec ID from the [AudioCodec enum](https://github.com/livekit/protocol/blob/main/protobufs/livekit_models.proto)","bitrate": "audio bitrate for the layer in bit per second","channels": "audio channel count, 1 for mono, 2 for stereo","disable_dtx": "wether to disable the [DTX feature](https://www.rfc-editor.org/rfc/rfc6716#section-2.1.9) for the OPUS codec"}}}
Then create the Ingress using lk
:
lk ingress create ingress.json
Enabling transcoding for WHIP sessions
By default, WHIP ingress sessions forward incoming audio and video media unmodified from the source to LiveKit clients. This behavior allows the lowest possible end to end latency between the media source and the viewers. This however requires the source encoder to be configured with settings that are compatible with all the subscribers, and ensure the right trade offs between quality and reach for clients with variable connection quality. This is best achieved when the source encoder is configured with simulcast enabled.
If the source encoder cannot be setup easily to achieve such tradeoffs, or if the available uplink bandwidth is insufficient to send all required simulcast layers, WHIP ingresses can be configured to transcode the source media similarly to other source types. This is done by setting the enable_transcoding
option on the ingress. The encoder settings can then be configured in the audio
and video
settings in the same manner as for other inputs types.
Create a file at ingress.json
with the following content:
{"input_type": 1 (WHIP only)"name": "Name of the egress goes here","room_name": "Name of the room to connect to","participant_identity": "Unique identity for the room participant the Ingress service will connect as","participant_name": "Name displayed in the room for the participant","enable_transcoding": true"video": {"name": "track name","source": "SCREEN_SHARE","preset": "Video preset enum value"},"audio": {"name": "track name","source": "SCREEN_SHARE_AUDIO","preset": "Audio preset enum value"}}
Then create the Ingress using lk
:
lk ingress create ingress.json
Service architecture
LiveKit Ingress exposes public RTMP and WHIP endpoints streamers can connect to. On initial handshake, the Ingress service validates the incoming request and retrieves the corresponding Ingress metadata, including what LiveKit room the stream belongs to. The Ingress server then sets up a GStreamer based media processing pipeline to transcode the incoming media to a format compatible with LiveKit WebRTC clients, publishes the resulting media to the LiveKit room.