6 ms·

AAC and Debian

51 points by tookmund 3y ago

ugjka 3y ago
The problem is with spectral band replication in aac-he and parametric stereo in aac-he-v2 both of which are impressive but not transparent and should only be used if you are trying save bandwidth
ebb_earl_co 3y ago
Interesting. Could FFmpeg’s AAC en/decoder not be used? There’s an explicit flag necessary to include libfdk-aac when compiling FFmpeg and it makes the resulting binary not able to be shared. However, without that flag, FFmpeg still has (their own? VideoLAN’s?) an AAC en/decoder that works fine.
- cogman10 3y ago
  The issue, I believe, is more around the AAC patents and less around the actual library.
theossuary 3y ago
Any reason they didn't use the debian apt source repositories instead of git? I tend to try and use deb-src whenever possible, to stay as close to Debian truth as possible.
- jauntywundrkind 3y ago
  They cloned the Debian git repo, https://salsa.debian.org/multimedia-team/fdk-aac https://salsa.debian.org/multimedia-team/fdk-aac , and used apt source directly for pipewire. Not sure why the split approach, but it does look like they are relying on a Debian source of truth.
  - tookmund 3y ago
    The split approach is because the free version of the library is not yet in Debian. There’s probably some way to pull it from the new queue directly but cloning the git repo is easier.
- JNRowe 3y ago
  If you run "apt source" for the package you'll see it - like lots of other packages - point you to the git repository when the packaging is maintained in a public git repository. The Vcs-Tag field in the package lists is the magic that triggers that message.
deleted 3y ago
[deleted]
rcarmo 3y ago
This kind of thing is why I’ve only ever used Debian as a server distro until the Raspberry Pi started “fixing” various aspects of it… My Linux laptops ran Ubuntu for a solid decade until Fedora 36 turned me around (and I’ve been happy since). But the key thing is that Debian tends to lag on user amenites (hardware, drivers, codecs, etc.) to a point where one wonders if they actually use the distro on modern hardware...
- Doxin 3y ago
  The trick with Debian is to use Debian testing. Despite the name it's thoroughly stable enough for desktop use. Debian stable is for when you're needing an OS for a nuclear power plant or something. This could be advertised better.
mustache_kimono 3y ago
From the article: "This is a slightly unusual situation, as the fdk-aac library is licensed under what even the GNU project acknowledges is a free software license. However, this license explicitly does not grant any patent rights." Here, in the US at the very least, this would seem to be less of a problem given De Forest Radio, 273 U.S. 236 (1927): "Any language used by the owner of the patent, or any conduct on his part exhibited to another from which that other may properly infer that the owner consents to his use of the patent in making or using it, or selling it, upon which the other acts, constitutes a license and a defense to an action for a tort." And logically this case makes sense. If I've granted you all these copyrights (MIT and BSD), just to surprise you/someone with a patent suit, that seems not equitable. Large companies are more comfortable with Apache 2 given it's explicit patent grant, but I wouldn't be surprised if users of certain Rust software (which is often MIT + Apache 2 licensed) had more expansive patent rights under the MIT license, given how narrow the rights granted by the Apache 2 are. However, here, the facts are not as stated in the article. The FDK license does not just "explicitly not grant", as the article notes, it puts you on notice that you must obtain a patent license. That is not like the MIT license. The MIT license is silent re: a patent license.
- AshamedCaptain 3y ago
  Franhoufer is not the owner of the patents in question, most of them are likely owned by the usual gang . They cannot license it to you even if they wanted to.
  - mustache_kimono 3y ago
    > Franhoufer is not the owner of the patents in question, most of them are likely owned by the usual gang . They cannot license it to you even if they wanted to. The point remains, if you license your software permissively (MIT), and you were aware of it being patent encumbered, and someone uses your software in a patent infringing way, the problem would likely be licensor's, not yours. Here, you may be correct, that is less certain because the license explicitly mentions needing to obtain a patent license.
noisem4ker 3y ago
> Bluetooth headphones that require the AAC codec cannot be used Isn't SBC support mandatory for Bluetooth audio devices?
- Scion9066 3y ago
  Looks like it should be mandatory: https://en.wikipedia.org/wiki/SBC_%28codec%29 https://en.wikipedia.org/wiki/SBC_%28codec%29 As of A2DP version 1.3, the Low Complexity Subband Coding remains the default codec and its implementation is mandatory for devices supporting that profile, but vendors are free to add their own codecs to match their needs.
  - tookmund 3y ago
    It should be, but I’ve never gotten it to work with any Apple Bluetooth headphones. Only static unless I switch to AAC.
gcr 3y ago
Is there any reason why we cannot put a pipewire-with-aac build in the nonfree repository that replaces the default pipewire build using the Alternatives system? Or perhaps pipewire could ldopen() libfaac as required. Edit: the issue is social, not technical—it’s not desirable to have an easy way to “slot in” a nonfree aac because of patent disputes

51 points by tookmund 3y ago

The problem is with spectral band replication in aac-he and parametric stereo in aac-he-v2 both of which are impressive but not transparent and should only be used if you are trying save bandwidth

ebb_earl_co 3y ago

Interesting. Could FFmpeg’s AAC en/decoder not be used? There’s an explicit flag necessary to include libfdk-aac when compiling FFmpeg and it makes the resulting binary not able to be shared. However, without that flag, FFmpeg still has (their own? VideoLAN’s?) an AAC en/decoder that works fine.

cogman10 3y ago
The issue, I believe, is more around the AAC patents and less around the actual library.

theossuary 3y ago

Any reason they didn't use the debian apt source repositories instead of git? I tend to try and use deb-src whenever possible, to stay as close to Debian truth as possible.

jauntywundrkind 3y ago
They cloned the Debian git repo, https://salsa.debian.org/multimedia-team/fdk-aac https://salsa.debian.org/multimedia-team/fdk-aac , and used apt source directly for pipewire. Not sure why the split approach, but it does look like they are relying on a Debian source of truth.
- tookmund 3y ago
  The split approach is because the free version of the library is not yet in Debian. There’s probably some way to pull it from the new queue directly but cloning the git repo is easier.
JNRowe 3y ago
If you run "apt source" for the package you'll see it - like lots of other packages - point you to the git repository when the packaging is maintained in a public git repository. The Vcs-Tag field in the package lists is the magic that triggers that message.

deleted 3y ago

[deleted]

rcarmo 3y ago

This kind of thing is why I’ve only ever used Debian as a server distro until the Raspberry Pi started “fixing” various aspects of it… My Linux laptops ran Ubuntu for a solid decade until Fedora 36 turned me around (and I’ve been happy since). But the key thing is that Debian tends to lag on user amenites (hardware, drivers, codecs, etc.) to a point where one wonders if they actually use the distro on modern hardware...

Doxin 3y ago
The trick with Debian is to use Debian testing. Despite the name it's thoroughly stable enough for desktop use. Debian stable is for when you're needing an OS for a nuclear power plant or something. This could be advertised better.

mustache_kimono 3y ago

From the article: "This is a slightly unusual situation, as the fdk-aac library is licensed under what even the GNU project acknowledges is a free software license. However, this license explicitly does not grant any patent rights." Here, in the US at the very least, this would seem to be less of a problem given De Forest Radio, 273 U.S. 236 (1927): "Any language used by the owner of the patent, or any conduct on his part exhibited to another from which that other may properly infer that the owner consents to his use of the patent in making or using it, or selling it, upon which the other acts, constitutes a license and a defense to an action for a tort." And logically this case makes sense. If I've granted you all these copyrights (MIT and BSD), just to surprise you/someone with a patent suit, that seems not equitable. Large companies are more comfortable with Apache 2 given it's explicit patent grant, but I wouldn't be surprised if users of certain Rust software (which is often MIT + Apache 2 licensed) had more expansive patent rights under the MIT license, given how narrow the rights granted by the Apache 2 are. However, here, the facts are not as stated in the article. The FDK license does not just "explicitly not grant", as the article notes, it puts you on notice that you must obtain a patent license. That is not like the MIT license. The MIT license is silent re: a patent license.

AshamedCaptain 3y ago
Franhoufer is not the owner of the patents in question, most of them are likely owned by the usual gang . They cannot license it to you even if they wanted to.
- mustache_kimono 3y ago
  > Franhoufer is not the owner of the patents in question, most of them are likely owned by the usual gang . They cannot license it to you even if they wanted to. The point remains, if you license your software permissively (MIT), and you were aware of it being patent encumbered, and someone uses your software in a patent infringing way, the problem would likely be licensor's, not yours. Here, you may be correct, that is less certain because the license explicitly mentions needing to obtain a patent license.

noisem4ker 3y ago

> Bluetooth headphones that require the AAC codec cannot be used Isn't SBC support mandatory for Bluetooth audio devices?

Scion9066 3y ago
Looks like it should be mandatory: https://en.wikipedia.org/wiki/SBC_%28codec%29 https://en.wikipedia.org/wiki/SBC_%28codec%29 As of A2DP version 1.3, the Low Complexity Subband Coding remains the default codec and its implementation is mandatory for devices supporting that profile, but vendors are free to add their own codecs to match their needs.
- tookmund 3y ago
  It should be, but I’ve never gotten it to work with any Apple Bluetooth headphones. Only static unless I switch to AAC.

gcr 3y ago

Is there any reason why we cannot put a pipewire-with-aac build in the nonfree repository that replaces the default pipewire build using the Alternatives system? Or perhaps pipewire could ldopen() libfaac as required. Edit: the issue is social, not technical—it’s not desirable to have an easy way to “slot in” a nonfree aac because of patent disputes