Retiring AAC Support about centos-rpm-liquidsoap

[smlz]

👍

[paraenggu]

In short, I'm OK with your removal plans related to liquidsoap RPMs.

I guess it would be helpful for other users of centos-rpm-liquidsoap, if you could elaborate on the motivation behind the removal decision in order to understand/accept the change.

Given that we are not currently using any FOSS AAC encoders or decoders @radiorabe and there are no plans to do so in the foreseeable future, I think retiring its support in these binaries is the way forward.

I agree as for the codec usage within liquidsoap. However, there are other fields were we still are and will be using AAC codecs (testing of DAB+, maintaining the ODR RPMs, sporadic playout on desktops etc.).

[hairmare]

With regards to the ODR and DAB+ usage, we're on a rather specialized AAC fork that aims at providing broadcast quality HE-AAC (with SBR) by re-implementing the parts of AAC not opensourced by Fraunhofer as they were not part of the Android code drop.

Playout on desktops is not affected by this as distro fdk-aac packages will be available where needed (and choosing the right decoder if alternatives with SBR support from rpmfusion are installed should be handled by gsteamer in the long run).

The main motivation is me wanting to get rid of the Nux Dextop dependency on this build so I can start figuring out how to upstream this package and its deps.
Since it is looking likely that the official Fedora fdk-aac packages will not be able to support the full range of AAC profiles available (like HE-AAC with SBR) anything we package will end up with a rather poor user experience for anyone wanting to look at anything related to HE-AAC.

[tzumbrunnen]

Thank you for providing this pakage for a hassle free installation. From the maintainability point of view I fully understand the motivation to get rid of unnecessary depdendencies. we started using the centos Liquidsoap rpm a while ago for the sole purpose of transcoding to %fdkaac output.
Just for my understanding I need to ask, do you completely remove the AAC support or do you make it more upstream compatible (i.e Dynamically load fdk-aac encoder) ?

[hairmare]

@tzumbrunnen As far as I remember transcoding to %fdkaac used to load the needed sofile dynamically... Current builds seem to indicate otherwise. I'm not sure if this was changed in liquidsoap or I just remember it wrong.

 * Supported output formats
   - FDK-AAC           : yes

I'm not really sure when I'll get around to getting rid of AAC support, but I'll certainly try to keep the output support if anyway possible.
I waited for so long with this because I was hoping that https://bugzilla.redhat.com/show_bug.cgi?id=1501522 gets resolved at some point. If that bug finally gets resolved I'll most likely be able to keep aac output support.

[hairmare]

After some further digging I realized that we can probably use the dynload feature for fdk-aac and %fdkaac will still work (just like on debian where fdk-aac is nonfree).

I tested this in a container and sure enough, detected at runtime shows up in configure as it should.