Ingress Overview

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.

• 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

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, or forwards media unchanged if transcoding is disabled.
5. The Ingress Service joins the LiveKit room and publishes the 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

When pulling media from a HTTP or SRT 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 or media and transcoding it
3. The Ingress Service joins the LiveKit room and publishes the transcoded media for other Participants
4. When the media is completely consumed, or if DeleteIngress is called, the Ingress Service participant leaves the room.

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

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

export LIVEKIT_URL=https://my-livekit-host
export LIVEKIT_API_KEY=livekit-api-key
export LIVEKIT_API_SECRET=livekit-api-secret

lk ingress create ingress.json

With URL Input, Ingress will begin immediately after CreateIngress is called. URL_INPUT Ingress cannot be re-used.

{
    "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"
}

export LIVEKIT_URL=https://my-livekit-host
export LIVEKIT_API_KEY=livekit-api-key
export LIVEKIT_API_SECRET=livekit-api-secret

lk ingress create ingress.json

lk ingress list

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.

{
    "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"
}

lk ingress update ingress.json

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

lk ingress delete <INGRESS_ID>

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:

{
    "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"
    }
}

lk ingress create ingress.json

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.

{
    "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"
        }
    }
}

lk ingress create ingress.json

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.

{
    "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"
    }
}

lk ingress create ingress.json

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.