Manually dropping video frame in element

[Sebastian Dröge]

On Wed, 2021-01-20 at 16:35 -0800, Ryan Brigden wrote:
> 
> The master branch of the example repo reproduces the double meta api
> initialization error [2].

Yeah that's exactly the case we talked about: it causes two copies of
the meta to be used and those conflict then.

> Another branch [3] of this repo contains our attempt to resolve the
> issue by separating the implementation (gst-meta-imp), which is built
> as a dylib, and wrapper (gst-meta). The example in this branch also
> includes a plugin that uses the custom meta.
> 
> In [3], the custom_meta example (in the gst-meta crate) runs fine,
> but the test_pipeline fails with the error:
> ./target/release/test_pipeline: error while loading shared libraries:
> libstd-e12de7683a34c500.so: cannot open shared object file: No such
> file or directory
> 
> We're not sure what exactly requires a libstd shared object?

The one from your currently used Rust toolchain. That's required
because the meta and its users have to use the same implementation of
the `String` type (etc) and that's defined in there.

If std was linked statically you would have three copies of that again
(one in the application, one in the plugin, one in the
libgst_meta_imp.so).

If you installed Rust via rustup you would find it at e.g.
  ~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib

To get around that you would have to use only C types in the meta
implementation and compile it as a cdylib. You'd then have basically
the same situation as with the bindings for e.g. GstVideoMeta: a plain
C interface between shared libraries and Rust bindings for those.

> Perhaps we are taking the incorrect approach here?

It depends on your goals. What you do there would work. You can also do
it a bit simpler though. See the attached patch.

If you build libgst_meta_imp.so as a Rust shared library you must build
everything as part of the same cargo workspace or otherwise you'll
likely run into symbol mismatches unless you try really hard (and that
probably requires cargo changes).

The only way around that is using the C ABI between the shared
libraries. The above is all a result of Rust not having a stable ABI
and the tooling trying to prevent ABI mismatches as much as possible by
default.

-- 
Sebastian Dröge, Centricular Ltd · https://www.centricular.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: build.diff
Type: text/x-patch
Size: 861 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20210121/6a434eb3/attachment.bin>