Use of ffmpeg 4.x.x

I wonder why Audacity does not use more recent ffmpeg versions.
Presently ffmpeg is at version 4.1.3.
I have been using Audacity 2.1.2 Portable for some time, it insists on using avformat-55.dll of ffmpeg-2.2.2.
Just installed Audacity 2.3.2 hoping, it might allow use of avformat-58.dll of ffmpeg-4.0.2.
No, it still insists on avformat-55.dll.
Why is that so ?
Like any program or library ffmpeg improves from version to version.
Why can’t Audacity use the latest avformat-xx.dll ?

Regards whykai

Purely a matter of human resources. Audacity’s development team is very small, and there’s a lot of competing priorities.

Actually would be nice to be able to use the latest ffmpeg as I have been having some issues relating to the old version.

When importing some file types that use ffmpeg, most obviously my cherished .PSM files but other types too as I have seen this with some .MP4s, the import is not correct. The length of the track is longer and I find that it contains some rubbish / blank data. I initially thought this had to be the fault of Audacity but, using ffmpeg in isolation from Audacity produces the same results. Clearly there was a fault in ffmpeg as the latest version works perfectly. Sadly, can’t use the latest version whilst within Audacity.

Anybody interested in updating this? I really don’t fancy attempting it myself.

That was surprisingly easy. Turns out that all you have to do is overwrite the headers in the Audacity source \lib-src\ffmpeg\ with those from the ffmpeg 4.13 source and recompile Audacity. If you have a copy of Visual Studio 2017 or Visual Studio 2019 with the VS 2017 build tools. I didn’t but then… somehow I did.

Works really well with ffmpeg 4.1.3.

I would suggest that somebody updates the git as this is a very simple improvement with very little effort. I’m not suggesting this is a bug (not with Audacity) but an update which would be very welcome. The old ffmped is VERY flakey.

There is a lot of scope for adding some bells and whistles too to make full use of ffmpeg 4.1.3 but this will do for now and is best left to the devs I think.





Thanks for the info. Compiled and using Audacity 2.3.2 changed for ffmpeg 4.2 without issues so far.

Does anyone have a idea where i could pass “drc_scale” 0 option for ffmpeg in the audacity code?

It always bothered me that ffmpeg defaults to the bad dynamic range compression for AC3 by default.

Would be great to just fix this in audacity code for my private build for now. An GUI option in Audacity (like the ffmpeg dev intended) would be great, but a quick fix for a private audacity compile would also do it for now. :slight_smile:

Thanks for any hint :smiley:

You are probably going to get me banned for this but here is a kludge to get you going.
This will mean that ALL files containing ac3 audio will be treated in the same way. You want an option to enable or disable it? You’ll have to do that yourself.

Insert the following code at line 427 of ImportFFmpeg.cpp
AVDictionary *opts = NULL;
if (id == AV_CODEC_ID_AC3) {
av_dict_set(&opts, “drc_scale”, “0”, 0);
Then change the following line
if (avcodec_open2(sc->m_codecCtx, codec, NULL) < 0)
if (avcodec_open2(sc->m_codecCtx, codec, &opts) < 0)

Sorry, formatting in last post was horrible. Shoot me, I got lazy :stuck_out_tongue:

Insert new code at line 427 of ImportFFmpeg.cpp

AVDictionary* opts = NULL;

		 if (id == AV_CODEC_ID_AC3) 
			 av_dict_set(&opts, "drc_scale", "0", 0);

Change existing line immediately following from:

if (avcodec_open2(sc->m_codecCtx, codec, NULL) < 0)


if (avcodec_open2(sc->m_codecCtx, codec, &opts) < 0)

Many thanks - i’ll try that out asap.
And no - i don’t need an option.
I just wanted to permanenty disable the (imho totally wrong) default ffmpeg behaviour where all AC3 tracks get compressed in dynamic range by default.
Now i don’t have to recompile ffmpeg anymore like in the past. This will be a big time saver. Thanks again!

I agree that in the context of a sound editor, you really want to see and use the full dynamic range so it would be more appropriate to have drc_scale disabled. Perhaps you should suggest it in its own right as a feature request.

There is a lot of debate regarding the default behaviour of ffmpeg but I would argue that, in the context of a media player, ffmpeg,s behaviour is entirely correct and complies fully with the standard. It is the responsibility of the media player to enable it for use in a home setting where having a huge dynamic range could be problematic. I have neighbours and young children who may be in bed when the wife and I want to watch a movie. I generally go the other way and actively seek to reduce the dynamic range still further so that we can enjoy the movie and avoid disturbing those around us. In cinemas, it is entirely appropriate to use the full dynamic range and so drc_scale is switched off. I don’t see any problem with that.


Not at all :sunglasses:


Good to know :slight_smile: I haven’t been here long and didn’t want to face the firing squad for encouraging non standard / dodgy code.


Hopefully your code isn’t “dodgy” in a bad way.

If you would like to see an updated version of ffmpeg in the release version of Audacity, you could submit a “pull request” to Audacity on GitHub: GitHub - audacity/audacity: Audio Editor
The Audacity code needs to work on Windows, Mac and Linux. If you’re unsure if your code works on all platforms, then you could create your own fork of Audacity in your own GitHub account, make your changes, then talk to the Audacity developers (via the developer’s mailing list:

:laughing: No, not dodgy as in bad code, just unofficial / unsanctioned and differing from the main release. I would ALWAYS prefer to have the DEVs implement what THEY consider to be worthwhile and do it in a manner which is in keeping with the main concept. Having it documented is always a great thing too.

I already see from that there is a feature request to “Keep FFmpeg dynamic library support updated to latest FFmpeg”. I have no idea when that appeared as I saw whakai’s forum post first. I simply observed that it was very easy to update the headers and made the suggestion. I believe everything else is already implemented in the main code.

As for the drc_scale code, that is standard, fairly obvious code and I was just wanted to help out with a “personal build” but encouraged audctydude123 to suggest it be added as a feature in its own right as I’m in total agreement that it really should be implemented in some way.

I DO have a git but I have no wish to directly contribute by submitting pull requests and I haven’t even forked Audacity. My skills lie elsewhere and at least one of those skills tells me that I’m not in the same league as your developers, which is why I came here to make a suggestion for adding a feature and try hard not to rock the boat :slight_smile:


No problem with that.

I’m nowhere near the same league as the main developers, but I’ve still provided a bunch of new features and many bug fixes. The good thing about pull requests, is that it will only be merged if one of the main developers is happy with it. If the request has only minor problems but is otherwise a positive enhancement, then one of the main developers may fix it up as necessary and then merge it. Code contributions are very welcome.

I hear what you are saying and if sometime in the future, I consider that Audacity could benefit from Biometric Monitoring of the user and / or some form of Telemetry, I’m right there :slight_smile:



Thanks again, it did work out with your code without problems.

But: I did remove the condition regarding the codec (…if (id == AV_CODEC_ID_AC3)…) since i want it disabled for all codecs which support it.
As far as i know it’s supported by all dolby codecs (ac3, eac3, truehd) - IF the producer includes DRC metadata accordingly)
FFmpeg just ignores the drc_scale 0 parameter for codecs which don’t use it or when there is no dolby DRC metadata included.
Therefore the condition is not needed imho.

Fair enough, it was your idea. Great that it worked out for you :slight_smile: As I said before, if you think it is worthwhile having the feature added, others might also benefit from having it in there to. Perhaps YOU should raise it as a feature request…