Contrary to the existing Task Sink, the Async and Sync Mutex Sinks
handle buffers in the `PadSinkHandler` directly. The Async Mutex
Sink uses an async Mutex for the `PadSinkHandlerInner` while the
Sync Mutex Sink uses... a sync Mutex.
All Sinks share the same settings and stats manager.
Use the `--sink` command line option to select the sink (default is
`sync-mutex` since it allows evaluating the framework with as little
overhead as possible.
Also apply various fixes:
- Only keep the segment start instead of the full `Segment`. This
helps with cache locality (`Segment` is a plain struct with many
fields) and avoids downcasting the generic `Segment` upon each
buffer handling.
- Box the `Stat`s. This should improve cache locality a bit.
- Fix EOS handling which took ages for no benefits in this
particular use case.
- Use a macro to raise log level in the main element.
- Move error handling during item processing in `handle_loop_error`.
This function was precisely designed for this and it should reduce
the `handle_item`'s Future size.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/977>
error[E0425]: cannot find value `LIBRARY_NAME` in this scope
--> net/ndi/src/ndisys.rs:336:23
|
336 | path.push(LIBRARY_NAME);
| ^^^^^^^^^^^^ not found in this scope
error[E0425]: cannot find value `LIBRARY_NAME` in this scope
--> net/ndi/src/ndisys.rs:339:33
|
339 | path::PathBuf::from(LIBRARY_NAME)
| ^^^^^^^^^^^^ not found in this scope
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/977>
This can happen at the beginning of a stream if upstream is
rtpjitterbuffer and it has problems figuring out timestamps in the
beginning due to resetting / skew.
... instead of the `Pad{Src,Sink}Ref` wrappers:
- In practice, only the `gst::Pad` is useful in these functions.
Some of these which need a `Pad{Src,Sink}Ref`, but it's the one
for the opposite stream direction. In those cases, it is accessed
via the element's implementation.
- It saves a few `clone`s.
- The implementations usually use the `gst::Pad` for logging.
They no longer need to access it via `pad.gst_pad()`.
- They are either unit types or `Clone` (in which case they are implemented
as pointers).
- Internally, we already use an owned version, so there's no need to get a
reference.
- It facilitates implementation if the handler must be moved into a closure
or a `Future`.
Fixed following warning.
gst-plugins-rs| WARNING: You should add the boolean check kwarg to the run_command call.
gst-plugins-rs| It currently defaults to false,
gst-plugins-rs| but it will default to true in future releases of meson.
gst-plugins-rs| See also: https://github.com/mesonbuild/meson/issues/9300
