- Nov 18, 2024
-
-
Normal "fat" lto is quite resource heavy and requires a lot of ram at compile time. Thinlto is a much lighter alternative that produces comparable results performance but it scales much better. [1] [2] [3] All browser engines also compile with thinlto exclusively, as it's almost as fast and saves considerable amount of link time in the build. [1]: https://doc.rust-lang.org/cargo/reference/profiles.html#lto [2]: https://clang.llvm.org/docs/ThinLTO.html [3]: https://blog.llvm.org/2016/06/thinlto-scalable-and-incremental-lto.html In a test build on a windows machine, this brings down the from scratch compile time from 7m30s to roughly 5m. Part-of: <!1924>
-
- Oct 29, 2024
-
-
Tim-Philipp Müller authored
Part-of: <!1898>
-
- Oct 22, 2024
- Oct 21, 2024
-
-
There's no connection between the two and dmabuf can also not be supported if GL is also unsupported. Part-of: <!1842>
-
- Oct 18, 2024
- Sep 27, 2024
- Sep 26, 2024
- Sep 24, 2024
- Sep 21, 2024
-
-
The CI runners run multiple jobs concurrently, and as such we should only be building with the number of jobs allocated to us when the variable is set. Related to gstreamer-rs!1545 Also move the rest of the common flags we pass to cargo together so it's a bit easier to read. Part-of: <!1795>
-
Part-of: <!1781>
-
- Sep 20, 2024
-
-
webrtcsink was starting the negotiation process on Ready and concurrently moving the consumer pipeline to Playing, but when answering the remote description was set so fast that input streams were connected (and the time format set on appsrc) before the state change to Paused had completed. This meant gst_base_src_start was happening after that and setting the format back to bytes, the time segment that was next coming in then caused: basesrc gstbasesrc.c:4255:gst_base_src_push_segment:<video_0> segment format mismatched, ignore And the consumer pipeline errored out. The same issue existed in theory when webrtcsink was creating the offer, but was much harder to trigger as it required that the remote answer came in before the state change to Paused had completed. This commit fixes the issue by simply waiting for the state to have changed to Paused before negotiating. Part-of: <!1786>
-
Dumping the pipeline on state changes from an async bus handler was triggering criticals. Instead, dump from the sync handler. Part-of: <!1784>
-
Relax the dependency on `awstranscriber` by still building the initial state when it is absent, this also means an alternative transcriber can be linked even when `awstranscriber` was not available during construction. Also fix property getter / setters to avoid unwrapping the pad state, and bubble up channel bin construction errors instead of unwrapping (eg when textwrap was not available). Fixes: #584 Part-of: <!1783>
-
Noticed this typo Part-of: <!1780>
-
As soon as input caps arrive, we can set output caps. This means upstream can send gap events earlier, before there is any actual metadata to send Part-of: <!1787>
-
- Sep 19, 2024
-
-
add-transceiver needs application/x-rtp caps and not raw caps. We were providing raw caps which is incorrect. Part-of: <!1782>
-
- Aug 21, 2024
- Aug 13, 2024
-
-
Sebastian Dröge authored
Part-of: <!1710>
-
- Aug 05, 2024
-
-
This was defined one bracket above, which was causing the gst-gl codepath below to also be disabled when there was no dmabuf feature enabled. This was also resulting in the following warning as we were never creating the MappedFrame::GL vartiant due to this ``` warning: unused variable: `wrapped_context` --> video/gtk4/src/sink/frame.rs:541:85 | 541 | ...", feature = "gst-gl"))] wrapped_context: Option< | ^^^^^^^^^^^^^^^ help: if this is intentional, prefix it with an underscore: `_wrapped_context` | = note: `#[warn(unused_variables)]` on by default warning: variant `GL` is never constructed --> video/gtk4/src/sink/frame.rs:80:5 | 74 | enum MappedFrame { | ----------- variant in this enum ... ``` Move the cfg to the appropriate place where it encaplsulates only the dmabuf related code. Part-of: <!1686>
-
- Jul 24, 2024
-
-
Tim-Philipp Müller authored
Part-of: <!1678>
-
Tim-Philipp Müller authored
Part-of: <!1678>
-
Tim-Philipp Müller authored
Part-of: <!1678>
-
- Jul 12, 2024
-
-
- Jul 09, 2024
-
-
GTK4 has matching enums and thus should handle them fine. Further more it should allow renderers to reduce memory bandwidth by applying occlusion culling. Part-of: <!1661>
-
- Jul 06, 2024
- Jul 04, 2024
-
-
Part-of: <!1650>
-
- Jul 02, 2024
-
-
Otherwise the following can happen: - 25fps stream - buffer with PTS 0ms, duration 20ms arrives, is output - buffer with PTS 40ms, duration 20ms arrives - is considered early because 20ms < 40ms - filler buffer with PTS 20ms and 40ms duration is output - buffer with PTS 40ms is output After this change no filler would be inserted because the gap is smaller than the duration of a filler buffer. Also, previously the 40ms duration would be used if a filler was previously output because in that case the cached output buffer duration would've already been patched from 20ms to 40ms. Part-of: <!1648>
-
- Jun 28, 2024
-
-
By default livesync will wait for each buffer on the clock. If sync is set to false, it will output buffers immediately once they're available and only waits on the clock for outputting gap filler buffers. Part-of: <!1643>
-
Previously the first buffer would be output immediately and synchronization would only happen from the second buffer onwards. This would mean that the first buffer would potentially be output too early. Instead, if there is no known output timestamp yet but a buffer with a timestamp, first of all take its start as the initial output timestamp and synchronize on that buffer. Part-of: <!1643>
-
Part-of: <!1643>
-
This was already reported by the latency query, and not doing this would require to always put a queue before livesync. Part-of: <!1643>
-
- Jun 20, 2024
-
-
Fixes https://gitlab.freedesktop.org/tpm/gstreamer/-/jobs/60108579 Part-of: <!1633>
-
