Ingress Overview

Use LiveKit's ingress service to bring live streams from non-WebRTC sources into LiveKit rooms.

On this page

IntroductionSupported SourcesWorkflowWHIP / RTMPURL InputAPICreateIngressListIngressUpdateIngressDeleteIngressUsing video presetsCustom settingsBypass transcoding for WHIP sessionsService architecture

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

Workflow

WHIP / RTMP

A typical push Ingress goes like this:

  1. Your app creates an Ingress with CreateIngress API, which returns a URL and stream key of the Ingress
  2. Your user copies and pastes the URL and key into your streaming workflow
  3. Your user starts their stream
  4. The Ingress Service starts transcoding their stream
  5. The Ingress Service joins the LiveKit room and publishes the transcoded media for other Participants
  6. When the stream source disconnects from the Ingress service, the Ingress Service participant leaves the room.
  7. 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 server, Ingress has a slightly different lifecycle: it will start immediately after calling CreateIngress.

  1. Your app creates an Ingress with CreateIngress API
  2. The Ingress Service starts fetching the file and transcoding it
  3. The Ingress Service joins the LiveKit room and publishes the transcoded media for other Participants
  4. When the file 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 contents:

{
    "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",
    "bypass_transcoding": true // for WHIP ingress only, disables transcoding and simulcast
}

Then create the Ingress using livekit-cli:

% export LIVEKIT_URL=https://my-livekit-host
% export LIVEKIT_API_KEY=livekit-api-key
% export LIVEKIT_API_SECRET=livekit-api-secret
% livekit-cli create-ingress --request 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 contents:

{
    "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) url to the file"
}

Then create the Ingress using livekit-cli:

% export LIVEKIT_URL=https://my-livekit-host
% export LIVEKIT_API_KEY=livekit-api-key
% export LIVEKIT_API_SECRET=livekit-api-secret
% livekit-cli create-ingress --request ingress.json

ListIngress

% livekit-cli list-ingress

The optional --room parameter allows restricting the output to the Ingress' associtated to a given room.

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.

% livekit-cli update-ingress --request ingress.json

The optional --room option allows to restrict the output to the Ingress associtated to a given room.

DeleteIngress

An Ingress can be reused multiple times. When not needed anymore, it can be deleted using the DeleteIngress API:

% livekit-cli delete-ingress --id 'ingress_id'

Using video presets

By default, the Ingress service transcodes the media being received using settings suitable for most use cases. These settings enable video simulcast to ensure media can be consumed by all viewers. 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 contents:

{
    "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 livekit-cli:

% livekit-cli create-ingress --request 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 contents:

{
    "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/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/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 livekit-cli:

livekit-cli create-ingress --request ingress.json

Bypass transcoding for WHIP sessions

For WHIP ingress sessions, the Ingress service allows disabling the transcoding step on the server. This means that the audio and video media sent by the WHIP encoder will be forwarded unmodified to the LiveKit clients. This decreases the end to end latency between the media encoder and the viewers. When using this mode, it is the responsibility of the entity setting the encoder parameters to ensure that these settings are compatible with all the clients who will consume the media, and achieve the right trade offs between quality and reach for clients with variable connection quality. Simulcast is not supported when bypassing transcoding.

This mode is enabled using the bypass_transcoding parameter in the create ingress request:

Create a file at ingress.json with the following contents:

{
    "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",
    "bypass_transcoding": true
}

Then create the Ingress using livekit-cli:

livekit-cli create-ingress --request 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.

Ingress instance

GitHubSlack
Sign in