feat: Try h264 instead of vp8 - compatible with classic simulcast, hardware-accelerated on more devices
This commit is contained in:
@@ -1,6 +1,6 @@
|
||||
{
|
||||
"name": "@sorb/threadnet-call-embedded",
|
||||
"version": "0.19.2-threadnet.3",
|
||||
"version": "0.19.2-threadnet.4",
|
||||
"files": [
|
||||
"README.md",
|
||||
"LICENSE-AGPL-3.0",
|
||||
|
||||
@@ -31,12 +31,12 @@ export default defineConfig((env) =>
|
||||
delayed_leave_event_delay_ms: 18000,
|
||||
},
|
||||
media_quality: {
|
||||
// video_codec intentionally left unset (defaults to vp8) - setting it to
|
||||
// "vp9" broke calls entirely in production (2026-07-28, no audio/video
|
||||
// transmitted). Likely cause: LiveKit uses SVC for vp9/av1 instead of
|
||||
// classic simulcast, but buildPublishOptions() in src/livekit/options.ts
|
||||
// always sets simulcast-shaped videoSimulcastLayers regardless of codec -
|
||||
// needs a code fix in that function before vp9 can be retried safely.
|
||||
// h264 uses classic simulcast (like vp8), not SVC, so it's compatible
|
||||
// with buildPublishOptions()'s simulcast-shaped layers without a code
|
||||
// fix - unlike vp9/av1 (see 2026-07-28 incident: forcing vp9 broke calls
|
||||
// entirely, likely due to that SVC/simulcast mismatch). h264 also tends
|
||||
// to be hardware-accelerated on more devices (notably iOS/Safari).
|
||||
video_codec: "h264",
|
||||
video: {
|
||||
max_resolution: 1440,
|
||||
max_bitrate: 8_000_000,
|
||||
|
||||
Reference in New Issue
Block a user