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