GStreamer

[Scott Palmer]

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.ruck at 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.rushforth at oracle.com <mailto:kevin.rushforth at 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.rushforth at 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