Hi Michael,
On 24.03.2014 4:31, Michael Berry wrote:
Hi all,
I'm now a bit further along with this, though struggling to get the
matroska plugin to compile (getting a bunch of unresolved external symbol
errors for functions it uses in glib - not entirely sure why at the moment,
as I said C is not my strong point.) I've also noticed the plugins
currently bundled have quite a few changes to the gstreamer version, and I
can't quite work out the logic behind why things have been changed the way
they have - so even after the compilation issue is resolved I'm now less
confident that it will just drop in and work! Again, if someone
knowledgeable in this area that's lurking in the shadows could shed any
light on any of this, it would be hugely appreciated.
However, putting the current problems aside for a bit, the snags I hit up
until this point could I think be relatively easily addressed in the
documentation. With that in mind could I suggest a few additional points
for the wiki? These may be obvious to the majority reading here, but as
someone completely new to building JFX they had me stumped for a while!
- It turns out that the Gstreamer stuff doesn't compile at all by default,
which is why I wasn't seeing any changes on the native level. To ensure
GStreamer is actually compiled, you need to copy the
gradle.properties.template file to gradle.properties, and uncomment the
"#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist for
any webkit alterations as per the line above.)
You may just add -PCOMPILE_MEDIA=true as a gradle argument.
You may also want to add -PCONF=DebugNative to build debug version (in
case if you didn't find that option yet)
Regards,
Anton.
- As well as the requirements listed, I needed the Windows SDK (
http://www.microsoft.com/en-gb/download/details.aspx?id=8279) installed for
GStreamer to compile successfully under Windows (7) - without it cygpath
just threw a rather confusing error.
- The DirectX SDK failed to install for me, Googling found the fix
relatively easily (
http://stackoverflow.com/questions/4102259/directx-sdk-june-2010-installation-problems-error-code-s1023),
but perhaps this could be included just for reference.
- The developer workflow page (
https://wiki.openjdk.java.net/display/OpenJFX/Developer+Work+Flow) refers
to "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs" instead?
I'm happy to make the above changes myself but unsure of if / where you can
sign up for an account, so I'm just throwing them here for now - if anyone
could point me to the right place then that'd be great!
If I do ever manage to get this working (ha-ha) I'd also like to throw up a
wiki page just detailing how to grab a gstreamer plugin and make the
necessary changes to it to compile it into openjfx as a stop gap to then
perhaps working on one or both of the above JIRA issues and seeing where I
get - does this sound reasonable?
Many thanks,
Michael
On 23 March 2014 15:32, Michael Berry <berry...@gmail.com> wrote:
Hi Scott,
Sure, that's in fact my eventual goal - but in order to successfully get
that far I need to work out how to compile OpenJFX with other GStreamer
plugins first, and unfortunately at the moment I seem to be getting stuck
at that hurdle!
Time permitting, I do indeed plan to look at addressing 2684 if I can get
that far.
Thanks,
Michael
On 23 March 2014 14:03, Scott Palmer <swpal...@gmail.com> wrote:
I applaud your effort, but please consider while you are doing this:
Addressing RT-18009 is good
Addressing RT-2684 is way better.
https://javafx-jira.kenai.com/browse/RT-2684
If there is a mechanism to write a stub plugin that hooks into the
GStreamer plugin mechanism such that end users of JavaFX can write a module
(in Java, with the option of using JNI) that supplies the uncompressed
frames via a NativeByteBuffer, that would be a great start.
Scott
On Mar 22, 2014, at 9:26 PM, Michael Berry <berry...@gmail.com> wrote:
Hi all,
I've managed to clone and build OpenJFX successfully, and am now in the
process of trying to see how feasible it would be to add support for
other
media formats. As a first port of call I'm attempting to see if I can
get
the framework accepting the Matroska plugin, but seem to be coming a bit
unstuck on the native side of things (including the plugin with
GStreamer.)
I've made the relevant modifications on the Java side of things to
persuade
the platform to accept MKV files and pass them down to the GStreamer
layer,
and that compiles and runs without any issues.
However, I'm not sure if I'm going about including the matroska plugin
in
the right way - I've currently done the following:
- Downloaded the latest version of the plugins from here (
http://gstreamer.freedesktop.org/src/gst-plugins-good/), then added the
matroska one to the modules/media/src/main/native/gstreamer/plugins/
folder, as well as the
modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/
folder (I'm unsure of this - should I add it to both these folders?).
- Added all the C files from the first folder mentioned above to the
plugins.vcxproj file
- Added the relevant files and directory to Makefile.gstplugins
- Called the additional relevant plugin_init() function in
gstplugins-lite.c
However, after the above I still get the same result having touched
none of
the native code, that being that GSTMediaPlayer throws a MediaException
with flag 257, which seems to mean it couldn't create the required media
from the given location.
So at this point I'm a bit stuck really - of course, the whole task may
be
much more complicated than I'm assuming it should be. I'm not even sure
if
the default "gradle sdk" task is actually reflecting the changes I've
made
- certainly gstreamer-lite.dll seems to be exactly the same size as
before,
though I'm unsure if the additional plugin is meant to be embedded in
this
file or not. I'm experienced with Java but much less so with C++, and
completely new to gradle (as of yesterday.)
Is there anything obvious I'm not doing correctly, and if so would
someone
be kind enough to give me a bit of a nudge in the right direction?
Many thanks,
Michael
--
Thanks,
Michael
