Android support

[boblak2]

Describe the bug
I am having problem compailing your code on Android. I get exception:
java.lang.ClassNotFoundException: Didn't find class "java.awt.image.BufferedImage".

The problem is that BufferedImage is a part of java SDK and not part of Android SDK, that is why I can not run my code on Android.

To Reproduce
Steps to reproduce the behavior:

1. Import jmisb with gradle
2. Add android permission to your manifest file (INTERNET and READ_EXTERNAL_STORAGE)
3. Use code from your example (ExampleProcessor, and the main code):

ExampleProcessor exampleProcessor = new ExampleProcessor();
IVideoFileInput stream = VideoSystem.createInputFile();
try {
stream.open(getFilePath());
stream.addFrameListener(exampleProcessor);
stream.addMetadataListener(exampleProcessor);
}catch (Exception e){
e.printStackTrace();
}

Expected behavior
Application crashes and I get an error:
java.lang.NoClassDefFoundError: Failed resolution of: Ljava/awt/image/BufferedImage;
at org.jmisb.core.video.FrameConverter.convert(FrameConverter.java:44)
at org.jmisb.api.video.VideoDecodeThread.run(VideoDecodeThread.java:198)
Caused by: java.lang.ClassNotFoundException: Didn't find class "java.awt.image.BufferedImage" on path: DexPathList[[zip file "/data/app/si.blazdev.jmisbtest-r81oRJZ9eZWhKl6GTDxHIg==/base.apk"],nativeLibraryDirectories=[/data/app/si.blazdev.jmisbtest-r81oRJZ9eZWhKl6GTDxHIg==/lib/arm, /data/app/si.blazdev.jmisbtest-r81oRJZ9eZWhKl6GTDxHIg==/base.apk!/lib/armeabi-v7a, /system/lib, /system/vendor/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:134)

Configuration (please complete the following information):

• OS: Android 9, Galaxy Tab Active 2, targetSdkVersion 30, compileSdkVersion 30
• jMISB version or commit: I installed it with gradle: compile group: 'org.jmisb', name: 'jmisb-api', version: '1.9.0'

[wlfgang]

@boblak2 - Currently Android is unsupported (one reason, like you said, is the dependence on BufferedImage for video I/O). There have been suggestions that we could factor that out, but no one has had the time to work on it yet. Do you need video support, or are you just looking to encode/decode metadata?

[boblak2]

I also need video support becase I have to show video stream to the users while simultaneously show them the data (KLV data) from the stream. I am opened to any suggestions.

[wlfgang]

The underlying ffmpeg implementation we use (from https://github.com/bytedeco/javacpp-presets) does run on Android, so I think there is reason to believe we can support it too. One pretty big issue up front is that our VideoFrame class uses a BufferedImage to represent the uncompressed image.

Do have time to help out with this, or know anyone who might? I can assist but my Android experience is pretty limited.

[bradh]

@boblak2 I see the problem, but I don't know what success (to you) looks like. Can you describe how you would like to get the data? Clearly BufferedImage isn't going to work, but what would?

@wlfgang The BufferedImage is exposed as public API (all the way down to FrameConverter in core), so this looks like a breaking change.

[boblak2]

Hi @wlfgang sorry for delay, I am facing a strict deadline, and don't have any free time. Anyway I am a Android develeper but I don't have much experiance in JNI/native develpment so I doubt I can help You. For my company I need to develep a player (for Android) which can show video using RTSP protocol, menwhile I also need to extract KLV data from the stream and show the data on the screen. The KLV data is in MISB standard.
In my search I also found a JavaCV https://github.com/bytedeco/javacv where they manage to convert object "Frame" in to Android Bitmap (using AndroidFrameConverter) which is simular what you need, but the thing is a bit slow on the Android.

[wlfgang]

Thanks guys. One idea would be to move what is currently in org.jmisb.api.video into its own separate library which would stick to using BufferedImage and create a new Android-specific library. Even if we never get a working Android port, this would have the advantage of fewer dependencies in the "main" API, e.g., for those doing their own video encode/decode. Like @bradh said, this would be a breaking change, although hopefully just an update of client POM/gradle files.

@boblak2 thank you for the pointer. I did notice in AndroidFrameConverter they describe how it could be optimized. I wonder if android.graphics.Bitmap is the preferred choice for working with video? I also noticed some stuff in android.media that looked potentially useful.

[boblak2]

@wlfgang Yes you are right, android.graphics.Bitmap is NOT a good choice for the video the result is very "chopy".