Scott Palmer swpalmer at
Sun May 19 16:36:59 UTC 2019

It’s been 11 years… <>

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.  



> On May 14, 2019, at 8:27 PM, Curtis Ruck <curtis.ruck at> wrote:
> Gstreamer-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.rushforth at <mailto:kevin.rushforth at>>
> 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
>> 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.rushforth at>
>> 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, 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

More information about the openjfx-dev mailing list