I'm trying to call ffmpeg.c to trim a video based on this code 'video-trimmer'. So when I try to run the activity (that loads and uses the native lib) the first time I click trin it works and I could trim the video but when I try to run it again it crashes (and it only work with the application restarts).
So I spend three days looking for a solution for this issue, most of the answers says the issue with the static variables in ffmpeg.c and creating a lib that loads and unload the class fixes the issue (answer1, answer2). So I tried to apply the solution that is based on the answers and this github repo on the video-trimmer project but all my attempts failed.
Is there any one knows about a fork of the 'video-trimmer' project that fixes the issue?. or can anybody provide step by step answer of how to implement the solution in the 'video-trimmer' project (because I tried to follow all the solution on the web and apply them in that project but with no luck).
the problem seems to be with the initialized values (some variables are declared as global static vars, presumably for ease of access but breaks OOP principles and causes us problems like you're facing), however, there are a few ways round this that I can think of:
write a quick function to manually set the static vars back to their correct init values (quick and dirty but works). A list of methods which should not be allowed to fire off as and when they please follows:
avcodec_register_all(), avdevice_register_all(), av_register_all()
avcodec_find_encoder(), avcodec_find_decoder(), av_find_stream_info()
avcodec_open(), avcodec_close()
these could be wrapped in a boolean controlled method for example so that if they have run previously they cannot run again.
another way to control things is to manually force the variable values (by use of a class or struct to control the ffmpeg global vars) that are being re-initialised on subsequent runs, for example on running the method which currently causes the code to fail, the first step could be to manually set the variables back to their default settings so that they run correctly as at the moment I suspect you have data remaining resident between iterations, and thats what is causing problems.
you could utilse mutexes to ensure that the aforementioned methods behave more responsibly when used with threads.
Addendum:
also (at the C level) use libffmpeginvoke in preference to libffmpeg if you are going to invoke main() multiple times
forcibly invoke Garbage Collection (yep this is another 'ugly' fix) on the call to load the ffmpeg lib, which would then clean things up allowing you to call another instance
Let me know if you need something more in-depth: I can try making a test framework to replicate your problems and see where I get, although that needs access to my home PC as when I am at work I have no Android SDK.
Help us help you, please provide your implemented code or a part of it. Also Crash Log will be helpful.
Hint: Initialise ffmpeg object/thread.
Then use a call back interface. Once the VideoTrimmer gets over, give a callback.
In that callback call the destroy/kill of the ffmpeg object/thread.
May be this link can help you.
I have recently used the "android-ffmpeg-java" project from github, this is a working library, I can guarantee. You just have to implement a wrapper (test application) which will do the work.
Check this link for Source : android-ffmpeg-java
Check this link for example : android-ffmpeg-cmdline. See if you can solve on with this.
I am not sure if this will help, but C files typically have a header where you can use
ifndef
Please see the following:
http://www.cprogramming.com/reference/preprocessor/ifndef.html
Use that syntax to sandwhich the declaration in the associated .h file to ensure multiple imports don't cause a crash in the importing code.
Good Luck!
Edit: Ok, looks like that would mean recompiling ffmpeg to the .so file. You should just try to verify that it has a mechanism as described above in the codebase and try to confirm it isn't somehow being loaded twice.
While somewhat crude, a potential workaround could be to utilize/link to ffmpeg from a Service (you had better be doing that anyway) which is declared in the manifest to run in its own process rather than that of client Activities. Then have that process terminate itself - calling native exit() if needed - when the task is completely finished. Android won't particularly like that happening - it's not good practice - but you can probably make it work.
Re-engineering the library to be able to reset itself to a fresh state (or even make it entirely contextual) would be better, but for a huge legacy codebase may prove to be a large project.
Related
I have to estimate the time it takes to update a specific application made for Android 4.4 to Android 10 and I need to see all the methods that are deprecated or not working. Is there any way to see the methods without going file by file? (I'm using Android Studio with Java)
When I build the application I only get one or two types of error at a time, when I correct them I get another one and so on.
Thanks and best regards.
P.S: How long does it take you to update something like that? I'm a junior and I'm a little lost doing this.
Here, go to Analyze -> Inspect code. After inspecting check maturity there you will have depreciated methods. (Don't forget to change minSdk)
After you will do that it give you method with a warning and you can filter it by having API not support warning
I'm trying to keep track of the entire app flow so I figured using the Loggable annotation on every single method in my code would do the job.
My issue is that I can't seem to understand how to setup form scratch the Loggable option, including(to my limited understanding of it):
Importing all dependencies with gradle
Configuring the log4j properties , from inside the code or from a file
Using a PackageInfo class to log all methods in my project
A while ago I played around with Gradle and Android SDK in connection with AspectJ in order to help another user. Maybe you want to check this answer.
P.S.: Your question is very general, so my answer is too. This is StackOverflow, please show some code and/or configuration. Give the community a concrete problem to solve and make your own problem reproducible, ideally via an SSCCE.
I'm new to android development.
I download a toy project and want to figure out the flow of this project.
Can I use debugging to figure out it and how?
Let me explain it more detail. Every android project starts from an "main" activity. I guess I find the "main" activity for the project and set a breakpoint at the onCreate method of this "main" activity. I expect to run this project from that breakpoint one step by step to figure out the flow. However it doesn't work since the debugging stop after finishing the onCreate method.
Start with AndroidManifest.xml file. Open it and look for an Activity with LAUNCHER category. Then open that Activity and go to onCreate(...) method. This is where your app starts. Inside the method, there is a call to setContentView(R.layout.some_layout). some_layout.xml in res/layout folder is UI for this Activity.
Each window you see in Android app is an Activity and each Activity has a layout file.
The "flow" of an android application is more like an asynchronous model than a sequential flow of action. There is a main application loop that processes external events (such as clicks on button) and callbacks related to the activity lifecycle (such as your onCreate method), and lot of other stuff.
Every event is put into the queue and processed asynchronously, so it's not easy to follow it. It's better to think about actions and reactions. In any case you can dig into the android source code and see what's running behind the scenes. Some hints about the model of android apps can be found here but any google search for "android ui thread queue" would lead to relevant info.
If you want to learn the flow of a typical android application, I would recommend you download the samples if you haven't already and add your own log statements. You could use the debugger too. Then start making small changes here and there to force different 'flows' of control, as you make guesses about what should happen and observe your logging statements and the app behavior to see what's going on.
The sample projects can be downloaded from the adt plugin in eclipse and come as ready-made projects. They are also a good way to learn because they are generally the 'best-practice' way of doing things.
Hope that helps! Good luck :)
I understand there is the LogCat view to check the messages logged but I can't make sense of it.
When debugging (I use Java primarily) I've been accustomed to stepping over each line of code and finding out the exact point where the program crashes and then doing something about it.
How can I do this with Android development? Is there a way to precisely locate the line which is causing the application to crash?
I can't understand what to make of/how to read the LogCat messages and when I try to step over (using the F9 key or the 'Debug' option in Eclipse) it keeps opening new tabs for inbuilt classfiles (like Instrumentation.class etc) and after pressing F6 a few times over again the app crashes showing 'The application has stopped unexpectedly. Please try again'
Can someone tell me if there's something to be done in a way that I'm not doing here?
Thanks!
Btw if it helps, here's the generated log:
http://pastebin.com/EaqaWUdS
You are using a resource id that doesn't exist at line : 93 of com.site.custom.ModAdapter.getView(CustomListProjectActivity.java
--EDIT : add explanations
You will read a logcat stack trace in the same way as you did in Java : read bottom up and the culprit is the last line of your classes (before the code gets into the android sdk code).
You can do it the other way around, and start from top, stopping at the first class of yours and discarding android classes.
The same reasoning applies when debugging : step into your methods if needed and step over all methods of the SDK unless you want to debug them (and usually you don't, if you really suspect a bug inside the SDK, check the source at grepcode to see the inner mechanics of the android sdk class you are interested in).
Sometimes it gets difficult to track bugs on android, especially for widget layout related bugs because you can only see the code that is executed by the android platform, no code of your is executed, only your data are read from an xml file for instance. If something breaks here, it can be harder to debug. In that case, apply the dichotomy method : remove half line, if the bug doesn't show up, then readd your lines, remove half of them, etc...
It is the same like in java. Basically you need the sources to open the java files instead the class files. Google shows you how to add the sources.
Basically you debug android while staying in your own classes. I barely look into the android classes as the most issues are, of course, located in my own classes.
So just debug like you already do but don't step into methods/classes you don't own unless you have the sources added to your sdk. Even if you have, there might be some classes that aren't open source, so you can't step into the sources there. (Basically all Google API classes)
I've got an android project that I started from an old standard Java project, so because of the vast difference in target platform, I have a lot of dead code to cleanup.
I've seen UCDetector recommended for finding unused public methods in java projects in Eclipse. I installed it as directed, and it just doesn't show up on the menu, and I have no idea how to get it to work.
Has anyone got this combo to work, or have another recommendation? Or know how to get it to show up?
(I've tried Find Bugs which found some good stuff, but it doesn't find unused public code.)
Big warning!
It might partially work, but beware, cause it doesn't seem to know about XML-defined callback functions.
If you have installed a callback function on a widget, say a button in an XML Style Sheet, and it is not called in code, UCdetector will think it has 0 references, and suggest it deleted. This obviously is wrong, and will render your code uncompilable.
There might be other similar issues, related to Android specifics.
Viggo
Yes, UCDetector works for android projects. I just installed it and it works.
It's available in context menu of project in Package Explorer.