Open j2bmw opened 3 years ago
LluisTrapeCasanovas
commented
3 years ago Hi i find a solution in my project, in your log said "libc Fatal signal 6 (SIGABRT)", you need add this line code before use ffmpeg.execute or in start the program: FFmpegConfig.IgnoreSignal(24); //24(Com.Arthenica.Mobileffmpeg.Signal.Sigxcpu) works in my project. you need find your singnal error and ignore it. i don't, know if the best solution, but work in debug mode
framinosona
commented
3 years ago Thank you @LluisTrapeCasanovas! @j2bmw let me know if it does solve the issue, if it does, I might look at that in detail and see if I can either incorporate that workaround inside the nuget OR handle that signal properly.
framinosona
commented
3 years ago Okay from what I read it seems like it's optional when your request reaches the soft limit of the CPU. That's why I don't get any error when calling information commands, they don't need much CPU. I don't think I should make it an automatic thing though. It's just one of those things you need to know when using tanersener 's mobile-ffmpeg I guess
j2bmw
commented
3 years ago @LluisTrapeCasanovas Thanks for your suggestion. I tried FFmpegConfig.IgnoreSignal(24). Now the app is no longer locked up in debugger because libc Fatal signal 6 (SIGABRT) is ignored. In the release build, it no longer crashes. This is good. However, there is a remaining issue like iOS app (see https://github.com/Laerdal/Laerdal.Xamarin.FFmpeg/issues/3): converted video cannot be played with the default media player on Android although the same file can be played on PC.
@framinosona, @LluisTrapeCasanovas I have been looking at what ffmpeg command line produces video more compatible across all Android and iOS devices, searching for a codec and resolution pair. It seems I have resolved the issue on Android.
This DLL's size is big (about 56 MB). I don't think we can do anything about it. This causes a side issue now that our app is big, more than 120 MB. Our app uses two video libraries including the one from our vendor. We will have two options: 1. ask our vendor to add the conversion in their SDK; 2. shrink the libraries.
Description Our app is to convert video files in a Xamarin forms project. On Android, FFmpeg.Execute() locks app on Visual Studio debugger and seems cause a crash after reopening a page. Note that:
Expected behavior There should be no lockup or crash inside or outside the debugger.
Current behavior
Screenshots No
Logs crash after converting to mp4.txt
Environment
Other Our app is to convert video files in a Xamarin forms project. On Android app, running ffmpeg command line locks the app on Visual Studio debugger. However, the conversion seems completed (at least a significant portion is done and can be played back) outside the debugger without locking the app. The bigger problem: after the conversion, the app crashes not long after. Please see the device log "crash after converting to mp4.txt" crash after converting to mp4.txt. It seems the conversion didn't complete and it triggered the following exception: 02-12 19:04:18.635 Google Pixel 3 Error 23366 libc Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 23470 (x.tecommobilev2), pid 23366 (x.tecommobilev2) 02-12 19:04:18.624 Google Pixel 3 Error 23366 libc FORTIFY: pthread_mutex_lock called on a destroyed mutex (0x77f6994c30)
It seems this crash is related to int rc = FFmpeg.Execute($"-i "{filename}" "{mp4File}"");
If I comment out this line, there is no crash. I haven't figured out the cause.
I tried the alternative using long rc = Laerdal.Xamarin.FFmpeg.Android.FFmpeg.ExecuteAsync($"-i "{_recordedVideoFileName}" "{mp4File}"", executeCallback);
The issue remains.