Page MenuHomeFreeBSD

audio/cmus: Clean up port defaults
ClosedPublic

Authored by diizzy on Nov 6 2019, 6:47 PM.
Tags
None
Referenced Files
Unknown Object (File)
Feb 28 2024, 5:32 AM
Unknown Object (File)
Feb 20 2024, 2:43 AM
Unknown Object (File)
Feb 20 2024, 2:43 AM
Unknown Object (File)
Feb 20 2024, 2:43 AM
Unknown Object (File)
Feb 20 2024, 2:29 AM
Unknown Object (File)
Jan 14 2024, 4:13 PM
Unknown Object (File)
Nov 4 2023, 1:04 PM
Unknown Object (File)
Sep 21 2023, 5:41 PM
Subscribers

Details

Summary

FFmpeg can handle AAC, FLAC, MP3, MP4, OPUS, VORBIS, WAV making these dependencies unnecessary.
Ref: ip/ffmpeg.c

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

tobik requested changes to this revision.Nov 6 2019, 7:45 PM

I do not understand what problem you are solving with this? Most of the dependencies are still there afterwards transitively.

This revision now requires changes to proceed.Nov 6 2019, 7:45 PM

The idea is to minimize the amount of dependencies, try to consolidate overall in the long run and possibly try to deprecate some such as madlib which isn't seen development in years and has known vulns and is quite inefficient. While the default configuration of ffmpeg pulls in opus and vorbis they aren't necessarily needed as ffmpeg supports decoding of both these formats without any external libraries. This will also make it potentially less tedious when doing custom packages/repos and you want to avoid getting unnecessary dependencies pulled in.

If libmad is vulnerable and should be removed in the near future, why disable the other input plugins? What about the other ~80 ports that depend on libmad? I strongly suggest opening a PR (with patch) for marking audio/libmad vulnerable in vuln.xml to inform users about it.

That being said I am going to disable MAD by default in cmus. FFMPEG is the fallback input plugin and seeking in files is slower than with the other plugins, so I'd rather keep them on by default unless there is a more compelling reason than saving a few small dependencies.

This revision was not accepted when it landed; it landed in state Needs Revision.Nov 9 2019, 6:34 AM
This revision was automatically updated to reflect the committed changes.

It's in the works, I'm slowly working my way through the list so it's on my todo list. Many utilities in /audio have newer counterparts or so but I'm not sure how you would go about deprecating those in a later stage.

Are you experience performance issues with any specific format as it pretty much instantly with indexed formats such as m4a which is to be expected however I noticed a minor difference using MP3s on my ARMv7 box jumping 1h or so however ffmpeg seems to be a bit more accurate in that regard.