Bug 1908922 - Review Request: libopenaptx - Open Source implementation of Audio Processing Technology codec (aptX)
Summary: Review Request: libopenaptx - Open Source implementation of Audio Processing ...
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Zbigniew Jędrzejewski-Szmek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: FE-Legal
TreeView+ depends on / blocked
 
Reported: 2020-12-17 23:15 UTC by Gergely Gombos
Modified: 2021-10-04 17:59 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-15 20:08:47 UTC
Type: ---
zbyszek: fedora-review+


Attachments (Terms of Use)

Description Gergely Gombos 2020-12-17 23:15:59 UTC
Spec URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx.spec
SRPM URL: https://gombosg.fedorapeople.org/libopenaptx/libopenaptx-0.2.0-1.fc33.src.rpm
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.build#L31-32

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?

Comment 1 Aleksei Bavshin 2020-12-18 00:26:18 UTC
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.

Comment 2 Gergely Gombos 2020-12-18 10:38:51 UTC
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.

Comment 3 Gergely Gombos 2020-12-19 20:02:38 UTC
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.rpm

Comment 4 Ben Cotton 2020-12-21 14:34:08 UTC
Ack on the legal review. I'll get the patent status verified and then update this bug.

Comment 5 Neal Gompa 2020-12-22 07:07:52 UTC
> %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?

Comment 6 Aleksei Bavshin 2020-12-22 07:22:00 UTC
(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.

Comment 7 Neal Gompa 2020-12-22 13:09:43 UTC
Hmm, that's true since this package is actually named by the library name. Though `-utils` is weird compared to `-tools`.

Comment 8 Gergely Gombos 2020-12-22 13:54:46 UTC
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.rpm

Comment 9 Zbigniew Jędrzejewski-Szmek 2021-01-03 18:44:25 UTC
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.

Comment 10 Aleksei Bavshin 2021-01-05 12:32:15 UTC
(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.

Comment 11 Gergely Gombos 2021-02-02 07:22:24 UTC
(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.

Comment 12 Zbigniew Jędrzejewski-Szmek 2021-02-02 07:46:42 UTC
It's been forwarded to the appropriate people. We're waiting for the resolution.

Comment 13 Ben Cotton 2021-02-02 13:41:54 UTC
(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.

Comment 14 Ben Cotton 2021-02-15 20:08:47 UTC
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.

Comment 15 Gergely Gombos 2021-02-18 06:39:04 UTC
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.

Comment 16 Zbigniew Jędrzejewski-Szmek 2021-02-18 08:24:30 UTC
I assume the needinfo was by mistake.

Comment 18 Gergely Gombos 2021-04-27 12:45:20 UTC
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.

Comment 19 Julian Sikorski 2021-07-15 15:16:10 UTC
Would it make sense to make a pipewire-freeworld package in rpmfusion until dlopening codecs work?

Comment 20 Pasi Karkkainen 2021-08-02 08:23:34 UTC
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.

Comment 21 ValdikSS 2021-08-14 22:09:25 UTC
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.

Comment 22 Neal Gompa 2021-08-15 19:34:35 UTC
You're better off just doing pipewire-freeworld.

Comment 23 pav 2021-09-07 09:15:26 UTC
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.

Comment 24 Gergely Gombos 2021-09-09 07:22:07 UTC
Thanks for the heads up! Once 0.3.35 is out, I could package aptX codec for RPM Fusion.

Comment 25 Pablo Mendez Hernandez 2021-09-13 08:27:31 UTC
It seems it's been already released :)

https://gitlab.freedesktop.org/pipewire/pipewire/-/tags/0.3.35

Comment 26 Gergely Gombos 2021-09-13 21:07:36 UTC
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#_292
[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/

Comment 27 pav 2021-09-14 06:52:57 UTC
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.

Comment 28 pav 2021-09-14 06:56:52 UTC
So, yes, you need to package libfreeaptx also.

Comment 29 pav 2021-09-14 07:03:59 UTC
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.

Comment 30 pav 2021-09-16 18:16:00 UTC
Something like this https://gitlab.freedesktop.org/pvir/pipewire-codec-aptx-rpm/
(not planning to maintain it though)

Comment 31 Gergely Gombos 2021-09-17 08:07:51 UTC
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.

Comment 32 Gergely Gombos 2021-09-21 14:16:50 UTC
For those interested, I submitted:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6088
https://bugzilla.rpmfusion.org/show_bug.cgi?id=6089

Comment 33 Gergely Gombos 2021-10-04 17:59:33 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.