Le Fri, Jan 10, 2025 at 03:17:48PM +0000, Johannes Thyssen Tishman a écrit : > 2025-01-09T19:13:49+0100 Stefan Hagen <sh+openbsd-po...@codevoid.de>: > > Landry Breuil wrote (2025-01-09 14:16 CET): > > > 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: > > > > [...snip...] > > > > > > 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. > > > > As long as there is a fallback, otherwise it won't play. > > > > > 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. > > > > That's actually a good thing. Because it means this toggle works without > > HW support. > > > > > 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 think there's no harm in enabling it per default. I can't find any > > evidence on the Internet in form of reports where it broke anything. > > > > > > 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). > > > > Yes, you do. widevine is the DRM thing. All parts needed for the cisco > > openh264 plugin are available, and actually in the ports tree. > > > > multimedia/openh264: > > Must be enabled to build the GMP API. > > > > multimedia/gstreamer1/plugins-bad: > > Must be enabled to build the openh264 plugin. > > This builds libgmpopenh264.so, which is, what the plugin wants to > > download in binary form. > > > > To convince the plugin to not download, but use the system gstreamer1 > > plugin, the libgmpopenh264.so must be placed at a special path (I > > think it was MOZ_PLUGIN_PATH/<version>/libgmpopenh264.so), and some > > about:config keys (media.gmp-gmpopenh264*) need to be set correctly. > > (including a fake lastUpdated time) > > > > To do this right, firefox probably needs to be patched, so the plugin > > looks at the right path and accepts .so.X.Y. > > > > That's how far we got, but still haven't seen it working. > > But the "will be installed shortly" banner went away! > > > > If someone wants to keep playing with that plugin, please do. > > > > I'm in favor of setting media.webrtc.hw.h264.enabled = true as default > > or documenting it and calling it a day :) > > I'm not a dev, but FWIW I'm also in favor of enabling this setting by > default. If it works even when firefox has no hardware support for it, I > doubt it'll cause any problems. We can revisit the topic if/when > hardware support is added. > > diff /usr/ports > path + /usr/ports > commit - c69c8333fd531f9987d5e116c0af876764be3704 > blob - b6677accc64302066bd1420edec9f1fa86b5a523 > file + www/mozilla-firefox/files/all-openbsd.js > --- www/mozilla-firefox/files/all-openbsd.js > +++ www/mozilla-firefox/files/all-openbsd.js > @@ -9,3 +9,4 @@ pref("extensions.pocket.enabled", false); > pref("browser.newtabpage.enabled", false); > pref("browser.startup.homepage", "about:blank"); > pref("network.trr.mode", 5); > +pref("media.webrtc.hw.h264.enabled", true);
So i finally found some time to test this. on an 'empty' profile, without changing anything (so the knob is false), going to https://mozilla.github.io/webrtc-landing/pc_test_no_h264.html says h.264 is NOT supported. going to the webex test meeting, i can see myself in the cam shown before entering the meeting, but indeed after really entering the test meeting i see that there's no support/missing codecs. manually added the above line to /usr/local/lib/firefox/browser/defaults/preferences/all-openbsd.js, restarted firefox on the same empty profile, going to about:config and filtering keys on 'h264' shows that the new default value for media.webrtc.hw.h264.enabled is now true (which i thought didnt work), going to https://mozilla.github.io/webrtc-landing/pc_test_no_h264.html tells me that h.264 is supported, and i can now see my cam within the webex test meeting. on a sidenote: that webex thing is painfully slow. guess i'm lucky for not having to use it :) i never had issues before with jitsi/zoom/teams, but as i already said i have low standards for this usecase. anyway, thanks for the time spent on debugging this. i'll commit that diff shortly. Landry
