Closed Gicminos closed 3 years ago
tanersener
commented
3 years ago I see that native calls trigger a cleanup routine and that routine fails with SIGABRT. I don't see why that routine is called in the stack trace. Can you explain which flutter_ffmpeg calls are made by your app? Is this case reproducible, can you list the steps to reproduce it?
Gicminos
commented
3 years ago I see that native calls trigger a cleanup routine and that routine fails with
SIGABRT. I don't see why that routine is called in the stack trace. Can you explain whichflutter_ffmpegcalls are made by your app? Is this case reproducible, can you list the steps to reproduce it?
Thank you for your quick reply. It was not easy to determine the command causing the crash but I am quite sure that it is getMediaInformation from FlutterFFprobe.
This is the code where I use it:
final FlutterFFprobe flutterFFprobe = FlutterFFprobe();
MediaInformation mediaInformation = await flutterFFprobe.getMediaInformation(this.path);
Map<dynamic, dynamic> mp = mediaInformation.getAllProperties();It is worth to mention that sometimes this method returns null and in that case I run it again. Usually a second run retrieves the correct data but it seems that sometimes it causes this crash.
I am not sure how to trustly reproduce it because as said sometimes it happens and sometimes it doesn't. I could not figure yet exact steps to make it happen at the first shot.
tanersener
commented
3 years ago getMediaInformation method of FlutterFFprobe is a utility method which parses ffprobe output. If the output is not complete or not in the right format it returns null. In these situations logcat in Android includes a stack trace that explains why parsing failed. I suggest looking at it.
The stack trace in your first post shows that the crash happens during an ffmpeg call, not ffprobe. getMediaInformation is not to blame there.
com.app.app-T9kJdSRjZ9WidZfqbsKwiw==/lib/arm64/libmobileffmpeg.so (exit_program+32) (BuildId: b57e749e21d9106923ad74eb8a4b767e70a578d9)
com.app.app-T9kJdSRjZ9WidZfqbsKwiw==/lib/arm64/libmobileffmpeg.so (ffmpeg_execute+10848) (BuildId: b57e749e21d9106923ad74eb8a4b767e70a578d9)
com.app.app-T9kJdSRjZ9WidZfqbsKwiw==/lib/arm64/libmobileffmpeg.so (Java_com_arthenica_mobileffmpeg_Config_nativeFFmpegExecute+412) (BuildId: b57e749e21d9106923ad74eb8a4b767e70a578d9)Ah, sorry about that!
This is the ffmpeg execute called before that:
await _flutterFFmpeg.execute('-i input.mp4 -codec:v libx264 -vf transpose=2 -s 480x720 -r 30 output.mp4');
Here is the full log of the execution.
I thought that the problem was not here because looking at the logs it seemed that the video gets processed successfully. As you mentioned that it happens during a cleanup, maybe it is when it tries to free memory? Thanks.
tanersener
commented
3 years ago Logs show that this issue happens when you run multiple commands at the same time. One ffmpeg execute and one getMediaInformation. Do you have the same crash when you are not doing that? When each command runs after the previous one is completed.
Gicminos
commented
3 years ago Yes, the situation seems better now!
I have then received a different memory error but I think that is not related with this package but with image_picker.
If you could allow me a couple of more days before closing the issue, I will test it more throughly to make sure that it is completely solved, and then close this myself.
Happy to provide any more details in case it could help somebody else. Thanks!
Gicminos
commented
3 years ago Hi, so far so good. Currently experiencing a different memory error but I believe it to not be related and currently being discussed in the issue #83090 on the main flutter repo.
Thanks for your help, I will close for now and re-open in case the error pops up again!
Description After doing various conversions, FFmpeg makes the Android application crash. The issue seems similar to https://github.com/tanersener/mobile-ffmpeg/issues/320 but it happens on the new FFmpeg version 4.4-dev-416
Expected behavior I expect the app not to crash or at least crash with an error that can be caught instead of generating a SIGABRT
Current behavior After a not defined number of operation, the app crashes fatally.
Logs
Environment
Any help is highly appreciated. Thanks.