Subject: TrackCompositeEgress for Internal Streaming Without Pre-existing Track IDs Context: We are building a live streaming platform where hosts stream their scenes to YouTube. We have two streaming types: 1. External — OBS pushes via RTMP to LiveKit Ingress → we use

TrackCompositeEgress

with ingress track IDs ✅ works perfectly 2. Internal — Host shares browser tab (scene URL) via WebRTC screen share → we want to use

TrackCompositeEgress

but facing issues Current Problem: For internal streaming, we currently use

WebEgress

which opens our display page (

/display

) in a headless browser. This causes duplicate audio — the display page plays participant audio AND the host hears it echoed back through their screen share capture. What We Tried: We want to switch internal streaming to

TrackCompositeEgress

to avoid the headless browser and duplicate audio issue. However: When stream starts, the host may not have published their screen share tracks yet — so

TrackCompositeEgress

fails with

invalid_argument: audio_track_id or video_track_id missing

We tested passing

nil

for track IDs — LiveKit returns

invalid_argument

— so empty track IDs are not supported 1. We need the egress to capture screen share audio + video when host starts screen sharing, and fall back to mic + camera when not sharing Questions: Is there a way to create

TrackCompositeEgress

without specifying track IDs upfront and have LiveKit auto-select tracks as they are published? Is there a

track_published

webhook event we can listen to so we can create egress after the host publishes their screen share tracks? 1. Can we update an existing

TrackCompositeEgress

to swap track IDs when the host switches between camera and screen share? 2. What is the recommended approach for capturing a host's screen share + audio for streaming to RTMP when tracks are published after egress creation? Tech Stack: Ruby on Rails backend, LiveKit Ruby SDK, Next.js frontend, LiveKit JS SDK

Thanks for reaching out, Chandan. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

any other solution

Thanks — I hear you want alternatives that avoid frequent stop/start of TrackCompositeEgress and still prevent duplicate audio. Options to consider (short list): • Use RoomCompositeEgress instead of TrackCompositeEgress ◦ Start a RoomCompositeEgress for the whole room (no per-track IDs). It captures all published tracks and lets you compose/layout streams server-side. This removes the need to know track IDs up front. Note: composition is room-wide, so you’ll need to filter/select what you want in the final layout. • Client-side mix + single published mixed track ◦ Have the host (or a lightweight mixing participant) mix screen video + the desired audio locally (or in your app), then publish a single “stream” track to the room. Start TrackCompositeEgress against that single mixed track ID. This avoids server-side switching and prevents echo because the browser capture excludes playback audio. • Use a small dedicated “muxer” participant/Bot that joins and captures locally ◦ Run a minimal headless or server-side participant that subscribes to the host’s tracks (or the room), performs mixing (mute playback to avoid echo), and re-publishes a stable track ID for egress to use. This keeps egress stable and offloads switching to the muxer. • Faster stop/start orchestration (optimized fallback) — keep if other options infeasible ◦ Start with mic+cam egress, listen for

track_published

for screen-share, then stop/start TrackCompositeEgress quickly. Keep the same RTMP target to reduce visible transitions; optimize for minimal downtime. Questions to pick the best path: • Do you need selective per-participant composition (only host), or is capturing the entire room acceptable? • Can you run a small mixing process (client or server-side bot), or must all logic stay purely server-side without extra participants? Tell me which constraints apply and I’ll give a focused implementation sketch (Rails webhook + Ruby SDK, or a small muxer design). , with interactive elements

Multiple participants can share their screen, not just the host. The scene layout determines what gets streamed — it's a custom Rails page that renders: • Video feed elements (showing specific participants' camera/screen share) • Text overlays, graphics, banners • Custom layouts with multiple participants So we need to capture the entire scene layout as rendered, not individual tracks. This makes

RoomCompositeEgress

with a custom layout URL the most suitable option. Updated preferred approach:

RoomCompositeEgress

with custom layout URL — if it supports providing our own display page URL (like

WebEgress

does), this would be perfect because: • No track ID management needed • Captures the full scene with all overlays and elements • No duplicate audio since it's a separate headless browser context • Handles any participant's screen share automatically • No stop/start needed when participants switch between camera and screen share Key question: Can

RoomCompositeEgress

accept a custom layout URL (our scene display page at

<https://our-domain.com/display/:uuid>

) similar to how

WebEgress

works? If yes, this solves all our problems cleanly. If not, what is the recommended way to stream a custom scene layout that includes multiple participants' tracks, overlays, and dynamic elements to RTMP?

Thanks — I’m responding to your key question about using RoomCompositeEgress with your custom scene URL and the best way to stream a fully custom layout (multiple participants, overlays, dynamic screen shares) to RTMP. Short answer • RoomCompositeEgress does not accept an arbitrary external URL (like

https://our-domain.com/display/:uuid

) in the same way WebEgress does. • RoomCompositeEgress uses the Egress Template SDK: you must provide a template (hosted for the egress service) that implements your layout logic. The egress service runs the template in a headless browser and captures the composed output. • WebEgress is the feature that captures a supplied web page URL directly, but RoomCompositeEgress won’t load your Rails page by URL. What that means for your requirements • If you need the exact Rails-rendered page (your scene HTML/CSS/JS) captured as-is, WebEgress is the intended match because it accepts a page URL. If WebEgress supports RTMP in your environment, it solves your needs directly. • If you must use RoomCompositeEgress (for RTMP support or other reasons), you’ll need to reproduce your scene within an Egress Template. The template can: ◦ Render multiple participant tracks, screen shares, overlays, banners, and dynamic layouts. ◦ Be driven by the same data/logic you use in your Rails page, but implemented inside the template (web code run by the egress service). ◦ Capture any participant’s screen share automatically because it subscribes to room tracks. Alternatives and trade-offs • WebEgress (capture your actual display URL): Easiest to preserve exact Rails rendering and page logic. Confirm whether your deployment’s WebEgress supports RTMP output if RTMP is required. • RoomCompositeEgress + Egress Template SDK: More work to port your scene into the template, but offers server-managed composition and is compatible with RoomComposite workflows (and captures screen shares and overlays via template logic). • Hybrid: Replicate only the dynamic composition parts in the template (reuse components) and keep nonessential UI in Rails to minimize porting. Recommended next step (pick one) • If capturing the Rails page exactly is highest priority: try WebEgress for the display URL and verify RTMP support in your environment. • If RTMP support requires RoomCompositeEgress or you want the egress to control composition: plan to port the scene into an Egress Template. I can help sketch how to map your Rails components to a template (track placement, overlay injection, layout rules). Which path do you prefer — test WebEgress for RTMP, or get a template-sketch to port your Rails scene into RoomCompositeEgress? Sources: Universal Egress | LiveKit | server-sdk-js | livekit/livekit_composite | DeepWiki, with interactive elements