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