Plan to integrate the ffmpeg build directly in our build systems

[hrydgard]

The ppsspp-ffmpeg submodule repo is a sad story of huge binary bloat and binary compatibility issues. It's only there because building FFMPEG the official way is a royal pain, and on Windows requires installing msys, and so forth, even though the actual compile in the end is done by your local VS compiler.

We are using an old ffmpeg version and have no need for any upgrades, ever, since PSP games are not adding new codecs for obvious reasons, and we depend on some quirks of this old version anyway (new versions are not as reliable for us).

Any patching (like will be needed for the attempt at solving #15788 ) is super expensive since we need to rebuild and check in so many binaries.

Instead, I think we should move ffmpeg into our own build system and get rid of the precompiled binaries. The first step will be as follows:

• Create ext/ffmpeg-build, with subdirectories WindowsX64Config/ , AndroidARM64Config etc, where I'll put the generated config.h files from running the current build system.
• Create Visual Studio projects, CMakeLists.txt and Android.mk
• Refer to those to the main build files/.sln

One remaining issue might be the reliance on the nasm assembler, or maybe we can do assembly-free builds (that won't perform as well) if it's not present. Can we just include nasm binaries in our repo or a submodule to solve that particular issue (at least much smaller than full ffmpeg binaries)? ...

Then later, maybe even clean up the ffmpeg repo (deleting everything we don't need) and merge it into the main repo. At that point, we can start really shaving down ffmpeg into something more suitable for us, if it brings any benefits.

[hrydgard]

Actually hitting a bunch of issues with this already.

There's an "internal.h" in most major subdirectories, but it seems code often expects to get another one than the one is in their directory, most often libavutil/internal.h. Really not sure how that is working with the makefile build, don't see any special include path or anything :(

Another fun part is how multiple files are named the same thing in different directories, such as aacdec in both libavcodec and libavformat. Think I'm gonna have to use separate VS projects for each.

[anr2me]

Can the project file generated from this be used for PPSSPP? https://github.com/ShiftMediaProject/FFVS-Project-Generator

[hrydgard]

Oh that look pretty promising! Going to have to look into that.

[hrydgard]

And here's some kind of starting point for CMake:

https://github.com/cthirase/cmake-FFmpeg

It's clear this won't be easy, heh.

[anr2me]

CMake for Android (at the repo it's said to be ok for iOS too) https://syllogismobile.wordpress.com/2020/06/02/android-cmake-and-ffmpeg-part-two-building-ffmpeg/

FFmpeg Development Kit

Main purpose of this repository is to help people in building FFmpeg, mainly on mobile platforms (I tested this on Android, but armv7 shared libraries should be ok for iOS too).

[sum2012]

Does our ffmpeg already support mp4 and aac ?
Just need coding ?

[unknownbrackets]

Yes, FFmpeg 3.0.2 is from 2016 so it supports all those things just fine. It's still much more recent than the PSP OS support of those things.

Mp4 and Aac are tricky just because it takes a lot of work to figure out the specifics of the PSP's API handling, and there aren't a lot of example uses for those codecs. I think I did find one of the games that uses at least one of those formats for cheap somewhere and bought it, but haven't had the motivation to dedicate the days and weekends to investigating and making it work...

I feel like we could start by building FFmpeg at least for Linux. I do think we need to do this for Android at some point though, because IIRC the latest NDK requires relocations that will necessitate new FFmpeg libs. But on Linux, at least, yasm is less of an issue.

-[Unknown]