Thanks for retesting, @MathiasLui! What you're seeing in Firefox is now the expected behaviour.
The LiveKit server refuses H.264 publishing from Firefox on Linux and Android [1]. Until now we still offered H.264 there, so the client asked for it and the SDK silently fell back to VP8 while the UI and diagnostics kept saying H.264. #3122 stops offering H.264 in that case, so the codec picker now shows what is actually sent.
We clamp screen shares to 720p30 when H.264 runs as a software encoder [2], because Chromium's software H.264 encoder (OpenH264) can't keep up at higher settings. Before that fix the app believed it was sending H.264, so it applied the clamp to what was really a VP8 stream. Now that it knows it's VP8, the clamp no longer applies.
Firefox doesn't implement hardware encoding for WebRTC on Linux. Its VA-API support only covers decoding [3], so AV1 is software as well. The yellow warning is gone because Firefox doesn't report which encoder it uses, so we can't tell either way. It doesn't mean it switched to hardware.
Firefox doesn't support H.265 for WebRTC at all, only Chrome 136+ does [4].
Chromium on Linux ships with hardware video encoding off unless it's enabled with AcceleratedVideoEncoder on a working VA-API driver [5]. So H.264 there was software and got the 720p30 clamp, while VP8 and VP9 didn't. #3139 makes Automatic skip H.264 whenever it would be software encoded and clamped, and pick VP9 or VP8 instead. A manual H.264 pick is still honoured. (The diagnostic labelled H.264 in your comment is actually from a VP8 share, for what it's worth.)
[1] [livekit-server `clientconfiguration/conf.go`, Firefox on Linux/Android H.264 publish rule](https://github.com/livekit/livekit/blob/v1.12.0/pkg/clientconfiguration/conf.go#L52-L64)
[2] [Software H.264 screen share budget in `ScreenShareOptions.ts`](https://github.com/fluxerapp/fluxer/blob/98fa41dc/fluxer_app/src/features/voice/utils/ScreenShareOptions.ts#L32-L33)
[3] [Fedora Project Wiki, Firefox hardware acceleration](https://fedoraproject.org/wiki/Firefox_Hardware_acceleration)
[4] [MDN, Codecs used by WebRTC](https://developer.mozilla.org/en-US/docs/Web/Media/Guides/Formats/WebRTC_codecs)
[5] [ArchWiki, Chromium hardware video acceleration](https://wiki.archlinux.org/title/Chromium/Tips_and_tricks)
Thread
Comment by Hampus
AcceleratedVideoEncoderon a working VA-API driver [5]. So H.264 there was software and got the 720p30 clamp, while VP8 and VP9 didn't. #3139 makes Automatic skip H.264 whenever it would be software encoded and clamped, and pick VP9 or VP8 instead. A manual H.264 pick is still honoured. (The diagnostic labelled H.264 in your comment is actually from a VP8 share, for what it's worth.)