I am using ffmpeg compiled for android and works pretty acceptable for now, however sometimes errors appear (based on some android phone configurations) and the app simply force closes with this message:
Fatal signal 11 (SIGSEGV) at 0x00000001 (code=1), thread 20745 (AsyncTask #2)
The ffmpeg call is inside a try/catch; however, it does not seem to care.
So, how can I prevent this force close and show the user a message?
I'm afraid I can't do that. See also this answer which hints at why.
When ffmpeg dies, it takes with it your entire program. This is just the way things are. When programming in Java, you don't have to think about programs crashing in that manner, but when ffmpeg, which is written i C, dies, it can take down your entire Java program.
try/catch does not help, because ffmpeg does not know or care about Java exceptions. Your only solution while staying within a Java program, is to either find the bug which makes ffmpeg die, or find what triggers the bug and call ffmpeg in such a way that it does not crash. As pointed out by Alex Cohn, another solution is to run ffmpeg in another process, so that it can not take down anything else but its own process.
You can run ffmpeg not as a library, but as a separate executable process. This may be significantly less efficient, but in such setup your process may survive ffmpeg crash.
You can also setup your app such that it has Activity and Service that run in separate processes, see e.g. How to create an Android Activity and Service that use separate processes.
This allows for some watchdog mechanism, and more. I cannot tell without careful testing if this way can deliver better performance than running ffmpeg executable, or worse.
Related
How can I know the flow if more than two threads are in use , as in case of any networking library like VOLLEY , ASYSNCTASK etc .?
You can see the sequence of threads by logging, but by definition you can't possibly know when exactly threads will execute since it's not deterministic. Who decides this is the kernel based on some internal rules and Android has some "layers" built on top of the Linux Kernel that allow you to somehow control the priority of your threads. What this means is: everytime you run your application the order of the methods inside threads will change.
I recommend you to watch this presentation where this is explained in detail: https://www.youtube.com/watch?v=xQoc1nSvvMw
There is one tool that can help you to debug threads: Dalvik Debug Monitor Server (DDMS) https://developer.android.com/studio/profile/ddms.html
Here is a post explaining how to use it https://www.toptal.com/android/android-ddms-ultimate-power-console
My app makes a JNI call in an AsyncTask. The activity would crash (or somehow be terminated) on Android 4.0, but is ok on later versions.
Eventually, I tracked it down to a possible stackoverflow(!) in the JNI. One of my routines put 4K on the C stack (not recursive). Once I took this out of the stack, everything worked.
My question is, how much can generally be assumed, can it be configured or changed and does anyone know the reliable limits for various API versions.
My theory is that additional threads like AsyncTask are given a lot less than the main UI thread, which is why this doesn't often bite.
thanks for any info.
This question is related to android system.
Dalvik VM uses JIT concept, it means that when you first run application Dalvik VM compiles it and loads into RAM as long as it could stay there. I understand that concept. But new virtual machine called ART, uses AOT method. ART compiles app after you install it(or when you are installing it?). What this means ? Apps compiled by ART are the same as already compiled apps(like C apps) but run in a separate processes separated from the rest of OS ?
Can somebody explains me this concepts more thoroughly. I have to make some presentation, and this is mentioning there, but I don't understand this concept and I don't want to look dumb if somebody asks me something about that :)
Sorry for bad English, it would be nice if somebody could edit question a bit.
I am not completely familier how Dalvik JIT on Android works in practice, because JIT have several options how can work.
First option is, that JIT translate all bytecode into CPU instructions on application launch. This option spent some time before application launches and after that application can run as native. Problem is, that translated application has to kept in memory during launch, which is not good.
Second option is, that JIT works as real Just-In-Time, which means that translate block of code when is about to launch. Whole application is not translated on launch, but only main function is translated on launch and then is translated during run, when certain block of code (function etc.) is used. This option consumes less memory, but application is much slower during run.
According to informations I found, Android uses first option. Application is translated on launch and after that it runs "almost" natively. And this "almost" makes main difference between JIT and AOT.
When you are about to launch some application, JIT have only limited time to compile all bytecode to CPU instructions to make launch-lag "acceptable" long. This means, it can perform only basic optimizations. However, when you install some application, you have usually more time to waste and you are doing it only once - not on every launch. This means that AOT compiler has much more time to find tricks how to optimize that application. Resulted code should be more "efficient". Second benefit is, that compiled application is stored to cache and only part of it can be loaded to memory on launch. That means that OS hadn't keep whole code in memory and can save it. And that is main differences.
And last part of your question - ART on Android will perform compilation on installation (after saving apk to /data/app/). However, if you wipe that cache, or switch from Dalvik to ART, it will compile all installed application on first boot, which can take 10 or even more minutes.
And sorry for my bad english too, I am Czech :-)
Ahead Of Time(AOT) - Android Runtime(ART) - generates machine byte code during installation.
[JIT vs AOT]
I am using ffmpeg to decode a file and play it back on an android device. I have this working and would now like to decode two streams at the same time. I have read some comments regarding needing to use av_lockmgr_register() call with ffmpeg, unfortunately I am not sure how to use these and how the flow would work when using these locks.
Currently I have seperate threads on the java side making requests through JNI to native code that is communicating with ffmpeg.
Do the threads need to be on the native(NDK) side, or can I manage them on the java side? And do I need to do any locking, and if so how does that work with ffmpeg?
***UPDATE
I have this working now, it appears that setting up the threads at the java sdk level transfers into separate threads at the native level. With that I was able to create a struct with my variables, and then pass a variable to the native layer to specify what struct to use for each video. So for I have needed to use any mutexs or locks at the native level, and haven't had any issues.
Does anyone know of potential gotchas I may encounter by not doing so with ffmpeg?
I'll answer this, my latest update approach appears to be working. By controlling the threads from the java layer and making my native calls on separate threads everything is working and I have not encountered any issues.
What is happening under the hood? somehow this is passed down to the OS, and someshow the OS will find the right activity / activities, and launch it? Is there a service / lib running in Android handling this? I am trying to modified the OS to override the logic of startActivity across the board, is this possible?
Thanks.
I would take a look at the Android source! Whenever I'm developing and I run into an issue I read through the source to discover what is happening under the hood; it's quite interesting! It's an insight into what's actually going on, and also very good guidelines for documentation and code formatting!
http://source.android.com/source/downloading.html
A good starting point might be ActivityManagerService
Basically, when an app is first launched, startProcessLocked() in ActivityManagerService creates a new ProcessRecord (if necessary) and then calls Process.start(), which in turns builds the arguments for zygote and sends to zygote's socket using zygoteSendArgsAndGetResult(). Of course there's more to it than that, for example if an app shares a uid, is isolated, etc. But that gives you the basic process.
Looking over the source is indeed a good way to understand what's going on. However, unless you're planning on modifying it, don't bother downloading AOSP, just use GrepCode. Easier to browse, search and everything is hyperlinked so it's easy to follow through to classes, find usages, derived methods, etc. If you download AOSP, you'll be stuck with grep, ack-grep if you're lucky and a text editor. Also, you'll only have the one version you picked to checkout. GrepCode has the code for almost every version since 1.5.
The linked text above will take you to the relevant source at GrepCode. Try it out! The only downside is that GrepCode doesn't include the native C++ layer.