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);
