Bug#974678: chromium: WebRTC lack H264 because of un-bundled OpenH264, is this intended ?

[Adam Cecile]

Package: chromium
Version: 83.0.4103.116-1~deb10u3.rtc.use.h264
Severity: important

Dear Chromium maintainer,

Current Chromium package in Debian lack H264 support for WebRTC, which
basically renders this feature unusable.
Yesterday I dig into the issue and figured out why it was behaving like this
(and not on other distribution nor with officiel Chrome package).

It seems OpenH264 has been un-bundled from the sources, and, unlike Firefox,
Chromium does not rely on FFMPEG for WebRTC decoding but needs this library.

I think it's quite an important feature that is missing here. I fully
understand that OpenH264 should not be bundled into Chromium sources but I
failed to find any discussion about this point, so I wanted to bring back this
issue on-top.

Despite being copyrighted by Cisco, OpenH264 is published on GitHub and
released under a 2-clause BSD license, which looks okay to me.
I think the issue might be legal, as H264 is tighted to MPEG group but FFMPEG
also comes with H264 encoder/decoder so that should not be an issue.

Would you consider enabling this feature ? At least if the main issue is just
the lack of OpenH264 package in Debian, we should at least create a RFP for it
and mark this bug being blocked by the RFP. This library should not be hard to
get into the archive, looks like being C++/ASM with Meson build-system.

Thanks in advance,

Regards, Adam.


PS: For the record, here is how I dirty-patched Debian's chromium package to
re-bundle OpenH264 and enable support:

--- chromium-83.0.4103.116/debian/control 2020-06-30 01:38:06.000000000
+0200
+++ chromium-83.0.4103.116/debian/control 2020-11-12 15:21:23.000000000
+0100
@@ -88,6 +88,8 @@
libgcrypt20-dev,
fonts-ipafont-gothic,
fonts-ipafont-mincho,
+ wget,
+ ca-certificates,

Package: chromium
Architecture: i386 amd64 arm64 armhf
diff -Nru chromium-83.0.4103.116/debian/patches/series
chromium-83.0.4103.116/debian/patches/series
--- chromium-83.0.4103.116/debian/patches/series 2020-07-11
18:03:32.000000000 +0200
+++ chromium-83.0.4103.116/debian/patches/series 2020-11-12
15:21:23.000000000 +0100
@@ -35,7 +35,7 @@
disable/signin.patch
disable/android.patch
disable/fuzzers.patch
-disable/openh264.patch
+#disable/openh264.patch
disable/buildbot.patch
disable/catapult.patch
disable/installer.patch
diff -Nru chromium-83.0.4103.116/debian/rules
chromium-83.0.4103.116/debian/rules
--- chromium-83.0.4103.116/debian/rules 2020-07-04 04:50:23.000000000 +0200
+++ chromium-83.0.4103.116/debian/rules 2020-11-12 15:21:23.000000000 +0100
@@ -1,5 +1,7 @@
#!/usr/bin/make -f

+include /usr/share/dpkg/pkg-info.mk
+
# enable verbose build messages
export DH_VERBOSE=1

@@ -92,6 +94,7 @@
proprietary_codecs=true \
ffmpeg_branding=\"Chrome\" \
fieldtrial_testing_like_official_build=true \
+ rtc_use_h264=true \

# handle parallel build options
njobs=1
@@ -108,6 +111,17 @@
override_dh_auto_configure:
# output compiler information
$(CXX) --version
+
+ # Re-introduce Cisco OpenH264 source code
+ # Also make sure to add it to keepers in ./debian/scripts/unbundle
+ # And don't forget include /usr/share/dpkg/pkg-info.mk on top
+ wget -qO- 'https://commondatastorage.googleapis.com/chromium-browser-
official/chromium-$(DEB_VERSION_UPSTREAM).tar.xz' \
+ | tar xvJ --directory '$(CURDIR)/third_party/' \
+ --strip-components=2 \
+ --wildcards \
+ '*/third_party/openh264/' \
+ '*/third_party/yasm/'
+
# prefer unbundled (system) libraries
./debian/scripts/unbundle

@@ -142,6 +156,8 @@
rm -rf out
find . -name \*.pyc -execdir rm -f {} \;
dh_auto_clean
+ rm -rf third_party/openh264/*
+ rm -rf third_party/yasm/*

###################### upstream source downloading
############################

diff -Nru chromium-83.0.4103.116/debian/scripts/unbundle
chromium-83.0.4103.116/debian/scripts/unbundle
--- chromium-83.0.4103.116/debian/scripts/unbundle 2020-06-27
03:10:37.000000000 +0200
+++ chromium-83.0.4103.116/debian/scripts/unbundle 2020-11-12
15:21:23.000000000 +0100
@@ -8,7 +8,7 @@

import replace_gn_files

-keepers = ()
+keepers = ("openh264", "yasm")

for lib,rule in replace_gn_files.REPLACEMENTS.items():
if lib not in keepers:



-- System Information:
Debian Release: 10.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-12-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages chromium depends on:
ii chromium-common 83.0.4103.116-1~deb10u3.rtc.use.h264
ii libasound2 1.1.8-1
ii libatk-bridge2.0-0 2.30.0-5
ii libatk1.0-0 2.30.0-2
ii libatspi2.0-0 2.30.0-7
ii libavcodec58 7:4.1.6-1~deb10u1
ii libavformat58 7:4.1.6-1~deb10u1
ii libavutil56 7:4.1.6-1~deb10u1
ii libc6 2.28-10
ii libcairo2 1.16.0-4
ii libcups2 2.2.10-6+deb10u3
ii libdbus-1-3 1.12.20-0+deb10u1
ii libdrm2 2.4.97-1
ii libevent-2.1-6 2.1.8-stable-4
ii libexpat1 2.2.6-2+deb10u1
ii libflac8 1.3.2-3
ii libfontconfig1 2.13.1-2
ii libfreetype6 2.9.1-3+deb10u2
ii libgbm1 18.3.6-2+deb10u1
ii libgcc1 1:8.3.0-6
ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii libglib2.0-0 2.58.3-2+deb10u2
ii libgtk-3-0 3.24.5-1
ii libharfbuzz0b 2.3.1-1
ii libicu63 63.1-6+deb10u1
ii libjpeg62-turbo 1:1.5.2-2+b1
ii libjsoncpp1 1.7.4-3
ii liblcms2-2 2.9-3
ii libminizip1 1.1-8+b1
ii libnspr4 2:4.20-1
ii libnss3 2:3.42.1-1+deb10u3
ii libopenjp2-7 2.3.0-2+deb10u1
ii libopus0 1.3-1
ii libpango-1.0-0 1.42.4-8~deb10u1
ii libpangocairo-1.0-0 1.42.4-8~deb10u1
ii libpng16-16 1.6.36-6
ii libpulse0 12.2-4+deb10u1
ii libre2-5 20190101+dfsg-2
ii libsnappy1v5 1.1.7-1
ii libstdc++6 8.3.0-6
ii libvpx5 1.7.0-3+deb10u1
ii libwebp6 0.6.1-2
ii libwebpdemux2 0.6.1-2
ii libwebpmux3 0.6.1-2
ii libx11-6 2:1.6.7-1+deb10u1
ii libx11-xcb1 2:1.6.7-1+deb10u1
ii libxcb-dri3-0 1.13.1-2
ii libxcb1 1.13.1-2
ii libxcomposite1 1:0.4.4-2
ii libxcursor1 1:1.1.15-2
ii libxdamage1 1:1.1.4-3+b3
ii libxext6 2:1.3.3-1+b2
ii libxfixes3 1:5.0.3-1
ii libxi6 2:1.7.9-1
ii libxml2 2.9.4+dfsg1-7+b3
ii libxrandr2 2:1.5.1-1
ii libxrender1 1:0.9.10-1
ii libxslt1.1 1.1.32-2.2~deb10u1
ii libxss1 1:1.2.3-1
ii libxtst6 2:1.2.3-1
ii zlib1g 1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii chromium-sandbox 83.0.4103.116-1~deb10u3.rtc.use.h264

Versions of packages chromium suggests:
ii chromium-driver 83.0.4103.116-1~deb10u3.rtc.use.h264
ii chromium-l10n 83.0.4103.116-1~deb10u3.rtc.use.h264
pn chromium-shell <none>

Versions of packages chromium-common depends on:
ii x11-utils 7.7+4
ii xdg-utils 1.1.3-1+deb10u1

Versions of packages chromium-common recommends:
ii chromium-sandbox 83.0.4103.116-1~deb10u3.rtc.use.h264
ii fonts-liberation 1:1.07.4-9
ii gnome-shell [notification-daemon] 3.30.2-11~deb10u2
ii libgl1-mesa-dri 18.3.6-2+deb10u1
pn libu2f-udev <none>
ii notification-daemon 3.20.0-4
ii upower 0.99.10-1

Versions of packages chromium-driver depends on:
ii libc6 2.28-10
ii libevent-2.1-6 2.1.8-stable-4
ii libglib2.0-0 2.58.3-2+deb10u2
ii libicu63 63.1-6+deb10u1
ii libminizip1 1.1-8+b1
ii libnspr4 2:4.20-1
ii libnss3 2:3.42.1-1+deb10u3
ii libre2-5 20190101+dfsg-2
ii libstdc++6 8.3.0-6
ii libx11-6 2:1.6.7-1+deb10u1
ii zlib1g 1:1.2.11.dfsg-1

Versions of packages chromium-sandbox depends on:
ii libc6 2.28-10

-- no debconf information

[Hauke Mehrtens]

Hi,

Currently chromium uses ffmpeg to decode h264 and uses openh264 to
encode such streams. It is described here:
https://www.chromestatus.com/feature/6417796455989248

There are a lot of patents on the h264 codec. Cisco created the open
source OpenH264 and ships this also as binaries. Cisco paid all
royalties for the library in binary form, this allows everyone to use
the *binary* of the OpenH264 library in compliance with the MPEG LA
license terms without paying anything extra to them. If you build it
yourself from the source code you still have to pay the royalties, at
least when you distribute your binary.
https://en.wikipedia.org/wiki/OpenH264

Compiling openh264 into chromium would probably be problematic from a
legal point of view for Debian.


To get chromium with openh264 support you can install the libopenh264
from deb-multimedia.org and then remove the disable/openh264.patch patch.
https://debian.pkgs.org/10/multimedia-main-amd64/libopenh264-5_2.0.0-dmo1_amd64.deb.html
https://debian.pkgs.org/10/multimedia-main-amd64/libopenh264-dev_2.0.0-dmo1_amd64.deb.html

libopenh264 is probably not inside the main Debian repository because of
these patent problems.


I would propose the following:

Create a libopenh264 in Debian main or non-free repositories which
downloads the binary which was build by Cisco when the package is
installed. I think Debian would then not ship the patented binary.
Create a libopenh264-dev with the matching header files.
We would do it in a similar way like this:
https://packages.debian.org/de/sid/firmware-b43-installer

Modify chromium to use dlopen to try to load the libopenh264.so.6
library dynamically and not statically link against it, if it is found
on the system it will support h264 in WebRTC, if it is not found this
feature will not work.
It looks like there are only two symbols used from this library:
WelsCreateSVCEncoder
WelsDestroySVCEncoder

Chromium would not depend on libopenh264, but if it finds this binary on
the system it would make use of it. User would not be forced to install
libopenh264 and it should not be a dependency.

I haven't started this, I only looked at the code and it looks like it
is possible. I would like to know if this solution would be acceptable
by Debian. My motivation is that I want to use GeForce Now and make it
easier to use Google Stadia with Chromium on Debian.

GeForce Now currently fails with "ERROR CODE: 0xC0F2220E" on Debian with
chromium because of the missing h264 support in WebRTC, with openh264 it
works.

I am not a lawyer and also not a Debian developer, but I would implement
this if this proposal looks ok.

Hauke

[Adam Cécile]

Hello,


OpenH264 is also used to receive H264 WebRTC streams. I can confirm this
100% sure.


Adam.

[Bastian Germann]

On Sat, 5 Dec 2020 15:46:14 +0100 Hauke Mehrtens <ha...@hauke-m.de> wrote:
> Create a libopenh264 in Debian main or non-free repositories which
> downloads the binary which was build by Cisco when the package is
> installed. I think Debian would then not ship the patented binary.
> Create a libopenh264-dev with the matching header files.
> We would do it in a similar way like this:
> https://packages.debian.org/de/sid/firmware-b43-installer

This is fine. The package must not reside in main. If you plan to
release the package (the downloader) under a DFSG-compatible license,
please submit it to contrib rather than non-free.

> I haven't started this, I only looked at the code and it looks like it
> is possible. I would like to know if this solution would be acceptable
> by Debian. My motivation is that I want to use GeForce Now and make it

> easier to use Google Stadia with Chromium on Debian...

> I am not a lawyer and also not a Debian developer, but I would implement
> this if this proposal looks ok.

Please go ahead. I would like to have openh264 in contrib.

[Bastian Germann]

Control: retitle -1 ITP: openh264 -- H.264 encoding and decoding

On Sat, 8 May 2021 18:28:35 +0200 Bastian Germann <bastian...@fishpost.de> wrote:
> This is fine. The package must not reside in main. If you plan to
> release the package (the downloader) under a DFSG-compatible license,
> please submit it to contrib rather than non-free.

I am currently packaging openh264.

[Tobias Frost]

(I was checking the RFS, thats why I came accross this ITP)

I'm confused; is there now a legal patent problem with the library that could
affect/hurt Debian? 
Has this been discussed on e.g debian-legal or with the ftp masters beforehand?
Is this RFS package now a downloader or the library itself?

--
tobi

[Bastian Germann]

Am 02.06.21 um 17:33 schrieb Tobias Frost:

> On Fri, 14 May 2021 00:04:52 +0200 Bastian Germann wrote:
>>> This is fine. The package must not reside in main. If you plan to
>>> release the package (the downloader) under a DFSG-compatible license,
>>> please submit it to contrib rather than non-free.
>>
>> I am currently packaging openh264.
>>
> (I was checking the RFS, thats why I came accross this ITP)
>
> I'm confused; is there now a legal patent problem with the library that could
> affect/hurt Debian?

There are H.264 patents that are applicable. I do not know how the existing H.264 implementations in
Debian handle this, e.g. x264 or ffmpeg. According to the legal FAQ, these seem to be ignored.

For the OpenH264 binaries, Cisco actually pays a license fee so that it can be used by the general
public at no cost. The exact license terms are included in the package:
https://salsa.debian.org/bage/openh264/-/blob/debian/2.1.1-1/debian/libopenh264-6.copyright

The key point for having the library package in contrib and download the library is: "The
Cisco-provided binary is separately downloaded to an end user's device, and not integrated into or
combined with third party software prior to being downloaded to the end user's device;"

> Has this been discussed on e.g debian-legal or with the ftp masters beforehand?

Not for OpenH264 specifically, but I am including debian-legal now. For the H.264 patents, there is
an old thread at https://lists.debian.org/debian-legal/2006/04/msg00286.html

> Is this RFS package now a downloader or the library itself?

It's both. The -dev package is created from the source files and resides in main. The library
package contains the downloader as a postinst script, which checks the known SHA256 hashes.
There are some example userspace tools available in the package which could potentially be packaged
in an additional package. I left this for a later version.

There is also a chance that reproducible build might be implemented:
https://github.com/cisco/openh264/issues/893
When that works, the package could build the lib, verify the resulting hashes, and throw away the
built binary. That way we could be sure not to have any additions to the downloaded library that are
not available as source.

I think, as Cisco provides the patent license, having the downloader in contrib (for some
architectures) is better than having the built library in main (for all compiling architectures). We
could also provide both. Any thoughts?

[Paul Wise]

On Wed, Jun 2, 2021 at 3:36 PM Tobias Frost wrote:

> Has this been discussed on e.g debian-legal or with the ftp masters beforehand?

FTR, Debian's patent policy is to only discuss them with lawyers,
never in public:

https://www.debian.org/legal/patent
https://www.debian.org/reports/patent-faq

--
bye,
pabs

https://wiki.debian.org/PaulWise

[Sam Hartman]

>>>>> "Bastian" == Bastian Germann <bastian...@fishpost.de> writes:

Bastian> There are H.264 patents that are applicable. I do not know
Bastian> how the existing H.264 implementations in Debian handle
Bastian> this, e.g. x264 or ffmpeg. According to the legal FAQ,
Bastian> these seem to be ignored.

I suspect you meant to say that there are H.264 patents that may be
applicable and that Debian should evaluate this risk using its normal
proocesses and policies for looking at software patents.

THOSE PROCESSES DO NOT INVOLVE debian-legal. Discussing patents in a
public forum may result in speculative communication--like the assertion
above where you said that patents are applicable and where you probably
meant to say that the patents may be applicable--being produced in
response to allegations of patent infringement.
That harms Debian.
Thus, we have a policy that we discuss patents only in privileged
communication.
See https://www.debian.org/legal/patent


and if you are concerned about a specific patent risk, write to
pat...@debian.org.

[Adam Cecile]

Hello everyone,

Is it possible to have an update regarding this issue ?
I do not really understand what the problem with patent is, but I'd like know if this is still under consideration !

Regards, Adam.

[Adam Cecile]

For the record, ungoogled chromium people decided to re-enable h264:

https://github.com/ungoogled-software/ungoogled-chromium-debian/commit/2c75d7f41c5189f8578c1a4b3759d80aa8d05061