From time to time, when requesting an image, the native image encoder simply fails to send the final frame of image data.

The image data is fetched in chunks, this is repeated 1..n times by the native code invoking a callback with the image data. The return value of that callback signifies to the native encoder that it should send the next frame. Tracing the Java code shows that the callback is correctly invoked, and that the correct return value is being sent back to native code. Nevertheless, from time to time the native encoder simply seems to stall and will stop sending image data. It always seems to be the last chunk of data.

What this means in practical terms is that the Java application hangs while waiting for a native callback that will never occur. The JVM must then be terminated.

This is a show-stopper issue that precludes the use of this library.

There is similar strangeness, it may be unrelated, during native resource clean-up whereby native warning messages are intermittently dumped to stdout or stderr (e.g. freeing a resource that has already been freed).

This may point to there being a fundamental problem with the implementation of this library.

Having said that, the code for handling capture data from the native library has been implemented and debugged very carefully from the ground up on two entirely separate occasions. So either there is something wrong in native code that the JVM is exposing, or the exact same mistake has been made on two separate Java implementations.

Until the root cause of this issue can be identified, this library can not be used reliably.

Any hints from anyone and anywhere on what could be wrong here will be most welcome.