Migrate to FFmpeg 6.0

[equeim]

These changes are also compatible with FFmpeg 5.1, which is now minimum supported version.

Also set -Wl,-Bsymbolic flag via target_link_options command which is more correct.

[equeim]

Returned -Wl,-Bsymbolic flag. It seems that it's still needed for some codecs.

[equeim]

It seems that this also broke AC3 (it compiles but audio is wrong) and I have no idea why.

AC3 works with FFmpeg 4.4.4 witout this patch, but played sound is distorted with FFMpeg 6.0 and this patch. MP2 works fine in both cases.

[Tolriq]

@equeim Have you checked logcat? (Output buffer size (%d) too small for output data (%d))

I've migrated to ffmpeg 6 some times ago locally and it seems the comment :

// Output buffer sizes when decoding PCM mu-law streams, which is the maximum FFmpeg outputs.

is no more true and requires a bigger buffer. Doubling OUTPUT_BUFFER_SIZE_16BIT fixed all my issues. (But I do not support nor test ac3)

[equeim]

Nope, it was wrong option names for SwrContext (and there is no error handling av_opt_set calls so there was nothing in logcat). I think I will change it to use swr_alloc_set_opts2 function which accepts these options as parameters, so that there will be a better chance of discovering this at compile time.

[equeim]

@Tolriq I tried to encode some audio using ffmpeg with pcm_mulaw encoder and wav container and there wasn't any issues with ffmpeg 6.0 and this patch (without any changes to OUTPUT_BUFFER_SIZE_16BIT).

[Tolriq]

The issue is about decoding media I can send you a file in private that shows the issue.

[equeim]

The issue is about decoding media I can send you a file in private that shows the issue.

Sure, I have gmail address with the same user as on here.

[Tolriq]

@equeim file sent please do not spread.

[equeim]

I'm not sure that just doubling OUTPUT_BUFFER_SIZE_16BIT is a good idea. From what I can gather the required size of output buffer depends on numbers of samples in AVFrame structure (AVFrame::nb_samples), and that's can't be determined ahead of time for all codecs. I don't see a way to get "maximum" value either. I see 2 correct solutions:

1. Allocate buffer dynamically for each ffmpegDecode() call, or at least reallocate it's too small
2. Rewrite ffmpegDecode() to read AVFrame partially

Both seems a non-trivial changes.

[Tolriq]

Ho yes doubling is not the proper solution but it reduces the issue a lot without too much side effects or changes that may be refused upstream.
So far for normal music files no reports of unplayable files.

Anyway just wanted to inform about the issue as the comment is no more valid I assumed it's ffmpeg change that needs to be taken in account during update.

[equeim]

@microkatz @rohitjoins Currently there are changes regarding NDK r26 in this PR, I think it would be better to move them to separate PR. The question, do we want to support NDK r26? It dropped support of SDK levels < 21, and AFAIK currently media3 has minSdkVersion 16. I suppose it's possible to add automatic detection of NDK version in ffmpeg build script, but it won't be obvious to users that their minSdkVersion should be bumped to 21 if they are building with r26.

[equeim]

@Tolriq Actually with your file the issue with output buffer size is present in FFmpeg 4.4 too, so I think I will leave it as is here and make separate PR that adds dynamic reallocation.

[rohitjoins]

@equeim,

Thank you for your contribution.

there are changes regarding NDK r26 in this PR

While file in particular? Should we throw an WARN log in the build script if someone is building with NDK r26?

currently media3 has minSdkVersion 16

yes, and so we mention in the README that our build configuration is tested with NDK r21.

[equeim]

While file in particular? Should we throw an WARN log in the build script if someone is building with NDK r26?

I've removed it since this is out scope of this PR.

yes, and so we mention in the README that our build configuration is tested with NDK r21.

But shouldn't we at least be able to compile with the latest LTS version of SDK (which is r26b right now)? Currently build scripts for native libraries don't work at all with r26.

[rohitjoins]

Hi @equeim,

This PR is merged in the main branch. Agreed, NDK r21 is outdated and we should possibly update it to a newer version of NDK. Though we are constrained by the NDK support per Gradle version, please create another PR for supporting NDK r26b, I'll discuss this internally and try to upgrade our extension to it.

Thank you once again for your contributions.

[rohitjoins]

Hi @equeim,

Upon discussing internally it seems we are not constrained by the NDK support per Gradle version and would be happy to upgrade our README to the latest LTS for NDK which is r26b.

[equeim]

Hi @equeim,

Upon discussing internally it seems we are not constrained by the NDK support per Gradle version and would be happy to upgrade our README to the latest LTS for NDK which is r26b.

To do this it will be necessary to replace armv7a-linux-androideabi16- and i686-linux-android16- prefixes in build scripts with ones that set API 21, since NDK r26 does not support pre-21 APIs. This in turn would mean that all extensions that use native libraries will need to raise their minSdk versions to 21. Are you fine with this change? AFAIK minSdk for media3 is still 16.

[rohitjoins]

No, we can't do this. May be we can introduce some optional flag which people can enable to use the newer version of NDK.

[equeim]

No, we can't do this. May be we can introduce some optional flag which people can enable to use the newer version of NDK.

I'm thinking of adding another argument to build_ffmpeg.sh (and friends) scripts to pass ABI level (minSdk) from outside instead of hardcoding 16/21. This way those who have minSdk >= 21 will be able to use latest NDK without modifying build scripts.