Critical LiveKit Composite Egress Failure — GStreamer error: clock problem

Egress / Ingress
,
1

Critical LiveKit Composite Egress Failure — GStreamer error: clock problem

Summary

We are experiencing a reproducible production issue with LiveKit video Composite Egress.

The affected Egress processes fail with:

EGRESS_FAILED
error_code = 500
GStreamer error: clock problem.

The failure normally occurs approximately 2–7 seconds after Egress startup.

When the failure occurs:

  • output duration is 0

  • output bytes are 0

  • no recording artifact is produced

  • the recording cannot be used

Across the measured attempts:

  • 9 Composite attempts were observed

  • 7 failed

  • the last 6 attempts failed consecutively

We performed multiple controlled tests to isolate the issue and currently have strong evidence that the failure occurs in LiveKit’s managed browser / video Composite / GStreamer path.

We would appreciate your help identifying the root cause and providing a mitigation or fix as soon as possible.

Exact Failure

The repeated provider error is:

EGRESS_FAILED
error_code = 500
GStreamer error: clock problem.

The failure typically appears within a few seconds of startup.

Representative failed attempts:

Egress ID Status Error Code Error Alive Output Duration Output Bytes Artifact
EG_ANCr45HWMd4n EGRESS_FAILED 500 GStreamer error: clock problem. 7 s 0 0 none
EG_G953kpNLnR9B EGRESS_FAILED 500 GStreamer error: clock problem. 6 s 0 0 none
EG_ifDz5aMZrviS EGRESS_FAILED 500 GStreamer error: clock problem. 7 s 0 0 none

The application remained active after these Egress processes had already failed, so the failure appears to occur independently of normal session shutdown behavior.

Independent Web Egress Reproduction

To eliminate our application logic from the test, we ran a standard LiveKit Web Egress against:

https://example.com/

Result:

Egress ID: EG_TT2ezqZuheR9
Type: EGRESS_WEB
Status: EGRESS_FAILED
Error code: 500
Error: GStreamer error: clock problem.
Alive: approximately 2 seconds
Artifact: none

This experiment involved:

  • no application-specific page

  • no custom recorder template

  • no room participants

  • no application state

Requested video encoding:

1280×720
12 fps
900 kbps video
AAC 64 kbps
MP4

The same GStreamer clock error reproduced.

This suggested that the issue was not limited to our application.

Controlled Paired A/B Experiment

We then ran a paired experiment designed to compare audio-only recording with standard LiveKit video Composite under nearly identical conditions.

Both Egress requests were started approximately 1.094 seconds apart.

The following were held constant:

  • same LiveKit project

  • same LiveKit node

  • same region

  • same storage configuration

  • same deterministic publisher source

  • same MP4 output

  • same AAC 64 kbps audio

  • same StartRoomCompositeEgress API

  • one participant publishing AUDIO + VIDEO in each room

LiveKit node:

NM_OJEDDAH1A_6G54MtQSpSgg

Region:

Saudi Arabia / OJEDDAH1A

Server information observed:

version 1.13.6
protocol 17

Arm A — Audio-Only

Configuration:

audio_only: true
no layout
no custom_base_url
no video encoding

Result:

Egress ID: EG_nGnuG6jgbcRt
Status: EGRESS_COMPLETE
Error code: 0
Error: none
Alive: 52.48 seconds
Output duration: 51.92 seconds
Output bytes: 658,885
Artifact: present

The audio-only Egress remained active throughout the test and completed normally.

Arm B — Standard LiveKit Video Composite

Configuration:

audio_only: false
layout: "grid"
custom_base_url: none
resolution: 1280×720
framerate: 12 fps
video bitrate: 900 kbps
audio: AAC 64 kbps
container: MP4

This used LiveKit’s own built-in grid layout.

No custom page or custom recorder template was involved.

Result:

Egress ID: EG_PUkCJyxScftP
Status: EGRESS_FAILED
Error code: 500
Error: GStreamer error: clock problem.
Alive: 2.15 seconds
Output duration: 0
Output bytes: 0
Artifact: none

The Egress had already failed by the first three-second poll.

Why the Paired Experiment Is Important

The two tests ran:

  • on the same LiveKit project

  • on the same node

  • in the same minute

  • with the same storage configuration

  • using equivalent media publishers

The audio-only recording succeeded.

The standard video Composite failed immediately.

The primary difference between the two paths was whether LiveKit launched the managed browser/video Composite encoding path.

This strongly suggests that the failure is associated with the managed browser / video Composite / GStreamer portion of the Egress pipeline.

Previously Successful Composite Recordings

The same general video Composite configuration has successfully produced recordings in the past.

Examples include:

EG_mReGGnmzRFWo   EGRESS_COMPLETE   approximately 670 seconds
EG_2kEyu4XTzjGt   EGRESS_COMPLETE   538 seconds
EG_bbU7ZxKtK3zK   EGRESS_COMPLETE   71 seconds
EG_iqMAgnUcTTHu   EGRESS_COMPLETE

This is important because the configuration is not consistently invalid.

The same general settings have previously produced valid recordings.

Factors We Investigated

We investigated whether the failure could be caused by application lifecycle or media transitions.

The error occurred in scenarios where:

  • no camera transition occurred

  • no screen-sharing transition occurred

  • no reconnect occurred

  • no shutdown action had occurred yet

  • the failure happened before any long-running media activity

  • the failure occurred only a few seconds after Egress startup

We also reproduced the same error using:

  • LiveKit’s built-in Composite layout

  • no custom base URL

  • no custom application recorder

  • a plain Web Egress against example.com

For these reasons, we do not currently see evidence that application-specific logic is responsible.

Additional Observation

During the same investigation window, LiveKit Ingress also appeared degraded.

We observed:

  • two Ingress instances that were created but never began publishing

  • one CreateIngress request returning:

HTTP 503
request timed out

We consider this secondary evidence only, but it may help identify a broader provider-side condition affecting the same environment.

Current Failure Handling

When Egress fails, our application correctly:

  • releases the recording reservation

  • does not charge the user

  • does not expose a partial recording

  • does not create duplicate settlement records

  • does not leave a stranded reservation

  • does not expose Replay when no valid artifact exists

We have deliberately avoided implementing automatic retry behavior because repeated attempts could create conflicting or partial artifacts.

We would prefer to understand and resolve the underlying Egress failure rather than hide it with retries.

Technical Conclusion

Based on the current evidence, the issue appears to be associated with:

LiveKit’s managed browser / video Composite / GStreamer path.

The strongest evidence is:

  1. Standard LiveKit Room Composite using the built-in grid layout fails with the same error.

  2. Audio-only Room Composite succeeds on the same project, node, storage, and minute.

  3. Plain Web Egress against example.com, without any application code, also fails with the same error.

  4. The same general video Composite configuration has successfully worked previously.

Request for Help

We would appreciate LiveKit’s assistance investigating this issue.

Could your engineering team please help us determine:

  1. Why standard video Composite Egress is failing with:
GStreamer error: clock problem.

on node:

NM_OJEDDAH1A_6G54MtQSpSgg

  1. Why audio-only Egress succeeds on the same project and node at the same time while video Composite fails.

  2. Whether there is a known internal issue involving:

  • the affected node

  • the Saudi Arabia region

  • managed Egress browsers

  • GStreamer clock or timestamp handling

  • video encoding

  • Egress worker capacity

  • degraded Egress workers

  • a recent Egress deployment or regression

  1. Whether you can inspect your internal logs for the following Egress IDs:
EG_PUkCJyxScftP
EG_TT2ezqZuheR9
EG_ANCr45HWMd4n
EG_G953kpNLnR9B
EG_ifDz5aMZrviS
EG_nGnuG6jgbcRt

The final ID is a successful audio-only control from the same minute and may be useful for comparison.

  1. Whether there is a recommended temporary mitigation, such as:

  • routing Egress to another region or node

  • changing Composite configuration

  • changing frame rate

  • changing codec

  • using another supported Egress configuration

We have intentionally avoided making speculative configuration changes so the issue remains reproducible.

Requested Priority

This issue is affecting production recording reliability.

When the failure occurs, the recording process produces no artifact at all.

We would greatly appreciate:

  • root-cause investigation

  • a recommended temporary mitigation

  • and a permanent resolution as soon as possible

If first-line support cannot inspect the relevant GStreamer or internal Egress logs, please escalate this case to the LiveKit Egress / Cloud Engineering Team.

Thank you for your help.

2

Any ideas on this one @Milos_Pesic

3

This is a known issue with requests setting relatively low fps. We will be working on addressing that on our side - in a meantime as a mitigation could you try increasing fps value to at least >=15 if that’s possible?