Integrated: 8283318: Videos with unusual sizes cannot be played on windows
On Tue, 19 Apr 2022 22:38:13 GMT, Alexander Matveev wrote: > Fixed by removing check which enables dynamic format change, since it > requires for portrait videos, not standard resolutions and anything that has > width > 1920 or/and height > 1080. This pull request has now been integrated. Changeset: ee7f23d5 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/ee7f23d562ebb46ddcfdeff42d1f1855d60f7a65 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod 8283318: Videos with unusual sizes cannot be played on windows Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/775
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 [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
RFR: 8283318: Videos with unusual sizes cannot be played on windows
Fixed by removing check which enables dynamic format change, since it requires for portrait videos, not standard resolutions and anything that has width > 1920 or/and height > 1080. - Commit messages: - 8283318: Videos with unusual sizes cannot be played on windows Changes: https://git.openjdk.java.net/jfx/pull/775/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=775=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8283318 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/775.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/775/head:pull/775 PR: https://git.openjdk.java.net/jfx/pull/775
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] 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]
> - 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
Integrated: 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8
On Fri, 11 Mar 2022 03:01:39 GMT, Alexander Matveev wrote: > - Problem was that our code which checks if URI ends with file extension was > not considering that URI can have query parameters. Fixed by checking URI > path, instead of actual URI. > - Also, creation of HLS Connection holder was missing checking for mimetype, > since we do support URI without extensions as long as they provide correct > mimetype. > - Added #EXTM3U to file signature check in case if extension and mimetype > checks failed to determine stream type. All playlists of HLS based on spec > should start with #EXTM3U. For some reason this particular stream has > mimetype of "audio/x-mpegurl" and it is not mimetype from spec. Based on spec > it should be "audio/mpegurl". Thus check for signature was added in case if > URI does not use extension and has unsupported mimetype. > > Note: audio will not work on Windows and Linux for stream provided in this > bug report due to provided example uses separate audio stream via EXT-X-MEDIA > tag and it is not supported. I filed separate issue for this. This pull request has now been integrated. Changeset: d1110f47 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/d1110f479567c314ecb6848700bcf4552509d7e9 Stats: 65 lines in 2 files changed: 27 ins; 3 del; 35 mod 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8 Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/750
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
Integrated: 8277309: Add support for H.265/HEVC to HTTP Live Streaming
On Fri, 4 Feb 2022 11:24:48 GMT, Alexander Matveev wrote: > - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. > - Added support for elementary AAC streams without any container for audio > only streams. > - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder > cannot handle AAC elementary streams directly. DirectShow decoder works > without it. > - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will > be reloaded when fMP4 stream changes resolution. Dynamic format change did > not worked for these streams on Windows and Linux. This pull request has now been integrated. Changeset: 424aebae Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/424aebae8f28d0c75caa3281a3e5d6a7ede86a8a Stats: 2690 lines in 29 files changed: 2384 ins; 137 del; 169 mod 8277309: Add support for H.265/HEVC to HTTP Live Streaming Reviewed-by: kcr, arapte, jvos - PR: https://git.openjdk.java.net/jfx/pull/726
Re: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3]
On Fri, 18 Mar 2022 02:20:11 GMT, Alexander Matveev wrote: >> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. >> - Added support for elementary AAC streams without any container for audio >> only streams. >> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder >> cannot handle AAC elementary streams directly. DirectShow decoder works >> without it. >> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will >> be reloaded when fMP4 stream changes resolution. Dynamic format change did >> not worked for these streams on Windows and Linux. > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] Fixed several issues found during additional testing: - sendHeader was true by default which caused sending first and second segment together for MP2TS and MP3/AAC elementary streams. This variable should be true only for fragmented MP4. - Removed G_SIGNAL_NO_RECURSE flag from javasource signals. From GLib doc "G_SIGNAL_NO_RECURSE - Signals being emitted for an object while currently being in emission for this very object will not be emitted recursively, but instead cause the first emission to be restarted." Basically it caused skipping data segments since in some cases loadNextSegment() was called twice. We do use signal mechanism from separate thread when reading duration. This issue is intermittent. All GStreamer provided elements do not use G_SIGNAL_NO_RECURSE flag, so not sure why javasource was using it. - Fixed duration calculation. We should not count duration of header, since header does not contain any data. - Added code which will adjust PTS during rendering to start with 0, otherwise (after duration fix) we will drop frames with PTS > duration. Note: In fMP4 HLS streams PTS starts with N and goes upto duration + N. Our rendering code expects start with 0 and stop at duration. - Minor code cleanup and removal of unnecessary "if (segment.start != 0)" check in hlsprogressbuffer. - PR: https://git.openjdk.java.net/jfx/pull/726
Re: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3]
> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. > - Added support for elementary AAC streams without any container for audio > only streams. > - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder > cannot handle AAC elementary streams directly. DirectShow decoder works > without it. > - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will > be reloaded when fMP4 stream changes resolution. Dynamic format change did > not worked for these streams on Windows and Linux. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v3] - Changes: - all: https://git.openjdk.java.net/jfx/pull/726/files - new: https://git.openjdk.java.net/jfx/pull/726/files/08ce8569..49b6b2e4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=726=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=726=01-02 Stats: 84 lines in 5 files changed: 51 ins; 17 del; 16 mod Patch: https://git.openjdk.java.net/jfx/pull/726.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/726/head:pull/726 PR: https://git.openjdk.java.net/jfx/pull/726
RFR: 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8
- Problem was that our code which checks if URI ends with file extension was not considering that URI can have query parameters. Fixed by checking URI path, instead of actual URI. - Also, creation of HLS Connection holder was missing checking for mimetype, since we do support URI without extensions as long as they provide correct mimetype. - Added #EXTM3U to file signature check in case if extension and mimetype checks failed to determine stream type. All playlists of HLS based on spec should start with #EXTM3U. For some reason this particular stream has mimetype of "audio/x-mpegurl" and it is not mimetype from spec. Based on spec it should be "audio/mpegurl". Thus check for signature was added in case if URI does not use extension and has unsupported mimetype. Note: audio will not work on Windows and Linux for stream provided in this bug report due to provided example uses separate audio stream via EXT-X-MEDIA tag and it is not supported. I filed separate issue for this. - Commit messages: - 8282054: Mediaplayer not working with HTTP Live Stream link with query parameter appended with file extension m3u8 Changes: https://git.openjdk.java.net/jfx/pull/750/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=750=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282054 Stats: 65 lines in 2 files changed: 27 ins; 3 del; 35 mod Patch: https://git.openjdk.java.net/jfx/pull/750.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/750/head:pull/750 PR: https://git.openjdk.java.net/jfx/pull/750
Re: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2]
On Tue, 8 Mar 2022 23:50:57 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2] > > modules/javafx.media/src/main/native/gstreamer/plugins/dshowwrapper/dshowwrapper.cpp > line 1954: > >> 1952: } >> 1953: >> 1954: if (decoder->pDecoder != NULL && decoder->pGraph != NULL) > > Can `decoder->pDecoder` be non-null and `decoder->pGraph` be null? If so, > then the decoder wouldn't be released. Does it need to be? Unlikely. I changed it to check for `if (decoder->pGraph == NULL)` at beginning of function and return `FALSE` if it happens, since we cannot swap decoder if graph is not initialized. Not sure if it can happen, so this check is more for just in case. Yes, we need to release decoder and re-create it during format change. I tried all possible ways to change format dynamically and nothing worked. Only complete recreation of decoder instance worked. - PR: https://git.openjdk.java.net/jfx/pull/726
Re: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2]
> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. > - Added support for elementary AAC streams without any container for audio > only streams. > - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder > cannot handle AAC elementary streams directly. DirectShow decoder works > without it. > - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will > be reloaded when fMP4 stream changes resolution. Dynamic format change did > not worked for these streams on Windows and Linux. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8277309: Add support for H.265/HEVC to HTTP Live Streaming [v2] - Changes: - all: https://git.openjdk.java.net/jfx/pull/726/files - new: https://git.openjdk.java.net/jfx/pull/726/files/01720c79..08ce8569 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=726=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=726=00-01 Stats: 11 lines in 2 files changed: 3 ins; 7 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/726.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/726/head:pull/726 PR: https://git.openjdk.java.net/jfx/pull/726
Re: RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming
On Sat, 26 Feb 2022 00:30:10 GMT, Kevin Rushforth wrote:
>> - Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC.
>> - Added support for elementary AAC streams without any container for audio
>> only streams.
>> - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder
>> cannot handle AAC elementary streams directly. DirectShow decoder works
>> without it.
>> - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will
>> be reloaded when fMP4 stream changes resolution. Dynamic format change did
>> not worked for these streams on Windows and Linux.
>
> modules/javafx.media/src/main/java/com/sun/media/jfxmedia/locator/HLSConnectionHolder.java
> line 406:
>
>> 404: mediaFileIndex = 0;
>> 405: }
>> 406: } catch (Exception e) {
>
> Do you need to catch exceptions here? Or would just doing a try / finally be
> sufficient? If you do intend to catch all exceptions here, should some
> logging or error handling be done if an exceptions occurs?
No. Removed.
-
PR: https://git.openjdk.java.net/jfx/pull/726
Integrated: 8280840: Update libFFI to 3.4.2
On Sat, 19 Feb 2022 07:45:43 GMT, Alexander Matveev wrote: > LibFFI updated to 3.4.2. No additional changes to our code, libffi code or > build system were required. Tested on all platforms. This pull request has now been integrated. Changeset: 1beb3235 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/1beb3235223452929ec951ee18dd30a5345307cf Stats: 3475 lines in 34 files changed: 927 ins; 38 del; 2510 mod 8280840: Update libFFI to 3.4.2 Reviewed-by: kcr, sykora - PR: https://git.openjdk.java.net/jfx/pull/738
Re: RFR: 8280840: Update libFFI to 3.4.2
On Sat, 19 Feb 2022 07:45:43 GMT, Alexander Matveev wrote: > LibFFI updated to 3.4.2. No additional changes to our code, libffi code or > build system were required. Tested on all platforms. [v2] - Fixed TAB issue. [v3] - Fixed space alignment issue in aarch64/ffitarget.h. - PR: https://git.openjdk.java.net/jfx/pull/738
Re: RFR: 8280840: Update libFFI to 3.4.2 [v2]
> LibFFI updated to 3.4.2. No additional changes to our code, libffi code or > build system were required. Tested on all platforms. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8280840: Update libFFI to 3.4.2 [v3] - Changes: - all: https://git.openjdk.java.net/jfx/pull/738/files - new: https://git.openjdk.java.net/jfx/pull/738/files/2ca3a52a..a06a3e65 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=738=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=738=00-01 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.java.net/jfx/pull/738.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/738/head:pull/738 PR: https://git.openjdk.java.net/jfx/pull/738
RFR: 8280840: Update libFFI to 3.4.2
LibFFI updated to 3.4.2. No additional changes to our code, libffi code or build system were required. Tested on all platforms. - Commit messages: - 8280840: Update libFFI to 3.4.2 [v2] - 8280840: Update libFFI to 3.4.2 Changes: https://git.openjdk.java.net/jfx/pull/738/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=738=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8280840 Stats: 3463 lines in 34 files changed: 927 ins; 38 del; 2498 mod Patch: https://git.openjdk.java.net/jfx/pull/738.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/738/head:pull/738 PR: https://git.openjdk.java.net/jfx/pull/738
RFR: 8277309: Add support for H.265/HEVC to HTTP Live Streaming
- Added support for fragmented MP4 with HEVC/H.265, H.264 and AAC. - Added support for elementary AAC streams without any container for audio only streams. - Added "aacparse" plugin from GStreamer. Required on Linux, since decoder cannot handle AAC elementary streams directly. DirectShow decoder works without it. - DirectShow H.264 decoder on Windows and H.265/H.264 decoder on Linux will be reloaded when fMP4 stream changes resolution. Dynamic format change did not worked for these streams on Windows and Linux. - Commit messages: - 8277309: Add support for H.265/HEVC to HTTP Live Streaming Changes: https://git.openjdk.java.net/jfx/pull/726/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=726=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8277309 Stats: 2637 lines in 27 files changed: 2343 ins; 126 del; 168 mod Patch: https://git.openjdk.java.net/jfx/pull/726.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/726/head:pull/726 PR: https://git.openjdk.java.net/jfx/pull/726
Integrated: 8273096: Add support for H.265/HEVC to JavaFX Media
On Thu, 21 Oct 2021 07:51:20 GMT, Alexander Matveev wrote: > - Added support for H.265/HEVC for all 3 platforms. > - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP > Live Streaming with H.265/HEVC is not supported. > - On Windows mfwrapper was introduced which uses Media Foundation APIs to > decode HEVC. > - 10 and 12-bit HEVC was tested and also supported, however due to graphics > pipeline not supporting 10-bit YUV rendering we will use color converter to > convert video frame to 8-bit before sending it for rendering. > - Resolution upto 4k is supported. > > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 > > Additional build dependency: > Linux: libswscale-dev This pull request has now been integrated. Changeset: 1f10c633 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/1f10c63358ac4cfdbe503da823f420d224397c78 Stats: 2086 lines in 30 files changed: 1964 ins; 28 del; 94 mod 8273096: Add support for H.265/HEVC to JavaFX Media Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/649
Re: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v4]
On Fri, 17 Dec 2021 17:15:22 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8273096: Add support for H.265/HEVC to JavaFX Media [v5] > > modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp > line 646: > >> 644: >> 645: if (SUCCEEDED(hr) && dwFlags != MFT_OUTPUT_STATUS_SAMPLE_READY) >> 646: return FALSE; > > If the previous call failed, should you really continue with the following > call to `ProcessOutput`? Yes, if call GetOutputStatus() fails we need to call ProcessOutput(). It is based on documentation. See https://docs.microsoft.com/en-us/windows/win32/medfound/basic-mft-processing-model#process-data - PR: https://git.openjdk.java.net/jfx/pull/649
Re: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2]
On Fri, 10 Dec 2021 18:56:43 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8273096: Add support for H.265/HEVC to JavaFX Media [v3] > > modules/javafx.media/src/main/native/gstreamer/plugins/av/videodecoder.c line > 525: > >> 523: if (decoder->sws_context == NULL || decoder->dest_frame == NULL || >> 524: decoder->sws_scale_func == NULL) >> 525: return TRUE; > > Should this be `return FALSE;`? Not really. videodecoder_init_converter() should fail if we need converter, but did not able to initialize it. videodecoder_convert_frame() return TRUE here, since it assumes that it will never be called if we need converter and fail to initialize it. So, TRUE here means we do not need to convert frame. I modified this logic by checking base->frame->format value to make it clear. - PR: https://git.openjdk.java.net/jfx/pull/649
Re: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v3]
On Mon, 13 Dec 2021 19:29:59 GMT, Kevin Rushforth wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8273096: Add support for H.265/HEVC to JavaFX Media [v4]
>
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 698:
>
>> 696: {
>> 697: pMediaBuffer->Unlock();
>> 698: gst_buffer_unref(pGstBuffer); // INLINE - gst_buffer_unref()
>
> Is it safe to call gst_buffer_unref with `NULL`?
No, it is not safe. I fixed it.
-
PR: https://git.openjdk.java.net/jfx/pull/649
Re: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v4]
> - Added support for H.265/HEVC for all 3 platforms. > - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP > Live Streaming with H.265/HEVC is not supported. > - On Windows mfwrapper was introduced which uses Media Foundation APIs to > decode HEVC. > - 10 and 12-bit HEVC was tested and also supported, however due to graphics > pipeline not supporting 10-bit YUV rendering we will use color converter to > convert video frame to 8-bit before sending it for rendering. > - Resolution upto 4k is supported. > > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 > > Additional build dependency: > Linux: libswscale-dev Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8273096: Add support for H.265/HEVC to JavaFX Media [v5] - Changes: - all: https://git.openjdk.java.net/jfx/pull/649/files - new: https://git.openjdk.java.net/jfx/pull/649/files/cb1ee6c2..21dffaa5 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=649=03 - incr: https://webrevs.openjdk.java.net/?repo=jfx=649=02-03 Stats: 16 lines in 2 files changed: 4 ins; 2 del; 10 mod Patch: https://git.openjdk.java.net/jfx/pull/649.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/649/head:pull/649 PR: https://git.openjdk.java.net/jfx/pull/649
Re: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2]
On Tue, 16 Nov 2021 02:24:11 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP >> Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to >> decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics >> pipeline not supporting 10-bit YUV rendering we will use color converter to >> convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v3] modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 452: > 450: > 451: if (SUCCEEDED(hr)) > 452: hr = pBuffer->Lock(, NULL, NULL); I fixed unlock here as well in case if code below fails. modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp line 559: > 557: hr = MFSetAttributeRatio(pInputType, > MF_MT_PIXEL_ASPECT_RATIO, unNumerator, unDenominator); > 558: else > 559: hr = S_OK; I fixed get/set MF_MT_PIXEL_ASPECT_RATIO and MF_MT_DEFAULT_STRIDE. We should only set it if we get it and it is ok if aspect ration or stride is not available. In way it is currently written we will overwrite value of hr if it is failed and never exit a loop as well. - PR: https://git.openjdk.java.net/jfx/pull/649
Re: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2]
On Fri, 10 Dec 2021 19:34:25 GMT, Kevin Rushforth wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8273096: Add support for H.265/HEVC to JavaFX Media [v3]
>
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 313:
>
>> 311: default:
>> 312: break;
>> 313: }
>
> This block is a no-op. Is this intended? (and if so, is it needed?)
Actually mfwrapper_change_state() is not needed, since it is not used at all.
Default handler should be just fine. It was copy-paste from dshowwrapper when I
created this element and forgot to remove it. In dshowwrapper it is used. I
will remove this function.
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 517:
>
>> 515: do
>> 516: {
>> 517: hr = decoder->pDecoder->GetOutputAvailableType(0, dwTypeIndex,
>> );
>
> Do you need to check `SUCCEEDED(hr)` here?
No checks below should handle it in case if it fails.
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 571:
>
>> 569: SafeRelease();
>> 570:
>> 571: } while (hr != MF_E_NO_MORE_TYPES && hr != S_OK);
>
> Should this be `FAILED(hr)` instead of `hr != S_OK`? Also, is it guaranteed
> to get success or `MF_E_NO_MORE_TYPES`? If not, this could lead to an
> infinite loop.
Fixed. Yes, it should be FAILED(hr) and it is not guaranteed to get success or
MF_E_NO_MORE_TYPES.
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 577:
>
>> 575: do
>> 576: {
>> 577: hr = decoder->pColorConvert->GetOutputAvailableType(0,
>> dwTypeIndex, );
>
> Same questions for this loop as for the previous.
Fixed as well.
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 684:
>
>> 682: return FALSE;
>> 683: }
>> 684: else if (hr == MF_E_TRANSFORM_STREAM_CHANGE)
>
> Is it OK that this case will return FALSE always?
Yes, we return TRUE only if we got output from converter which is ready to be
delivered. MF_E_TRANSFORM_STREAM_CHANGE is needed to reconfigure converter. I
removed MF_E_TRANSFORM_NEED_MORE_INPUT since it is not needed.
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 723:
>
>> 721:
>> 722: if (SUCCEEDED(hr))
>> 723: hr = pMediaBuffer->Lock(, ,
>> );
>
> If this succeeds, but later operations fail, it seems possible that Unlock
> won't be called in some cases. Might this cause a problem?
It can cause a problem, but it should be called, since nothing will change hr
value between Lock/Unlock. I will remove unnecessary check of hr value before
unlock. It will only miss unlock if cbCurrentLength == 0, which can happen for
empty buffers, but unlikely. I will fix it as well.
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 730:
>
>> 728: GstMapInfo info;
>> 729:
>> 730: if (!gst_buffer_map(pGstBuffer, , GST_MAP_WRITE))
>
> Do you need to check for `pGstBuffer == NULL`? My concern is that either
> `gst_buffer_map` will crash if it is, or else it return NULL and then
> `gst_buffer_unref` might crash.
Yes, we should. I fixed it.
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 791:
>
>> 789: return PO_FLUSHING;
>> 790:
>> 791: HRESULT hr = decoder->pDecoder->GetOutputStatus();
>
> Do you not need to check `hr` here?
Yes, fixed.
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 811:
>
>> 809: do
>> 810: {
>> 811: hr = decoder->pDecoder->GetOutputAvailableType(0,
>> dwTypeIndex, );
>
> Same question as earlier loops -- do you need to check `hr` (from previous
> time through loop) here?
Fixed as well.
> modules/javafx.media/src/main/native/gstreamer/plugins/mfwrapper/mfwrapper.cpp
> line 963:
>
>> 961: // Ask decoder to produce all remaining data
>> 962: if (SUCCEEDED(hr))
>> 963: hr =
>> decoder->pDecoder->ProcessMessage(MFT_MESSAGE_COMMAND_DRAIN, 0);
>
> Does this `hr` need to be checked?
No, I removed it. I think we still need to attempt reading data from decoder,
even if it refused DRAIN which asks decoder to produce all output it can
possible produce without any additional input.
> modules/javafx.media/src/main/native/gstreamer/plugins
Re: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v3]
> - Added support for H.265/HEVC for all 3 platforms. > - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP > Live Streaming with H.265/HEVC is not supported. > - On Windows mfwrapper was introduced which uses Media Foundation APIs to > decode HEVC. > - 10 and 12-bit HEVC was tested and also supported, however due to graphics > pipeline not supporting 10-bit YUV rendering we will use color converter to > convert video frame to 8-bit before sending it for rendering. > - Resolution upto 4k is supported. > > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 > > Additional build dependency: > Linux: libswscale-dev Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8273096: Add support for H.265/HEVC to JavaFX Media [v4] - Changes: - all: https://git.openjdk.java.net/jfx/pull/649/files - new: https://git.openjdk.java.net/jfx/pull/649/files/6cb1ac5c..cb1ee6c2 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=649=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx=649=01-02 Stats: 110 lines in 1 file changed: 13 ins; 80 del; 17 mod Patch: https://git.openjdk.java.net/jfx/pull/649.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/649/head:pull/649 PR: https://git.openjdk.java.net/jfx/pull/649
Re: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2]
On Tue, 16 Nov 2021 02:24:11 GMT, Alexander Matveev wrote: >> - Added support for H.265/HEVC for all 3 platforms. >> - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP >> Live Streaming with H.265/HEVC is not supported. >> - On Windows mfwrapper was introduced which uses Media Foundation APIs to >> decode HEVC. >> - 10 and 12-bit HEVC was tested and also supported, however due to graphics >> pipeline not supporting 10-bit YUV rendering we will use color converter to >> convert video frame to 8-bit before sending it for rendering. >> - Resolution upto 4k is supported. >> >> Additional runtime dependency requirements: >> Windows: Windows 10 with HEVC Video Extensions installed. >> macOS: macOS High Sierra and later >> Linux: at least libavcodec56 and libswscale5 >> >> Additional build dependency: >> Linux: libswscale-dev > > Alexander Matveev has updated the pull request incrementally with one > additional commit since the last revision: > > 8273096: Add support for H.265/HEVC to JavaFX Media [v3] Added new patch. libswscale will be loaded dynamically on Linux for H.265/HEVC 10/12-bit. Playback will not fail for other formats if it is not present. Windows should play other formats without "HEVC Video Extensions" without any issues. Same for macOS. Following MediaException will be thrown on Linux if libswscale is not present. Output is from FXMediaPlayer. onError: MediaException: PLAYBACK_ERROR : [com.sun.media.jfxmediaimpl.platform.gstreamer.GSTMediaPlayer@a88d9ab] ERROR_MISSING_LIBSWSCALE: ERROR_MISSING_LIBSWSCALE - PR: https://git.openjdk.java.net/jfx/pull/649
Re: RFR: 8273096: Add support for H.265/HEVC to JavaFX Media [v2]
> - Added support for H.265/HEVC for all 3 platforms. > - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP > Live Streaming with H.265/HEVC is not supported. > - On Windows mfwrapper was introduced which uses Media Foundation APIs to > decode HEVC. > - 10 and 12-bit HEVC was tested and also supported, however due to graphics > pipeline not supporting 10-bit YUV rendering we will use color converter to > convert video frame to 8-bit before sending it for rendering. > - Resolution upto 4k is supported. > > Additional runtime dependency requirements: > Windows: Windows 10 with HEVC Video Extensions installed. > macOS: macOS High Sierra and later > Linux: at least libavcodec56 and libswscale5 > > Additional build dependency: > Linux: libswscale-dev Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8273096: Add support for H.265/HEVC to JavaFX Media [v3] - Changes: - all: https://git.openjdk.java.net/jfx/pull/649/files - new: https://git.openjdk.java.net/jfx/pull/649/files/62ba1ec8..6cb1ac5c Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=649=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=649=00-01 Stats: 134 lines in 6 files changed: 113 ins; 0 del; 21 mod Patch: https://git.openjdk.java.net/jfx/pull/649.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/649/head:pull/649 PR: https://git.openjdk.java.net/jfx/pull/649
RFR: 8273096: Add support for H.265/HEVC to JavaFX Media
- Added support for H.265/HEVC for all 3 platforms. - Support is added only for .mp4 files over FILE/HTTP/HTTPS protocols. HTTP Live Streaming with H.265/HEVC is not supported. - On Windows mfwrapper was introduced which uses Media Foundation APIs to decode HEVC. - 10 and 12-bit HEVC was tested and also supported, however due to graphics pipeline not supporting 10-bit YUV rendering we will use color converter to convert video frame to 8-bit before sending it for rendering. - Resolution upto 4k is supported. Additional runtime dependency requirements: Windows: Windows 10 with HEVC Video Extensions installed. macOS: macOS High Sierra and later Linux: at least libavcodec56 and libswscale5 Additional build dependency: Linux: libswscale-dev - Commit messages: - 8273096: Add support for H.265/HEVC to JavaFX Media [v2] - JDK-8273096: Add support for H.265/HEVC to JavaFX Media Changes: https://git.openjdk.java.net/jfx/pull/649/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=649=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8273096 Stats: 2039 lines in 30 files changed: 1916 ins; 28 del; 95 mod Patch: https://git.openjdk.java.net/jfx/pull/649.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/649/head:pull/649 PR: https://git.openjdk.java.net/jfx/pull/649
Integrated: 8270107: Open source FXMediaPlayer test app
On Fri, 27 Aug 2021 22:06:31 GMT, Alexander Matveev wrote: > - Added FXMediaPlayer test application. > - This app uses all media APIs and very handy in verifying media builds > during development. > - It can be compiled and run by running "ant" and "ant run" in > tests/manual/media/FXMediaPlayer. This pull request has now been integrated. Changeset: 51265c0b Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/51265c0b8762859ec9926e03965f471287e81213 Stats: 5970 lines in 26 files changed: 5970 ins; 0 del; 0 mod 8270107: Open source FXMediaPlayer test app Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/613
RFR: 8270107: Open source FXMediaPlayer test app
- Added FXMediaPlayer test application. - This app uses all media APIs and very handy in verifying media builds during development. - It can be compiled and run by running "ant" and "ant run" in tests/manual/media/FXMediaPlayer. - Commit messages: - 8270107: Open source FXMediaPlayer test app Changes: https://git.openjdk.java.net/jfx/pull/613/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=613=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8270107 Stats: 5970 lines in 26 files changed: 5970 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/613.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/613/head:pull/613 PR: https://git.openjdk.java.net/jfx/pull/613
Integrated: 8242531: [macos] JavaFX OSXPlatform tries to load nonexistent libjfxmedia_qtkit
On Fri, 30 Jul 2021 00:42:30 GMT, Alexander Matveev wrote: > Removed code which loads nonexistent libjfxmedia_qtkit. This pull request has now been integrated. Changeset: ba61a173 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/ba61a17307d48d373fd8faa169ed16821e81c0fd Stats: 14 lines in 1 file changed: 0 ins; 10 del; 4 mod 8242531: [macos] JavaFX OSXPlatform tries to load nonexistent libjfxmedia_qtkit Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/597
RFR: 8242531: [macos] JavaFX OSXPlatform tries to load nonexistent libjfxmedia_qtkit
Removed code which loads nonexistent libjfxmedia_qtkit. - Commit messages: - 8242531: [macos] JavaFX OSXPlatform tries to load nonexistent libjfxmedia_qtkit Changes: https://git.openjdk.java.net/jfx/pull/597/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=597=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242531 Stats: 14 lines in 1 file changed: 0 ins; 10 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/597.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/597/head:pull/597 PR: https://git.openjdk.java.net/jfx/pull/597
Integrated: 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's
On Sat, 24 Jul 2021 02:59:52 GMT, Alexander Matveev wrote: > Fixed by not failing initialization if DSERR_NODRIVER is returned, which will > be return if device is not present at all. Fixed format initialization even > if DirectSound device was not created in case if audio device will arrive > after playback started. Since we already handle correctly device arrival > after playback started, audio will resume if device is enabled or USB audio > card is plugged back. Due to lack of access to USB audio device, it was > tested by disabling sound card via Device Manager, then starting playback > (video plays, but not audio) and then enabling device and once enabled audio > will start playing. This pull request has now been integrated. Changeset: b738e1ce Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/b738e1cee709d0842196c086ad33db95a6e13856 Stats: 27 lines in 1 file changed: 18 ins; 7 del; 2 mod 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's Reviewed-by: jvos, kcr - PR: https://git.openjdk.java.net/jfx/pull/586
Re: RFR: 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's [v2]
> Fixed by not failing initialization if DSERR_NODRIVER is returned, which will > be return if device is not present at all. Fixed format initialization even > if DirectSound device was not created in case if audio device will arrive > after playback started. Since we already handle correctly device arrival > after playback started, audio will resume if device is enabled or USB audio > card is plugged back. Due to lack of access to USB audio device, it was > tested by disabling sound card via Device Manager, then starting playback > (video plays, but not audio) and then enabling device and once enabled audio > will start playing. Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8253351 - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's - Changes: - all: https://git.openjdk.java.net/jfx/pull/586/files - new: https://git.openjdk.java.net/jfx/pull/586/files/731b4cd6..2b06faed Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=586=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=586=00-01 Stats: 326714 lines in 6075 files changed: 179112 ins; 103349 del; 44253 mod Patch: https://git.openjdk.java.net/jfx/pull/586.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/586/head:pull/586 PR: https://git.openjdk.java.net/jfx/pull/586
RFR: 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's
Fixed by not failing initialization if DSERR_NODRIVER is returned, which will be return if device is not present at all. Fixed format initialization even if DirectSound device was not created in case if audio device will arrive after playback started. Since we already handle correctly device arrival after playback started, audio will resume if device is enabled or USB audio card is plugged back. Due to lack of access to USB audio device, it was tested by disabling sound card via Device Manager, then starting playback (video plays, but not audio) and then enabling device and once enabled audio will start playing. - Commit messages: - 8253351: MediaPlayer does not display an mp4 if there no speakers connected to the PC's Changes: https://git.openjdk.java.net/jfx/pull/586/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=586=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8253351 Stats: 27 lines in 1 file changed: 18 ins; 7 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/586.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/586/head:pull/586 PR: https://git.openjdk.java.net/jfx/pull/586
Integrated: 8268718: [macos] Video stops, but audio continues to play when stopTime is reached
On Thu, 1 Jul 2021 01:38:14 GMT, Alexander Matveev wrote: > Not sure why, but our finish() handle was not implemented on OSXPlatform. > This handle should pause media stream when called. Also, seek should restart > playback when we finish playing video. With proposed fix OSXPlatform will > behave same as GSTPlatform. Stop playback when stopTime is reached and resume > playback if seek is performed after EndOfMedia or stopTime is reached. This pull request has now been integrated. Changeset: 0c98d960 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/0c98d9608611aa2378b38604e2528935c94e84ae Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod 8268718: [macos] Video stops, but audio continues to play when stopTime is reached Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/559
RFR: 8268718: [macos] Video stops, but audio continues to play when stopTime is reached
Not sure why, but our finish() handle was not implemented on OSXPlatform. This handle should pause media stream when called. Also, seek should restart playback when we finish playing video. With proposed fix OSXPlatform will behave same as GSTPlatform. Stop playback when stopTime is reached and resume playback if seek is performed after EndOfMedia or stopTime is reached. - Commit messages: - 8268718: [macos] Video stops, but audio continues to play when stopTime is reached Changes: https://git.openjdk.java.net/jfx/pull/559/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=559=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268718 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/559.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/559/head:pull/559 PR: https://git.openjdk.java.net/jfx/pull/559
Integrated: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc
On Tue, 29 Jun 2021 03:07:11 GMT, Alexander Matveev wrote: > Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of > cycle is reached regardless if it is repeating or not. This pull request has now been integrated. Changeset: cfa60ff7 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/cfa60ff7a54edcfd099f08585df71e1f7fc09ddb Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/552
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: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2]
On Tue, 29 Jun 2021 22:55:50 GMT, Kevin Rushforth wrote:
>> Alexander Matveev has updated the pull request incrementally with one
>> additional commit since the last revision:
>>
>> 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc
>> [v2]
>
> modules/javafx.media/src/main/java/javafx/scene/media/MediaPlayer.java line
> 117:
>
>> 115: * {@link #onRepeatProperty onRepeat} property is invoked. If the stop
>> time is
>> 116: * reached, then the event handler registered with the {@link
>> #onEndOfMediaProperty onEndOfMedia}
>> 117: * property is invoked regardless if the cycle is to be repeated or not.
>
> I recommend the following wording change:
>
> `regardless if the cycle` --> `regardless of whether the cycle`
Fixed.
-
PR: https://git.openjdk.java.net/jfx/pull/552
Re: RFR: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2]
> Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of > cycle is reached regardless if it is repeating or not. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc [v2] - Changes: - all: https://git.openjdk.java.net/jfx/pull/552/files - new: https://git.openjdk.java.net/jfx/pull/552/files/1592e86b..68e5df99 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=552=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=552=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/552.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/552/head:pull/552 PR: https://git.openjdk.java.net/jfx/pull/552
RFR: 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc
Fixed javadoc to indicate that onEndOfMedia is invoked each time when end of cycle is reached regardless if it is repeating or not. - Commit messages: - 8268683: JavaFX MediaPlayer onEndOfMedia behaviour different from Javadoc Changes: https://git.openjdk.java.net/jfx/pull/552/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=552=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8268683 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jfx/pull/552.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/552/head:pull/552 PR: https://git.openjdk.java.net/jfx/pull/552
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
RFR: 8268219: Investigate gstmpegaudioparse PTS issue
- 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. - Commit messages: - 8268219: Investigate gstmpegaudioparse PTS issue Changes: https://git.openjdk.java.net/jfx/pull/532/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=532=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/jfx/pull/532.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/532/head:pull/532 PR: https://git.openjdk.java.net/jfx/pull/532
Integrated: 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams
On Thu, 3 Jun 2021 09:37:18 GMT, Alexander Matveev wrote: > With recent GStreamer update gstmpegaudioparse no longer provides audio > buffers with valid timestamps. This issue is only reproducible with MP3 HTTP > Live Stream and was noticed on Linux. I think Windows audio decoder handles > such case better and thus MP3 HLS works fine. I did not figure out why it > behaves this way and for now fix is reverting gstmpegaudioparse changeset > which caused it. Follow up issue will be filed to investigate why javasource > and/or hlsprogressbuffer no longer compatible with gstmpegaudioparse and > gstmpegaudioparse cannot figure out correct PTS. Also, fixed potential null > pointer reference for buffers with invalid PTS. This pull request has now been integrated. Changeset: ee032387 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/ee032387badadb41ed36de745aea3c0a074b79bd Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod 8268152: gstmpegaudioparse does not provides timestamps for HLS MP3 streams Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/526
Re: RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread
On Wed, 2 Jun 2021 14:29:41 GMT, Ambarish Rapte wrote:
>> JDK-8264737 introduced new code for audio device removal/arrival
>> notifications which calls CoInitialize/CoUninitialize on separate threads.
>> CoInitialize/CoUninitialize should be called on same thread, since
>> initialization is per thread. Doing it on separate thread will result in
>> unloading COM libraries on that thread and if it uses COM libraries it might
>> not work correctly. Fixed by calling it on same thread in same way it is
>> done in dshowwrapper.
>
> modules/javafx.media/src/main/native/gstreamer/gstreamer-lite/gst-plugins-good/sys/directsound/gstdirectsoundnotify.cpp
> line 57:
>
>> 55: bool bResult = false;
>> 56:
>> 57: if (FAILED(CoInitialize(NULL))) {
>
> As per the [`CoUninitialize`
> doc](https://docs.microsoft.com/en-us/windows/win32/api/combaseapi/nf-combaseapi-couninitialize#remarks),
> `CoUninitialize` should also be called if `CoInitialize` returns S_FALSE.
> Can you please check.
It will be called. S_FALSE is not a failure and defined as 1. FAILED macro
returns true if error code < 0.
-
PR: https://git.openjdk.java.net/jfx/pull/521
Re: RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread
On Thu, 27 May 2021 04:18:24 GMT, Alexander Matveev wrote: > JDK-8264737 introduced new code for audio device removal/arrival > notifications which calls CoInitialize/CoUninitialize on separate threads. > CoInitialize/CoUninitialize should be called on same thread, since > initialization is per thread. Doing it on separate thread will result in > unloading COM libraries on that thread and if it uses COM libraries it might > not work correctly. Fixed by calling it on same thread in same way it is done > in dshowwrapper. 1. Yes, I did test it on RDP reconnect for multiple streams. 2. Not really needed. CoCreateInstance() will fails in this case most likely and we will return false from Init(). So, it should be fine if it fails. Also, CoInitialize() can return RPC_E_CHANGED_MODE if someone already initialized thread as multithread apartment (MTA) and in this case CoCreateInstance() should work, so it is better not to fail Init() even if CoInitialize() failed. - PR: https://git.openjdk.java.net/jfx/pull/521
RFR: 8267819: CoInitialize/CoUninitialize should be called on same thread
JDK-8264737 introduced new code for audio device removal/arrival notifications which calls CoInitialize/CoUninitialize on separate threads. CoInitialize/CoUninitialize should be called on same thread, since initialization is per thread. Doing it on separate thread will result in unloading COM libraries on that thread and if it uses COM libraries it might not work correctly. Fixed by calling it on same thread in same way it is done in dshowwrapper. - Commit messages: - 8267819: CoInitialize/CoUninitialize should be called on same thread Changes: https://git.openjdk.java.net/jfx/pull/521/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=521=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8267819 Stats: 22 lines in 2 files changed: 10 ins; 9 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/521.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/521/head:pull/521 PR: https://git.openjdk.java.net/jfx/pull/521
Integrated: 8266860: [macos] Incorrect duration reported for HLS live streams
On Tue, 11 May 2021 23:43:36 GMT, Alexander Matveev wrote: > For indefinite durations CMTimeGetSeconds was returning NaN (not-a-number > double value) and our code expects -1.0. Based on doc we should be using > CMTIME_IS_INDEFINITE to test if duration is indefinite. Fixed by using > CMTIME_IS_INDEFINITE to test if duration is indefinite and if true -1.0 will > be return to our Java layer. This pull request has now been integrated. Changeset: c511789b Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/c511789b106a3f3172aef606419d372bcbca606f Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8266860: [macos] Incorrect duration reported for HLS live streams Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/495
RFR: 8266860: [macos] Incorrect duration reported for HLS live streams
For indefinite durations CMTimeGetSeconds was returning NaN (not-a-number double value) and our code expects -1.0. Based on doc we should be using CMTIME_IS_INDEFINITE to test if duration is indefinite. Fixed by using CMTIME_IS_INDEFINITE to test if duration is indefinite and if true -1.0 will be return to our Java layer. - Commit messages: - 8266860: [macos] Incorrect duration reported for HLS live streams Changes: https://git.openjdk.java.net/jfx/pull/495/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=495=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8266860 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/495.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/495/head:pull/495 PR: https://git.openjdk.java.net/jfx/pull/495
Integrated: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop
On Sat, 24 Apr 2021 02:23:19 GMT, Alexander Matveev wrote: > Remote Desktop will change default audio device when connecting or > disconnecting to it's own audio device. Also, when remote desktop is > disconnect, then remote desktop default audio device is removed and system > default device is not restored until user logs back to computer. So, after > remote desktop is disconnected, then system left without any default audio > devices. > > To fix this we will unload DirectSound when audio device is gone and will > continue playback by throwing away audio data. Once we receive notification > that default audio device is back, we will load it and continue playback via > this device. > > Loading device done in loop, since it is not always available right after > notification, but will be after very short period of time. > > Tested by connecting/disconnecting remote desktop and switching between > remote and normal desktop. In second case audio will switch between remote or > speakers. > > Since audio device is gone and not restored after disconnect, there will be > no audio on machine local speakers, until user logs back again. This pull request has now been integrated. Changeset: 0a686130 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/0a6861304e142eed547f3c82b0d2e2a55f91b9b4 Stats: 352 lines in 5 files changed: 349 ins; 0 del; 3 mod 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/479
Re: RFR: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop [v2]
On Wed, 28 Apr 2021 19:02:41 GMT, Ambarish Rapte wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8264737: JavaFX media stream stops playing after reconnecting via Remote >> Desktop [v2] > > The change fixes the issue and looks good. > While testing it regressively, I observed an issue. The issue can occur > always. > steps to reproduce: > 1. Run Ensemble app on remote desktop > 2. Run Streaming Media Player app > 3. Press the media player buttons for several times. Keep pressing different > buttons for a minute or more and at the end press stop backward. > 4. Disconnect remote desktop and connect again > 5. Press play button > 6. I observed two different issues at two different instances > - Video and audio bot do not play > - Audio plays but video does not play > > However, Looking at the steps to reproduce this does not seem like a stopper > to me, so approving > Let me know if you can or cannot reproduce the issue, we can take that as a > follow on issue. @arapte I was not able to reproduce issue as described. It might not be related to removal of audio device during Remote Desktop disconnect. I will go ahead and integrate fix. Can you file a bug for it? - PR: https://git.openjdk.java.net/jfx/pull/479
Re: RFR: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop
On Sat, 24 Apr 2021 02:23:19 GMT, Alexander Matveev wrote: > Remote Desktop will change default audio device when connecting or > disconnecting to it's own audio device. Also, when remote desktop is > disconnect, then remote desktop default audio device is removed and system > default device is not restored until user logs back to computer. So, after > remote desktop is disconnected, then system left without any default audio > devices. > > To fix this we will unload DirectSound when audio device is gone and will > continue playback by throwing away audio data. Once we receive notification > that default audio device is back, we will load it and continue playback via > this device. > > Loading device done in loop, since it is not always available right after > notification, but will be after very short period of time. > > Tested by connecting/disconnecting remote desktop and switching between > remote and normal desktop. In second case audio will switch between remote or > speakers. > > Since audio device is gone and not restored after disconnect, there will be > no audio on machine local speakers, until user logs back again. Audio device notification failed in case when CoInitialize() was not called. It worked in some cases, since other parts of JavaFX already initialized it. Fixed by adding CoInitialize() call before registering device notification. Also, removed unused header left from debug printf. - PR: https://git.openjdk.java.net/jfx/pull/479
Re: RFR: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop [v2]
> Remote Desktop will change default audio device when connecting or > disconnecting to it's own audio device. Also, when remote desktop is > disconnect, then remote desktop default audio device is removed and system > default device is not restored until user logs back to computer. So, after > remote desktop is disconnected, then system left without any default audio > devices. > > To fix this we will unload DirectSound when audio device is gone and will > continue playback by throwing away audio data. Once we receive notification > that default audio device is back, we will load it and continue playback via > this device. > > Loading device done in loop, since it is not always available right after > notification, but will be after very short period of time. > > Tested by connecting/disconnecting remote desktop and switching between > remote and normal desktop. In second case audio will switch between remote or > speakers. > > Since audio device is gone and not restored after disconnect, there will be > no audio on machine local speakers, until user logs back again. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop [v2] - Changes: - all: https://git.openjdk.java.net/jfx/pull/479/files - new: https://git.openjdk.java.net/jfx/pull/479/files/24063798..635cec91 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=479=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=479=00-01 Stats: 10 lines in 2 files changed: 9 ins; 1 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/479.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/479/head:pull/479 PR: https://git.openjdk.java.net/jfx/pull/479
RFR: 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop
Remote Desktop will change default audio device when connecting or disconnecting to it's own audio device. Also, when remote desktop is disconnect, then remote desktop default audio device is removed and system default device is not restored until user logs back to computer. So, after remote desktop is disconnected, then system left without any default audio devices. To fix this we will unload DirectSound when audio device is gone and will continue playback by throwing away audio data. Once we receive notification that default audio device is back, we will load it and continue playback via this device. Loading device done in loop, since it is not always available right after notification, but will be after very short period of time. Tested by connecting/disconnecting remote desktop and switching between remote and normal desktop. In second case audio will switch between remote or speakers. Since audio device is gone and not restored after disconnect, there will be no audio on machine local speakers, until user logs back again. - Commit messages: - 8264737: JavaFX media stream stops playing after reconnecting via Remote Desktop Changes: https://git.openjdk.java.net/jfx/pull/479/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=479=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8264737 Stats: 344 lines in 5 files changed: 341 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/479.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/479/head:pull/479 PR: https://git.openjdk.java.net/jfx/pull/479
Re: RFR: 8265469: Allow to build media and webkit for Linux-AArch64
On Mon, 19 Apr 2021 19:57:50 GMT, Johan Vos wrote: > Changes that allow to build linux configuration on Linux AArch64 > This PR introduces an `IS_AARCH64` parameter in build.gradle. > This PR already contains the change from PR #465 so if this one gets > integrated, that change needs to removed from this PR. Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/467
Integrated: 8259356: MediaPlayer's seek freezes video
On Sat, 17 Apr 2021 01:39:17 GMT, Alexander Matveev wrote: > This is regression (introduced) by JDK-8199527. JDK-8199527 added fix for HLS > streams (unfortunately I was not able to find repro case and more details on > why it was added) in gstappsink.c line 659-678 to store current caps which > can be lost during seek/flush. However, this workaround broke code in > gst_app_sink_render_common() line 939 which was restoring caps if they were > flushed, since we set last_caps to non NULL value. Since code in > gst_app_sink_render_common() did not work to propagate caps to sample our > rendering code was dropping frames without caps. Fixed by setting caps on > sample in HLS workaround code. This pull request has now been integrated. Changeset: a6835580 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/a6835580 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8259356: MediaPlayer's seek freezes video Reviewed-by: kcr, jvos - PR: https://git.openjdk.java.net/jfx/pull/464
RFR: 8259356: MediaPlayer's seek freezes video
This is regression (introduced) by JDK-8199527. JDK-8199527 added fix for HLS streams (unfortunately I was not able to find repro case and more details on why it was added) in gstappsink.c line 659-678 to store current caps which can be lost during seek/flush. However, this workaround broke code in gst_app_sink_render_common() line 939 which was restoring caps if they were flushed, since we set last_caps to non NULL value. Since code in gst_app_sink_render_common() did not work to propagate caps to sample our rendering code was dropping frames without caps. Fixed by setting caps on sample in HLS workaround code. - Commit messages: - 8259356: MediaPlayer's seek freezes video Changes: https://git.openjdk.java.net/jfx/pull/464/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=464=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8259356 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx/pull/464.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/464/head:pull/464 PR: https://git.openjdk.java.net/jfx/pull/464
Integrated: 8262366: Update glib to version 2.66.7
On Wed, 31 Mar 2021 05:15:20 GMT, Alexander Matveev wrote: > - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 > - One bug was discovered in updated GStreamer which was causing deadlock or > infinite loop during seek on macOS. See gstsystemclock.c for changes between > ifdef GSTREAMER_LITE. Otherwise no changes. This pull request has now been integrated. Changeset: e63931e6 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/e63931e6 Stats: 39567 lines in 441 files changed: 23434 ins; 5427 del; 10706 mod 8262366: Update glib to version 2.66.7 8262365: Update GStreamer to version 1.18.3 Reviewed-by: jvos, kcr - PR: https://git.openjdk.java.net/jfx/pull/447
Re: RFR: 8262366: Update glib to version 2.66.7
On Thu, 1 Apr 2021 23:47:15 GMT, Kevin Rushforth wrote: >> All my testing looks good on all three platforms. I'll take a look at the >> diffs next. >> >> One thing I did spot is that you need to update `gstreamer.md` and `glib.md` >> to bump the version numbers. > > It now builds for me on my old Linux box. And the changes to the /legal/ > files looks good. > > One more thing I just thought of: we should do a test build on macOS aarch64. > I have no reason to believe that there will be a problem, but worth > double-checking. It builds fine on macOS aarch64 and I did minor testing as well. No issues. - PR: https://git.openjdk.java.net/jfx/pull/447
Re: RFR: 8264449: Enable reproducible builds with SOURCE_DATE_EPOCH [v2]
On Thu, 1 Apr 2021 19:14:37 GMT, John Neffenger wrote: >> This pull request allows for reproducible builds of JavaFX on Linux, macOS, >> and Windows by defining the `SOURCE_DATE_EPOCH` environment variable. For >> example, the following commands create a reproducible build: >> >> $ export SOURCE_DATE_EPOCH=$(git log -1 --pretty=%ct) >> $ bash gradlew sdk jmods javadoc >> $ strip-nondeterminism -v -T $SOURCE_DATE_EPOCH build/jmods/*.jmod >> >> The three commands: >> >> 1. set the build timestamp to the date of the latest source code change, >> 2. build the JavaFX SDK libraries, JMOD archives, and API documentation, and >> 3. recreate the JMOD files with stable file modification times and ordering. >> >> The third command won't be necessary once Gradle can build the JMOD archives >> or the `jmod` tool itself has the required support. For more information on >> the environment variable, see the [`SOURCE_DATE_EPOCH`][1] page. For more >> information on the command to recreate the JMOD files, see the >> [`strip-nondeterminism`][2] repository. I'd like to propose that we allow >> for reproducible builds in JavaFX 17 and consider making them the default in >> JavaFX 18. >> >> Fixes >> >> There are at least four sources of non-determinism in the JavaFX builds: >> >> 1. Build timestamp >> >> The class `com.sun.javafx.runtime.VersionInfo` in the JavaFX Base module >> stores the time of the build. Furthermore, for builds that don't run on the >> Hudson continuous integration tool, the class adds the build time to the >> system property `javafx.runtime.version`. >> >> 2. Modification times >> >> The JAR, JMOD, and ZIP archives store the modification time of each file. >> >> 3. File ordering >> >> The JAR, JMOD, and ZIP archives store their files in the order returned >> by the file system. The native shared libraries also store their object >> files in the order returned by the file system. Most file systems, though, >> do not guarantee the order of a directory's file listing. >> >> 4. Build path >> >> The class `com.sun.javafx.css.parser.Css2Bin` in the JavaFX Graphics >> module stores the absolute path of its `.css` input file in the >> corresponding `.bss` output file, which is then included in the JavaFX >> Controls module. >> >> This pull request modifies the Gradle and Groovy build files to fix the >> first three sources of non-determinism. A later pull request can modify the >> Java files to fix the fourth. >> >> [1]: https://reproducible-builds.org/docs/source-date-epoch/ >> [2]: https://salsa.debian.org/reproducible-builds/strip-nondeterminism > > John Neffenger has updated the pull request incrementally with one additional > commit since the last revision: > > Include media shared libraries for Windows > > Enable reproducible builds of the native media shared libraries for > Windows when SOURCE_DATE_EPOCH is defined. The libraries are: > > fxplugins.dll > glib-lite.dll > gstreamer-lite.dll > jfxmedia.dll Media makefiles look fine. - Marked as reviewed by almatvee (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/446
Re: RFR: 8262366: Update glib to version 2.66.7 [v2]
> - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 > - One bug was discovered in updated GStreamer which was causing deadlock or > infinite loop during seek on macOS. See gstsystemclock.c for changes between > ifdef GSTREAMER_LITE. Otherwise no changes. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: Updated .md files and added missing include files - Changes: - all: https://git.openjdk.java.net/jfx/pull/447/files - new: https://git.openjdk.java.net/jfx/pull/447/files/341eb765..77640795 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=447=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=447=00-01 Stats: 14 lines in 4 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.java.net/jfx/pull/447.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/447/head:pull/447 PR: https://git.openjdk.java.net/jfx/pull/447
Re: RFR: 8262366: Update glib to version 2.66.7
On Wed, 31 Mar 2021 19:25:09 GMT, Kevin Rushforth wrote: >> - GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 >> - One bug was discovered in updated GStreamer which was causing deadlock or >> infinite loop during seek on macOS. See gstsystemclock.c for changes between >> ifdef GSTREAMER_LITE. Otherwise no changes. > > I get a compilation error on Linux: > > ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c: > In function 'gst_audio_buffer_map': > ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:158:7: > error: implicit declaration of function 'memset' > [-Werror=implicit-function-declaration] > 158 | memset (buffer->map_infos, 0, > | ^~ > ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:158:7: > warning: incompatible implicit declaration of built-in function 'memset' > ../../../gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.c:26:1: > note: include '' or provide a declaration of 'memset' > ... > cc1: some warnings being treated as errors > Makefile:270: recipe for target > 'modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.o' > failed > make: *** > [modules/javafx.media/build/native/linux/Release/obj/gstreamer-lite/gst-plugins-base/gst-libs/gst/audio/audio-buffer.o] > Error 1 > > This is with the gcc 10.2 compiler used for production builds. I cannot reproduce build failure on Linux. - PR: https://git.openjdk.java.net/jfx/pull/447
RFR: 8262366: Update glib to version 2.66.7
- GLib was updated to version 2.66.7 and GStreamer to version 1.18.3 - One bug was discovered in updated GStreamer which was causing deadlock or infinite loop during seek on macOS. See gstsystemclock.c for changes between ifdef GSTREAMER_LITE. Otherwise no changes. - Commit messages: - 8262366: Update glib to version 2.66.7 Changes: https://git.openjdk.java.net/jfx/pull/447/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=447=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8262366 Stats: 39553 lines in 439 files changed: 23426 ins; 5427 del; 10700 mod Patch: https://git.openjdk.java.net/jfx/pull/447.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/447/head:pull/447 PR: https://git.openjdk.java.net/jfx/pull/447
Integrated: 8257895: Allow building of JavaFX media libs for Apple Silicon
On Fri, 26 Feb 2021 03:58:17 GMT, Alexander Matveev wrote: > - Added support to compile media on arm. > - libffi is based on 3.3. This pull request has now been integrated. Changeset: 8adbc673 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/8adbc673 Stats: 2860 lines in 19 files changed: 2823 ins; 5 del; 32 mod 8257895: Allow building of JavaFX media libs for Apple Silicon Co-authored-by: Johan Vos Reviewed-by: jvos, kcr - PR: https://git.openjdk.java.net/jfx/pull/412
Re: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon [v2]
> - Added support to compile media on arm. > - libffi is based on 3.3. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] - Changes: - all: https://git.openjdk.java.net/jfx/pull/412/files - new: https://git.openjdk.java.net/jfx/pull/412/files/99f8788f..ca11a752 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jfx=412=01 - incr: https://webrevs.openjdk.java.net/?repo=jfx=412=00-01 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/412.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/412/head:pull/412 PR: https://git.openjdk.java.net/jfx/pull/412
Re: RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon [v2]
On Wed, 10 Mar 2021 23:46:39 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8257895: Allow building of JavaFX media libs for Apple Silicon [v2] > > This breaks the build on Windows. > > cl.exe -DFFI_BUILDING -DGSTREAMER_LITE -I../../../3rd_party/libffi/include > -I../../../3rd_party/libffi/include/win/x64 -nologo -W3 -WX- -EHsc -GS > -fp:precise -Gm- -Zc:wchar_t -Zc:forScope -Gd -wd"4430" -analyze- > -errorReport:queue -O1 -Oy -MD -Gy -GF -DX86_WIN64 -TC -c > -Fo.../jfx/modules/javafx.media/build/native/win/Release/obj/3rd_party/libffi/src/java_raw_api.obj > ../../../3rd_party/libffi/src/java_raw_api.c > ../../../3rd_party/libffi/include/win/x64\ffi.h(58): fatal error C1083: > Cannot open include file: 'ffitarget.h': No such file or directory > make[1]: *** [Makefile.ffi:79: > .../jfx/modules/javafx.media/build/native/win/Release/obj/3rd_party/libffi/src/closures.obj] > Error 2 > make[1]: *** Waiting for unfinished jobs > java_raw_api.c > ../../../3rd_party/libffi/include/win/x64\ffi.h(58): fatal error C1083: > Cannot open include file: 'ffitarget.h': No such file or directory > make[1]: *** [Makefile.ffi:79: > .../jfx/modules/javafx.media/build/native/win/Release/obj/3rd_party/libffi/src/java_raw_api.obj] > Error 2 > make[1]: Leaving directory > '.../jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite' > make: *** [Makefile:60: > .../jfx/modules/javafx.media/build/native/win/Release/libffi.lib] Error 2 > make: Leaving directory > '.../jfx/modules/javafx.media/src/main/native/gstreamer/projects/win/glib-lite' > > FAILURE: Build failed with an exception. > > * Where: > Build file '...\jfx\build.gradle' line: 3284 > > * What went wrong: > Execution failed for task ':media:buildWinGlib'. >> Process 'command 'make'' finished with non-zero exit value 2 Windows build should be fixed. - PR: https://git.openjdk.java.net/jfx/pull/412
RFR: 8257895: Allow building of JavaFX media libs for Apple Silicon
- Added support to compile media on arm. - libffi is based on 3.3. - Commit messages: - 8257895: Allow building of JavaFX media libs for Apple Silicon Changes: https://git.openjdk.java.net/jfx/pull/412/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx=412=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8257895 Stats: 2856 lines in 17 files changed: 2821 ins; 5 del; 30 mod Patch: https://git.openjdk.java.net/jfx/pull/412.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/412/head:pull/412 PR: https://git.openjdk.java.net/jfx/pull/412
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
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
Integrated: 8252107: Media pipeline initialization can crash if audio or video bin state change fails
On Thu, 20 Aug 2020 23:32:24 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8252107 > > - Fixed by checking return value of audio/video bin state change and stopping > pipeline initialization if error occurred. This pull request has now been integrated. Changeset: c3fb3210 Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/c3fb3210 Stats: 27 lines in 1 file changed: 0 ins; 24 del; 3 mod 8252107: Media pipeline initialization can crash if audio or video bin state change fails Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/285
Re: RFR: 8252107: Media pipeline initializtion can crash if audio or video bin state change fails
On Thu, 20 Aug 2020 23:59:24 GMT, Kevin Rushforth wrote: > The PR title doesn't match the JBS title. Can you fix it? Fixed. It looks like github auto truncate long titles. - PR: https://git.openjdk.java.net/jfx/pull/285
Re: RFR: 8252107: Media pipeline initializtion can crash if audio or video bin state change fails
On Thu, 20 Aug 2020 23:57:12 GMT, Kevin Rushforth wrote: > I built and tested it on Linux and it looks good. Have you done a build / > test on Mac and Windows as well? Yes, Mac and Windows was tested with all formats. - PR: https://git.openjdk.java.net/jfx/pull/285
RFR: 8252107: Media pipeline initializtion can crash if audio or video bin…
https://bugs.openjdk.java.net/browse/JDK-8252107 - Fixed by checking return value of audio/video bin state change and stopping pipeline initialization if error occurred. - Commit messages: - 8252107: Media pipeline initializtion can crash if audio or video bin state change fails Changes: https://git.openjdk.java.net/jfx/pull/285/files Webrev: https://webrevs.openjdk.java.net/jfx/285/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8252107 Stats: 27 lines in 1 file changed: 24 ins; 0 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/285.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/285/head:pull/285 PR: https://git.openjdk.java.net/jfx/pull/285
Re: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central
On Thu, 23 Jul 2020 21:40:05 GMT, Kevin Rushforth wrote: > When running a JavaFX application using the JavaFX modules from maven > central, the native libraries are packed into the > jar file, and then unpacked as needed by the JavaFX runtime. This fails for > libavplugin-ffmpeg-58.so, because the entry > for the `avplugin-ffmpeg-58` library is missing from the list of dependent > libraries of `jfxmedia` in > [NativeMediaManager.java](https://github.com/openjdk/jfx/blob/14-ga/modules/javafx.media/src/main/java/com/sun/media/jfxmediaimpl/NativeMediaManager.java#L118). Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/272
Re: [jfx15] RFR: 8250238: Media fails to load libav 58 library when using modules from maven central
On Thu, 23 Jul 2020 21:44:22 GMT, Kevin Rushforth wrote: >> NOTE: This is targeted to `jfx15`. As such I would like a second reviewer. > > @sashamatveev can you review? > > @tiainen or @johanvos can one of you review as well? Looks good. - PR: https://git.openjdk.java.net/jfx/pull/272
Integrated: 8248365: Debug build crashes on Windows when playing media file
On Sat, 11 Jul 2020 03:04:16 GMT, Alexander Matveev wrote: > According to information found for similar bugs filed against libffi, this is > known issue with libffi. libffi modifies > stack frames and it triggers stack frame run-time error checking. Fixed by > disabling stack frame error checking in > debug build. It was already off in release build. This pull request has now been integrated. Changeset: 946590e6 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/946590e6 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8248365: Debug build crashes on Windows when playing media file Reviewed-by: kcr - PR: https://git.openjdk.java.net/jfx/pull/265
RFR: 8248365: Debug build crashes on Windows when playing media file
According to information found for similar bugs filed against libffi, this is known issue with libffi. libffi modifies stack frames and it triggers stack frame run-time error checking. Fixed by disabling stack frame error checking in debug build. It was already off in release build. - Commit messages: - 8248365: Debug build crashes on Windows when playing media file Changes: https://git.openjdk.java.net/jfx/pull/265/files Webrev: https://webrevs.openjdk.java.net/jfx/265/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8248365 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/265.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/265/head:pull/265 PR: https://git.openjdk.java.net/jfx/pull/265
Integrated: 8247947: Build DirectShow Samples (Base Classes) from source checked into repo
On Thu, 25 Jun 2020 23:19:05 GMT, Alexander Matveev wrote: > - Added DirectShow baseclasses to repository. > - Dependency on Windows SDK 7.1 DirectShow baseclasses was removed. This pull request has now been integrated. Changeset: 62f8cee7 Author:Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/62f8cee7 Stats: 38685 lines in 73 files changed: 8 ins; 38674 del; 3 mod 8247947: Build DirectShow Samples (Base Classes) from source checked into repo Reviewed-by: kcr, arapte - PR: https://git.openjdk.java.net/jfx/pull/254
RFR: 8247947: Build DirectShow Samples (Base Classes) from source checked into repo
- Added DirectShow baseclasses to repository. - Dependency on Windows SDK 7.1 DirectShow baseclasses was removed. - Commit messages: - 8247947: Fixed files permissions - 8247947: Build DirectShow Samples (Base Classes) from source checked into repo Changes: https://git.openjdk.java.net/jfx/pull/254/files Webrev: https://webrevs.openjdk.java.net/jfx/254/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8247947 Stats: 38685 lines in 73 files changed: 38674 ins; 8 del; 3 mod Patch: https://git.openjdk.java.net/jfx/pull/254.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/254/head:pull/254 PR: https://git.openjdk.java.net/jfx/pull/254
Re: RFR: 8247360: Add missing license file for Microsoft DirectShow Samples
On Tue, 16 Jun 2020 22:25:48 GMT, Kevin Rushforth wrote: > This adds a missing third-party license file for the Microsoft DirectShow > Samples. Marked as reviewed by almatvee (Reviewer). - PR: https://git.openjdk.java.net/jfx/pull/252
Re: [Integrated] RFR: 8239095: Upgrade libFFI to the latest 3.3 version
On Fri, 29 May 2020 01:24:29 GMT, Alexander Matveev wrote: > - Updated libffi to 3.3. This pull request has now been integrated. Changeset: 6bd0e22d Author: Alexander Matveev URL: https://git.openjdk.java.net/jfx/commit/6bd0e22d Stats: 10217 lines in 37 files changed: 4167 ins; 5498 del; 552 mod 8239095: Upgrade libFFI to the latest 3.3 version Reviewed-by: jvos, kcr - PR: https://git.openjdk.java.net/jfx/pull/242
Re: RFR: 8239095: Upgrade libFFI to the latest 3.3 version
On Mon, 1 Jun 2020 13:21:08 GMT, Kevin Rushforth wrote: >> That's a good question. The commented line was there from the first commit >> (in 9, changeset 9231:241f9696e3ad, >> https://bugs.openjdk.java.net/browse/JDK-8043352) but I don't see a reason >> on why it was disabled. >> libffi is also built in the GraalVM project, and that line is not commented >> there. >> >> @sashamatveev or @kevinrushforth do you remember the reason? > > No, I don't remember. No, I don't remember as well. - PR: https://git.openjdk.java.net/jfx/pull/242
RFR: 8239095: Upgrade libFFI to the latest 3.3 version
- Updated libffi to 3.3. - Commit messages: - 8239095: Fixed jcheck - 8239095: Upgrade libFFI to the latest 3.3 version Changes: https://git.openjdk.java.net/jfx/pull/242/files Webrev: https://webrevs.openjdk.java.net/jfx/242/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8239095 Stats: 10110 lines in 37 files changed: 5391 ins; 4060 del; 659 mod Patch: https://git.openjdk.java.net/jfx/pull/242.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/242/head:pull/242 PR: https://git.openjdk.java.net/jfx/pull/242
RFR: 8242530: [macos] Some audio files miss spectrum data when another audio file plays first
https://bugs.openjdk.java.net/browse/JDK-8242530 - GstElementClass which is base class for all elements has same instance between all spectrum elements (not sure if it is same for all elements) and thus post_message was sending events to AVFoundation callback from GStreamer platform. This issue is reproducible if we load OSXPlatfrom first and then play media files using GStreamer. Fixed by introducing separate callback to send messages to AVFoundation. - Commit messages: - 8242530: [macos] Some audio files miss spectrum data when another audio file plays first Changes: https://git.openjdk.java.net/jfx/pull/184/files Webrev: https://webrevs.openjdk.java.net/jfx/184/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8242530 Stats: 23 lines in 3 files changed: 19 ins; 0 del; 4 mod Patch: https://git.openjdk.java.net/jfx/pull/184.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/184/head:pull/184 PR: https://git.openjdk.java.net/jfx/pull/184
RFR: 8241629: [macos10.15] Long startup delay playing media over https on Catalina
https://bugs.openjdk.java.net/browse/JDK-8241629 We used to link with system provided libffi (due to a bug in Makefile) and for some reason GLib signals did not work correctly and thus we did not able to build dynamic pipelines. We did not switch to AVFoundation until timeout is reached while waiting for GStreamer to start playing or report us an error. Fixed by linking GLib with libffi which we build, like we do for other platforms. - Commit messages: - 8241629: [macos10.15] Long startup delay playing media over https on Catalina Changes: https://git.openjdk.java.net/jfx/pull/179/files Webrev: https://webrevs.openjdk.java.net/jfx/179/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8241629 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jfx/pull/179.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/179/head:pull/179 PR: https://git.openjdk.java.net/jfx/pull/179
Re: [Closed] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina
On Tue, 7 Apr 2020 23:44:17 GMT, Alexander Matveev wrote: > https://bugs.openjdk.java.net/browse/JDK-8240694 > > - Original fix JDK-8236832 was reverted. > - Timestamp will be queried on event loop thread when spectrum event is > received by event loop. > - FIx only enabled for macOS when using OSXPlatform. This pull request has been closed without being integrated. - PR: https://git.openjdk.java.net/jfx/pull/163
Re: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina
On Wed, 8 Apr 2020 22:52:27 GMT, Kevin Rushforth wrote: >> Alexander Matveev has updated the pull request incrementally with one >> additional commit since the last revision: >> >> 8240694: Improved comments per reviewers request > > Can you add a root cause / evaluation either in JBS or to this PR? > > I also noted a few places where it might be helpful to add a comment in the > code, so anyone looking at it later will > know why you are querying the timestamp later from the event thread. > I'll finish my testing in parallel with your addressing those comments and > adding the evaluation. I updated comments in code and added a root cause / evaluation to JBS. - PR: https://git.openjdk.java.net/jfx/pull/163
Re: [Rev 01] RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina
> https://bugs.openjdk.java.net/browse/JDK-8240694 > > - Original fix JDK-8236832 was reverted. > - Timestamp will be queried on event loop thread when spectrum event is > received by event loop. > - FIx only enabled for macOS when using OSXPlatform. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8240694: Improved comments per reviewers request - Changes: - all: https://git.openjdk.java.net/jfx/pull/163/files - new: https://git.openjdk.java.net/jfx/pull/163/files/b43ace5c..0ea46c79 Webrevs: - full: https://webrevs.openjdk.java.net/jfx/163/webrev.01 - incr: https://webrevs.openjdk.java.net/jfx/163/webrev.00-01 Stats: 7 lines in 3 files changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jfx/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/163/head:pull/163 PR: https://git.openjdk.java.net/jfx/pull/163
RFR: 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina
https://bugs.openjdk.java.net/browse/JDK-8240694 - Original fix JDK-8236832 was reverted. - Timestamp will be queried on event loop thread when spectrum event is received by event loop. - FIx only enabled for macOS when using OSXPlatform. - Commit messages: - 8240694: [macos 10.15] JavaFX Media hangs on some video files on Catalina Changes: https://git.openjdk.java.net/jfx/pull/163/files Webrev: https://webrevs.openjdk.java.net/jfx/163/webrev.00 Issue: https://bugs.openjdk.java.net/browse/JDK-8240694 Stats: 62 lines in 11 files changed: 29 ins; 13 del; 20 mod Patch: https://git.openjdk.java.net/jfx/pull/163.diff Fetch: git fetch https://git.openjdk.java.net/jfx pull/163/head:pull/163 PR: https://git.openjdk.java.net/jfx/pull/163
Re: RFR: 8240832: Remove unused applecoreaudio.md third-party legal file
On Tue, 10 Mar 2020 18:37:50 GMT, Kevin Rushforth wrote: > As noted in the JBS issue, this is a follow-on bug to > [https://bugs.openjdk.java.net/browse/JDK-8232589](https://bugs.openjdk.java.net/browse/JDK-8232589) > to remove the > applecoreaudio.md third-party legal file now that we no longer include or use > CoreAudio. Looks good. - Marked as reviewed by almatvee (Reviewer). PR: https://git.openjdk.java.net/jfx/pull/142
Re: [Integrated] RFR: 8236832: [macos 10.15] JavaFX Application hangs on video play on Cata…
Changeset: 4c82af8d Author:Alexander Matveev Date: 2020-02-28 05:07:50 + URL: https://git.openjdk.java.net/jfx/commit/4c82af8d 8236832: [macos 10.15] JavaFX Application hangs on video play on Cata… Reviewed-by: kcr, ghb ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioProcessor.mm ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.cpp ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFAudioSpectrumUnit.h ! modules/javafx.media/src/main/native/jfxmedia/platform/osx/avf/AVFMediaPlayer.mm
