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
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
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_
ode 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 incrementa
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:
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_
ode 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 incrementa
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_
ode 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 incrementa
ode 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 incrementa
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 Conne
- 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
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. Re
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
ementary 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
- 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
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]
>
> module
ementary 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
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
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 Matvee
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.
---
> 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
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
- 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
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 introduce
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.m
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.m
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.m
ependency 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 incre
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 mfwrap
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.m
ependency 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 incre
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 mfwrap
ependency 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 incre
- 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
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 ru
- 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
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/com
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:
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 wi
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 additio
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
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 OS
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
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 Matvee
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/
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
>>
> 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 onEndO
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:
- 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:
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 t
- 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
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 decode
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
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
> in
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
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
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
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
> de
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
>> Des
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
> de
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 t
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
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
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 cur
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
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 change
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
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
> - 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.
Alexa
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
>>
- 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
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
> - 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:
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]
>
> Th
- 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:
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 i
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:
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
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
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
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
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
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:
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
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.
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:
- 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:
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
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
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
- 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-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
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
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 enab
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 ca
> 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 ha
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
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
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
1 - 100 of 157 matches
Mail list logo
