mirrors/gst-plugins-rs
mirrors/gst-plugins-rs
1
1
Fork 0
mirror of https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs.git synced 2024-11-15 14:52:04 +00:00
Code Issues Projects Releases Wiki Activity
gst-plugins-rs/generic/threadshare/Cargo.toml

84 lines
2.3 KiB
TOML
Raw Normal View History

threadshare: Initial commit
2018-03-06 09:38:27 +00:00
[package]
name = "gst-plugin-threadshare"
build: Update versions to be 0.9.0-alpha.1 0.9.0 is the next release, so we can't name things that already. Also the version in meson.build was 0.13.0, which is completely wrong.
2022-10-04 15:49:52 +00:00
version = "0.9.0-alpha.1"
threadshare: Initial commit
2018-03-06 09:38:27 +00:00
authors = ["Sebastian Dröge <sebastian@centricular.com>"]
fix LGPL-2.1+ license in Cargo.toml The proper SPDX name is LGPL-2.1-or-later, see https://spdx.org/licenses/
2020-04-16 11:06:34 +00:00
license = "LGPL-2.1-or-later"
Make GStreamer plugin/crate/library/directory names and descriptions consistent Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/238
2022-10-23 09:13:23 +00:00
description = "GStreamer Threadshare Plugin"
Add build.rs that provides a version number, release date and other details
2019-06-03 10:53:58 +00:00
repository = "https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs"
Update to Rust edition 2021 and minimum supported Rust version to 1.56
2021-10-31 10:54:12 +00:00
edition = "2021"
Update minimum supported Rust version to 1.63
2022-09-04 18:31:55 +00:00
rust-version = "1.63"
threadshare: Initial commit
2018-03-06 09:38:27 +00:00
[dependencies]
ts/Task: spawn StateMachine on ts Context Task state machines used to execute in an executor from the Futures crate. State transitions actions and iteration functions were then spawned on the target threadshare Context. This commit directly spawns the task state machine on the threadshare Context. This simplifies code a bit and paves the way for the changes described in [1]. Also introduces struct `StateMachineHandle`, which gather together fields to communicate and synchronize with the StateMachine. Renamed `StateMachine::run` as `spawn` and return `StateMachineHandle`. [1]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/793#note_1464400
2022-07-26 07:23:52 +00:00
async-task = "4.3.0"
ts/executor: replace tokio with smol-like implementation The threadshare executor was based on a modified version of tokio which implemented the throttling strategy in the BasicScheduler. Upstream tokio codebase has significantly diverged from what it was when the throttling strategy was implemented making it hard to follow. This means that we can hardly get updates from the upstream project and when we cherry pick fixes, we can't reflect the state of the project on our fork's version. As a consequence, tools such as cargo-deny can't check for RUSTSEC fixes in our fork. The smol ecosystem makes it quite easy to implement and maintain a custom async executor. This MR imports the smol parts that need modifications to comply with the threadshare model and implements a throttling executor in place of the tokio fork. Networking tokio specific types are replaced with Async wrappers in the spirit of [smol-rs/async-io]. Note however that the Async wrappers needed modifications in order to use the per thread Reactor model. This means that higher level upstream networking crates such as [async-net] can not be used with our Async implementation. Based on the example benchmark with ts-udpsrc, performances seem on par with what we achieved using the tokio fork. Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/118 Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/604
2021-12-14 18:40:27 +00:00
concurrent-queue = "1.2.2"
ts/udpsink: reduce sync primitives in async hot path The way the runtime::Task is implemented, UdpSinkTask is available as a mutable ref in all the TaskImpl functions, which offers the opportunity to avoid using Mutexes. Main higlights: - Removed the back and forth calls between UdpSinkPadHandler and UdpSinkTask. - Udp sockets are now part of UdpSinkTask, which is also in charge of preparing them instead of leaving this to UdpSink. This removed the need for Context::enter since TaskImpl::prepare already operates under the target Context. - In order for the clients list to be visible from the UdpSink, this list was maintained by UdpSinkPadHandler which was also in charge of (un)configuring the Udp sockets. The sockets are now part of UdpSinkTask, which is also in charge of the (un)configuration. Add/remove/replace requests are passed as commands to the UdpSinkTask via a channel. - The clients list visible to the UdpSink is now part of the Settings (it is also a read/write property). Since the actual socket (un)configuration is asynchronously handled by the Task, the clients list is updated by the add/remove/replace signals and set_property("clients", ..). Should a problem occur during the async (un)configuration, and only in this case, the UdpSinkTask would update the clients lists in Settings accordingly so that it stays consistent with the internal state. - The function clear_clients was renamed as replace_with_clients. - clients is now based on a BTreeSet instead of a Vec. All the managing functions perform some sort of lookup prior to updating the collection. It also ease implementation. - Removed the UdpSinkPadHandler RwLock. Using flume channels, we are able to clone the Receiver so it can be stored in UdpSink and reused when preparing the UdpSinkTask.
2022-06-23 16:50:11 +00:00
flume = "0.10.13"
ts/Task: spawn StateMachine on ts Context Task state machines used to execute in an executor from the Futures crate. State transitions actions and iteration functions were then spawned on the target threadshare Context. This commit directly spawns the task state machine on the threadshare Context. This simplifies code a bit and paves the way for the changes described in [1]. Also introduces struct `StateMachineHandle`, which gather together fields to communicate and synchronize with the StateMachine. Renamed `StateMachine::run` as `spawn` and return `StateMachineHandle`. [1]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/793#note_1464400
2022-07-26 07:23:52 +00:00
futures = "0.3.21"
ts-udpsrc: Dup the socket so that both tokio and GIO can take ownership of it Otherwise both would be closing the same socket, which a) breaks the second user of the socket if any and b) could on the second close cause a completely unrelated socket to be closed. Windows part of the code is untested.
2018-11-30 17:38:25 +00:00
libc = "0.2"
Update repository URL for gtk-rs "core" crates
2021-05-13 06:50:08 +00:00
gio = { git = "https://github.com/gtk-rs/gtk-rs-core" }
Delete minimum GStremer required version for some plugins Tested building the pluging with cargo-c and running gst-inspect-1.0 in a Ubuntu Xenial 18.04 LTS. It contains GStreamer 1.8.3.
2021-07-20 19:49:24 +00:00
gst = { package = "gstreamer", git = "https://gitlab.freedesktop.org/gstreamer/gstreamer-rs" }
threadsharing: migrate to async/await and tokio 0.2.0-alpha.6 See https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/merge_requests/164
2019-11-24 20:12:40 +00:00
gst-net = { package = "gstreamer-net", git = "https://gitlab.freedesktop.org/gstreamer/gstreamer-rs" }
gst-rtp = { package = "gstreamer-rtp", git = "https://gitlab.freedesktop.org/gstreamer/gstreamer-rs" }
threadshare: spawn StateMachine on the futures::executor::ThreadPool StateMachines are spawned on a runtime::Context which uses a tokio runtime. The StateMachine doesn't need all the features from tokio such as the IO and timers drivers. This commit makes use of a light-weight futures executor to spawn the StateMachines.
2020-05-15 21:37:56 +00:00
once_cell = "1"
ts/executor: replace tokio with smol-like implementation The threadshare executor was based on a modified version of tokio which implemented the throttling strategy in the BasicScheduler. Upstream tokio codebase has significantly diverged from what it was when the throttling strategy was implemented making it hard to follow. This means that we can hardly get updates from the upstream project and when we cherry pick fixes, we can't reflect the state of the project on our fork's version. As a consequence, tools such as cargo-deny can't check for RUSTSEC fixes in our fork. The smol ecosystem makes it quite easy to implement and maintain a custom async executor. This MR imports the smol parts that need modifications to comply with the threadshare model and implements a throttling executor in place of the tokio fork. Networking tokio specific types are replaced with Async wrappers in the spirit of [smol-rs/async-io]. Note however that the Async wrappers needed modifications in order to use the per thread Reactor model. This means that higher level upstream networking crates such as [async-net] can not be used with our Async implementation. Based on the example benchmark with ts-udpsrc, performances seem on par with what we achieved using the tokio fork. Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/118 Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/604
2021-12-14 18:40:27 +00:00
pin-project-lite = "0.2.0"
ts/async_wrapper: remove fd from reactor before dropping its handle The I/O handle was dropped prior to removing it from the reactor, which caused `Poller::delete` to fail due to an invalid file descriptor. This used to happen silently unless the same fd was added again, e.g. by changing states in the pipeline as follow: Null -> Playing -> Null -> Playing. In which case `Poller::add` failed due to an already existing file. This commit makes sure the fd is removed from the reactor prior to dropping the handle. In order to achieve this, a new task is spawned on the `Context` on which the I/O was originally registered, allowing it to access the proper `Reactor`. The I/O can then safely be dropped. Because the I/O handle is moved to the spawned future, this solution requires adding the `Send + 'static` bounds to the I/O handle used within the `Async` wrapper. This appears not too restrictive for existing implementations though. Other attempts were considered, but they would cause deadlocks. This new approach also solves a potential race condition where a fd could be re-registered in a `Reactor` before it was removed.
2022-06-14 18:38:25 +00:00
polling = "2.2.0"
Update to rand 0.8
2021-01-09 10:24:28 +00:00
rand = "0.8"
ts/Task: spawn StateMachine on ts Context Task state machines used to execute in an executor from the Futures crate. State transitions actions and iteration functions were then spawned on the target threadshare Context. This commit directly spawns the task state machine on the threadshare Context. This simplifies code a bit and paves the way for the changes described in [1]. Also introduces struct `StateMachineHandle`, which gather together fields to communicate and synchronize with the StateMachine. Renamed `StateMachine::run` as `spawn` and return `StateMachineHandle`. [1]: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/793#note_1464400
2022-07-26 07:23:52 +00:00
slab = "0.4.7"
threadshare: Update to socket2 0.4
2021-03-21 10:57:10 +00:00
socket2 = {features = ["all"], version = "0.4"}
ts/executor: replace tokio with smol-like implementation The threadshare executor was based on a modified version of tokio which implemented the throttling strategy in the BasicScheduler. Upstream tokio codebase has significantly diverged from what it was when the throttling strategy was implemented making it hard to follow. This means that we can hardly get updates from the upstream project and when we cherry pick fixes, we can't reflect the state of the project on our fork's version. As a consequence, tools such as cargo-deny can't check for RUSTSEC fixes in our fork. The smol ecosystem makes it quite easy to implement and maintain a custom async executor. This MR imports the smol parts that need modifications to comply with the threadshare model and implements a throttling executor in place of the tokio fork. Networking tokio specific types are replaced with Async wrappers in the spirit of [smol-rs/async-io]. Note however that the Async wrappers needed modifications in order to use the per thread Reactor model. This means that higher level upstream networking crates such as [async-net] can not be used with our Async implementation. Based on the example benchmark with ts-udpsrc, performances seem on par with what we achieved using the tokio fork. Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/118 Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/604
2021-12-14 18:40:27 +00:00
waker-fn = "1.1"
threadshare: Initial commit
2018-03-06 09:38:27 +00:00
ts/examples: introduce a standalone pipeline test Implement a test that initializes pipelines with minimalistic theadshare src and sink. This can help with the evaluation of changes to the threadshare runtime or with element implementation details. It makes it easy to run flamegraph or callgrind and to focus on the threadshare runtime overhead.
2022-08-16 12:26:24 +00:00
# Used by examples
examples: Update to clap 4
2022-09-29 06:48:53 +00:00
clap = { version = "4", features = ["derive"], optional = true }
ts/examples: introduce a standalone pipeline test Implement a test that initializes pipelines with minimalistic theadshare src and sink. This can help with the evaluation of changes to the threadshare runtime or with element implementation details. It makes it easy to run flamegraph or callgrind and to focus on the threadshare runtime overhead.
2022-08-16 12:26:24 +00:00
ts-udpsrc: Dup the socket so that both tokio and GIO can take ownership of it Otherwise both would be closing the same socket, which a) breaks the second user of the socket if any and b) could on the second close cause a completely unrelated socket to be closed. Windows part of the code is untested.
2018-11-30 17:38:25 +00:00
[target.'cfg(windows)'.dependencies]
ts/executor: replace tokio with smol-like implementation The threadshare executor was based on a modified version of tokio which implemented the throttling strategy in the BasicScheduler. Upstream tokio codebase has significantly diverged from what it was when the throttling strategy was implemented making it hard to follow. This means that we can hardly get updates from the upstream project and when we cherry pick fixes, we can't reflect the state of the project on our fork's version. As a consequence, tools such as cargo-deny can't check for RUSTSEC fixes in our fork. The smol ecosystem makes it quite easy to implement and maintain a custom async executor. This MR imports the smol parts that need modifications to comply with the threadshare model and implements a throttling executor in place of the tokio fork. Networking tokio specific types are replaced with Async wrappers in the spirit of [smol-rs/async-io]. Note however that the Async wrappers needed modifications in order to use the per thread Reactor model. This means that higher level upstream networking crates such as [async-net] can not be used with our Async implementation. Based on the example benchmark with ts-udpsrc, performances seem on par with what we achieved using the tokio fork. Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/118 Related to https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/604
2021-12-14 18:40:27 +00:00
winapi = { version = "0.3.9", features = ["winsock2", "processthreadsapi"] }
ts-udpsrc: Dup the socket so that both tokio and GIO can take ownership of it Otherwise both would be closing the same socket, which a) breaks the second user of the socket if any and b) could on the second close cause a completely unrelated socket to be closed. Windows part of the code is untested.
2018-11-30 17:38:25 +00:00
generic: Update to 2018 edition
2020-11-22 14:24:55 +00:00
[dev-dependencies]
gst-check = { package = "gstreamer-check", git = "https://gitlab.freedesktop.org/gstreamer/gstreamer-rs" }
gst-app = { package = "gstreamer-app", git = "https://gitlab.freedesktop.org/gstreamer/gstreamer-rs" }
threadshare: Initial commit
2018-03-06 09:38:27 +00:00
[lib]
name = "gstthreadshare"
use cargo-c to produce cdy and static libs cargo-c will produce a pkg-config file making it easier to statically link plugins. Also add 'static' features for plugins depending on < 1.14 as this is the minimal required version to use static linking because of ABI changes in core.
2020-11-26 15:07:41 +00:00
crate-type = ["cdylib", "rlib"]
threadshare: Initial commit
2018-03-06 09:38:27 +00:00
path = "src/lib.rs"
threadshare: Refactor
2018-03-15 18:52:38 +00:00
threadshare: Add very simple udpsrc/tonesrc benchmark application
2018-04-05 13:00:43 +00:00
[[example]]
threadshare: Rename udpsrc_benchmark.rs to benchmark.rs.
2018-07-06 07:35:16 +00:00
name = "benchmark"
path = "examples/benchmark.rs"
threadshare: Add very simple udpsrc/tonesrc benchmark application
2018-04-05 13:00:43 +00:00
threadshare: Update udpsrc benchmark a bit
2018-04-05 17:28:20 +00:00
[[example]]
name = "udpsrc-benchmark-sender"
path = "examples/udpsrc_benchmark_sender.rs"
threadshare: Add TcpClient elements and unit test.
2018-07-06 07:32:24 +00:00
[[example]]
name = "tcpclientsrc-benchmark-sender"
path = "examples/tcpclientsrc_benchmark_sender.rs"
Add build.rs that provides a version number, release date and other details
2019-06-03 10:53:58 +00:00
ts/examples: introduce a standalone pipeline test Implement a test that initializes pipelines with minimalistic theadshare src and sink. This can help with the evaluation of changes to the threadshare runtime or with element implementation details. It makes it easy to run flamegraph or callgrind and to focus on the threadshare runtime overhead.
2022-08-16 12:26:24 +00:00
[[example]]
ts/standalone: multiple improvements - Reworked buffer push. - Reworked stats. - Make first elements logs stand out. This make it possible to follow what's going on with pipelines containing 1000s of elements. - Actually handle EOS. - Use more significant defaults. - Allow building without `clap` feature.
2022-08-19 17:40:05 +00:00
name = "ts-standalone"
ts/examples: introduce a standalone pipeline test Implement a test that initializes pipelines with minimalistic theadshare src and sink. This can help with the evaluation of changes to the threadshare runtime or with element implementation details. It makes it easy to run flamegraph or callgrind and to focus on the threadshare runtime overhead.
2022-08-16 12:26:24 +00:00
path = "examples/standalone/main.rs"
Add build.rs that provides a version number, release date and other details
2019-06-03 10:53:58 +00:00
[build-dependencies]
Drop gst-plugin- prefix in plugin directory name
2020-04-05 14:38:52 +00:00
gst-plugin-version-helper = { path="../../version-helper" }
WIP: thread-sharing jitterbuffer Actual thread-sharing will follow!
2019-08-05 13:19:06 +00:00
cc = "1.0.38"
pkg-config = "0.3.15"
use cargo-c to produce cdy and static libs cargo-c will produce a pkg-config file making it easier to statically link plugins. Also add 'static' features for plugins depending on < 1.14 as this is the minimal required version to use static linking because of ABI changes in core.
2020-11-26 15:07:41 +00:00
[features]
Update minimum supported GStreamer version to 1.14
2022-04-07 09:41:54 +00:00
static = []
Add capi feature to all plugin crates This fixes the build with cargo-c 0.9.2.
2021-08-11 17:51:36 +00:00
capi = []
ts: add feature to add counters for performance evaluation Add a `tuning` feature which adds counters that help with performance evaluation. The only counter added so far accumulates the duration a Scheduler has been parked, which is pretty accurate an indication of CPU usage of the Scheduler.
2022-09-07 21:10:29 +00:00
# Adds performance counters used by benchmarking tools.
tuning = []
Generate plugins documentation using hotdoc Which will automatically be integrated in gstreamer documentation
2022-08-25 22:30:08 +00:00
doc = ["gst/v1_18"]
use cargo-c to produce cdy and static libs cargo-c will produce a pkg-config file making it easier to statically link plugins. Also add 'static' features for plugins depending on < 1.14 as this is the minimal required version to use static linking because of ABI changes in core.
2020-11-26 15:07:41 +00:00
[package.metadata.capi]
Update versions to 0.8.0 for the master branch
2021-07-09 10:49:33 +00:00
min_version = "0.8.0"
use cargo-c to produce cdy and static libs cargo-c will produce a pkg-config file making it easier to statically link plugins. Also add 'static' features for plugins depending on < 1.14 as this is the minimal required version to use static linking because of ABI changes in core.
2020-11-26 15:07:41 +00:00
[package.metadata.capi.header]
enabled = false
[package.metadata.capi.library]
install_subdir = "gstreamer-1.0"
versioning = false
[package.metadata.capi.pkg_config]
requires_private = "gstreamer-1.0, gstreamer-net-1.0, gstreamer-rtp-1.0, gobject-2.0, glib-2.0, gmodule-2.0"
Reference in a new issue Copy permalink