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 <mailto: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
