[Libretro] "UseFFMPEGFindStreamInfo" crashes RetroArch on Android
Game or games this happens in
ULUS10213 - The Warriors / ULUS10435 - G.I. Joe: The Rise of Cobra
What area of the game / PPSSPP
The 2 games listed under [UseFFMPEGFindStreamInfo] in compat.ini crash RetroArch on Android a few seconds after booting. If I remove it then the games don't crash anymore (but then FMVs run like crap in The Warriors, seems OK in G.I. Joe but only tested for a very short period of time).
Last few lines of the logs (full logs attached below):
[MPEG] sceMpegInit(), mpegLibVersion 0x10a, mpegLibcrc 0
[MPEG] Detected semaID 640
[MPEG] 00000000=sceMpegCreate(09fff450, 09578000, 00010000, 09fff2c0, 00000200, 00000000, 00000000)
[MPEG] Stream offset: 2048, Stream size: 0x33800
[MPEG] First timestamp: 90000, Last timestamp: 417327
[MPEG] Stream offset: 2048, Stream size: 0x33800
[MPEG] First timestamp: 90000, Last timestamp: 417327
[MPEG] 1=sceMpegRegistStream(09fff450, 00000000, 00000000)
[MPEG] 2=sceMpegRegistStream(09fff450, 00000001, 00000000)
[MPEG] UNIMPL sceMpegAvcInitYCbCr(09fff450, 1, 480, 272, 09589400)
[SCEKERNEL] 308=sceKernelCreateThread(displayThread, 089dcbcc, 0000003f, 2048, 00004000, 00000000)
[SCEKERNEL] 309=sceKernelCreateThread(readThread, 08992e98, 00000041, 2048, 00000000, 00000000)
[SCEKERNEL] 310=sceKernelCreateThread(soundThread, 08887fd8, 0000003d, 2048, 00004000, 00000000)
[MPEG] Stream offset: 2048, Stream size: 0x33800
[MPEG] First timestamp: 90000, Last timestamp: 417327
[ME] Failed to read valid video stream data from header
[ME] FF: Stream #0: not enough frames to estimate rate; consider increasing probesize
[ME] FF: deprecated pixel format used, make sure you did set range correctly
Also managed to get a crash dump, never did this before so it was a bit of a PITA to get, so I hope it won't be useless :p
********** Crash dump: **********
Build fingerprint: 'Redmi/sapphiren_global/sapphiren:15/AQ3A.240829.003/OS2.0.201.0.VNHMIXM:user/release-keys'
WARNING: Could not parse ABI from: b"2025-08-10 13:58:38.046 28833-28833 DEBUG crash_dump64 A ABI: 'arm64'"
#00 0x0000000000d803f8 /data/user/0/com.retroarch.aarch64/cores/ppsspp_libretro_android.so
ff_seek_frame_binary
C:/dev/ppsspp/ffmpeg/libavformat/utils.c:1923:16
#01 0x0000000000d81184 /data/user/0/com.retroarch.aarch64/cores/ppsspp_libretro_android.so
seek_frame_internal
C:/dev/ppsspp/ffmpeg/libavformat/utils.c:2228:16
av_seek_frame
C:/dev/ppsspp/ffmpeg/libavformat/utils.c:2251:11
#02 0x00000000007a8204 /data/user/0/com.retroarch.aarch64/cores/ppsspp_libretro_android.so
MediaEngine::openContext(bool)
/builds/bslenul/ppsspp/Core/HW/MediaEngine.cpp:340:3
#03 0x00000000007a8f68 /data/user/0/com.retroarch.aarch64/cores/ppsspp_libretro_android.so
MediaEngine::addStreamData(unsigned char const*, int)
/builds/bslenul/ppsspp/Core/HW/MediaEngine.cpp:463:5
#04 0x00000000006e8c84 /data/user/0/com.retroarch.aarch64/cores/ppsspp_libretro_android.so
PostPutAction::run(MipsCall&)
/builds/bslenul/ppsspp/Core/HLE/sceMpeg.cpp:1439:72
#05 0x000000000062c5e8 /data/user/0/com.retroarch.aarch64/cores/ppsspp_libretro_android.so
HLEReturnFromMipsCall()
/builds/bslenul/ppsspp/Core/HLE/HLE.cpp:684:11
#06 0x000000000062ce3c /data/user/0/com.retroarch.aarch64/cores/ppsspp_libretro_android.so
CallSyscallWithoutFlags(HLEFunction const*)
/builds/bslenul/ppsspp/Core/HLE/HLE.cpp:889:2
#07 0x00000000000bf588 <anonymous:6f2718b000>
What should happen
Not crash.
Logs
Platform
Android
Mobile device model or graphics card (GPU)
Redmi Note 13 (GPU is apparently a Adreno 610)
PPSSPP version affected
v1.19.1-498-g5898466
Last working version
No clue if it ever worked
Graphics backend (3D API)
Vulkan (also tested with GL)
Checklist
- [x] Test in the latest git build in case it's already fixed.
- [x] Search for other reports of the same issue.
- [x] Try resetting settings or older versions and include if the issue is related.
- [x] Try without any cheats and without loading any save states.
- [x] Include logs or screenshots of issue.
Where are you getting the retroarch binary, how is it built? Is it built with the version off FFMPEG that we supply, or differently?
I wasn't able to build the Android core locally so I used the Libretro buildbot to build it (I didn't have Docker installed), here's the Docker file it uses: https://git.libretro.com/libretro-infrastructure/libretro-build-android/-/blob/master/Dockerfile?ref_type=heads and the script to build Android cmake cores (which I slightly modified to build the core with RelWithDebInfo and to add the build files to the artifacts to be able to use ndk-stack): https://git.libretro.com/libretro-infrastructure/ci-templates/-/blob/master/android-cmake.yml?ref_type=heads
The version of FFmpeg used is the one from your repo.
So I reinstalled Docker and as a test I replaced the .a files in ppsspp/ffmpeg/android/arm64/lib/ with older ones (https://github.com/hrydgard/ppsspp-ffmpeg/tree/f4e4938b8aac8369c07c1189517831d81dcaf349/android/arm64/lib, it's 9 years old but there's no in-between prebuilt libs) and no crash anymore, so for whatever reason it looks like the Libretro core doesn't like the new libs when that "UseFFMPEGFindStreamInfo" setting is used (or at least on Android ARM64) 🤔
So next I bisected from the PPSSPP FFMpeg repo directly, and it looks like the crashes started with the update to NDK 27: https://github.com/hrydgard/ppsspp-ffmpeg/commit/6bf1d8205d99c2343a8721e0c80e2fc3bb3a38a4, and indeed if I replace NDK=/c/Android/sdk/ndk/27.2.12479018 with NDK=/c/Android/sdk/ndk/21.4.7075529 in android_arm64-v8a.sh and rebuild the libs it's not crashing anymore.
But no idea why it only affects the Libretro core and not the standalone version :p
Revisited this issue one more time and think I've found the issue: https://ffmpeg.org/pipermail/ffmpeg-cvslog/2024-April/142577.html If I apply that small fix in your FFmpeg repo then rebuild the libs and then rebuild the Android core, it's not crashing anymore!
Ooh, great find! Feel free to do a PR with the change and the rebuilt libs, or I can rebuild the libs in a while.
PR submitted, I'll let you rebuild the libs if you don't mind, I'm using a slightly different NDK version so idk if it could cause any issue + I can only test arm64 libs.
Sure, I'll rebuild them next week.
Really nice to have this resolved, thanks for your digging!