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 :) Best Regards, Stefan
