On Wed, Apr 1, 2015 at 10:50 PM, Scott Palmer <swpal...@gmail.com> wrote:
> I seems like a decent compromise to defer to the native platform code that > will ultimately be used to process the file anyway. It seems a little > heavy, but the alternative is perhaps bloating the JavaFX API. > > Yes absolutely but ... (see my reply to David). > It likely makes more sense to use the MediaInfo project with some JNA > bindings (you can probably find either JNI or JNA bindings on the web) if > you need access to the metadata: > https://mediaarea.net/nn/MediaInfo > > Yes, also agreed for real general-purpose metadata retrieval like in a broadcast or media converter product, it does not make sense to kick off such a huge project in Java, when there is already native code around for that and we are doing that already in one of our products using JNI. I am talking about the super-simple cases where I am fine with the (very limited) format support of JavaFX and I just want to know duration, width and height basically for those files and I do not want to ship native libs with my cross-platform app which otherwise works well enough with pure Java. I just don't see any technical reason to instantiate a player for that in any native framework I know and it should not be necessary in JavaFX IMHO. Of course I can wrap all that in my own library and probably will and then the fact that a player is instantiated and then thrown away is just an implementation detail, I just did not and still do not see why this is necessary or sensible, which is why I asked. > I keep thinking a pure java port of MediaInfo would be cool... but > probably not worth the time :-) > > Yes, I agree and it's doable but A LOT of work (if you want to have the level of completeness and maturity of MediaInfo) and therefore not likely to happen anytime soon.
