Opened 6 months ago

Closed 6 months ago

Last modified 6 months ago

#6934 closed enhancement (invalid)

Global option to compile FFmpeg with only audio-related features

Reported by: cybersinh Owned by:
Priority: wish Component: build system
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Today, compiling FFmpeg to get only audio-related features is not very developer friendly.

We have to write many options (and hard to maintain) to enable all audio decoder, demuxer, parser... one by one:
https://github.com/CyberSinh/Luminescence.Audio/blob/master/lib/make/ffmpeg/configure-ffmpeg-msvc.sh

It would be great if there was a global option in the 'configure' bash script to enable all (and only) audio-related features like (eg. for demuxers):
--disable-video-demuxers
--enable-audio-demuxers

Thanks!

Change History (12)

comment:1 Changed 6 months ago by cehoyos

  • Keywords audio removed
  • Priority changed from normal to wish
  • Resolution set to invalid
  • Status changed from new to closed

I believe that if you try to work on such a patch, you will see that it is not possible - what is an audio demuxer?

comment:2 follow-up: Changed 6 months ago by cybersinh

Why is it not possible? I don't understand.
I think 'ogg' could be considered mainly as audio demuxer, with 'flac', 'vorbis',... as audio decoder.
This shell script shows what I considered as audio-oriented, but maybe at wrong (I'm ready to discuss if my approach is not the best way to filter video related features...):
https://github.com/CyberSinh/Luminescence.Audio/blob/master/lib/make/ffmpeg/configure-ffmpeg-msvc.sh

comment:3 in reply to: ↑ 2 Changed 6 months ago by cehoyos

Replying to cybersinh:

Why is it not possible? I don't understand.

I think 'ogg' could be considered mainly as audio demuxer

No matter if I (and Xiph) agree or not (I don't and I strongly assume Xiph doesn't), this case is sufficient to show the task cannot be completed...
But as said, please feel free to send a patch to the development mailing list: Such issues are much better discussed there!

Concerning your script: --disable-all and --enable-decoder=pcm* --enable-demuxer=matroska,pcm* should significantly simplify it.
Does --arch really have an effect for msvc? I would consider that a bug because it has no effect on Linux and similar systems for native tool-chains.

comment:4 Changed 6 months ago by cybersinh

Demuxer was certainly not the best example to demonstrate what is an audio-related feature.
Decoder would have been more demonstrative. But you don't seem to be open to discuss this feature request on this issue tracker so I am going to send a mail to the development mailing list, as suggested.

comment:5 Changed 6 months ago by cehoyos

You seem to have forgotten to attach a patch to your email.

In the description of this ticket, you do not request a feature --enable-audio-decoders, please do not claim that I am not open to discuss such a feature!

comment:6 follow-up: Changed 6 months ago by cybersinh

Sorry if the nature of "feature request" of this issue was not clear enough: its type is however "enhancement" with "Global option to compile FFmpeg with only audio-related features" as title.

You closed this thread 20 minutes after it was created by just saying "not possible". I deduced that you did not really want to continue the discussion of the real need.

comment:7 in reply to: ↑ 6 Changed 6 months ago by cehoyos

Replying to cybersinh:

You closed this thread 20 minutes after it was created by just saying "not possible".

Nothing that was written since has made me believe --enable-audio-demuxers (or --disable-video-demuxers) is possible - on the contrary, your first comment confirmed my initial suspicions.

comment:8 Changed 6 months ago by cybersinh

Yeah, but demuxers was just an example (please note "eg. for demuxers: ..."), not limitative to the real need. I could (and should) have taken decoders for example. I had list "decoder, demuxer, parser" in the issue description.

I did not understand why the issue was closed so quickly, for an example maybe bad chosen, but with clear purpose.

comment:9 follow-up: Changed 6 months ago by Gyan

Implementation will require the creation of a custom list of demuxers/parsers/decoders/filters/encoders/muxers and their dependents. This list will have to be maintained and updated, so whomever takes on the task has to monitor for new and deprecated components. In the absence of sufficient demand, doesn't seem anyone will be interested.

Best bet seems for you to work on it yourself. If it doesn't get merged, you can still offer it as a patch.

comment:10 in reply to: ↑ 9 Changed 6 months ago by cehoyos

Replying to Gyan:

Implementation will require the creation of a custom list of demuxers/parsers/decoders/filters/encoders/muxers and their dependents.

I don't think this is true for decoders and encoders.

comment:11 Changed 6 months ago by Gyan

Yeah, you can select those based on AVMEDIA_TYPE.

comment:12 Changed 6 months ago by cybersinh

It's easy for decoders/encoders.

But what would be the selection criteria to exclude parsers (eg. png, dirac, h264,...) and demuxers (subtitle, image,...) that have no meaning for audio? Can the selection be only manual?

Note: See TracTickets for help on using tickets.