https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Bug ID: 1908922 Summary: Review Request: libopenaptx - Open Source implementation of Audio Processing Technology codec (aptX) Product: Fedora Version: rawhide Hardware: All OS: Linux Status: NEW Component: Package Review Severity: medium Priority: medium Assignee: nobody@fedoraproject.org Reporter: gombosg@disroot.org QA Contact: extras-qa@fedoraproject.org CC: package-review@lists.fedoraproject.org Target Milestone: --- Classification: Fedora
Spec URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx.spec SRPM URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx-0.2.0-1.fc33.src.rp... Description: This is Open Source implementation of Audio Processing Technology codec (aptX) derived from ffmpeg 4.0 project and licensed under LGPLv2.1+. This codec is mainly used in Bluetooth A2DP profile. Fedora Account System Username: gombosg
Scratch build: http://koji.fedoraproject.org/koji/taskinfo?taskID=57676629
---
This is going to be very useful for pipewire, along with libldac.
Upstream implementation is going on in here: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/227 Then, pipewire can be built with this in Fedora: https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/spa/meson.bui...
Note that aptX was patent protected, but (IANAL) it has expired. The library README says "derived from ffmpeg 4.0 project". But this only contains aptX related code and doesn't depend on ffmpeg.
Maybe it will need legal review?
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Aleksei Bavshin alebastr89@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alebastr89@gmail.com Doc Type|--- |If docs needed, set a value
--- Comment #1 from Aleksei Bavshin alebastr89@gmail.com --- IANAL as well, but I'm not sure about the legal status of aptX HD. Blocking FE-Legal (bug182235) would be a good idea.
As for the spec file -- have you considered making commandline tools a separate package? Although the only benefit I'm aware of that multilib packages could be installed in parallel (e.g. i686 + x86_64). Looks good otherwise.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Gergely Gombos gombosg@disroot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |182235 (FE-Legal)
--- Comment #2 from Gergely Gombos gombosg@disroot.org --- Good idea, I'll block the legal review bug. Aleksei, good point, I'll package the 2 binaries in a separate subpackage called "openaptx". This is according to the guidelines, too.
Referenced Bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=182235 [Bug 182235] Fedora Legal Tracker
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #3 from Gergely Gombos gombosg@disroot.org --- I separated the CLI utilities into a subpackage.
Spec URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx.spec SRPM URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx-0.2.0-2.fc33.src.rp...
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Ben Cotton bcotton@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bcotton@redhat.com
--- Comment #4 from Ben Cotton bcotton@redhat.com --- Ack on the legal review. I'll get the patent status verified and then update this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Neal Gompa ngompa13@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ngompa13@gmail.com
--- Comment #5 from Neal Gompa ngompa13@gmail.com ---
%package utils Summary: %{name} encoder and decoder utilities Requires: %{name}%{?_isa} = %{version}-%{release}
This is a weird pattern. Usually the main package includes the utilities and a -libs subpackage includes the libraries. This can be observed even in the RPM package: https://src.fedoraproject.org/rpms/rpm/blob/master/f/rpm.spec
Can you please restructure this accordingly?
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #6 from Aleksei Bavshin alebastr89@gmail.com --- (In reply to Neal Gompa from comment #5)
This is a weird pattern. Usually the main package includes the utilities and a -libs subpackage includes the libraries. This can be observed even in the RPM package: https://src.fedoraproject.org/rpms/rpm/blob/master/f/rpm.spec
Seems common for codecs and other library packages: opus (library), opus-tools (encoder/decoder) libavif (library), libavif-tools (encoder/decoder) libpng, libpng-tools libwebp, libwebp-tools ...
The main content here is a library and binaries are just an additional content that is unlikely to be installed by a regular user.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #7 from Neal Gompa ngompa13@gmail.com --- Hmm, that's true since this package is actually named by the library name. Though `-utils` is weird compared to `-tools`.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #8 from Gergely Gombos gombosg@disroot.org --- Thanks for the suggestion. Renamed from -utils to -tools.
Spec URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx.spec SRPM URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx-0.2.0-3.fc33.src.rp...
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |POST CC| |zbyszek@in.waw.pl Assignee|nobody@fedoraproject.org |zbyszek@in.waw.pl Flags| |fedora-review+
--- Comment #9 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- According to wikipedia, this is the patent https://patents.google.com/patent/EP0398973B1/en, long expired.
But please wait for ack from Legal before building this in Fedora.
fedora-review says: - Package does not contain duplicates in %files. Note: warning: File listed twice: /usr/lib64/libopenaptx.so Please fix.
+ package name is OK + license is acceptable for Fedora (LGPLv2.1+) + license is specified correctly (LGPGv2+) + builds and installs OK + Provides/Requires/BuildRequires look OK + distro build flags are used + looks OK in general
Rpmlint ------- Checking: libopenaptx-0.2.0-3.fc34.x86_64.rpm libopenaptx-devel-0.2.0-3.fc34.x86_64.rpm libopenaptx-tools-0.2.0-3.fc34.x86_64.rpm libopenaptx-debuginfo-0.2.0-3.fc34.x86_64.rpm libopenaptx-debugsource-0.2.0-3.fc34.x86_64.rpm libopenaptx-0.2.0-3.fc34.src.rpm libopenaptx.x86_64: W: spelling-error Summary(en_US) aptX -> apt X, apt, apex libopenaptx.x86_64: W: spelling-error %description -l en_US aptX -> apt X, apt, apex libopenaptx.x86_64: W: spelling-error %description -l en_US ffmpeg -> MPEG libopenaptx.x86_64: W: no-documentation libopenaptx-devel.x86_64: W: no-documentation libopenaptx-tools.x86_64: W: no-documentation libopenaptx-tools.x86_64: W: no-manual-page-for-binary openaptxdec libopenaptx-tools.x86_64: W: no-manual-page-for-binary openaptxenc libopenaptx.src: W: spelling-error Summary(en_US) aptX -> apt X, apt, apex libopenaptx.src: W: spelling-error %description -l en_US aptX -> apt X, apt, apex libopenaptx.src: W: spelling-error %description -l en_US ffmpeg -> MPEG → False positives.
libopenaptx-devel.x86_64: E: rpath-in-buildconfig /usr/lib64/pkgconfig/libopenaptx.pc lines ['9'] Yeah, the .pc files is borked:
prefix=/usr/lib64 exec_prefix=${prefix} libdir=${exec_prefix}//usr/include
→ this evaluates to libdir=/usr/lib64//usr/include
Libs: -Wl,-rpath=${libdir} -L${libdir} -lopenaptx
→ this sets rpath, and it shouldn't.
Cflags: -I${includedir}
→ this gets the include path wrong ;(
I think it'd be easiest to do something like sed -r -i 's/^Libs:.*/Libs: -lopenaptx/; /Cflags:/d' /path/to/.pc
libopenaptx-tools.x86_64: W: summary-not-capitalized C libopenaptx encoder and decoder utilities libopenaptx-tools.x86_64: E: description-line-too-long C The libopenaptx-tools package contains openaptxenc encoder and openaptxdec decoder → Maybe "AptX encoding and decoding tools"
6 packages and 0 specfiles checked; 2 errors, 12 warnings.
Package is APPROVED, conditional on Legal review. Please fix issues listed above before upload.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #10 from Aleksei Bavshin alebastr89@gmail.com --- (In reply to Zbigniew Jędrzejewski-Szmek from comment #9)
Yeah, the .pc files is borked:
prefix=/usr/lib64 exec_prefix=${prefix} libdir=${exec_prefix}//usr/include
→ this evaluates to libdir=/usr/lib64//usr/include
Libs: -Wl,-rpath=${libdir} -L${libdir} -lopenaptx
→ this sets rpath, and it shouldn't.
Cflags: -I${includedir}
→ this gets the include path wrong ;(
I think it'd be easiest to do something like sed -r -i 's/^Libs:.*/Libs: -lopenaptx/; /Cflags:/d' /path/to/.pc
`%make_install PREFIX="%{_prefix}" LIBDIR="%{_lib}"` would generate correct paths in pkgconfig file. Makefile for this project expects all *DIR variables to be relative to the PREFIX.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #11 from Gergely Gombos gombosg@disroot.org --- (In reply to Ben Cotton from comment #4)
Ack on the legal review. I'll get the patent status verified and then update this bug.
Hi @Ben, any advancements on the legal review? Looks like this still is still blocking the FE-Legal ticket.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #12 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- It's been forwarded to the appropriate people. We're waiting for the resolution.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #13 from Ben Cotton bcotton@redhat.com --- (In reply to Gergely Gombos from comment #11)
Hi @Ben, any advancements on the legal review? Looks like this still is still blocking the FE-Legal ticket.
Not yet. I'll flag this with Red Hat Legal again.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Ben Cotton bcotton@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|POST |CLOSED Resolution|--- |CANTFIX Last Closed| |2021-02-15 20:08:47
--- Comment #14 from Ben Cotton bcotton@redhat.com --- Because the patent status is unclear, and we don't have a comprehensive list of the all patents involved in this technology, the aptX codec cannot be included in Fedora at this time. I am closing this ticket and wish I had a better answer.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Gergely Gombos gombosg@disroot.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wtaymans@redhat.com Flags| |needinfo?(bcotton@redhat.co | |m) | |needinfo?(wtaymans@redhat.c | |om)
--- Comment #15 from Gergely Gombos gombosg@disroot.org --- Thanks @bcotton@redhat.com, this will go to rpmfusion then. I asked in IRC and @wtaymans@redhat.com confirmed that Pipewire could later use dlopen for codecs, so it could find the library even if it hadn't been built together with it.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(bcotton@redhat.co | |m) | |needinfo?(wtaymans@redhat.c | |om) |
--- Comment #16 from Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl --- I assume the needinfo was by mistake.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
Linus Lewandowski linus@lew21.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |linus@lew21.net
--- Comment #17 from Linus Lewandowski linus@lew21.net --- aptX was created by Audio Processing Technology Ltd (a subsidiary of Solid State Logic Ltd) in 1990s - see https://www.aptx.com/history and https://patents.google.com/patent/EP0398973B1/en (the expired patent mentioned earlier)
APT Ltd was sold - (one can safely assume: together with all the patents required for aptX) - in 2005: https://www.mixonline.com/technology/solid-state-logic-sells-apt-381257
There is only one patent assigned to APT Ltd: https://patents.google.com/?assignee=Audio+Processing+Technology+Limited - it's the expired one (EP0398973B1).
The original owner - Solid State Logic Ltd - had some more patents: https://patents.google.com/?assignee=Solid+State+Logic - but they're all expired, except for one from 2020.
So... I'm pretty sure that there is no other patent that affects aptX itself.
There might still be something affecting aptX LL (launched in 2012) and aptX HD (launched in 2016) - but they aren't really innovative.
aptX LL is the trivial merge of the idea behind CSR FastStream (launched in 2008, https://web.archive.org/web/20080509054609/www.csr.com/pr/pr328.htm) and the aptX codec. FastStream looks like patent-free, because it's referred to in https://patents.google.com/patent/US9398620B1/en (expired), and this patent does not depend on any other related patent - while it describes how to use FastStream in a selected use case.
aptX HD seems to just be a different set of settings for the aptX algorithm, but I'm not really sure here, I haven't looked at the code.
On the other hand, aptX Adaptive (launched in 2018) might be innovative - it introduces variable bit rate - so I wouldn't recommend adding it at this point.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #18 from Gergely Gombos gombosg@disroot.org --- At the moment, adding libopenaptx to rpmfusion doesn't look like a viable alternative, because pipewire has to be built along with libopenaptx (like it's built with libldac) to enable support. Suggestions are welcome, though.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #19 from Julian Sikorski belegdol@gmail.com --- Would it make sense to make a pipewire-freeworld package in rpmfusion until dlopening codecs work?
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #20 from Pasi Karkkainen pasik@iki.fi --- FYI: libopenaptx has been forked and replaced with libfreeaptx (https://github.com/iamthehorker/libfreeaptx) due to problems with the libopenaptx author and recent weird license changes.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
ValdikSS iam@valdikss.org.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iam@valdikss.org.ru
--- Comment #21 from ValdikSS iam@valdikss.org.ru --- Is it possible to split libspa-bluez5.so from pipewire-libs and give it spa-version instead of general pipewire version? That would allow easy replacement package.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #22 from Neal Gompa ngompa13@gmail.com --- You're better off just doing pipewire-freeworld.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
pav@iki.fi changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pav@iki.fi
--- Comment #23 from pav@iki.fi --- In pipewire git (and next release 0.3.35), the codecs are split out to separate .so files that can be safely built and shipped separately, so if someone wants to make a pipewire-codec-aptx package that contains just libspa-codec-bluez5-aptx.so they can do so now.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #24 from Gergely Gombos gombosg@disroot.org --- Thanks for the heads up! Once 0.3.35 is out, I could package aptX codec for RPM Fusion.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #25 from Pablo Mendez Hernandez pmendezh@redhat.com --- It seems it's been already released :)
https://gitlab.freedesktop.org/pipewire/pipewire/-/tags/0.3.35
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #26 from Gergely Gombos gombosg@disroot.org --- Looks like it still needs to build with libfreeaptx. I tried a scratch build [1] of pipewire without the -D bluez5-codec-aptx=disabled option [2]. It failed miserably, not finding the library at build time. [3]
The current Fedora PW build just doesn't find the libfreeaptx codex.
But there is SBC-XQ [4] now which is almost as good as aptX and is enabled by default.
Any help and comments are appreciated though.
[1] https://src.fedoraproject.org/rpms/pipewire/blob/rawhide/f/pipewire.spec#_29... [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=75626355 [3] https://kojipkgs.fedoraproject.org//work/tasks/6355/75626355/build.log [4] https://www.lineageos.org/engineering/Bluetooth-SBC-XQ/
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #27 from pav@iki.fi --- From the logs it doesn't look like it installs freeaptx at all, and it's not mentioned in spec file.
SBC-XQ is not comparable to APTX-LL, one has latency < 40ms, the other is > 150ms.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #28 from pav@iki.fi --- So, yes, you need to package libfreeaptx also.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #29 from pav@iki.fi --- The RPM build environment should have libfreeaptx present. Then you can do `meson configure builddir` as usual, and after that `meson compile -C builddir spa-codec-bluez5-aptx`. This generates builddir/spa/plugins/bluez5/libspa-codec-bluez5-aptx.so, which can be just copied to the right place, and the codec RPM can contain only that file.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #30 from pav@iki.fi --- Something like this https://gitlab.freedesktop.org/pvir/pipewire-codec-aptx-rpm/ (not planning to maintain it though)
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #31 from Gergely Gombos gombosg@disroot.org --- Thanks for the POC repo! I haven't had time to look into it during the week, but I tested, this is working well, it's enough to start packaging in RPMFusion.
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #32 from Gergely Gombos gombosg@disroot.org --- For those interested, I submitted: https://bugzilla.rpmfusion.org/show_bug.cgi?id=6088 https://bugzilla.rpmfusion.org/show_bug.cgi?id=6089
https://bugzilla.redhat.com/show_bug.cgi?id=1908922
--- Comment #33 from Gergely Gombos gombosg@disroot.org --- FYI for those interested: package pipewire-codec-aptx is in RPM Fusion right now (currently in testing, then stable). Please report any bugs you find in RPM Fusion Bugzilla.
package-review@lists.fedoraproject.org