On Thu, 9 Jan 2025 14:16:41 +0100 Landry Breuil <lan...@openbsd.org> wrote:
> Le Thu, Jan 09, 2025 at 10:17:47AM +0100, Stefan Hagen a écrit : > > Kirill A. Korinsky wrote (2025-01-08 22:58 CET): > > > On Wed, 08 Jan 2025 22:27:49 +0100, > > > Klemens Nanni <k...@openbsd.org> wrote: > > > > > > > > 8 янв. 2025 г. 18:26:37 Johannes Thyssen Tishman > > > > <johan...@thyssentishman.com>: > > > > > Some web conferencing applications, like Webex or Jitsi-meet, > > > > > require H264 hardware decoding to work, but in Firefox, this > > > > > feature is disabled by default. > > > > > > > > Why? > > > > > > > > Can it not detect it at runtime or is there a reason to not use > > > > it? > > > > > > > > I am under the impression that you want to offload whenever > > > > possible. > > > > > > I just tried test meeting in webex.com and it indeed, doesn't > > > work under firefox with error: > > > > > > Your browser doesn't meet Webex system requirements. > > > Install and activate the OpenH264 Video Codec provided by Cisco > > > Systems, Inc. and then try joining again. > > > > > > Before I had join the meeting the cam works. > > > > It's not about _your_ cam. It's about how it plays other cams to > > you. > > > Thus, I also had tested it at chromium, and it works. > > > > Yes, chromium has h264 enabled by default, (our) firefox does not. > > Toggle the mentioned about:config key on, and webex will work. > > > > Here is a h264 support test page: > > https://mozilla.github.io/webrtc-landing/pc_test_no_h264.html > > > > It's not only webex that will work better. It's just that webex has > > no fallback implemented (like jitsi, when configured...). > > > > We spend quite some time to get the openh264 plugin to run when > > Johannes figured out that it's not needed and toggling > > "media.webrtc.hw.h264.enabled" to "true" is sufficient. > > > > I think this should be mentioned in the README. > > > > (Can someone test if media.webrtc.hw.h264.enabled works on a system > > without libva / hardware h264 decoding support?) > > thanks a lot for digging into that, i lack time/interest for this > whole thing. im using jitsi on firefox without that flag, and it > works not so bad... but i have low standards. > > i dont understand much of this mumbojumbo, but i want to remind > everyone that firefox doesnt support libva for now, it requires some > patching to find the right libs, and ways too much unveil/pledge > changes that i stopped looking. Interested hackers can tinker with > the branch at > https://cgit.rhaalovely.net/mozilla-firefox/log/?h=vaapi. I might > come back to it someday. > > So it shouldnt be confused here... whether toggling that flag makes > thing work or not is i think unrelated to 'hardware support', since > there's none. Thank you for the clarification on vaapi support in firefox! That may make my testing more relevant than I initially thought: I tested on my 2015 MacBook Air (i7) running amd64/7.5-stable (ACPI bug prevents upgrade to either 7.6-release or -current) with Logitech C925e USB webcam, Yeti X USB mic, the 7.5-stable firefox-128.3.0 package, and Google Meet. So, definitely no vaapi support, but not the -current package (which I now understand doesn't actually utilize vaapi support anyway.) The Google Meet I attended was far more performant with no audio or video stutters (which usually occur, even when it's the only application running with obsdfreqd(1) disabled and `apm -H` enabled), plus less CPU load. In addition, I left obsdfreqd enabled (I've been using `-t 100 -i 5` flags), and it was throttling down and still not causing any audio or video stutters. > now the real question is, instead of adding sections over sections for > various quirks to the README (and making it an unreadable mess nobody > would read anyway), does it harm to enable it inconditionally for all > new profiles by adding it to www/mozilla-firefox/files/all-openbsd.js > ? (yeah, only new profiles, iirc values there arent changing the > defaults for existing profiles, or that was the case last i looked) I do think that enabling the option in www/mozilla-firefox/files/all-openbsd.js would be helpful, unless there's a security concern that I'm missing. I do think that still mentioning it in the pkg-readme would be beneficial, at least for some period so that those upgrading know it must be manually changed for existing profiles. Of course, that could probably be put in (or moved to?) the upgrade guide (upgrade77.html), when the time comes, for greater visibility. -- Morgan Aldridge
