Bug 1216393

We cannot build chromium against openH264 as legal does not allow to ship that library in Factory.

What we can do is to patch it to detect whether the library is available and dlopen it. There is a patch from Fedora that purpots to do this:
https://src.fedoraproject.org/rpms/qt6-qtwebengine/blob/rawhide/f/qtwebengine-webrtc-dlopen-h264.patch

I'm not sure what's the use case for H264 RTC support in Electron. Does Element need it? No other apps use that functionality (Signal has its own RTC implementation).

(In reply to dziobian from comment #1)
> We cannot build chromium against openH264 as legal does not allow to ship
> that library in Factory.

It is now permitted through Cisco distribution of openSUSE rpms

> 
> What we can do is to patch it to detect whether the library is available and
> dlopen it. There is a patch from Fedora that purpots to do this:
> https://src.fedoraproject.org/rpms/qt6-qtwebengine/blob/rawhide/f/
> qtwebengine-webrtc-dlopen-h264.patch

I believe there's an openh264-dlopen-headers.tar.xz somewhere but I haven't tested Chromium integration

> 
> I'm not sure what's the use case for H264 RTC support in Electron. Does
> Element need it? No other apps use that functionality (Signal has its own
> RTC implementation).

I'll have a greater look when I'm available next week

Callum F

I know of the Cisco repo. You can't build Factory packages against it or depend on it from Factory so the point stands.

(In reply to dziobian from comment #3)
> I know of the Cisco repo. You can't build Factory packages against it or
> depend on it from Factory so the point stands.

It'll work if it can be changed to dlopen() instead of linking and by using the dlopen-headers tarball I mentioned (I think from openSUSE ffmpeg).  It may be possible or it may not be.

(In reply to dziobian from comment #1)
> We cannot build chromium against openH264 as legal does not allow to ship
> that library in Factory.

Is that also true when only the headers are used and openh264 is used later as dlopen?

From what I saw that's what I assumed, it does sound strange that ffmpeg h264 isn't enough.

> What we can do is to patch it to detect whether the library is available and
> dlopen it. There is a patch from Fedora that purpots to do this:
> https://src.fedoraproject.org/rpms/qt6-qtwebengine/blob/rawhide/f/qtwebengine-webrtc-dlopen-h264.patch
> 
> I'm not sure what's the use case for H264 RTC support in Electron. Does
> Element need it? No other apps use that functionality (Signal has its own
> RTC implementation).

There's a Teams app for Electron that requires H264 since that's the only codec supported in Teams.
I think there are others that use the builtin webrtc support.

I assume the Signal RTC support is also based on the same Chromium library.
Taking a quick look at their repo it does look like it:
https://github.com/signalapp/webrtc/tree/main

The last time i was forced to use it, Teams used lots of binary modules (at least on Windows). They will likely not work with another version of Electron, and we cannot rebuild them since we don't have the source.

As for Signal, I know that since i'm a maintainer. They use their own heavily-patched webrtc copy and put it in a rust wrapper which is then loaded as a node module: https://build.opensuse.org/package/show/network:im:signal/nodejs-signal-ringrtc

Signal does not seem to use the web APIs for RTC. It is not possible to use Electron's copy of webrtc in any other way, since it does not expose the C/C++ bindings.

> From what I saw that's what I assumed, it does sound strange that ffmpeg
> h264 isn't enough.

In fact, ffmpeg's h264 is enough for *decoding* video which works out of the box in Chromium, Electron and QtWebEngine.

The webcodecs API and WebRTC don't use ffmpeg.

> The last time i was forced to use it, Teams used lots of binary modules (at least on Windows). They will likely not work with another version of Electron, and we cannot rebuild them since we don't have the source.

There's a foss versiono of the Electron client. The old Teams client is deprecated, new client is based on Edges version of Electron.
https://github.com/IsmaelMartinez/teams-for-linux

> As for Signal, I know that since i'm a maintainer. They use their own heavily-patched webrtc copy and put it in a rust wrapper which is then loaded as a node module: https://build.opensuse.org/package/show/network:im:signal/nodejs-signal-ringrtc

Even thou it's a fork the logic of loading openh264 runtime should still apply I think.

(In reply to Björn Bidar from comment #8)
> There's a foss versiono of the Electron client. The old Teams client is
> deprecated, new client is based on Edges version of Electron.
> https://github.com/IsmaelMartinez/teams-for-linux
The client you're promoting seems to have a “feature” allowing whatever website it loads to execute arbitrary code on your computer:
https://github.com/IsmaelMartinez/teams-for-linux/blob/84aaf108e9ee7142d3d0fd8276530f8e87d49683/app/mainAppWindow/index.js#L460
As for what you mean by “Edges version of Electron”, i have no idea.


(In reply to Björn Bidar from comment #9)
> Even thou it's a fork the logic of loading openh264 runtime should still
> apply I think.

Signal does not use h264, only vpx (which is not encumbered by unjust laws) for RTC.

(In reply to dziobian from comment #10)
> (In reply to Björn Bidar from comment #8)
> > There's a foss versiono of the Electron client. The old Teams client is
> > deprecated, new client is based on Edges version of Electron.
> > https://github.com/IsmaelMartinez/teams-for-linux
> The client you're promoting seems to have a “feature” allowing whatever
> website it loads to execute arbitrary code on your computer:
> https://github.com/IsmaelMartinez/teams-for-linux/blob/
> 84aaf108e9ee7142d3d0fd8276530f8e87d49683/app/mainAppWindow/index.js#L460

Calling it a feature with the intention to allow arbitrary code to be executed  in this way sounds like slanderous term. I don't know the indent, anyway I will report/ask.

> As for what you mean by “Edges version of Electron”, i have no idea.
https://techcommunity.microsoft.com/t5/microsoft-teams/teams-2-0-moves-away-from-electron-to-embrace-edge-webview2/td-p/2484565
> 
> (In reply to Björn Bidar from comment #9)
> > Even thou it's a fork the logic of loading openh264 runtime should still
> > apply I think.
> 
> Signal does not use h264, only vpx (which is not encumbered by unjust laws)
> for RTC.
OK good to know.