This JIRA is covering adding support for more media formats. Since we are just talking about MKV, please open a separate JIRA to cover this work and attach the patch there. We can link to the new JIRA from RT-18009.


On 2014-03-25 7:47 PM, Jonathan Giles wrote:
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.


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



On 25 March 2014 17:01, Stephen F Northover <>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
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
can't quite work out the logic behind why things have been changed the
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

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
which is why I wasn't seeing any changes on the native level. To ensure
GStreamer is actually compiled, you need to copy the file to, and uncomment the "#COMPILE_MEDIA = true" line. (A similar scenario would appear to exist
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 ( installed
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 (
to  "-Djavafx.ext.dirs" - I think this should be "-Djava.ext.dirs"

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
sign up for an account, so I'm just throwing them here for now - if
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.

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
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 <> wrote:
However, I'm not sure if I'm going about including the matroska plugin


the right way - I've currently done the following:

- Downloaded the latest version of the plugins from here (, then added
matroska one to the modules/media/src/main/native/gstreamer/plugins/
folder, as well as the


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

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


Reply via email to