The buffer, in the writable case, needs to be actually writable (i.e.
refcount 1) and this was previously not ensured.
Also it caused some API mismatch when trying to use it e.g. as part of
basetransform's `transform_ip()` virtual method.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/162
This struct is "reimplemented" to make it easier to access the fields
instead of going through `ffi::GstVideoRectangle`, but should be marked
`repr(C)` to remain binary-compatible.
The usual use of this will be through the `ElementImpl::metadata`
method, which requires a `&'static` reference to `ElementMetadata` to be
returned, so we better make it easy to construct these (without forcing
people to resort to `Lazy`'n'stuff)
Attributes don't do anything when applied to macro invocations:
warning: unused attribute `doc`
--> gstreamer/src/lib.rs:146:29
|
146 | #[cfg_attr(feature = "dox", doc(cfg(feature = "v1_14")))]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: `#[warn(unused_attributes)]` on by default
note: the built-in attribute `doc` will be ignored, since it's applied to the macro invocation `cfg_if::cfg_if`
--> gstreamer/src/lib.rs:147:1
|
147 | cfg_if::cfg_if! {
| ^^^^^^^^^^^^^^
And, on line 294-295:
warning: unused attribute `doc`
--> gstreamer/src/lib.rs:294:33
|
294 | #[cfg_attr(feature = "dox", doc(cfg(feature = "v1_14")))]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
note: the built-in attribute `doc` will be ignored, since it's applied to the macro invocation `cfg_if::cfg_if`
--> gstreamer/src/lib.rs:295:5
|
295 | cfg_if::cfg_if! {
| ^^^^^^^^^^^^^^
Fortunately these two `cfg_if`'s for the Unix and Windows bus already
apply unnecessary trickery that duplicates the `mod`s and `use`s in
order to get documenation for both no matter the target platform; we can
capitalize on that by removing the `cfg_if` altogether and instead
applying the `cfg` and `doc(cfg())` attributes directly.
The `links` annotation in `Cargo.toml` is intended to ensure that in the
crate graph there's at most one crate that's an implementation of
some sort concept.
This can make sense in some scenarios, most prominent of which is when
the crate defines `#[no_mangle]` symbols (e.g. by compiling a vendored C
library.) In that situation linking a binary that depends on two
versions of the library cannot work because of colliding symbol names.
There does not appear to be a similar reason to impose such a
restriction on the users of `gstreamer-sys` and similar, however. All of
these crates link to a system library, they do not define any
`#[no_mangle]` symbols nor they vendor and build C libraries as part of
their build process. All they do is linking to a system library. Most
likely all the different versions of the bindings will link to the exact
same library too.
I haven't seen any global resources that these bindings use to ensure
soundness of the library, either.
