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-27 05:51:01 +00:00
Code Issues Projects Releases Wiki Activity
gst-plugins-rs/generic/threadshare/Cargo.toml

73 lines
2.1 KiB
TOML
Raw Normal View History

threadshare: Initial commit
2018-03-06 09:38:27 +00:00
[package]
name = "gst-plugin-threadshare"
Update versions to 0.9.0
2022-01-15 18:33:49 +00:00
version = "0.9.0"
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"
Add build.rs that provides a version number, release date and other details
2019-06-03 10:53:58 +00:00
description = "Threadshare Plugin"
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.57
2022-02-21 20:38:01 +00:00
rust-version = "1.57"
threadshare: Initial commit
2018-03-06 09:38:27 +00:00
[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
async-task = "4.0.3"
concurrent-queue = "1.2.2"
futures = { version = "0.3.17", features = ["thread-pool"] }
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/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
slab = "0.4.2"
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-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
[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 = []
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