Re: [9] Review request for 8134996: GSTREAMER_LITE conditional compilation should be used for all changes in GStreamer
1) Some files have empty diffs: modules/media/src/main/native/gstreamer/3rd_party/glib/glib-2.42.1/build/win32/dirent/dirent.[h|c] modules/media/src/main/native/gstreamer/3rd_party/glib/glib-2.42.1/build/win32/dirent/wdirent.c and some more. 2) what's the purpose of surrounding in modules/media/src/main/native/gstreamer/3rd_party/glib/glib-2.42.1/glib/gbacktrace.c in GSTREAMER_LITE ? Can we just compile with G_ENABLE_DEBUG if needed ? 3) modules/media/src/main/native/gstreamer/3rd_party/glib/glib-2.42.1/glib/gutils.c as far as I know we compile with G_DISABLE_DEPRECATED so this code won't be included hence why to change ? 4) I'm not sure we need these modules/media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-bad/COPYING files I included them long ago without any reason. 5) Where do we need functions from modules/media/src/main/native/gstreamer/3rd_party/glib/glib-2.42.1/glib/deprecated/gthread.h ? Maybe if it's our code we could rewrite it to make sure we don't use deprecated ghtread at all ? Overall looks fine. So approved. K On 05.09.2015 6:20, Alexander Matveev wrote: Hi Kirill and Kevin, Please review the fix: https://bugs.openjdk.java.net/browse/JDK-8134996 http://cr.openjdk.java.net/~almatvee/8134996/webrev.00/ - Added missing GSTREAMER_LITE. - Fixed some white spaces. - Fixed line ending for some files. - Several files were not merged correctly with latest GStreamer. - Deleted several unused files. Thanks, Alexander
Re: CFV: New OpenJFX Committer: Alexander Matveev
Vote: yes. On 28.08.2015 4:55, Kevin Rushforth wrote: I hereby nominate Alexander Matveev [1] to OpenJFX Committer. Alexander was an initial member of JavaFX team at Oracle when the OpenJFX project was created, and was on the initial list of approved committers [2]. His status as OpenJFX committer was not recorded at that time on the Census. This CVF is intended to correct this oversight. Alexander's changes prior to JavaFX becoming open-source were significant (which is why he was on the initial list of committers). In particular, Alexander, along with the rest of the media team, contributed much of the code that went into the open-source changeset that Kirill Kirichenko pushed for OpenJFX in the JDK 8 release: hg log -r aee256fde55 Counting his contribution to that changeset, Alexander now also has the requisite number of changes in the open-source repo to become a committer. hg log -M -u matvee Votes are due by September 10, 2015. Only current OpenJFX Committers [3] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [4]. Nomination to a project Committer is described in [5]. Thanks, -- Kevin [1] http://openjdk.java.net/census#almatvee [2] http://mail.openjdk.java.net/pipermail/announce/2011-November/000113.html [3] http://openjdk.java.net/census#openjfx [4] http://openjdk.java.net/bylaws#lazy-consensus [5] http://openjdk.java.net/projects#project-committer
Re: Just pushed the updated GStreamer for JEP 257
Congratulations Alexander, Kevin ant to all involved. This is a great milestone which opens opportunities to use newer gstreamer plugins in Media. On 28.08.2015 4:25, Kevin Rushforth wrote: I just pushed the changeset for JEP 257 [1] [2] on behalf of Alexander Matveev to the openjfx 9-dev repo. If you have any questions about the new GStreamer, please let Alexander or Kirill know. This will be in next week's early access build of JDK 9 (build 80). As previously announced [3] this means that JavaFX for JDK 9 will no longer build or run on some older Linux distros. -- Kevin [1] http://openjdk.java.net/jeps/257 [2] https://bugs.openjdk.java.net/browse/JDK-8043352 [3] http://mail.openjdk.java.net/pipermail/openjfx-dev/2015-August/017722.html
Re: [9] Proposal to deprecate VP6 video and the FLV/FXM file formats
On 27.08.2015 9:29, Dr. Michael Paus wrote: To me this sounds again like a Java/JavaFX specific solution which, to my opinion, is a dead-end road. I think it would be much more important that JavaFX can directly use all system installed codecs. I simply don't understand why it is possible to install a codec pack on a machine and almost all software, with the exception of JavaFX, is able to immediately use that and only JavaFX based applications are not. Although this is an off-topic I'll answer to your question. Security and testing are the reasons. It's virtually impossible to test every possible codec on every possible platform. Many of them are proprietary so we don't control their code/can't fix their bugs. And all blame that JavaFX can't play this/can't play that will fall on our heads. And it can open many potential security vulnerabilities.
[8u60,9] review request: 8088823: Advanced Media Player tab does not respond to Time slider on Windows
Hi Alexander, Kevin. Could you please review the following fix? jbs: https://bugs.openjdk.java.net/browse/JDK-8088823 wevrev: http://cr.openjdk.java.net/~stayer/8088823/webrev.00/ Please review and comment in JBS. This patch partly fixes regression after https://bugs.openjdk.java.net/browse/JDK-8092944 and partly fixes missing parts. In JDK-8092944 DeliverSample fails in CBaseOutputPin::GetDeliveryBuffer with E_NOINTERFACE because m_pAllocator is NULL. So this patch does not ignore all errors that are not E_FAIL. Patch in gstqueue.c allows to generate GST_ELEMENT_ERROR even if there is no eos in the queue. Without this part _loop task is silently stops and application is not generating any errors. Patch in flvdemux.c just cleans redundancy. It's just not necessary. I'd say that some SQE effort is necessary for testing this patch better. K
[8u60, 9] review request: RT-46186: FX application hangs on exit when media gets stuck
Hi Alexander, Kevin. Could you please review the following fix? jira: https://javafx-jira.kenai.com/browse/RT-46186 wevrev: http://cr.openjdk.java.net/~stayer/RT-46186/webrev.00/ Please review and comment in JIRA if it's still in read-write mode ? K
[8u60] Request for review: RT-39297: FXM player fails to exit
Hi Alexander. Could you please review this fix for flvdemux.c. gst_pad_pull_range in the code above the change may return FLOW_ERROR is the buffer is of some enormous size. We should react to the error. Also some files play well but don't receive EOS or Error because is coming with presentation timestamp which is far ahead te current time. So this isn't a erroneous situation but takes time to finish. webrev: https://javafx-jira.kenai.com/browse/RT-39297 jira: http://cr.openjdk.java.net/~stayer/RT-38079
Re: [8u60] Request for review: RT-39297: FXM player fails to exit
Correct jira link: https://javafx-jira.kenai.com/browse/RT-38079 On 17.04.2015 15:47, Kirill Kirichenko wrote: Hi Alexander. Could you please review this fix for flvdemux.c. gst_pad_pull_range in the code above the change may return FLOW_ERROR is the buffer is of some enormous size. We should react to the error. Also some files play well but don't receive EOS or Error because is coming with presentation timestamp which is far ahead te current time. So this isn't a erroneous situation but takes time to finish. webrev: https://javafx-jira.kenai.com/browse/RT-39297 jira: http://cr.openjdk.java.net/~stayer/RT-38079
[8u60] Request for review: RT-37900: MP3 player fails to exit
Hi Alexander. Could you please review this fix for directshowwrapper. When working with fuzzed mp3 files decoder-pSrc-DeliverSample fails but no error is generated and the whole pipeline just silently swithces to prerolling. webrev: cr.openjdk.java.net/~stayer/RT-37900/ jira: https://javafx-jira.kenai.com/browse/RT-37900
Re: [8u40] RFR: RT-39571: [Mac] AVFoundation player never sends FINISHED state at end of stream
Approved On 04.12.2014 01:44, David DeHaven wrote: Kevin, Kirill, please review the following change for 8u40 JIRA Issue: https://javafx-jira.kenai.com/browse/RT-39571 Webrev: http://cr.openjdk.java.net/~ddehaven/RT-39571/rt.0/ -DrD-
Re: [8u40] RFR: RT-38973: Media produces extraneous debugging when running Ensemble8
Approved On 25.11.14 0:10, David DeHaven wrote: Kevin, Kirill, please review the following fix for 8u40: JIRA: https://javafx-jira.kenai.com/browse/RT-38973 Webrev: http://cr.openjdk.java.net/~ddehaven/RT-38973/rt.0/ I added an additional (annoying) compiler warning fix. -DrD-
hg: openjfx/8u-dev/rt: RT-37914: [Linux] JavaFX Media does not run on Ubuntu 14.04
Changeset: df28c1bdf2e1 Author:stayer Date: 2014-07-28 19:25 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/df28c1bdf2e1 RT-37914: [Linux] JavaFX Media does not run on Ubuntu 14.04 ! build.gradle ! modules/media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstregistry.c ! modules/media/src/main/native/gstreamer/projects/linux/avplugin/Makefile
Re: [8u40] Review request for RT-37914: [Linux] JavaFX Media does not run on Ubuntu 14.04
That's right. My fault. On 24.07.2014 19:38, Kevin Rushforth wrote: Hi Kirill, Did you mean https://javafx-jira.kenai.com/browse/RT-37914 ? -- Kevin Kirill Kirichenko wrote: https://javafx-jira.kenai.com/browse/RT-3791
[8u40] Review request for RT-3791: [Linux] JavaFX Media does not run on Ubuntu 14.04
https://javafx-jira.kenai.com/browse/RT-3791
hg: openjfx/8u-dev/rt: RT-35770: Provide media support for libav version 54 and 55
Changeset: 647fd6fc387c Author:stayer Date: 2014-07-18 16:44 +0400 URL: http://hg.openjdk.java.net/openjfx/8u-dev/rt/rev/647fd6fc387c RT-35770: Provide media support for libav version 54 and 55 ! modules/media/src/main/native/gstreamer/gstreamer-lite/gstreamer/gst/gstregistry.c ! modules/media/src/main/native/gstreamer/plugins/av/audiodecoder.c ! modules/media/src/main/native/gstreamer/plugins/av/audiodecoder.h + modules/media/src/main/native/gstreamer/plugins/av/avdefines.h ! modules/media/src/main/native/gstreamer/plugins/av/avelement.c ! modules/media/src/main/native/gstreamer/plugins/av/avelement.h ! modules/media/src/main/native/gstreamer/plugins/av/decoder.c ! modules/media/src/main/native/gstreamer/plugins/av/decoder.h ! modules/media/src/main/native/gstreamer/plugins/av/mpegtsdemuxer.c ! modules/media/src/main/native/gstreamer/plugins/av/videodecoder.c ! modules/media/src/main/native/gstreamer/plugins/av/videodecoder.h
Re: ComboBox: TestEditor to ListView binding
I'm afraid in my project I will only allowed to use vanilla javafx only. It would be good if someone could write a blog of how to create a bare minimum combobox control with desired behaviour like I explained. Thanks for the reference. K On 07.07.2014 11:20, Werner Lehmann wrote: Kirill, ControlsFX has support for this if a 3rd party lib is ok. With TextFields.createClearableTextField() you create a search field with an eraser icon to clear the text. And the AutoCompletionBinding applied to the textfield implements the auto complete dropdown. You only have to provide a function to return search results for user input. Werner On 04.07.2014 23:48, Kirill Kirichenko wrote: I'm implementing a searchbox. In the textfield of the combobox I'm typing a search string. textProperty of the editor has an onChange listener which forms a list of strings that contain the text as a substring. Then I set this list of strings as a content of the drop down list of the combobox. The problem is when I start selecting items in the drop down list the editor field gets updated making new substring search and updating the list again. I want to break this dependency. I don't want to update the text property when I select an item in the drop down list OR I want to distinguish in the textProperty listener what caused that event - real editing the field or setting the field trough binding from the list view. I hope I could make myself clear. K
ComboBox: TestEditor to ListView binding
JavaFX ComboBox has binding between TextEdit field and the ListView selection such that edit field gets updated when we change the selected item in the drop down list. Is there a way to break this binding - when we select an item in the list the editor field remains untouched. Where should I look at ? Thanks. K
Re: ComboBox: TestEditor to ListView binding
I'm implementing a searchbox.
In the textfield of the combobox I'm typing a search string.
textProperty of the editor has an onChange listener which forms a list
of strings that contain the text as a substring. Then I set this list of
strings as a content of the drop down list of the combobox.
The problem is when I start selecting items in the drop down list the
editor field gets updated making new substring search and updating the
list again.
I want to break this dependency. I don't want to update the text
property when I select an item in the drop down list OR I want to
distinguish in the textProperty listener what caused that event - real
editing the field or setting the field trough binding from the list view.
I hope I could make myself clear.
K
On 05.07.2014 01:21, Stephen F Northover wrote:
Hi Kirill,
What exactly are you trying to do? The following (crap) listens for the
value to change and then sets it back:
ChangeListenerString l = new ChangeListenerString () {
public void changed(ObservableValue observable, String
oldValue,
String newValue) {
System.out.println(attempt to set new value: +
newValue);
Platform.runLater(() - {
comboBox3.valueProperty().removeListener(this);
System.out.println(restoring old value: +
newValue);
comboBox3.setValue(oldValue);
comboBox3.valueProperty().addListener(this);
});
};
};
comboBox3.valueProperty().addListener(l);
This is not good code because it adds and removes a listener to avoid
notification when the value is reset. It uses runLater() in order to
stop the combo box from getting confused when the value is changed from
within a changed listener.
Steve
On 2014-07-04, 3:09 PM, Kirill Kirichenko wrote:
JavaFX ComboBox has binding between TextEdit field and the ListView
selection such that edit field gets updated when we change the
selected item in the drop down list.
Is there a way to break this binding - when we select an item in the
list the editor field remains untouched. Where should I look at ?
Thanks.
K
Proportional TableColumn resizing
Hi all. How is it possible to create TableColumns (preferably in fxml) such that they have some proportional width say in percents rather than in pixels with a feature that when we resize the table the columns get resized proportionally ? Default behaviour is that when the window containing a table is grown in width all columns keep the width and one extra column appear that has no data. K
Re: Adding GStreamer plugins
Hi Michael
On 28.03.2014 23:40, Michael Berry wrote:
Hi Kirill,
Ok, so with help from here (https://github.com/pgregory/libffi-msvc) I
think I've now got a VS project / makefile that builds libffi.lib, but I
can't work out how to get the build script to build the visual studio
project!
The project is in modules\media\src\main\native\vs_project\libffi, and
I've updated FXMedia.sln to include it - this builds ok, but the
makefile then expects the object files in
modules\media\build\native\win\Release\obj\3rd_party\libffi-lite (I
deliberately kept this structure for consistency with the other
projects), and I can't seem to work out where in the script they're
copied across from the visual studio project (I feel like this should be
the easy bit of this step!)
FXMedia.sln is there just for debugging purposes. I wanted to switch to
NetBeans C/C++ project for native code. You shouldn't consider the MSVS
Solution as the build tool. Main build tools are makefiles. So start
with the makefile and then fine tune the FXMedia.sln.
So now what you need is to create a Makefile in
rt\modules\media\src\main\native\gstreamer\projects\win\glib-lite\Makefile.libffi
by copying if from Makefile.glib for example. Then you should edit this
new Makefile.libffi accordingly:
1) Change OBJBASE_DIR, SRCBASE_DIR, DIRLIST, C_SOURCES
2) You may need to change COMPILER_FLAGS but generally they are ok.
3) Carefully change CFLAGS to what the vanilla build system uses. Here
you can watch for output log and take those flags. Remember I told you
to try to build with MSVS. That's why it's important - we build it all
with MSVC not with gcc in Windows.
Then you need to edit Makefile in the same directory:
4) Add LIBFFI_TARGET with the target library name, and update MODULES
variable (add LIBFFI_TARGET to it). See GLIB_TARGET for example.
5) Add dependent target for LIBFFI_TARGET at the bottom of the file. See
GLIB_TARGET again.
If you feel you want give it a try. Open cygwin, go to rt ant type:
$ gradle clean
$ gradle -PCOMPILE_MEDIA=true :media:buildWinGlib
This should catch libffi changes.
Once you successfully do it you should be able to build
rt\modules\media\build\native\win\{Release|Debug}\libffi.lib or whatever
you assign at #4
After this step you can remove all files that don't participate in build
and leave only source/headers. Just like glib.
If I copy them there manually it works and builds libffi-lite.lib, but
obviously this isn't ideal - if it's not too much hassle could someone
point me at the relevant place?
Many thanks,
Michael
On 27 March 2014 08:58, Kirill Kirichenko kirill.kiriche...@oracle.com
mailto:kirill.kiriche...@oracle.com wrote:
On 27.03.2014 03:53, Michael Berry wrote:
Unfortunately I seem to have become a bit stuck at step one! I'm
probably missing a few things that are rather obvious, but haven't
really got much experience at all in this area, so am relying on
haphazard Googling and a bit of guesswork! It may well be that
updating
the framework is a bit beyond my skillset for the time I have
available
at the moment, but I'll keep pushing on if anyone's willing to
give me a
bit of guidance on it.
Yes. It's not trivial at all. You need to have enough patience to go
through all the steps.
Firstly libffi - I've downloaded that, put it in the 3rd_party
folder,
and have run ./configure, make, then make install (all under
cygwin.) That seems fine; so I've now got libffi.a (as well as
cygffi-6.dll) in 3rd_party\libffi\i686-pc-__cygwin\.libs.
The challenge here is first to build libffi with Mircosoft C
compiler and linker. Here at the first stage you should take libffi
and put it somewhere separately from javafx. Then try to build it
with VisualStudio. Once you succeed you should create a makefile in
the manner of javafx makefiles for Media. As the result of this step
you'll get a bunch of C/Header files, the makefile. Everything else
can be deleted. The resulting makefile should be able to build
libffi.lib - statically linked library.
I've then grabbed glib 2.40, placed that in the glib folder, and
attempted the same process - this first complained about a lack of
libiconv, so I grabbed that and set the appropriate flags to
point to
it, and now I get the following:
/configure: error: in
`/cygdrive/c/Users/Michael/__Documents/JFX8/modules/media/__src/main/native/gstreamer/3rd___party/glib/glib-2.28.8':/
/configure: error: The pkg-config script could not be found or
is too
old. Make sure it is in your PATH or set the PKG_CONFIG environment
variable to the full path to pkg-config./
/
/
/Alternatively, you may set the environment variables
LIBFFI_CFLAGS and
LIBFFI_LIBS to avoid the need to call
Re: Adding GStreamer plugins
There is another issue with new plugins. We have thoroughly tested with a closed source internal test suite on all platforms every plugin that we already have. If we add something new this may open a way for crashes, security breaches. So if you add something new and want this to be included in Oracle JavaFX (JDK) this needs to be tested well. As for OpenJFX - it's a good starting point. On 26.03.2014 12:58, Michael Berry wrote: Hi David, Sure - I'm aware there's legal issues surrounding many of the formats, though one of the reasons I picked MKV to start with was because it's an open container format. I'm certainly not aware of any restrictions surrounding it (though please correct me if I'm wrong on that front!) A switch certainly sounds like a good idea though, especially for formats with more restrictions surrounding their use; I'll bear that in mind if I add any additional plugins. Thanks, Michael On 26 March 2014 02:03, David DeHaven david.deha...@oracle.com wrote: 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? It sounds like there are perhaps two different ways to move forward here, the first is to take a submission in the form of WIKI writeup that we can post so that anybody else who wants to try extending the media files can follow the path you took. The other is to take a patch for the given JIRA issue. Sadly, the JIRA server doesn't allow just anybody to supply patches, so you will have to email to Steve or Kevin and they can attach it to the issue for you. Be careful how these are implemented. We cannot just enable formats in GStreamer, there are licensing and legal issues involved. I think the Matroska licenses are fairly benign, but it still requires some amount of process. What I would recommend is adding a switch to optionally enable additional formats, so those building GStreamer or OpenJFX themselves can turn whatever they want on or off, and they are on their own for dealing with legal issues. That being said, we actually tested with MKV during development and it was pretty solid :) -DrD-
Re: Adding GStreamer plugins
Michael, On 26.03.2014 04:11, Michael Berry wrote: Kirill - I think I'll take your suggestion next and start looking at upgrading the existing native components to the latest version of GStreamer before I look at adding any more plugins, that would seem to make sense. Have you any pointers in how best to approach this? No pointer at all. I have it my my head. And it's about time to pass this experience before I forget it =) The thing is I did it once and it took me ~ 2 months. Here is the brief plan that you need to keep: [1] Start with the lower lever. It's glib. Linux doesn't need any glib update - we use the system glib. So glib update is necessary for Win/Mac. [1.1] Latest glib has plenty of dependencies on other 3-rd party libraries. But there is one that's mandatory - libFFI. Fortunately Oracle has approval to use libFFI in it's products. But this probably isn't necessary for OpenJFX. So at you first step you need to bring libFFI sources, place them in rt/modules/media/src/main/native/gstreamer/3rd_party/libffi and make sure it builds on Windows and Mac producing lib/a for static linking. You can probably make dll/dylib instead but I don't think it's necessary. [1.2] Take the latest glib 2.38 or even 2.40. Place them in rt/modules/media/src/main/native/gstreamer/3rd_party/glib Note that you don't need all sources/headers. But to remove precisely what's redundant you should first compile gstreamer/plugins. Here you make sure you can compile and build glib-lite.dll/libglib-lite.dylib Having done 1.2 you should be able to run media component with the new glib-lite.dll. If it runs then you're done with glib upgrade. It's important to apply fixes that we made in glib to the newer glib library. You can find them by grepping for GSTREAMER_LITE in sources/headers. [2] GStreamer update. [3] Oracle plugins compilation/update. This step will also be necessary because 0.10.35 API is different from 1.0. For Example GstBuffer that we extensively use has incompatible APIs. I won't get deeper into details for [2] and [3] now. Let's just handle [1] and then continue.
Re: Adding GStreamer plugins
I added a wiki link: https://wiki.openjdk.java.net/pages/viewpage.action?pageId=18808963 I welcome free will participants to go over the steps, upgrade GStreamer and eventually create a precise version of the guide. I will provide as much help as I can. K On 26.03.2014 16:43, Kirill Kirichenko wrote: Michael, On 26.03.2014 04:11, Michael Berry wrote: Kirill - I think I'll take your suggestion next and start looking at upgrading the existing native components to the latest version of GStreamer before I look at adding any more plugins, that would seem to make sense. Have you any pointers in how best to approach this? No pointer at all. I have it my my head. And it's about time to pass this experience before I forget it =) The thing is I did it once and it took me ~ 2 months. Here is the brief plan that you need to keep: [1] Start with the lower lever. It's glib. Linux doesn't need any glib update - we use the system glib. So glib update is necessary for Win/Mac. [1.1] Latest glib has plenty of dependencies on other 3-rd party libraries. But there is one that's mandatory - libFFI. Fortunately Oracle has approval to use libFFI in it's products. But this probably isn't necessary for OpenJFX. So at you first step you need to bring libFFI sources, place them in rt/modules/media/src/main/native/gstreamer/3rd_party/libffi and make sure it builds on Windows and Mac producing lib/a for static linking. You can probably make dll/dylib instead but I don't think it's necessary. [1.2] Take the latest glib 2.38 or even 2.40. Place them in rt/modules/media/src/main/native/gstreamer/3rd_party/glib Note that you don't need all sources/headers. But to remove precisely what's redundant you should first compile gstreamer/plugins. Here you make sure you can compile and build glib-lite.dll/libglib-lite.dylib Having done 1.2 you should be able to run media component with the new glib-lite.dll. If it runs then you're done with glib upgrade. It's important to apply fixes that we made in glib to the newer glib library. You can find them by grepping for GSTREAMER_LITE in sources/headers. [2] GStreamer update. [3] Oracle plugins compilation/update. This step will also be necessary because 0.10.35 API is different from 1.0. For Example GstBuffer that we extensively use has incompatible APIs. I won't get deeper into details for [2] and [3] now. Let's just handle [1] and then continue.
Re: Adding GStreamer plugins
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'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 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?
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
Re: Adding GStreamer plugins
On 25.03.2014 17:21, Michael Berry wrote: It seems the issue that I was having was indeed to do with the step you outlined; I was getting unresolved external linker issues because it couldn't find the functions I hadn't added. However, while the linker errors associated with all the glib functions have now been resolved through adding the methods (to both glib-lite.def and glib-liteD.def), adding the relevant functions to gstreamer-lite.def complains about an unresolved external symbol in the def file: gstreamer-lite.def : error LNK2001: unresolved external symbol gst_byte_writer_free gstreamer-lite.def : error LNK2001: unresolved external symbol gst_byte_writer_free_and_get_buffer gstreamer-lite.def : error LNK2001: unresolved external symbol gst_byte_writer_new_with_size When they're not in the def file, I get the following linker errors instead: libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external symbol _gst_byte_writer_free referenced in function _gst_ebml_write_finalize libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external symbol _gst_byte_writer_new_with_size referenced in function _gst_ebml_start_streamheader libgstplugins.lib(ebml-write.obj) : error LNK2019: unresolved external symbol _gst_byte_writer_free_and_get_bufferreferenced in function _gst_ebml_stop_streamheader I've added these to the gstreamer-lite.def file in exactly the same way as I added the glib functions to the glib files - any idea what I might have missed? gst_byte_writer_free_and_get_buffer@184NONAME gst_byte_writer_free@185NONAME gst_byte_writer_new_with_size@186NONAME This is not necessary that you should add all methods to the def file. Here first you should look for where the symbols are implemented and you possibly miss this file from from makefile. Take all symbols that linker shows to you, strip leading underscore character, and find them in the vanilla glib. It's possible that we did not include the file where they are implemented to the sources. In short: look where gst_byte_writer_free, gst_byte_writer_new_with_size and gst_byte_writer_free_and_get_bufferreferenced are implemented and make sure this file is compiled. (I'm assuming NONAME is always there, and the number is sequential.) The functions are in gstbytewriter.h which is there, though perhaps I need to make the linker aware of that file specifically if it's not used anywhere else? (I'm just guessing here though.) NONAME is always there and the number is sequential. Also make sure use TABS between the columns. As far as I remember TABS are used, but do double check it. Happy to look at upgrading gstreamer to the latest version as a next task, so I'd be more than willing to give that a go. Though I would quite like to get the matroska plugin working first - just so I've got some experience at building in a working plugin, and have some end result from what I'm trying to achieve here! OK. Many thanks, Michael On 25 March 2014 11:00, Kirill Kirichenko kirill.kiriche...@oracle.com mailto:kirill.kiriche...@oracle.com 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
Re: [8u] Review request: RT-34950: [Media] JavaFx Player on MAC Crashes Application When Playing Specific Video
Looks good. Approved. On 21.03.2014 17:54, anton nashatyrev wrote: Hello, could you please review the following fix: Webrev: http://cr.openjdk.java.net/~anashaty/RT-34950/webrev.00/ http://cr.openjdk.java.net/%7Eanashaty/RT-34950/webrev.00/ Issue: https://javafx-jira.kenai.com/browse/RT-34950 Thank you! Anton.
Re: [8u20] Review request: RT-35197: Use Lambda in FX runtime and samples
I couldn't find media part in Jira. On 06.03.2014 00:44, Stephen F Northover wrote: ... of course I mean the media component, not base. I just change the template to say your component ... Steve On 2014-03-05 3:41 PM, Stephen F Northover wrote: Hi Kirill, Please review the lambdification of the base component. You are welcome to apply the patch, but there are numerous changes and they are all automatic. If you have outstanding changes, please commit them and I will lambdify once more, Jira: https://javafx-jira.kenai.com/browse/RT-35197 Webrev: See patch is in the JIRA Steve
Re: Media is now opensource
It will be once we create a 9.0 repo and merge our sandbox with the openjfx repo. Currently we have a working version of Recording/Capture APIs with FXMediaRecorder demo (in apps) implemented on Windows. Linux and Mac implementations are to be done. So expect more to be coming soon. Kirill. On 19.10.2013 3:39, Pedro Duque Vieira wrote: Thanks Kirill, good job. You guys had already a working prototype of an app that recorded audio and video. I wonder if this is also available? Thanks, best regards, Hello OpenJFXers ! We're happy to announce that Media part of JavaFX is now open source. Opensourcing touched all Media component except ON2 FLV demuxer and VP6 decoder. The decoder will remain closed. You're all welcome to contribute. Thanks, -- Pedro Duque Vieira
Media is now opensource
Hello OpenJFXers ! We're happy to announce that Media part of JavaFX is now open source. Opensourcing touched all Media component except ON2 FLV demuxer and VP6 decoder. The decoder will remain closed. You're all welcome to contribute. Thanks, K
Re: Media is now opensource
Media is very regulated area in legal terms. Using different codecs may involve using and even violating some license agreements. Anyway you're welcome to propose anything. On 18.10.2013 21:37, Robert Krüger wrote: Great news! Does this mean that it is now possible to add support for more demuxers/decoders e.g. by utilizing stuff from other projects (ffmpeg comes to mind)? On Fri, Oct 18, 2013 at 6:35 PM, Kirill Kirichenko kirill.kiriche...@oracle.com wrote: Hello OpenJFXers ! We're happy to announce that Media part of JavaFX is now open source. Opensourcing touched all Media component except ON2 FLV demuxer and VP6 decoder. The decoder will remain closed. You're all welcome to contribute. Thanks, K
JavaFX Media HTTPS support
We've started working on HTTPS support in JavaFX Media component. Due to internal restrictions we won't be able to support HTTPS on MacOs (and possibly on iOS). Do you think it a good idea to add a feature with limited support - just for Linux and Windows ?
Re: JavaFX Media HTTPS support
For HTTP Live Streaming and some cases for MP4 on Mac we using QTMovie, which only accepts URLs for FILE or HTTP protocol only and handles downloading, progress buffering and HLS playlists parsing internally. We do not have control over it. MP4 can also be played on Mac via GStreamer via Video Acceleration Framework, but it is limited to only one instance and one stream across all apps (meaning if someone runs QuickTime and loaded movie we cannot use it), limited support of H.264 bitsream (not all resolutions, framerates, profiles are supported). It depends on video card. On 03.10.2013 12:24, Randahl Isaksen wrote: No. Adding a feature which only works on some desktop OSes ruins the WORA quality of Java. What kinds of restrictions? Resource restrictions or...? Den 03/10/2013 10.19 skrev Kirill Kirichenko kirill.kiriche...@oracle.com mailto:kirill.kiriche...@oracle.com: We've started working on HTTPS support in JavaFX Media component. Due to internal restrictions we won't be able to support HTTPS on MacOs (and possibly on iOS). Do you think it a good idea to add a feature with limited support - just for Linux and Windows ?
Re: JavaFX Media HTTPS support
Forgot to add. It's this issue: https://javafx-jira.kenai.com/browse/RT-28420 On 03.10.2013 12:15, Kirill Kirichenko wrote: We've started working on HTTPS support in JavaFX Media component. Due to internal restrictions we won't be able to support HTTPS on MacOs (and possibly on iOS). Do you think it a good idea to add a feature with limited support - just for Linux and Windows ?
