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&pr=726&range=02 - incr: https://webrevs.openjdk.java.net/?repo=jfx&pr=726&range=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: 8283346: Optimize observable ArrayList creation in FXCollections
This simple PR optimizes the observable `ArrayList` creation by using the
ArrayList constructor/array size so that the underlying array will be
initialized at the correct size which will speed up the creation as the array
does not need to grow as a result of the `addAll` call.
I also added tests which will succeed before and after to verify that nothing
got broken by this change.
Also I made a benchmark test. Results:
Old: `ListBenchmark.init thrpt 25 722,842 ± 26,930 ops/s`
New: `ListBenchmark.init thrpt 25 29262,274 ± 2088,712 ops/s`
Benchmark code
import javafx.collections.FXCollections;
import javafx.collections.ObservableList;
import org.openjdk.jmh.annotations.Benchmark;
import org.openjdk.jmh.annotations.Scope;
import org.openjdk.jmh.annotations.Setup;
import org.openjdk.jmh.annotations.State;
import org.openjdk.jmh.annotations.TearDown;
import java.util.ArrayList;
import java.util.List;
@State(Scope.Benchmark)
public class ListBenchmark {
List strings;
@Setup
public void setup() {
strings = new ArrayList<>();
for(int i = 0; i< 10;i++) {
strings.add("abc: " + i);
}
}
@TearDown
public void tearDown() {
strings = null;
}
@Benchmark
public ObservableList init() {
return FXCollections.observableArrayList(strings);
}
}
-
Commit messages:
- 8283346: Optimized observable array list creation
Changes: https://git.openjdk.java.net/jfx/pull/758/files
Webrev: https://webrevs.openjdk.java.net/?repo=jfx&pr=758&range=00
Issue: https://bugs.openjdk.java.net/browse/JDK-8283346
Stats: 47 lines in 2 files changed: 41 ins; 2 del; 4 mod
Patch: https://git.openjdk.java.net/jfx/pull/758.diff
Fetch: git fetch https://git.openjdk.java.net/jfx pull/758/head:pull/758
PR: https://git.openjdk.java.net/jfx/pull/758
[jfx11u] RFR: 8197991: Selecting many items in a TableView is very slow
Co-authored-by: Naohiro Yoshimoto Reviewed-by: kcr, aghaisas - Commit messages: - 8197991: Selecting many items in a TableView is very slow Changes: https://git.openjdk.java.net/jfx11u/pull/82/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=82&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8197991 Stats: 403 lines in 5 files changed: 357 ins; 40 del; 6 mod Patch: https://git.openjdk.java.net/jfx11u/pull/82.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/82/head:pull/82 PR: https://git.openjdk.java.net/jfx11u/pull/82
[jfx11u] RFR: 8203463: [Accessibility, Narrator] NPE in TableView
Reviewed-by: kcr - Commit messages: - 8203463: [Accessibility, Narrator] NPE in TableView Changes: https://git.openjdk.java.net/jfx11u/pull/81/files Webrev: https://webrevs.openjdk.java.net/?repo=jfx11u&pr=81&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8203463 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.java.net/jfx11u/pull/81.diff Fetch: git fetch https://git.openjdk.java.net/jfx11u pull/81/head:pull/81 PR: https://git.openjdk.java.net/jfx11u/pull/81
Promote addEventHandler/removeEventHandler to EventTarget interface
I'm working on an application that uses the JavaFX event system extensively, and I'm finding it quite hard to use common code for event handler registrations. The problem is that the `EventTarget` interface contains no addEventHandler/removeEventHandler methods, and as a consequence of that, code that uses `EventTarget` ends up requiring lots of brittle instanceof tests to call these methods on all the different implementations of `EventTarget`. There are three buckets of `EventTarget` implementations: 1) Implementations that declare the following methods: void addEventHandler(EventType, EventHandler); void removeEventHandler(EventType, EventHandler); void addEventFilter(EventType, EventHandler); void removeEventFilter(EventType, EventHandler); --> Node, Scene, Window, Transform, Task, Service 2) Implementations that declare the following methods: void addEventHandler(EventType, EventHandler); void removeEventHandler(EventType, EventHandler); --> MenuItem, TreeItem, TableColumnBase (Note that the EventHandler argument ist parameterized as EventHandler, not EventHandler as in the first set of methods.) 3) Implementations that don't declare any methods to add or remove event handlers: --> Dialog, Tab I think the situation can be improved by promoting the bucket 1 methods to the `EventTarget` interface, so they can be used consistently across all implementations of `EventTarget`. This works seamlessly for bucket 1 and bucket 3 implementations. With bucket 2, there's the problem that, inconsistently, the EventHandler argument is not a lower-bounded wildcard. Unfortunately, a method with an EventHandler parameter cannot implement an interface method that expects EventHandler. However, since the erasure of the method remains the same, changing the method signature would technically be a binary-compatible change. Do you think this is a useful improvement?
Integrated: 8270867: Debug build of WebKit 613.1 fails on Linux
On Wed, 16 Mar 2022 07:54:57 GMT, Peter Zhelezniakov wrote: > The file `wtf/linux/MemoryPressureLinux.cpp` was renamed > `wtf/unix/MemoryPressureUnix.cpp` in https://trac.webkit.org/changeset/261428 > . In the openjfx workspace, both files are present. I'm removing the old file. This pull request has now been integrated. Changeset: eb7fa5dd Author:Peter Zhelezniakov URL: https://git.openjdk.java.net/jfx/commit/eb7fa5dd1c0911bca15576060691d884d29895a1 Stats: 142 lines in 2 files changed: 1 ins; 141 del; 0 mod 8270867: Debug build of WebKit 613.1 fails on Linux Reviewed-by: kcr, jbhaskar - PR: https://git.openjdk.java.net/jfx/pull/756
