[jfx17u] Integrated: 8283218: Update GStreamer to 1.20.1
On Mon, 9 May 2022 21:07:39 GMT, Kevin Rushforth wrote: > Almost clean backport to `jfx17u`. Tested in connection with libffi update in > the `test-kcr-17.0.4` branch. > > The only difference from the mainline patch is that the following file is not > present in `jfx17u`, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c This pull request has now been integrated. Changeset: 103cac04 Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx17u/commit/103cac04472d3eddb1f28a6a0b4f8d60f5ce3d7f Stats: 38921 lines in 412 files changed: 22007 ins; 5981 del; 10933 mod 8283218: Update GStreamer to 1.20.1 8283403: Update Glib to 2.72.0 Reviewed-by: jvos Backport-of: c4b1a72cc4d9253d1320d83281d50fb1f3bb6145 - PR: https://git.openjdk.java.net/jfx17u/pull/54
Re: What can I do with the GStreamer bundled in JavaFX? Can I record the screen?
Can't wait to see more GStreamer features inside JavaFX. Thank you for the answer! Davide Il 11/05/2022 13:27, Kevin Rushforth ha scritto: GStreamer is used by the JavaFX media API. It is an implementation detail, and is not exposed. There are no media capture APIs, although that is something we have considered providing in the future. -- Kevin On 5/10/2022 1:02 PM, Davide Perini wrote: Hi all, I haven't understood what part of GStreamer is included in JavaFX. Can I record the screen with it using d3d11screencapturesrc or ximagesrc? Thanks Davide
Re: [jfx17u] RFR: 8283218: Update GStreamer to 1.20.1
On Mon, 9 May 2022 21:07:39 GMT, Kevin Rushforth wrote: > Almost clean backport to `jfx17u`. Tested in connection with libffi update in > the `test-kcr-17.0.4` branch. > > The only difference from the mainline patch is that the following file is not > present in `jfx17u`, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx17u/pull/54
Re: What can I do with the GStreamer bundled in JavaFX? Can I record the screen?
GStreamer is used by the JavaFX media API. It is an implementation detail, and is not exposed. There are no media capture APIs, although that is something we have considered providing in the future. -- Kevin On 5/10/2022 1:02 PM, Davide Perini wrote: Hi all, I haven't understood what part of GStreamer is included in JavaFX. Can I record the screen with it using d3d11screencapturesrc or ximagesrc? Thanks Davide
What can I do with the GStreamer bundled in JavaFX? Can I record the screen?
Hi all, I haven't understood what part of GStreamer is included in JavaFX. Can I record the screen with it using d3d11screencapturesrc or ximagesrc? Thanks Davide
Re: [jfx17u] RFR: 8283218: Update GStreamer to 1.20.1
On Mon, 9 May 2022 21:07:39 GMT, Kevin Rushforth wrote: > Almost clean backport to `jfx17u`. Tested in connection with libffi update in > the `test-kcr-17.0.4` branch. > > The only difference from the mainline patch is that the following file is not > present in `jfx17u`, so that part of the patch was skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c Reviewer: @johanvos - PR: https://git.openjdk.java.net/jfx17u/pull/54
[jfx17u] RFR: 8283218: Update GStreamer to 1.20.1
Almost clean backport to `jfx17u`. Tested in connection with libffi update in the `test-kcr-17.0.4` branch. The only difference from the mainline patch is that the following file is not present in `jfx17u`, so that part of the patch was skipped: modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c - Commit messages: - 8283218: Update GStreamer to 1.20.1 Changes: https://git.openjdk.java.net/jfx17u/pull/54/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx17u=54=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283218 Stats: 38921 lines in 412 files changed: 22007 ins; 5981 del; 10933 mod Patch: https://git.openjdk.java.net/jfx17u/pull/54.diff Fetch: git fetch https://git.openjdk.java.net/jfx17u pull/54/head:pull/54 PR: https://git.openjdk.java.net/jfx17u/pull/54
[jfx11u] Integrated: 8283218: Update GStreamer to 1.20.1
On Sat, 30 Apr 2022 13:37:08 GMT, Kevin Rushforth wrote: > Backport to `jfx11u`. Tested in connection with libffi update in the > `test-kcr-11.0.16` branch. > > This was not a clean backport, but the merge conflicts were trivial to > resolve. Here is a summary of the changes. The jfx mainline patch applied > cleanly to all other files. > > 1. The following file is not present in jfx11u, so that part of the patch was > skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c > > > 2. The following files had minor merge conflicts, the first was a diff in > surrounding context and the rest were in copyright header blocks: > > > modules/javafx.media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile > modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > modules/javafx.media/src/tools/native/def-glib.pl > modules/javafx.media/src/tools/native/def-gstlite.pl This pull request has now been integrated. Changeset: d0df8471 Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/d0df8471c4e38e0b0dfae0e83848316694033002 Stats: 38984 lines in 412 files changed: 22060 ins; 5959 del; 10965 mod 8283218: Update GStreamer to 1.20.1 8283403: Update Glib to 2.72.0 Reviewed-by: jvos Backport-of: c4b1a72cc4d9253d1320d83281d50fb1f3bb6145 - PR: https://git.openjdk.java.net/jfx11u/pull/94
Re: [jfx11u] RFR: 8283218: Update GStreamer to 1.20.1
On Sat, 30 Apr 2022 13:37:08 GMT, Kevin Rushforth wrote: > Backport to `jfx11u`. Tested in connection with libffi update in the > `test-kcr-11.0.16` branch. > > This was not a clean backport, but the merge conflicts were trivial to > resolve. Here is a summary of the changes. The jfx mainline patch applied > cleanly to all other files. > > 1. The following file is not present in jfx11u, so that part of the patch was > skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c > > > 2. The following files had minor merge conflicts, the first was a diff in > surrounding context and the rest were in copyright header blocks: > > > modules/javafx.media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile > modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > modules/javafx.media/src/tools/native/def-glib.pl > modules/javafx.media/src/tools/native/def-gstlite.pl Marked as reviewed by jvos (Reviewer). - PR: https://git.openjdk.java.net/jfx11u/pull/94
Re: [jfx11u] RFR: 8283218: Update GStreamer to 1.20.1
On Sat, 30 Apr 2022 13:37:08 GMT, Kevin Rushforth wrote: > Backport to `jfx11u`. Tested in connection with libffi update in the > `test-kcr-11.0.16` branch. > > This was not a clean backport, but the merge conflicts were trivial to > resolve. Here is a summary of the changes. The jfx mainline patch applied > cleanly to all other files. > > 1. The following file is not present in jfx11u, so that part of the patch was > skipped: > > > modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c > > > 2. The following files had minor merge conflicts, the first was a diff in > surrounding context and the rest were in copyright header blocks: > > > modules/javafx.media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile > modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile > modules/javafx.media/src/tools/native/def-glib.pl > modules/javafx.media/src/tools/native/def-gstlite.pl Reviewer: @johanvos - PR: https://git.openjdk.java.net/jfx11u/pull/94
[jfx11u] RFR: 8283218: Update GStreamer to 1.20.1
Backport to `jfx11u`. Tested in connection with libffi update in the `test-kcr-11.0.16` branch. This was not a clean backport, but the merge conflicts were trivial to resolve. Here is a summary of the changes. The jfx mainline patch applied cleanly to all other files. 1. The following file is not present in jfx11u, so that part of the patch was skipped: modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/gst/audioparsers/gstaacparse.c 2. The following files had minor merge conflicts, the first was a diff in surrounding context and the rest were in copyright header blocks: modules/javafx.media/src/main/native/gstreamer/projects/linux/fxplugins/Makefile modules/javafx.media/src/main/native/jfxmedia/projects/linux/Makefile modules/javafx.media/src/tools/native/def-glib.pl modules/javafx.media/src/tools/native/def-gstlite.pl - Commit messages: - 8283218: Update GStreamer to 1.20.1 Changes: https://git.openjdk.java.net/jfx11u/pull/94/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u=94=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283218 Stats: 38984 lines in 412 files changed: 22060 ins; 5959 del; 10965 mod Patch: https://git.openjdk.java.net/jfx11u/pull/94.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/94/head:pull/94 PR: https://git.openjdk.java.net/jfx11u/pull/94
Integrated: 8283218: Update GStreamer to 1.20.1
On Fri, 8 Apr 2022 06:49:59 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp > g_atomic_pointer_compare_and_exchange() was changed to > g_atomic_pointer_set(). For some reason I was not able to get code compiled > with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do > not see a need to use g_atomic_pointer_compare_and_exchange(), since > m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. This pull request has now been integrated. Changeset: c4b1a72c Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/c4b1a72cc4d9253d1320d83281d50fb1f3bb6145 Stats: 38924 lines in 413 files changed: 22010 ins; 5981 del; 10933 mod 8283218: Update GStreamer to 1.20.1 8283403: Update Glib to 2.72.0 Reviewed-by: jvos, kcr - PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v5]
On Wed, 20 Apr 2022 23:08:00 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp >> g_atomic_pointer_compare_and_exchange() was changed to >> g_atomic_pointer_set(). For some reason I was not able to get code compiled >> with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do >> not see a need to use g_atomic_pointer_compare_and_exchange(), since >> m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v5] Answering my own question from above, I was able to take a `gstreamer-lite` binary built on Oracle Linux 7.x and run it on my Ubuntu 16.04 system, so it looks like we are good to go. Alexander or I will file a follow-on bug to build and ship `glib-lite` on Linux. It will allow some of the custom code to be reverted, and will avoid this problem the next time we update GLib. It also matches what we do for the other platforms (and what we do for Linux on Oracle's JDK 8u releases, so we have a data point that shows it to be a feasible approach). - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v5]
On Wed, 20 Apr 2022 23:08:00 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp >> g_atomic_pointer_compare_and_exchange() was changed to >> g_atomic_pointer_set(). For some reason I was not able to get code compiled >> with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do >> not see a need to use g_atomic_pointer_compare_and_exchange(), since >> m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v5] Marked as reviewed by jvos (Reviewer). I have this working on Ubuntu 18.04, and that gives me enough confidence that with the appropriate toolchain it can be built for 16.04. Exploring glib-lite.so sounds like a good plan. - PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v4]
On Mon, 18 Apr 2022 18:38:03 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp >> g_atomic_pointer_compare_and_exchange() was changed to >> g_atomic_pointer_set(). For some reason I was not able to get code compiled >> with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do >> not see a need to use g_atomic_pointer_compare_and_exchange(), since >> m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v4] The latest patch builds and runs for me now on Ubuntu 16.04. I do want to make sure that regardless of whatever system we build it on, the binary is able to run on the oldest version we are targeting. Otherwise, a binary built on, say, Oracle Linux 7.x or Ubuntu 20.04 might not run on an Ubuntu 16.04 system. Basically what we don't want is to be dependent on a particular version of libraries at compile time. The more I think about it, the best long term solution (not this time) is probably to build and deliver glib-lite.so on Linux. - PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v4]
On Mon, 18 Apr 2022 18:38:03 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp >> g_atomic_pointer_compare_and_exchange() was changed to >> g_atomic_pointer_set(). For some reason I was not able to get code compiled >> with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do >> not see a need to use g_atomic_pointer_compare_and_exchange(), since >> m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v4] 8283218: Update GStreamer to 1.20.1 [v5] - Added missing define which required for Windows 32-bit build. - PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v5]
> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp > g_atomic_pointer_compare_and_exchange() was changed to > g_atomic_pointer_set(). For some reason I was not able to get code compiled > with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do > not see a need to use g_atomic_pointer_compare_and_exchange(), since > m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8283218: Update GStreamer to 1.20.1 [v5] - Changes: - all: https://git.openjdk.java.net/jfx/pull/768/files - new: https://git.openjdk.java.net/jfx/pull/768/files/a29cd34b..39f0b050 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=768=04 - incr: https://webrevs.openjdk.java.net/?repo=jfx=768=03-04 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v3]
On Fri, 15 Apr 2022 23:29:54 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp >> g_atomic_pointer_compare_and_exchange() was changed to >> g_atomic_pointer_set(). For some reason I was not able to get code compiled >> with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do >> not see a need to use g_atomic_pointer_compare_and_exchange(), since >> m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v3] 8283218: Update GStreamer to 1.20.1 [v4] - Added missing include file (string.h). - PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v4]
> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp > g_atomic_pointer_compare_and_exchange() was changed to > g_atomic_pointer_set(). For some reason I was not able to get code compiled > with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do > not see a need to use g_atomic_pointer_compare_and_exchange(), since > m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8283218: Update GStreamer to 1.20.1 [v4] - Changes: - all: https://git.openjdk.java.net/jfx/pull/768/files - new: https://git.openjdk.java.net/jfx/pull/768/files/51cc1e0f..a29cd34b Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=768=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx=768=02-03 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v3]
On Fri, 15 Apr 2022 23:29:54 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp >> g_atomic_pointer_compare_and_exchange() was changed to >> g_atomic_pointer_set(). For some reason I was not able to get code compiled >> with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do >> not see a need to use g_atomic_pointer_compare_and_exchange(), since >> m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v3] I see one remaining build failure on Ubuntu 16.04, which should be easy to fix: ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:367:3: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration] 367 | memcpy (dup_data, data, size); | ^~ ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:367:3: warning: incompatible implicit declaration of built-in function 'memcpy' ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:27:1: note: include '' or provide a declaration of 'memcpy' 26 | #include +++ |+#include 27 | In file included from ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytewriter.h:25, from ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytewriter.c:26: ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h: In function 'gst_byte_reader_dup_data_unchecked': ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:367:3: error: implicit declaration of function 'memcpy' [-Werror=implicit-function-declaration] 367 | memcpy (dup_data, data, size); | ^~ ../../../gstreamer-lite/gstreamer/libs/gst/base/gstbytereader.h:367:3: warning: incompatible implicit declaration of built-in function 'memcpy' The workaround you needed to do this time suggests we will need a different approach for the next update. I think we will need to consider one of two things: 1. Build and link glib-lite on Linux, as we do for the other platforms 2. Bump the minimum version of GLib needed to build or run JavaFX media. This would mean we would no longer run on Ubuntu 16.0.4 (and probably older versions of RHEL / Oracle Linux). We can decide as it gets closer to the next update. - PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v3]
On Fri, 15 Apr 2022 23:29:54 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp >> g_atomic_pointer_compare_and_exchange() was changed to >> g_atomic_pointer_set(). For some reason I was not able to get code compiled >> with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do >> not see a need to use g_atomic_pointer_compare_and_exchange(), since >> m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v3] Update GStreamer to 1.20.1 [v2] - Made caps writable before changing them in qtdemux, otherwise values are not set and critical error printed in console. - Fixed compilation error in GstAudioSpectrum.cpp by casting pointer. - Added g_abort() if it is not defined (building with older GLib). Update GStreamer to 1.20.1 [v3] - Added -Werror=deprecated-declarations and GLIB_VERSION_MIN_REQUIRED/GLIB_VERSION_MAX_ALLOWED=2.48.0 to Linux makefiles. GLIB_VERSION_MIN_REQUIRED/GLIB_VERSION_MAX_ALLOWED will give deprecated warnings when code uses APIs from GLib which where added after 2.48.0. -Werror=deprecated-declarations will fail build if such warning detected. This is needed to make sure that we can build and run with older GLib starting with 2.48.0 and up. - avplugin does not have -Werror=deprecated-declarations, because avplugin uses deprecated APIs from libavcodec and build fails with this flag and fixing avplugin is out of scope of GStreamer update. - Fixed build issues that were discovered after above was implemented, so we can build/run with GLib 2.48.0 and up. - PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v3]
> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp > g_atomic_pointer_compare_and_exchange() was changed to > g_atomic_pointer_set(). For some reason I was not able to get code compiled > with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do > not see a need to use g_atomic_pointer_compare_and_exchange(), since > m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8283218: Update GStreamer to 1.20.1 [v3] - Changes: - all: https://git.openjdk.java.net/jfx/pull/768/files - new: https://git.openjdk.java.net/jfx/pull/768/files/b45b1fb1..51cc1e0f Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=768=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=768=01-02 Stats: 211 lines in 11 files changed: 210 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v2]
On Wed, 13 Apr 2022 07:48:44 GMT, Alexander Matveev wrote: >> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. >> - No changes to our code, except in GstAudioSpectrum.cpp >> g_atomic_pointer_compare_and_exchange() was changed to >> g_atomic_pointer_set(). For some reason I was not able to get code compiled >> with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do >> not see a need to use g_atomic_pointer_compare_and_exchange(), since >> m_pHolder always equals to old_holder. >> - Tested on all platforms with all supported media streams. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8283218: Update GStreamer to 1.20.1 [v2] The updated version gets past the earlier error, but still fails: ../../../gstreamer-lite/gstreamer/gst/gstelementfactory.c:494:28: error: implicit declaration of function 'g_object_new_with_properties'; did you mean 'g_object_class_list_properties'? [-Werror=implicit-function-declaration] 494 | element = (GstElement *) g_object_new_with_properties (factory->type, n, |^~~~ |g_object_class_list_properties - PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1 [v2]
> - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp > g_atomic_pointer_compare_and_exchange() was changed to > g_atomic_pointer_set(). For some reason I was not able to get code compiled > with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do > not see a need to use g_atomic_pointer_compare_and_exchange(), since > m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8283218: Update GStreamer to 1.20.1 [v2] - Changes: - all: https://git.openjdk.java.net/jfx/pull/768/files - new: https://git.openjdk.java.net/jfx/pull/768/files/0d515159..b45b1fb1 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=768=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=768=00-01 Stats: 10 lines in 3 files changed: 8 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768
Re: RFR: 8283218: Update GStreamer to 1.20.1
On Fri, 8 Apr 2022 06:49:59 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.20.1 and GLib updated to 2.72.0. > - No changes to our code, except in GstAudioSpectrum.cpp > g_atomic_pointer_compare_and_exchange() was changed to > g_atomic_pointer_set(). For some reason I was not able to get code compiled > with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do > not see a need to use g_atomic_pointer_compare_and_exchange(), since > m_pHolder always equals to old_holder. > - Tested on all platforms with all supported media streams. This still uses the system Glib library on Linux, right? What Linux platforms have you tried this on? It fails for me on my local Ubuntu 16.04 system. In file included from ../../../gstreamer-lite/gstreamer/gst/gstbuffer.c:137: ../../../gstreamer-lite/gstreamer/gst/gstbuffer.c: In function 'gst_buffer_new_m emdup': ../../../gstreamer-lite/gstreamer/gst/glib-compat-private.h:34:90: error: implicit declaration of function 'g_abort'; did you mean 'abort'? [-Werror=implicit-function-declaration] 34 | #define g_memdup2(ptr,sz) ((G_LIKELY(((guint64)(sz)) < G_MAXUINT)) ? g_memdup(ptr,sz) : (g_abort(),NULL)) | ^~~ We compile with `-Werror=implicit-function-declaration`, so this fails the build. - PR: https://git.openjdk.java.net/jfx/pull/768
RFR: 8283218: Update GStreamer to 1.20.1
- GStreamer updated to 1.20.1 and GLib updated to 2.72.0. - No changes to our code, except in GstAudioSpectrum.cpp g_atomic_pointer_compare_and_exchange() was changed to g_atomic_pointer_set(). For some reason I was not able to get code compiled with g_atomic_pointer_compare_and_exchange() used from C++ code. Also, I do not see a need to use g_atomic_pointer_compare_and_exchange(), since m_pHolder always equals to old_holder. - Tested on all platforms with all supported media streams. - Commit messages: - 8283218: Update GStreamer to 1.20.1 Changes: https://git.openjdk.java.net/jfx/pull/768/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=768=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283218 Stats: 38793 lines in 410 files changed: 21828 ins; 6021 del; 10944 mod Patch: https://git.openjdk.java.net/jfx/pull/768.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/768/head:pull/768 PR: https://git.openjdk.java.net/jfx/pull/768
[jfx11u] Integrated: 8268219: hlsprogressbuffer should provide PTS after GStreamer update
On Thu, 19 Aug 2021 16:05:20 GMT, Ambarish Rapte wrote: > This is clean backport. > Tested the patch in a > [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). > Backports tested in above branch are : > [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), > [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), > [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), > [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), > [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), > [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), > [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), > [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), > [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), > [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) This pull request has now been integrated. Changeset: cb152a8e Author:Ambarish Rapte URL: https://git.openjdk.java.net/jfx11u/commit/cb152a8ec20fb06416be8d8646d88b2696926acd Stats: 19 lines in 2 files changed: 13 ins; 4 del; 2 mod 8268219: hlsprogressbuffer should provide PTS after GStreamer update Backport-of: 98138c84a7f286731ad12dd5c533cd3fa265bf56 - PR: https://git.openjdk.java.net/jfx11u/pull/41
[jfx11u] RFR: 8268219: hlsprogressbuffer should provide PTS after GStreamer update
This is clean backport. Tested the patch in a [branch](https://github.com/arapte/jfx11u/tree/cherry-pick). Backports tested in above branch are : [JDK-8264737](https://bugs.openjdk.java.net/browse/JDK-8264737), [JDK-8266860](https://bugs.openjdk.java.net/browse/JDK-8266860), [JDK-8267819](https://bugs.openjdk.java.net/browse/JDK-8267819), [JDK-8268219](https://bugs.openjdk.java.net/browse/JDK-8268219), [JDK-8231558](https://bugs.openjdk.java.net/browse/JDK-8231558), [JDK-8268718](https://bugs.openjdk.java.net/browse/JDK-8268718), [JDK-8265400](https://bugs.openjdk.java.net/browse/JDK-8265400), [JDK-8267121](https://bugs.openjdk.java.net/browse/JDK-8267121), [JDK-8267858](https://bugs.openjdk.java.net/browse/JDK-8267858), [JDK-8267892](https://bugs.openjdk.java.net/browse/JDK-8267892) - Commit messages: - 8268219: hlsprogressbuffer should provide PTS after GStreamer update Changes: https://git.openjdk.java.net/jfx11u/pull/41/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u=41=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268219 Stats: 19 lines in 2 files changed: 13 ins; 4 del; 2 mod Patch: https://git.openjdk.java.net/jfx11u/pull/41.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/41/head:pull/41 PR: https://git.openjdk.java.net/jfx11u/pull/41
[jfx11u] Integrated: 8269147: Update GStreamer to version 1.18.4
On Tue, 17 Aug 2021 17:22:44 GMT, Kevin Rushforth wrote: > Clean backport of third-party update to GStreamer 1.18.4. > > As an FYI, I tested this patch in my > [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) > branch, which has the aggregate set of patches for the following bugs: > [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), > [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), > [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), > [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), > [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), > [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), > [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). This pull request has now been integrated. Changeset: 49ff8f6f Author:Kevin Rushforth URL: https://git.openjdk.java.net/jfx11u/commit/49ff8f6fc7dabcd18cb2447852d9e3002e6f3152 Stats: 178 lines in 18 files changed: 82 ins; 3 del; 93 mod 8269147: Update GStreamer to version 1.18.4 Backport-of: 098c0f393ef0849e140c9efd4d083f3282e1fa0e - PR: https://git.openjdk.java.net/jfx11u/pull/32
[jfx11u] RFR: 8269147: Update GStreamer to version 1.18.4
Clean backport of third-party update to GStreamer 1.18.4. As an FYI, I tested this patch in my [test-kcr-11.0.13](https://github.com/kevinrushforth/jfx11u/tree/test-kcr-11.0.13) branch, which has the aggregate set of patches for the following bugs: [JDK-8211308](https://bugs.openjdk.java.net/browse/JDK-8211308), [JDK-8268915](https://bugs.openjdk.java.net/browse/JDK-8268915), [JDK-8269147](https://bugs.openjdk.java.net/browse/JDK-8269147), [JDK-8269131](https://bugs.openjdk.java.net/browse/JDK-8269131), [JDK-8268849](https://bugs.openjdk.java.net/browse/JDK-8268849), [JDK-8270479](https://bugs.openjdk.java.net/browse/JDK-8270479), [JDK-8272329](https://bugs.openjdk.java.net/browse/JDK-8272329). - Commit messages: - 8269147: Update GStreamer to version 1.18.4 Changes: https://git.openjdk.java.net/jfx11u/pull/32/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u=32=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269147 Stats: 178 lines in 18 files changed: 82 ins; 3 del; 93 mod Patch: https://git.openjdk.java.net/jfx11u/pull/32.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/32/head:pull/32 PR: https://git.openjdk.java.net/jfx11u/pull/32
Integrated: 8269147: Update GStreamer to version 1.18.4
On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. This pull request has now been integrated. Changeset: 098c0f39 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/098c0f393ef0849e140c9efd4d083f3282e1fa0e Stats: 178 lines in 18 files changed: 82 ins; 3 del; 93 mod 8269147: Update GStreamer to version 1.18.4 Reviewed-by: kcr, sykora - PR: https://git.openjdk.java.net/jfx/pull/541
Re: RFR: 8269147: Update GStreamer to version 1.18.4
On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. We've also tested the changes on our build infrastructure and it all worked fine. - Marked as reviewed by sykora (Author). PR: https://git.openjdk.java.net/jfx/pull/541
Re: RFR: 8269147: Update GStreamer to version 1.18.4
On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. The code changes look good. I tested it on all three platforms. No problems. @tiainen can be the second reviewer on this. - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/541
Re: RFR: 8269147: Update GStreamer to version 1.18.4
On Thu, 24 Jun 2021 02:50:08 GMT, Alexander Matveev wrote: > - GStreamer updated to 1.18.4. > - Tested on all platforms with all formats. Those changes look reasonable. It seems that mainly windows is impacted. @tiainen can you double-check the static windows builds are ok with those changes? - PR: https://git.openjdk.java.net/jfx/pull/541
RFR: 8269147: Update GStreamer to version 1.18.4
- GStreamer updated to 1.18.4. - Tested on all platforms with all formats. - Commit messages: - 8269147: Update GStreamer to version 1.18.4 Changes: https://git.openjdk.java.net/jfx/pull/541/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=541=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8269147 Stats: 178 lines in 18 files changed: 82 ins; 3 del; 93 mod Patch: https://git.openjdk.java.net/jfx/pull/541.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/541/head:pull/541 PR: https://git.openjdk.java.net/jfx/pull/541
Integrated: 8268219: hlsprogressbuffer should provide PTS after GStreamer update
On Sat, 12 Jun 2021 00:10:55 GMT, Alexander Matveev wrote: > - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. > - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. > After GStreamer update mpregparser no longer tries to figure out timestamps > if stream in time format and it will assume that upstream provides > timestamps. Fixed by providing starting timestamp at the beginning or after > seek. In this case mpegparser able to figure out timestamps and will provide > them for each buffer downstream. > - Segment start was also incorrect it should be seek position, otherwise > after seek playback waits for seek time. For example if we seek to 2 min, > mediaplayer hangs for 2 min and only after that resumes playback. I think it > worked before, since mpegparser handled PTS before. This pull request has now been integrated. Changeset: 98138c84 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/98138c84a7f286731ad12dd5c533cd3fa265bf56 Stats: 19 lines in 2 files changed: 13 ins; 4 del; 2 mod 8268219: hlsprogressbuffer should provide PTS after GStreamer update Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/532
Re: RFR: 8268219: hlsprogressbuffer should provide PTS after GStreamer update
On Sat, 12 Jun 2021 00:10:55 GMT, Alexander Matveev wrote: > - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. > - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. > After GStreamer update mpregparser no longer tries to figure out timestamps > if stream in time format and it will assume that upstream provides > timestamps. Fixed by providing starting timestamp at the beginning or after > seek. In this case mpegparser able to figure out timestamps and will provide > them for each buffer downstream. > - Segment start was also incorrect it should be seek position, otherwise > after seek playback waits for seek time. For example if we seek to 2 min, > mediaplayer hangs for 2 min and only after that resumes playback. I think it > worked before, since mpegparser handled PTS before. Looks good to me, verified on macOS Mojave 10.14.6. - Marked as reviewed by arapte (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/532
Re: RFR: 8268219: hlsprogressbuffer should provide PTS after GStreamer update
On Sat, 12 Jun 2021 00:10:55 GMT, Alexander Matveev wrote: > - Reverted JDK-8268152 fix in gstbaseparse.c, since it is no longer needed. > - Our hlsprogressbuffer outputs buffers in time format, but without any PTS. > After GStreamer update mpregparser no longer tries to figure out timestamps > if stream in time format and it will assume that upstream provides > timestamps. Fixed by providing starting timestamp at the beginning or after > seek. In this case mpegparser able to figure out timestamps and will provide > them for each buffer downstream. > - Segment start was also incorrect it should be seek position, otherwise > after seek playback waits for seek time. For example if we seek to 2 min, > mediaplayer hangs for 2 min and only after that resumes playback. I think it > worked before, since mpegparser handled PTS before. Looks good. Tested on all three platforms. - Marked as reviewed by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/532
Integrated: 8252060: gstreamer fails to build with gcc 10
On Tue, 25 Aug 2020 01:00:31 GMT, Alexander Matveev wrote: > Fixed by defining GST_API as GST_EXPORT for gcc compiler as per Kevin > proposed solution. On Windows we do not need to > define GST_API, since we using .def file to export symbols. This pull request has now been integrated. Changeset: 7a4bd9b2 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/7a4bd9b2 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod 8252060: gstreamer fails to build with gcc 10 Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/287
Re: RFR: 8252060: gstreamer fails to build with gcc 10
On Tue, 25 Aug 2020 01:00:31 GMT, Alexander Matveev wrote: > Fixed by defining GST_API as GST_EXPORT for gcc compiler as per Kevin > proposed solution. On Windows we do not need to > define GST_API, since we using .def file to export symbols. Marked as reviewed by kcr (Lead). - PR: https://git.openjdk.java.net/jfx/pull/287
RFR: 8252060: gstreamer fails to build with gcc 10
Fixed by defining GST_API as GST_EXPORT for gcc compiler as per Kevin proposed solution. On Windows we do not need to define GST_API, since we using .def file to export symbols. - Commit messages: - 8252060: gstreamer fails to build with gcc 10 Changes: https://git.openjdk.java.net/jfx/pull/287/files Webrev: https://webrevs.openjdk.java.net/jfx/287/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252060 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/287.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/287/head:pull/287 PR: https://git.openjdk.java.net/jfx/pull/287
Re: [Integrated] RFR: 8230610: Upgrade GStreamer to the latest 1.16.1
Changeset: 798afbca Author:Alexander Matveev Date: 2019-11-26 22:33:00 + URL: https://git.openjdk.java.net/jfx/commit/798afbca 8230610: Upgrade GStreamer to version 1.16.1 8230609: Upgrade glib to version 2.62.2 Reviewed-by: kcr, jvos ! modules/javafx.media/src/main/legal/glib.md ! modules/javafx.media/src/main/legal/gstreamer.md ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/osx/config.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/osx/glibconfig.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/dirent/dirent.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/dirent/dirent.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/config.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/glib-lite.def - modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/glib-liteD.def ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/glibconfig.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/gmoduleconf.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/build/win32/vs100/msvc_recommended_pragmas.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/deprecated/gthread.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/galloca.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/garray.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/garray.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gasyncqueue.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gasyncqueue.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gatomic.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gatomic.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbacktrace.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbase64.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbitlock.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbitlock.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbookmarkfile.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbookmarkfile.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbytes.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gbytes.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gcharset.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gcharset.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gchecksum.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gconstructor.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gconvert.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gconvert.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdataset.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdataset.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdatasetprivate.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdate.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdate.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdatetime.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdatetime.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdir.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdir.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/genviron.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gerror.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gerror.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gfileutils.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gfileutils.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ggettext.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghash.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghash.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghmac.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghook.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghook.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/ghostutils.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/giochannel.c ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/giochannel.h ! modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib
Re: [Approved] RFR: 8230610: Upgrade GStreamer to version 1.16.1
On Thu, 21 Nov 2019 01:00:33 GMT, Alexander Matveev wrote: > - Upgraded GStreamer to 1.16.1 > - Upgraded GLib to 2.62.2. > - Removed glib-liteD.def, since it almost identical to release version > glib-lite.def. Debug build will use glib-lite.def. > - No changes to other parts of code, except minor changes to makefiles. > > > > Commits: > - 98e1157b: 8230610: Upgrade GStreamer to the latest 1.16.1 > > Changes: https://git.openjdk.java.net/jfx/pull/48/files > Webrev: https://webrevs.openjdk.java.net/jfx/48/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230610 > Stats: 46378 lines in 491 files changed: 17416 ins; 6527 del; 22435 mod > Patch: https://git.openjdk.java.net/jfx/pull/48.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/48/head:pull/48 build + sanity checks pass on windows/linux/mac Approved by jvos (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/48
Re: [Approved] RFR: 8230610: Upgrade GStreamer to the latest 1.16.1
On Thu, 21 Nov 2019 23:39:36 GMT, Kevin Rushforth wrote: > On Thu, 21 Nov 2019 01:00:33 GMT, Alexander Matveev > wrote: > >> - Upgraded GStreamer to 1.16.1 >> - Upgraded GLib to 2.62.2. >> - Removed glib-liteD.def, since it almost identical to release version >> glib-lite.def. Debug build will use glib-lite.def. >> - No changes to other parts of code, except minor changes to makefiles. >> >> ---- >> >> Commits: >> - 98e1157b: 8230610: Upgrade GStreamer to the latest 1.16.1 >> >> Changes: https://git.openjdk.java.net/jfx/pull/48/files >> Webrev: https://webrevs.openjdk.java.net/jfx/48/webrev.00 >> Issue: https://bugs.openjdk.java.net/browse/JDK-8230610 >> Stats: 46378 lines in 491 files changed: 17416 ins; 6527 del; 22435 mod >> Patch: https://git.openjdk.java.net/jfx/pull/48.diff >> Fetch: git fetch https://git.openjdk.java.net/jfx pull/48/head:pull/48 > > Looks good to me. I did have one question, but it's just for my information. > > modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdate.c > line 2601: > >> 2600: #pragma GCC diagnostic push >> 2601: #pragma GCC diagnostic ignored "-Wformat-nonliteral" >> 2602: #endif // G_OS_WIN32 > > Did you add this because it will fail on 32-bit Windows without it? This > logic is otherwise untouched as part of the upgrade. > > > > Approved by kcr (Lead). G_OS_WIN32 defined for both 32 and 64-bit Windows. Yes, I disable it because build fails on Windows due to unknown GCC pragma. PR: https://git.openjdk.java.net/jfx/pull/48
Re: [Approved] RFR: 8230610: Upgrade GStreamer to the latest 1.16.1
On Thu, 21 Nov 2019 01:00:33 GMT, Alexander Matveev wrote: > - Upgraded GStreamer to 1.16.1 > - Upgraded GLib to 2.62.2. > - Removed glib-liteD.def, since it almost identical to release version > glib-lite.def. Debug build will use glib-lite.def. > - No changes to other parts of code, except minor changes to makefiles. > > > > Commits: > - 98e1157b: 8230610: Upgrade GStreamer to the latest 1.16.1 > > Changes: https://git.openjdk.java.net/jfx/pull/48/files > Webrev: https://webrevs.openjdk.java.net/jfx/48/webrev.00 > Issue: https://bugs.openjdk.java.net/browse/JDK-8230610 > Stats: 46378 lines in 491 files changed: 17416 ins; 6527 del; 22435 mod > Patch: https://git.openjdk.java.net/jfx/pull/48.diff > Fetch: git fetch https://git.openjdk.java.net/jfx pull/48/head:pull/48 Looks good to me. I did have one question, but it's just for my information. modules/javafx.media/src/main/native/gstreamer/3rd_party/glib/glib/gdate.c line 2601: > 2600: #pragma GCC diagnostic push > 2601: #pragma GCC diagnostic ignored "-Wformat-nonliteral" > 2602: #endif // G_OS_WIN32 Did you add this because it will fail on 32-bit Windows without it? This logic is otherwise untouched as part of the upgrade. Approved by kcr (Lead). PR: https://git.openjdk.java.net/jfx/pull/48
RFR: 8230610: Upgrade GStreamer to the latest 1.16.1
- Upgraded GStreamer to 1.16.1 - Upgraded GLib to 2.62.2. - Removed glib-liteD.def, since it almost identical to release version glib-lite.def. Debug build will use glib-lite.def. - No changes to other parts of code, except minor changes to makefiles. Commits: - 98e1157b: 8230610: Upgrade GStreamer to the latest 1.16.1 Changes: https://git.openjdk.java.net/jfx/pull/48/files Webrev: https://webrevs.openjdk.java.net/jfx/48/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8230610 Stats: 46378 lines in 491 files changed: 17416 ins; 6527 del; 22435 mod Patch: https://git.openjdk.java.net/jfx/pull/48.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/48/head:pull/48 PR: https://git.openjdk.java.net/jfx/pull/48
Re: GStreamer
It’s been 11 years… https://bugs.openjdk.java.net/browse/JDK-8091063 <https://bugs.openjdk.java.net/browse/JDK-8091063> The gstreamer integration should have been a pluggable module into the media framework from the beginning. I would love to see that corrected. Refactoring towards a more usable media framework that has the necessary hooks to make it more than a very basic player with limited codec support gets a big plus one from me. I only wish I had the time to help more with actual code. Regards, Scott > On May 14, 2019, at 8:27 PM, Curtis Ruck wrote: > > Gstreamer-javafx examples: > https://github.com/gstreamer-java/gst1-javafx-examples > <https://github.com/gstreamer-java/gst1-javafx-examples> > > I admire how javafx is wrapping gstreamer compared to the above example. > I'd like to expand the support for more Media types and some method to > access alternative stream data like closed captioning. I don't want to > reinvent the wheel, I just prefer javafx as a modern, portable framework > over alternatives. Java has always had poor compatibility with media > frameworks in the past, > > I look at the ideal way for me to accomplish my goals above as easily as > possible (if I we're King for a little bit) would be to create a bolt-on > javafx-media-extras library that pulled in additional gstreamer plugins. I > definitely don't want to break downstream interfaces or expose additional > non-public APIs, I just want graceful API expansion that allows javafx to > compete against just about every other UI toolkit. > > On Tue, May 14, 2019, 20:14 Kevin Rushforth <mailto:kevin.rushfo...@oracle.com>> > wrote: > >> When you say "gstreamer-javafx" I don't know quite what you mean. The >> gstreamer-lite library is an internal component of JavaFX and it not >> something meant to be used by itself. Refactoring the native code in the >> javafx.media module just so it could be used independently from JavaFX >> doesn't seem like something that would benefit JavaFX or make it easier to >> maintain. Rather it could create defacto interfaces that could easily break >> when we upgrade gstreamer (which we do from time to time to keep up with >> bug fixes, etc). It's the same reason we don't support accessing Prism or >> Glass directly. >> >> -- Kevin >> >> >> On 5/14/2019 5:04 PM, Curtis Ruck wrote: >> >> Why is splitting gstreamer-lite out not on the table, curiosity? >> >> It feels a little silly to end up with two gstreamer libraries getting >> used by a single application. The gstreamer-javafx examples are horrible >> compared to the existing javafx-media API. >> >> >> >> On Tue, May 14, 2019, 19:55 Kevin Rushforth >> wrote: >> >>> We don't currently plan to add support for pluggable codecs, but that >>> might be something that the community could do, although it would be a >>> large effort. As for splitting gstreamer-lite out of javafx.media, we >>> are not likely to consider that. >>> >>> -- Kevin >>> >>> >>> On 5/13/2019 11:30 AM, Curtis Ruck wrote: >>>> I'm investigating a new application that would need tighter integration >>>> with gstreamer. Is there a way to add additional gstreamer plugins and >>>> media types without having to maintain a fork of javafx-media? >>>> >>>> Ideally, if i did end up needing a fork, i was thinking it would make >>> sense >>>> to split gstreamer-lite out of javafx-media into it's own project so I >>>> could easily swap in a full gstreamer dependency with 3rd project for >>> the >>>> additional media types. >>>> >>>> Background: ideally looking to pull in udpsource and some additional >>>> pipeline plugins (GPU decoding and some subtitle related plugins). >>>> >>>> Thoughts? >>>> >>>> -- >>>> Curtis Ruck
Re: GStreamer
Gstreamer-javafx examples: https://github.com/gstreamer-java/gst1-javafx-examples I admire how javafx is wrapping gstreamer compared to the above example. I'd like to expand the support for more Media types and some method to access alternative stream data like closed captioning. I don't want to reinvent the wheel, I just prefer javafx as a modern, portable framework over alternatives. Java has always had poor compatibility with media frameworks in the past, I look at the ideal way for me to accomplish my goals above as easily as possible (if I we're King for a little bit) would be to create a bolt-on javafx-media-extras library that pulled in additional gstreamer plugins. I definitely don't want to break downstream interfaces or expose additional non-public APIs, I just want graceful API expansion that allows javafx to compete against just about every other UI toolkit. On Tue, May 14, 2019, 20:14 Kevin Rushforth wrote: > When you say "gstreamer-javafx" I don't know quite what you mean. The > gstreamer-lite library is an internal component of JavaFX and it not > something meant to be used by itself. Refactoring the native code in the > javafx.media module just so it could be used independently from JavaFX > doesn't seem like something that would benefit JavaFX or make it easier to > maintain. Rather it could create defacto interfaces that could easily break > when we upgrade gstreamer (which we do from time to time to keep up with > bug fixes, etc). It's the same reason we don't support accessing Prism or > Glass directly. > > -- Kevin > > > On 5/14/2019 5:04 PM, Curtis Ruck wrote: > > Why is splitting gstreamer-lite out not on the table, curiosity? > > It feels a little silly to end up with two gstreamer libraries getting > used by a single application. The gstreamer-javafx examples are horrible > compared to the existing javafx-media API. > > > > On Tue, May 14, 2019, 19:55 Kevin Rushforth > wrote: > >> We don't currently plan to add support for pluggable codecs, but that >> might be something that the community could do, although it would be a >> large effort. As for splitting gstreamer-lite out of javafx.media, we >> are not likely to consider that. >> >> -- Kevin >> >> >> On 5/13/2019 11:30 AM, Curtis Ruck wrote: >> > I'm investigating a new application that would need tighter integration >> > with gstreamer. Is there a way to add additional gstreamer plugins and >> > media types without having to maintain a fork of javafx-media? >> > >> > Ideally, if i did end up needing a fork, i was thinking it would make >> sense >> > to split gstreamer-lite out of javafx-media into it's own project so I >> > could easily swap in a full gstreamer dependency with 3rd project for >> the >> > additional media types. >> > >> > Background: ideally looking to pull in udpsource and some additional >> > pipeline plugins (GPU decoding and some subtitle related plugins). >> > >> > Thoughts? >> > >> > -- >> > Curtis Ruck >> >> >
Re: GStreamer
When you say "gstreamer-javafx" I don't know quite what you mean. The
gstreamer-lite library is an internal component of JavaFX and it not
something meant to be used by itself. Refactoring the native code in the
javafx.media module just so it could be used independently from JavaFX
doesn't seem like something that would benefit JavaFX or make it easier
to maintain. Rather it could create defacto interfaces that could easily
break when we upgrade gstreamer (which we do from time to time to keep
up with bug fixes, etc). It's the same reason we don't support accessing
Prism or Glass directly.
-- Kevin
On 5/14/2019 5:04 PM, Curtis Ruck wrote:
Why is splitting gstreamer-lite out not on the table, curiosity?
It feels a little silly to end up with two gstreamer libraries getting
used by a single application. The gstreamer-javafx examples are
horrible compared to the existing javafx-media API.
On Tue, May 14, 2019, 19:55 Kevin Rushforth
mailto:kevin.rushfo...@oracle.com>> wrote:
We don't currently plan to add support for pluggable codecs, but that
might be something that the community could do, although it would
be a
large effort. As for splitting gstreamer-lite out of javafx.media, we
are not likely to consider that.
-- Kevin
On 5/13/2019 11:30 AM, Curtis Ruck wrote:
> I'm investigating a new application that would need tighter
integration
> with gstreamer. Is there a way to add additional gstreamer
plugins and
> media types without having to maintain a fork of javafx-media?
>
> Ideally, if i did end up needing a fork, i was thinking it would
make sense
> to split gstreamer-lite out of javafx-media into it's own
project so I
> could easily swap in a full gstreamer dependency with 3rd
project for the
> additional media types.
>
> Background: ideally looking to pull in udpsource and some additional
> pipeline plugins (GPU decoding and some subtitle related plugins).
>
> Thoughts?
>
> --
> Curtis Ruck
Re: GStreamer
Why is splitting gstreamer-lite out not on the table, curiosity? It feels a little silly to end up with two gstreamer libraries getting used by a single application. The gstreamer-javafx examples are horrible compared to the existing javafx-media API. On Tue, May 14, 2019, 19:55 Kevin Rushforth wrote: > We don't currently plan to add support for pluggable codecs, but that > might be something that the community could do, although it would be a > large effort. As for splitting gstreamer-lite out of javafx.media, we > are not likely to consider that. > > -- Kevin > > > On 5/13/2019 11:30 AM, Curtis Ruck wrote: > > I'm investigating a new application that would need tighter integration > > with gstreamer. Is there a way to add additional gstreamer plugins and > > media types without having to maintain a fork of javafx-media? > > > > Ideally, if i did end up needing a fork, i was thinking it would make > sense > > to split gstreamer-lite out of javafx-media into it's own project so I > > could easily swap in a full gstreamer dependency with 3rd project for the > > additional media types. > > > > Background: ideally looking to pull in udpsource and some additional > > pipeline plugins (GPU decoding and some subtitle related plugins). > > > > Thoughts? > > > > -- > > Curtis Ruck > >
Re: GStreamer
We don't currently plan to add support for pluggable codecs, but that might be something that the community could do, although it would be a large effort. As for splitting gstreamer-lite out of javafx.media, we are not likely to consider that. -- Kevin On 5/13/2019 11:30 AM, Curtis Ruck wrote: I'm investigating a new application that would need tighter integration with gstreamer. Is there a way to add additional gstreamer plugins and media types without having to maintain a fork of javafx-media? Ideally, if i did end up needing a fork, i was thinking it would make sense to split gstreamer-lite out of javafx-media into it's own project so I could easily swap in a full gstreamer dependency with 3rd project for the additional media types. Background: ideally looking to pull in udpsource and some additional pipeline plugins (GPU decoding and some subtitle related plugins). Thoughts? -- Curtis Ruck
GStreamer
I'm investigating a new application that would need tighter integration with gstreamer. Is there a way to add additional gstreamer plugins and media types without having to maintain a fork of javafx-media? Ideally, if i did end up needing a fork, i was thinking it would make sense to split gstreamer-lite out of javafx-media into it's own project so I could easily swap in a full gstreamer dependency with 3rd project for the additional media types. Background: ideally looking to pull in udpsource and some additional pipeline plugins (GPU decoding and some subtitle related plugins). Thoughts? -- Curtis Ruck
Re: RFR: JDK-8214185: Upgrade GStreamer to the latest (1.14.4) version
+1 -- Kevin On 1/17/2019 3:48 PM, Alexander Matveev wrote: Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8214185 - Upgrade for GStreamer (1.14.4) and GLib (2.58.2). Thanks, Alexander
RFR: JDK-8214185: Upgrade GStreamer to the latest (1.14.4) version
Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8214185 - Upgrade for GStreamer (1.14.4) and GLib (2.58.2). Thanks, Alexander
[11] Review request for 8199527: Upgrade GStreamer to 1.14
Hi Kevin, Please review the following: https://bugs.openjdk.java.net/browse/JDK-8199527 Upgraded GStreamer to 1.14. Thanks, Alexander
[9] Review request: 8174971: Missing modified source location in third-party WebKit, GStreamer, and Glib licenses
Alexander & Guru, Please review the following addition to the 3rd-party license files for media & web: https://bugs.openjdk.java.net/browse/JDK-8174971 http://cr.openjdk.java.net/~kcr/8174971/webrev.00/ -- Kevin
[9] Review request for 8136480: Warnings printed to console from new GStreamer code
Hi Kirill, https://bugs.openjdk.java.net/browse/JDK-8136480 Please review the following: http://cr.openjdk.java.net/~almatvee/8136480/webrev.00 This warning message is printed, because we using 0.10 style caps for raw video. I do not see any needs to switch caps to new style. As solution this warning message is disabled. Thanks, Alexander
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
[9] Review request for 8134996: GSTREAMER_LITE conditional compilation should be used for all changes in GStreamer
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: hg: openjfx/9-dev/rt: 8043352: JEP 257: Update JavaFX/Media to Newer Version of GStreamer
> On Aug 27, 2015, at 6:08 PM, kevin.rushfo...@oracle.com wrote: > > Changeset: 241f9696e3ad > Author:almatvee > Date: 2015-08-27 14:35 -0700 > URL: http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/241f9696e3ad > > 8043352: JEP 257: Update JavaFX/Media to Newer Version of GStreamer > Reviewed-by: stayer, ddehaven, kcr <applause!> -DrD-
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
Just pushed the updated GStreamer for JEP 257
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
JEP 257: Update JavaFX/Media to Newer Version of GStreamer
New JEP Candidate: http://openjdk.java.net/jeps/257 - Mark
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
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!) 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.comwrote: 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 pkg-config./ For GLib you can disable iconv in configure. This is the next step. Let's start with libffi first. I'm assuming this is something to do with the fact it can't find libffi, but I'm unaware of how to tell it that libffi is in the given folder! I'm also assuming that calling config / make etc. manually is the way to go for the time being - I think I'd be at even more of a loss trying to integrate it into the gradle build script. The reason for this to be such non trivial is/was the download size. We aimed the minimal possible download size. This is probably not an issue anymore and we can switch to simpler solutions like you originally did - download, unzip, run configure and here we go. K
Re: Adding GStreamer plugins
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
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
https://javafx-jira.kenai.com/browse/RT-18009 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. Steve 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. 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.comwrote: 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
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
Hi Kirill, Many thanks for the detailed response, that's incredibly helpful. I had noted already that you were using gstreamer 0.10.35 from downloading the gstreamer modifications for JFX8 from Oracle's site, so was using the appropriate version of the plugin already to try to ensure no compatibility issues arose. 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 @184 NONAME gst_byte_writer_free @185 NONAME gst_byte_writer_new_with_size @186 NONAME (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.) 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! Many thanks, Michael On 25 March 2014 11:00, Kirill Kirichenko kirill.kiriche...@oracle.comwrote: 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
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: Adding GStreamer plugins
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
Re: Adding GStreamer plugins
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.comwrote: 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
Re: Adding GStreamer plugins
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! Awesome! 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. Thanks! Richard
Re: Adding GStreamer plugins
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.comwrote: 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
Re: Adding GStreamer plugins
Hi Richard, Sure, I've emailed the patch to Scott and will work on a writeup for others that want to do something similar! (Minor point, is the wiki source in standard MediaWiki style or something else?) 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? Many thanks, Michael On 25 March 2014 23:46, Richard Bair richard.b...@oracle.com wrote: 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! Awesome! 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. Thanks! Richard
Re: Adding GStreamer plugins
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
Hi Michael, On 24.03.2014 4:31, Michael Berry wrote: Hi all, 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. 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! - 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 may just add -PCOMPILE_MEDIA=true as a gradle argument. You may also want to add -PCONF=DebugNative to build debug version (in case if you didn't find that option yet) Regards, Anton. - 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. - The DirectX SDK failed to install for me, Googling found the fix relatively easily ( http://stackoverflow.com/questions/4102259/directx-sdk-june-2010-installation-problems-error-code-s1023), but perhaps this could be included just for reference. - 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? 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! 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? Many thanks, Michael On 23 March 2014 15:32, Michael Berry berry...@gmail.com wrote: Hi Scott, Sure, that's in fact my eventual goal - but in order to successfully get that far I need to work out how to compile OpenJFX with other GStreamer plugins first, and unfortunately at the moment I seem to be getting stuck at that hurdle! Time permitting, I do indeed plan to look at addressing 2684 if I can get that far. Thanks, Michael On 23 March 2014 14:03, Scott Palmer swpal...@gmail.com wrote: I applaud your effort, but please consider while you are doing this: Addressing RT-18009 is good Addressing RT-2684 is way better. https://javafx-jira.kenai.com/browse/RT-2684 If there is a mechanism to write a stub plugin that hooks into the GStreamer plugin mechanism such that end users of JavaFX can write a module (in Java, with the option of using JNI) that supplies the uncompressed frames via a NativeByteBuffer, that would be a great start. Scott On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote: Hi all, I've managed to clone and build OpenJFX successfully, and am now in the process of trying to see how feasible it would be to add support for other media formats. As a first port of call I'm attempting to see if I can get the framework accepting the Matroska plugin, but seem to be coming a bit unstuck on the native side of things (including the plugin with GStreamer.) I've made the relevant modifications on the Java side of things to persuade the platform to accept MKV files and pass them down to the GStreamer layer, and that compiles and runs without any issues. 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
Re: Adding GStreamer plugins
I applaud your effort, but please consider while you are doing this: Addressing RT-18009 is good Addressing RT-2684 is way better. https://javafx-jira.kenai.com/browse/RT-2684 If there is a mechanism to write a stub plugin that hooks into the GStreamer plugin mechanism such that end users of JavaFX can write a module (in Java, with the option of using JNI) that supplies the uncompressed frames via a NativeByteBuffer, that would be a great start. Scott On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote: Hi all, I've managed to clone and build OpenJFX successfully, and am now in the process of trying to see how feasible it would be to add support for other media formats. As a first port of call I'm attempting to see if I can get the framework accepting the Matroska plugin, but seem to be coming a bit unstuck on the native side of things (including the plugin with GStreamer.) I've made the relevant modifications on the Java side of things to persuade the platform to accept MKV files and pass them down to the GStreamer layer, and that compiles and runs without any issues. 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?). - 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 However, after the above I still get the same result having touched none of the native code, that being that GSTMediaPlayer throws a MediaException with flag 257, which seems to mean it couldn't create the required media from the given location. So at this point I'm a bit stuck really - of course, the whole task may be much more complicated than I'm assuming it should be. I'm not even sure if the default gradle sdk task is actually reflecting the changes I've made - certainly gstreamer-lite.dll seems to be exactly the same size as before, though I'm unsure if the additional plugin is meant to be embedded in this file or not. I'm experienced with Java but much less so with C++, and completely new to gradle (as of yesterday.) Is there anything obvious I'm not doing correctly, and if so would someone be kind enough to give me a bit of a nudge in the right direction? Many thanks, Michael
Re: Adding GStreamer plugins
Hi Scott, Sure, that's in fact my eventual goal - but in order to successfully get that far I need to work out how to compile OpenJFX with other GStreamer plugins first, and unfortunately at the moment I seem to be getting stuck at that hurdle! Time permitting, I do indeed plan to look at addressing 2684 if I can get that far. Thanks, Michael On 23 March 2014 14:03, Scott Palmer swpal...@gmail.com wrote: I applaud your effort, but please consider while you are doing this: Addressing RT-18009 is good Addressing RT-2684 is way better. https://javafx-jira.kenai.com/browse/RT-2684 If there is a mechanism to write a stub plugin that hooks into the GStreamer plugin mechanism such that end users of JavaFX can write a module (in Java, with the option of using JNI) that supplies the uncompressed frames via a NativeByteBuffer, that would be a great start. Scott On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote: Hi all, I've managed to clone and build OpenJFX successfully, and am now in the process of trying to see how feasible it would be to add support for other media formats. As a first port of call I'm attempting to see if I can get the framework accepting the Matroska plugin, but seem to be coming a bit unstuck on the native side of things (including the plugin with GStreamer.) I've made the relevant modifications on the Java side of things to persuade the platform to accept MKV files and pass them down to the GStreamer layer, and that compiles and runs without any issues. 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?). - 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 However, after the above I still get the same result having touched none of the native code, that being that GSTMediaPlayer throws a MediaException with flag 257, which seems to mean it couldn't create the required media from the given location. So at this point I'm a bit stuck really - of course, the whole task may be much more complicated than I'm assuming it should be. I'm not even sure if the default gradle sdk task is actually reflecting the changes I've made - certainly gstreamer-lite.dll seems to be exactly the same size as before, though I'm unsure if the additional plugin is meant to be embedded in this file or not. I'm experienced with Java but much less so with C++, and completely new to gradle (as of yesterday.) Is there anything obvious I'm not doing correctly, and if so would someone be kind enough to give me a bit of a nudge in the right direction? Many thanks, Michael -- Thanks, Michael
Re: Adding GStreamer plugins
Hi all, 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. 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! - 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.) - 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. - The DirectX SDK failed to install for me, Googling found the fix relatively easily ( http://stackoverflow.com/questions/4102259/directx-sdk-june-2010-installation-problems-error-code-s1023), but perhaps this could be included just for reference. - 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? 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! 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? Many thanks, Michael On 23 March 2014 15:32, Michael Berry berry...@gmail.com wrote: Hi Scott, Sure, that's in fact my eventual goal - but in order to successfully get that far I need to work out how to compile OpenJFX with other GStreamer plugins first, and unfortunately at the moment I seem to be getting stuck at that hurdle! Time permitting, I do indeed plan to look at addressing 2684 if I can get that far. Thanks, Michael On 23 March 2014 14:03, Scott Palmer swpal...@gmail.com wrote: I applaud your effort, but please consider while you are doing this: Addressing RT-18009 is good Addressing RT-2684 is way better. https://javafx-jira.kenai.com/browse/RT-2684 If there is a mechanism to write a stub plugin that hooks into the GStreamer plugin mechanism such that end users of JavaFX can write a module (in Java, with the option of using JNI) that supplies the uncompressed frames via a NativeByteBuffer, that would be a great start. Scott On Mar 22, 2014, at 9:26 PM, Michael Berry berry...@gmail.com wrote: Hi all, I've managed to clone and build OpenJFX successfully, and am now in the process of trying to see how feasible it would be to add support for other media formats. As a first port of call I'm attempting to see if I can get the framework accepting the Matroska plugin, but seem to be coming a bit unstuck on the native side of things (including the plugin with GStreamer.) I've made the relevant modifications on the Java side of things to persuade the platform to accept MKV files and pass them down to the GStreamer layer, and that compiles and runs without any issues. 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?). - Added all the C files from the first folder mentioned above to the plugins.vcxproj file - Added the relevant files and directory
Adding GStreamer plugins
Hi all, I've managed to clone and build OpenJFX successfully, and am now in the process of trying to see how feasible it would be to add support for other media formats. As a first port of call I'm attempting to see if I can get the framework accepting the Matroska plugin, but seem to be coming a bit unstuck on the native side of things (including the plugin with GStreamer.) I've made the relevant modifications on the Java side of things to persuade the platform to accept MKV files and pass them down to the GStreamer layer, and that compiles and runs without any issues. 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?). - 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 However, after the above I still get the same result having touched none of the native code, that being that GSTMediaPlayer throws a MediaException with flag 257, which seems to mean it couldn't create the required media from the given location. So at this point I'm a bit stuck really - of course, the whole task may be much more complicated than I'm assuming it should be. I'm not even sure if the default gradle sdk task is actually reflecting the changes I've made - certainly gstreamer-lite.dll seems to be exactly the same size as before, though I'm unsure if the additional plugin is meant to be embedded in this file or not. I'm experienced with Java but much less so with C++, and completely new to gradle (as of yesterday.) Is there anything obvious I'm not doing correctly, and if so would someone be kind enough to give me a bit of a nudge in the right direction? Many thanks, Michael
