Good questions; here goes. On Sun, Jan 11, 2009 at 4:14 PM, Stas Oskin <[email protected]> wrote: > > 1) How much your JNI implementation is faster then JNA? AFAIK JNA creates > the binding on runtime, but then it's cached, meaning only the first > function calls would be slower.
Yup, that's the main way that JNA's slower, and it's not by much. The other reason we chose JNI was because (a) we wanted to be able to directly modify frame and audio data from Java without having to copy into byte[] arrays We do this through java.nio.ByteBuffer accesses using JNI 1.4 methods. (b) we wanted to be able to have the JVM collect and manage memory for us (and so Xuggler actually allocates frames and packets from Java, not the C++ heap). This also means that on a Java hprof dump, you can find the underlying java object that is causing you to hold on to objects by walking through the reference tree (which is invaluable for catching Java 'leaks'). That meant we needed reference-counting in C++ and proxy objects in Java that work closely together. We were concerned because writing JNI can be error prone, and so we use SWIG to generate the JNI for us to avoid mistakes. > 2) Do you test all the major functions for memleaks in your suite? We have all the major functions; and we continuously build with the memory check suite on every checkin. We use valgrind on linux and check for leaks, memory overrides and memory corruptions. See: http://build.xuggle.com/ for it in action (specifically the memcheck jobs, and look at the console output to see the tests running). By the way, this site is also the Red5 continuous build server (I'm also a core red5 developer). We also do some heft java-memory-leak checking on top of that. That said, since we do wrap FFMPEG and not expose the AVCodecContext (like fmj-java does) there are some elements we have not yet exposed (for example, some codec-specific configuration options used in encoding). We're open to adding them -- that's part of the reason we're releasing it so as to see what people want. > 3) What about multi-threading, is it stable and tested? FFMPEG only allows encoding and decoding to occur on one thread and we don't change that restriction, but we allow you to take any object decoded from FFMPEG and pass it to other threads for encoding. This is stable and tested. In fact, if you watch the demo video on http://www.xuggle.com/, that was recorded off a Red5 server running Xuggler that is reading raw packets broadcast from a flash player, and then decoding and modifying them in a separate thread for each stream that is broadcast. The main trick to multi-threading support that we found is management of memory across threads; hence every Xuggler object is reference-counted in our JNI library so that memory isn't freed out from under you while running. > > 4) How stable the beta is expected to be? Very. We've been using it internally for about 3-months and have had external folks testing in alpha for one month. Plus it was developed with a test-first-ask-questions-later development approach (hence the test suites you see on the build server). We think it's pretty stable -- although we're also expecting to uncover build issues as folks try OS combinations we haven't tested (we've tested Windows 32 Vista and XP, Ubuntu 8.4+ x86_64 and i386, and Fedora 8 and 9 i386, and Mac OS-X 10.5, under Java 1.5 and 1.6 in both 32 bit and 64 bit jvms). Again, you may want to join the google group we set up if you have follow on questions: http://groups.google.com/group/xuggler-users Hope that helps, - Art _______________________________________________ libav-user mailing list [email protected] https://lists.mplayerhq.hu/mailman/listinfo/libav-user
