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. 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 played a bit with firefox on my mac and there, h264 works > EITHER with the cisco openh264 plugin activated, OR with > media.webrtc.hw.h264.enabled toggled on. > > Getting the cisco plugin to run looks possible, but would > need some patching, because it expects the plugin library to > be available on an external URL and has some expectations > about the filename and the directory layout. > See firefox $WRKSRC/toolkit/content/gmp-sources/openh264.json i thought the whole 'cisco openh264' thing was only for drm with binary blobs provided by cisco, but i might confuse it with the widevine thing (which is for encrypted media extensions). Landry
