Typically in this case you would email the patch to the assigned developer, but it appears RT-18009 is unassigned at present. I think that is the first hurdle that needs to be resolved, but if you email me your patch I will attach it to the jira issue so that it is at least available for others.

Thanks!

-- Jonathan

On 26/03/2014 12:39 p.m., Michael Berry wrote:
Hi all,

Turns out it was a stupid mistake on my part causing the last few linking
errors, I hadn't added one of the C files I needed to the makefile (well I
had, but I'd then reverted it again without realising!) Thanks to all for
the prods and advice.

Once I'd done that, the build went through without a hitch - and then it
was just a case of making the relevant additions to the native code to
register the MKV type and create a pipeline from it using the plugin. This
wasn't hard to work out at all; I've since tried several test files in MKV
format (with AAC audio) all of which play in MediaPlayer without a hitch!

I mainly wanted to do this as a personal exercise, though I'd imagine this
is a useful piece of functionality for many others also - so should I
submit a patch of the changes, or is this unlikely to be accepted? (Again,
sorry for the perhaps obvious question, I'm rather new to this.) I've had a
look at the code review process and it seems to suggest adding a patch to
the relevant JIRA issue for those who don't have commit access (in this
case 18009), but I don't seem to have permission to do that either?

Thanks,

Michael


On 25 March 2014 17:01, Stephen F Northover <steve.x.northo...@oracle.com>wrote:

On 2014-03-25 7:00 AM, Kirill Kirichenko wrote:

Hi Michael.
See my comments inline.

On 24.03.2014 04:31, Michael Berry wrote:

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.

We did some changes in existing GStreamer code because it had errors and
because we needed to expand some functionality. The changes are not very
extensive.

  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!

I can give you some directions. There is no wiki. I'd appreciate if you
created one.

    - 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 don't need to comment/uncomment anything. Just add
-PCOMPILE_MEDIA=true to the gradle command line. You can however change the
properties file too.

    - 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.

You need windows 7.1a SDK and speaking precisely you need only samples
from it because samples have BaseClasses at 
Samples/multimedia/directshow/baseclasses.
BaseClasses are used for Oracle direchshowwrapper plugin.

    - 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?

What are you gonna use it for ?

I updated the page and got rid of the BINARY_STUB reference that is no
longer needed.


  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!

Steve. Can you give an advice ?

If you are looking to contribute (when you get to a good place), the
process is well known and is followed by the everyone.

     https://wiki.openjdk.java.net/display/OpenJFX/Code+Reviews


  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?

Only committers can edit the wiki right now.  It is possible to become an
Author and write to the wiki, but I would be happy to publish your recipe
when you are happy with it.


  It does.

  On Mar 22, 2014, at 9:26 PM, Michael Berry <berry...@gmail.com> wrote:
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?).

Well you see. If you download the latest matroska plugin it
potentially can have dependencies on the latest GStreamer platform. We
don't have/use the latest gstreamer. The version we use is 0.10.35. And the
latest available is 1.x. They are incompatible in some methods.

  - 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

There is one more thing you need to do here for Windows only apart
from running gradle with -PCOMPILE_MEDIA=true. Windows build system has
files that export symbols
1) from glib-lite.dll ${jfxroot}/rt/modules/media/
src/main/native/gstreamer/3rd_party/glib/glib-2.28.8/build/
win32/vs100/{glib-lite.def|glib-liteD.def}
Here the version with "D" is used for debug build and may contain more
symbols for export.
2) from gstreamer-lite.dll ${jfxroot}/rt/modules/media/
src/main/native/gstreamer/projects/win/gstreamer-lite.def - used for
both Release and Debug.

If your plugin uses some methods of gstreamer/glib libraries not
mentioned in the files you should add the methods to the files. Syntax is
pretty simple. If you don't add depending methods to these files you will
get linker errors. C/C++ compiler will not generate errors.

Actually I think the best way to start developing/improving the Media
component is to upgrade GStreamer to 1.x from 0.10.35. It would be a very
good starting point and you would get less or no problems using the latest
available plugins. If someone wanna take over this I can explain in details
how to do it.

K



Reply via email to