Feature: Enable openh264 plugin

x264 is GPL. IMHO Having openh264 for H.264 encoding can be useful.

The integration is trivial using the Arch openh264 package.

I can do it if you agree.

added priority3-normal severity4-low statusunconfirmed labels

assigned to @freswa, @toolybird, and @gromit

changed title from Enable openh264 plugin to Feature: Enable openh264 plugin

x264 is GPL

and?

H.264 encoding can be useful

How? Please provide example

It seems up until now this was intentionally disabled:

-D gst-plugins-bad:openh264=disabled

I find it a fair feature request to enable a new codec, let's see what the package maintainer has to say about it. Maybe there is a deeper reasoning why it is disabled

some reasoning may related to fact it's several times slower than x264. That's why I asked what's the usecase.

added scopefeature statusconfirmed labels and removed statusunconfirmed label

assigned to @heftig and unassigned @freswa, @toolybird, and @gromit

closed with commit e12f7ea4

Without going into the subject of H.264 patents.

If you are developing a non-GPL compatible tool that requires H.264 software encoding, x264 is not an option. For instance if you need it in a MIT application.

Creating a new Arch package for the openh264 GStreamer plugin is simple. I can help with it.

@rubenrua

Without going into the subject of H.264 patents.

Let's go into the subject. H.264 patents and x264 code license are orthogonal to each other. Obviously Arch doesn't care about patents otherwise it wouldn't be able to ship x264 and many other packages. Moreover openh264 cisco patent license require that binaries are downloaded straight from cisco which makes openh264 arch package patent situation identical to x264:

In order for Cisco to be responsible for the MPEG LA licensing royalties for the module, Cisco must provide the packaging and distribution of this code in a binary module format

https://www.openh264.org/BINARY_LICENSE.txt

I hope this makes clear you aren't exempted from H.264 patent royalties by using openh264 in Arch. (if you are curious how fedora/rhel workarounds that see https://fedoraproject.org/wiki/Non-distributable-rpms )

Does it really make sense for making another encoding app and license it incompatible with ffmpeg thus several times slower than others? Who is the target for such app?

Creating a new Arch package for the openh264 GStreamer plugin is simple. I can help with it.

I see openh264 was made hard dependency of gst-plugins-bad.

I see openh264 was made hard dependency of gst-plugins-bad.

its the same for opencv and arch creates a new package.

The only change needed should be:

diff --git a/PKGBUILD b/PKGBUILD
index c3548b4..87cf86b 100644
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -15,6 +15,7 @@ pkgname=(
   gst-plugin-msdk
   gst-plugin-onnx
   gst-plugin-opencv
+  gst-plugin-openh264
   gst-plugin-qml6
   gst-plugin-qmlgl
   gst-plugin-qsv
@@ -959,6 +960,25 @@ package_gst-plugin-opencv() {
   ); _install
 }
 
+package_gst-plugin-openh264() {
+  pkgdesc+=" - openh264 plugin"
+  depends=(
+    "gst-plugins-base-libs=$pkgver-$pkgrel"
+    "gstreamer=$pkgver-$pkgrel"
+    gcc-libs
+    glib2
+    glibc
+    openh264
+  )
+
+  cd root; local files=(
+    usr/lib/gstreamer-1.0/libgstopenh264.so
+  ); _install
+}
+
 package_gst-plugin-qml6() {
   pkgdesc+=" - qml6 plugin"
   depends=(

IMHO having the package can be useful. End users can decide if install or not.

added resolutioncompleted label