I’m using LiveKit with a self-hosted server, and I also have the egress service deployed. I’m using egress to launch the stream via RTMP and display the RTMP feed in a player for viewers. However, there is a significant delay between the LiveKit room and the RTMP live stream. I tried switching to HLS, but I still have the same issue. What would you suggest to reduce or eliminate this delay?

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

Îm uding room composite egress but what is the diffirence. Between the ffmeg and room composite egress

Thanks — I’ll explain the difference and the latency implications so you can pick the best option. • Room composite egress ◦ What it is: A headless Chrome instance renders the full room layout (multiple participant videos, canvas, overlays), captures that rendered output, then encodes and sends it to RTMP/HLS. ◦ When to use: You need a single composed view (gallery, speaker layout, overlays, or staged scene) that combines tracks into one output. ◦ Latency implications: Higher latency — browser compositing + capture + encoding adds processing overhead and startup time, so RTMP/HLS from composite will be noticeably delayed compared to in-room WebRTC. • FFmpeg / track (track-level) egress ◦ What it is: Individual published tracks are forwarded to an FFmpeg process (or similar encoder) which can directly transcode/pack and push to RTMP/HLS without using a browser compositor. ◦ When to use: You want single-track outputs (one camera, one screen share, or separate audio/video streams) or lower-overhead transcoding workflows. You can also stitch/encode with FFmpeg scripts if you need some layout control. ◦ Latency implications: Lower latency than browser-based composite because it avoids the headless Chrome capture step and typically uses more direct encoding pipelines. Still subject to RTMP/HLS buffering, so it won’t match WebRTC but will often be faster than composite egress. Recommendation: If your goal is lower end-to-end latency and you don’t require full-room compositing in a browser, switch to track/FFmpeg egress and optimize encoder settings (shorter GOP/keyframe interval, smaller HLS segment duration). If you still need a composed layout, consider producing separate tracks via FFmpeg and composing server-side with a lighter-weight encoder pipeline rather than using the Chrome compositor. If you want, tell me: • which layout/overlays you need in the final stream, and • whether you can accept separate streams or need a single composed output— and I’ll recommend the concrete egress setup and FFmpeg options. , with interactive elements

But the room is to record in live many participants , so what is the best solution

Thanks — I understand you need to record a room with many participants and want the best egress approach. Short recommendation • If you need one single composed recording (gallery/speaker layout, overlays): room composite egress is the easiest and safest choice for correct visuals, but it has higher latency and CPU cost. • If you prioritize lower latency, lower CPU, or finer control over encoding: use track-level (FFmpeg) egress — publish each participant track and let FFmpeg produce outputs. This is lower-overhead and can be used to: ◦ Record individual participant files (one file per participant). ◦ Produce a composed recording server-side with FFmpeg (combine tracks into a layout) for less overhead than a full Chrome compositor. ◦ Stream lower-latency RTMP/HLS outputs. Trade-offs • Room composite: simple single-file composed output, supports complex layouts/overlays, but higher latency and resource usage. • Track/FFmpeg: more setup work (syncing, composing if needed), more flexible, lower latency and CPU footprint for encoding. Quick questions to recommend a concrete setup 1. Do you need a single composed file (one video with all participants) or are individual per-participant recordings acceptable? 2. Do you require dynamic layouts/overlays (e.g., active speaker + graphics) that must match the room exactly? 3. What resources do you have for egress workers (CPU cores, memory, region)? Answer those and I’ll give a concrete egress configuration and FFmpeg command examples tailored to your needs. , with interactive elements

What the cpu and setup for the egress service ideal that will give no delai

Thanks — I’ll address the CPU/infra and configuration changes that will help minimize egress delay and set realistic expectations. Short reality check • You cannot achieve zero delay with RTMP/HLS; some latency is inherent to egress processing (compositing/transcoding) and the streaming protocols. WebRTC is the only option that matches LiveKit’s ultra-low in-room latency. What reduces egress delay (practical checklist) • Prefer track/FFmpeg egress over room composite when possible — it avoids the Chrome compositor overhead. • Use dedicated egress workers (don’t colocate with heavy services) so CPU isn’t shared. • Choose high-CPU instances for egress workers (more vCPUs improves encoding throughput and reduces queueing). • Keep egress workers and your CDN/players in the same region to reduce network latency. • Tune encoder settings: shorter GOP/keyframe interval, lower HLS segment duration, smaller buffer sizes. • Ensure ample network bandwidth and low packet loss between room server, egress worker, and RTMP/HLS destination. • Scale horizontally: run multiple egress workers to avoid queuing when multiple recordings/streams start. Recommended starting specs (for many-participant recording, lower latency) • Use dedicated machines with high single-thread and multi-core CPU capacity (example class: machines with >=8 vCPUs and high clock speed). More cores help when running multiple encodes or browser compositors. • Ensure at least 4–8 GB RAM per egress worker plus overhead for headless Chrome if using composite. • Use SSD storage for any local segmenting or temporary files. • Provision network bandwidth >= 50 Mbps upload per active high-bitrate stream (adjust upward for multiple simultaneous outputs). If you must use room composite • Expect higher CPU needs (headless Chrome + encoder). Use larger instances (more vCPUs) and prefer multiple workers to distribute load. • Consider lowering composition resolution or framerate to reduce encoding cost and latency. If you switch to track/FFmpeg egress • You’ll see lower processing overhead and reduced end-to-end delay. You can: ◦ Record per-participant files (minimal CPU per recording). ◦ Use FFmpeg to compose or transcode with tuned low-latency settings if a single output is required. Actionable next steps — tell me: 1. How many simultaneous participants (active video tracks) do you typically have? 2. Are you currently using room composite or can you switch to track/FFmpeg egress? 3. What instance type (vCPUs, RAM, region, network) are your egress workers running on? With those details I’ll recommend specific instance sizes and concrete FFmpeg/encoder settings to minimize delay. , with interactive elements