Mac-Intel are still very common and clients still use it a lot. Livekit wont work and will display a green screen (even in the sample application) when using Mac with intel chipset and safari with VP8 or VP9.
Hi @debugChicken , reading through the latest updates on [bug][reproductible in sample app] VP8/VP9 codecs do not work on intel-mac safari · Issue #1975 · livekit/client-sdk-js · GitHub it feels like the issue is only on VP8 now, not VP9?
Its both. Maybe VP9 falling back to VP8 because VP9 cannot even be run. Anyway, the big boss at my enterprise will escalate because it finally happened to a client so it should be looking into quite soon. Thanks for the answer though!
@debugChicken, Your own stats screenshot points straight at the decode path. Audio is clean (Opus, 0 lost). Video shows VP9/90000 at 1588 kbps, 1280x720 25fps, 1851 frames received and 1851 “decoded,” yet the picture is solid green and decoder: null. So the stream arrives fine and the network is healthy; the browser just cannot turn those VP9 frames into an image. Solid green is the classic signature of an all-zero YUV buffer reaching the renderer, which means the decode failed silently, not the send side or the SFU.
That localizes it: Safari on Intel Macs has no working VP8/VP9 decode here, while Apple Silicon does. It is a browser decode bug, tracked in client-sdk-js #1975, not a LiveKit encode or config fault.
The interim that unblocks your Intel-Mac users today is to publish H.264 instead of VP8/VP9. Safari decodes H.264 in hardware on Intel Macs, so it avoids the broken software VP8/VP9 path entirely. H.264 is a first-class LiveKit codec and you pick it at connect time (codecs).
const room = new Room({
publishDefaults: { videoCodec: 'h264' }, // Safari decodes H.264 in hardware; sidesteps the VP8/VP9 decode bug
});
One thing to get right: the codec is chosen by the publisher, not the viewer. An Intel-Mac Safari client cannot fix what it receives; the clients publishing the video have to send H.264. In a symmetric room, set this on every client. Trade-off: H.264 drops the VP9/AV1 SVC layering, but it decodes reliably on Safari, which is the whole point here. Keep it until the decode fix lands in #1975.
h264 has many, many more bugs: audio issues, video issues, screen share issues, a whole ordeal of issues. its not worth it to support old intel macs specifically on safari to use h264 whatsoever. i already tried that. it was terrible.
Fair enough, if H.264 caused more problems than it solved for your stack, there is no clean client-side codec path left on Intel-Mac Safari, since that is the only one it hardware-decodes. The real fix is the decode bug itself in #1975..