feat(media): deploy Element Call fork + optimize LiveKit quality
- Deploy self-hosted Element Call at call.sunbeam.pt with SSO login - LiveKit: VP9 > AV1 > H.264 codec preferences, Opus stereo - LiveKit: congestion_control.allow_pause=false, larger NACK buffers - LiveKit: resources bumped to 2Gi/4CPU for VP9 SVC - Proxy: add call.* route, TLS cert SAN for call.sunbeam.pt
This commit is contained in:
@@ -4,16 +4,57 @@
|
||||
# Reference: https://github.com/livekit/livekit-helm/blob/master/server-sample.yaml
|
||||
|
||||
livekit:
|
||||
# LiveKit server config injected as config.yaml
|
||||
port: 7880
|
||||
log_level: info
|
||||
prometheus_port: 6789
|
||||
|
||||
# ── Codec preferences (order matters — first match wins) ────────────
|
||||
room:
|
||||
enabled_codecs:
|
||||
- mime: audio/opus
|
||||
- mime: audio/red
|
||||
# VP9: ~2x quality-per-bit over H.264, built-in SVC.
|
||||
- mime: video/vp9
|
||||
# AV1: best compression, limited HW decode support still.
|
||||
- mime: video/av1
|
||||
# H.264: broadest HW accel, fallback for constrained clients.
|
||||
- mime: video/h264
|
||||
# VP8: widest compatibility baseline (Element Call default).
|
||||
- mime: video/vp8
|
||||
|
||||
# Receiver-side jitter buffer. Tight values for a small team.
|
||||
playout_delay:
|
||||
enabled: true
|
||||
min: 100
|
||||
max: 500
|
||||
sync_streams: true
|
||||
empty_timeout: 300
|
||||
departure_timeout: 20
|
||||
|
||||
# ── RTC / transport ─────────────────────────────────────────────────
|
||||
rtc:
|
||||
port_range_start: 49152
|
||||
port_range_end: 49252
|
||||
tcp_port: 7881
|
||||
use_external_ip: true
|
||||
allow_tcp_fallback: true
|
||||
|
||||
# Request keyframes faster after quality drops.
|
||||
pli_throttle:
|
||||
low_quality: 300ms
|
||||
mid_quality: 500ms
|
||||
high_quality: 500ms
|
||||
|
||||
# Larger NACK retransmission buffers for loss recovery.
|
||||
packet_buffer_size_video: 1000
|
||||
packet_buffer_size_audio: 500
|
||||
|
||||
# Never pause video tracks due to congestion — we have the bandwidth.
|
||||
congestion_control:
|
||||
enabled: true
|
||||
allow_pause: false
|
||||
|
||||
# ── TURN ────────────────────────────────────────────────────────────
|
||||
turn:
|
||||
enabled: true
|
||||
domain: meet.DOMAIN_SUFFIX
|
||||
@@ -24,11 +65,8 @@ livekit:
|
||||
relay_range_end: 23333
|
||||
|
||||
redis:
|
||||
# Valkey is protocol-compatible with Redis; LiveKit sees this as a Redis endpoint
|
||||
address: valkey.data.svc.cluster.local:6379
|
||||
|
||||
# API keys — loaded from K8s Secret managed by VSO (secret/livekit in OpenBao).
|
||||
# The keys.yaml field contains "devkey: <api-secret>" in YAML format.
|
||||
key_file: keys.yaml
|
||||
|
||||
storeKeysInSecret:
|
||||
@@ -39,16 +77,14 @@ storeKeysInSecret:
|
||||
# chart template requires livekit.prometheus_port which conflicts with hostNetwork.
|
||||
|
||||
deployment:
|
||||
# hostNetwork gives LiveKit direct access to the host network namespace,
|
||||
# which is the only practical way to expose the 10k-port TURN relay range
|
||||
# (13333-23333) without listing individual hostPorts in the pod spec.
|
||||
hostNetwork: true
|
||||
resources:
|
||||
limits:
|
||||
memory: 128Mi
|
||||
memory: 2048Mi
|
||||
cpu: 4000m
|
||||
requests:
|
||||
memory: 64Mi
|
||||
cpu: 100m
|
||||
memory: 512Mi
|
||||
cpu: 500m
|
||||
|
||||
# Recreate strategy: hostPorts (TURN UDP relay range) block RollingUpdate —
|
||||
# the new pod cannot schedule while the old one still holds the host ports.
|
||||
|
||||
Reference in New Issue
Block a user