2.0 discussion

[wlfgang]

We are starting work on jmisb 2.0 and would like your input! Please respond to this discussion of you have thoughts about what should be included.

Here is a draft list of the most likely changes:

• Move to Java 11.
• Split dependencies on FFmpeg into a separate jar. The primary API, jmisb-api, will be made independent of the video I/O implementation. This should make way for a gstreamer-based implementation.
• To support Android, remove use of packages not available in Android SDK, such as java.awt.image and javax.imageio.
• Add support for georeferencing using elevation models.
• Removal of any deprecated methods/classes.

This will include some breaking changes, necessitating the major version increment. We'll strive to get such changes done and out of the way before releasing 2.0 to ensure a long-lived and stable version 2.x!

[bradh]

Thanks for the work on this.

Does the Java 11 work including module-info activities? Or allowing Java-11 features into the code base (i.e. JDK 8 wouldn't be supported any more)?

[bradh]

It'd be good to have a concept for how we separate out the ffmpeg vs gstreamer (vs jcodec, or whatever) and the image formats (AWT, JavaFX, Android) support. There is an unfortunate coupling between them (because we want to turn AVFrame into each image format, and the same on gstreamer, et al) that I don't yet have a solution for. Normally there would be an abstraction in there, but performance might be an issue.

[wlfgang]

Exactly. There doesn't seem to be a good cross-platform image container class. I was playing around with making VideoFrame into one, but it's a little hairy. Would need to support efficient conversion to both java.awt.image.BufferedImage and android.graphics.Bitmap.

[bradh]

Possibly we could break up the "api" module (which is more like a "klv" module) into a set of smaller modules with some dependencies. I don't think one-per-directory feels quite right, but perhaps a klv-core with some of the key parsing functionality, along with an SPI loader, then everything else could just be plugins from the classpath.

Possibly there could be a klv-all maven artefact that brings in everything we have for people who don't want to be more specific.

The advantages would be that individual modules would be faster to build during development (especially without MIMD and ST 0601 / 0903, which is the bulk of the tests), and a bit smaller if you don't want it all. It would also focus modularity. The disadvantages would be more modules to manage, and possibly slightly slower startup for the SPI overhead.

[wlfgang]

Happy New Year!

As a quick update, I just performed the release of 1.11.0, so it should soon hit Central Repository.

My intention is that no additional features should go into 1.x, barring a critical need of some kind. We can keep patching 1.11.x for security and bug fixes.

@bradh, one thing I thought we might do is make main the default branch for a while (so that's where you first land when you find it on GitHub). The develop branch can then move over to 2.0.0-SNAPSHOT and replace the current 2.x branch. Probably not a huge deal but I wanted to run it by you.

[bradh]

@wlfgang Thanks for the 1.11.0 release.

I'm good with the branch switching - it basically matches what I've been working in any case.

[lannybroo]

I like the idea of separating the dependencies for FFmpeg to a separate jar. My jmisb use case so far is about creating a serialized MISB 0601 data stream, not reading one, so I really only need the org.jmisb.api.klv.st0601 api. What I ended up doing was building the whole thing and then thinning out the rawklv-1.12.0-jar-with-dependencies.jar to remove all of the ffmpeg content manually, taking the jar from 210 MB to 1.9 MB.

Another idea (for 1.x or 2.0) would be adding a clean example or two showing how to generate a MISB binary file or a FMV (KLV/MISB + video) file. The current Generator example is close-ish to this but seems more focused on internal testing than on end-user trying to use jmisb as a way of producing compliant FMV.

[bradh]

We do have this separation done for 2.0, see https://github.com/WestRidgeSystems/jmisb/tree/2.x

I see

-rw-rw-r--  1 bradh bradh 174K Jan 17 15:53 st0601-2.0.0-SNAPSHOT.jar

Note that because ST 0601 brings in quite a lot of other stuff (in particular, ST 0903), it isn't quite that lightweight in terms of total impact, but it at least provides options.

[bradh]

@lannybroo I'd like to understand the example need better though. The examples are used for testing (because we need files to throw at validation tools), but they are meant to be end-user oriented. I can see that I might have overloaded the generator case though.

Would it be easier if we split the current examples into leans-towards-test vs leans-towards-demo?

Can you describe what you'd like to see? Is it reading from an external source?

Or can you contribute the example? Happy to work with you on cleaning it up or answering questions if that would help.

[lannybroo]

Coming back to this a year later having a bit more experience with MISB, the Generator example is more understandable. I think what was hard as a beginner was sorting out all of the MISB jargon at the same time as understanding the jMISB api. I do still like the idea of some examples that are directly targeted at beginners just getting started. Maybe minimal tutorial-like example with heavy "why" comments as follows:

1. Reading MISB KLV data from a FMV .ts file
2. Writing MISB KLV data to a .klv binary file (focused on the v2.0 non-video API to simplify)
3. Writing multiplexed video + MISB KLV data to a FMV .ts file (again with the v2.0 API)

I would be happy to help develop these examples and corresponding documentation, of course with your guidance and assistance as needed.

[lannybroo]

Is there a targeted release date for jMISB 2.0? I see that most of the development has been on the 2.x branch for a while.