It’s been 11 years… https://bugs.openjdk.java.net/browse/JDK-8091063 <https://bugs.openjdk.java.net/browse/JDK-8091063>
The gstreamer integration should have been a pluggable module into the media framework from the beginning. I would love to see that corrected. Refactoring towards a more usable media framework that has the necessary hooks to make it more than a very basic player with limited codec support gets a big plus one from me. I only wish I had the time to help more with actual code. Regards, Scott > On May 14, 2019, at 8:27 PM, Curtis Ruck <curtis.r...@gmail.com> wrote: > > Gstreamer-javafx examples: > https://github.com/gstreamer-java/gst1-javafx-examples > <https://github.com/gstreamer-java/gst1-javafx-examples> > > I admire how javafx is wrapping gstreamer compared to the above example. > I'd like to expand the support for more Media types and some method to > access alternative stream data like closed captioning. I don't want to > reinvent the wheel, I just prefer javafx as a modern, portable framework > over alternatives. Java has always had poor compatibility with media > frameworks in the past, > > I look at the ideal way for me to accomplish my goals above as easily as > possible (if I we're King for a little bit) would be to create a bolt-on > javafx-media-extras library that pulled in additional gstreamer plugins. I > definitely don't want to break downstream interfaces or expose additional > non-public APIs, I just want graceful API expansion that allows javafx to > compete against just about every other UI toolkit. > > On Tue, May 14, 2019, 20:14 Kevin Rushforth <kevin.rushfo...@oracle.com > <mailto:kevin.rushfo...@oracle.com>> > wrote: > >> When you say "gstreamer-javafx" I don't know quite what you mean. The >> gstreamer-lite library is an internal component of JavaFX and it not >> something meant to be used by itself. Refactoring the native code in the >> javafx.media module just so it could be used independently from JavaFX >> doesn't seem like something that would benefit JavaFX or make it easier to >> maintain. Rather it could create defacto interfaces that could easily break >> when we upgrade gstreamer (which we do from time to time to keep up with >> bug fixes, etc). It's the same reason we don't support accessing Prism or >> Glass directly. >> >> -- Kevin >> >> >> On 5/14/2019 5:04 PM, Curtis Ruck wrote: >> >> Why is splitting gstreamer-lite out not on the table, curiosity? >> >> It feels a little silly to end up with two gstreamer libraries getting >> used by a single application. The gstreamer-javafx examples are horrible >> compared to the existing javafx-media API. >> >> >> >> On Tue, May 14, 2019, 19:55 Kevin Rushforth <kevin.rushfo...@oracle.com> >> wrote: >> >>> We don't currently plan to add support for pluggable codecs, but that >>> might be something that the community could do, although it would be a >>> large effort. As for splitting gstreamer-lite out of javafx.media, we >>> are not likely to consider that. >>> >>> -- Kevin >>> >>> >>> On 5/13/2019 11:30 AM, Curtis Ruck wrote: >>>> I'm investigating a new application that would need tighter integration >>>> with gstreamer. Is there a way to add additional gstreamer plugins and >>>> media types without having to maintain a fork of javafx-media? >>>> >>>> Ideally, if i did end up needing a fork, i was thinking it would make >>> sense >>>> to split gstreamer-lite out of javafx-media into it's own project so I >>>> could easily swap in a full gstreamer dependency with 3rd project for >>> the >>>> additional media types. >>>> >>>> Background: ideally looking to pull in udpsource and some additional >>>> pipeline plugins (GPU decoding and some subtitle related plugins). >>>> >>>> Thoughts? >>>> >>>> -- >>>> Curtis Ruck
