Writing a proper "depfile" to follow depending files, based on depfiles
generated by rustc.
This is based on work done while working on gobject-examples-rs
The element has a small race condition where it might output two buffers
with the same running time during e.g. a manual switch. In practice this
is not a problem, so the test takes this race into account.
Fixes: https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/195
This new video filter is able to detect the dominant color in a video frame.
When the color has changed from the previous frame the filter posts an Element
message on the bus, the associated structure is named `colordetect` and has two
fields:
* a string field named `dominant-color`
* a list field containing the whole color palette, stored as uint values, sorted
by dominance, with more dominant colors first
Also clip raw audio/video buffers according to the caps if they have the
relevant information in the caps, and drop raw audio samples if they're
outside the segment too.
In addition also set durations on raw audio/video buffers based on the
caps if no duration is set.
fallbackswitch might forward flush event if it's for the currently
active pad. But forwarded flush event will be problematic in various
reasons and that's not a behavior we expected.
There can be small race where transcription-bin is linked with
tee but state change of the transcription-bin is not finished.
And at the same time, upstream pushes event/buffer to the
transcription-bin. Do state change first then link to avoid
the condition
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/716>
Requesting the first pad will emit the property because the first pad is
then selected. That will cause the callback to be called, which tries to
take the same mutex that is already locked during element setup and
causes a deadlock.
I give up on crossbeam_channel. For some reasons some receivers are not
always unblocked and I was not able to reproduce using simpler test
cases.
Use with mpsc channels instead which are more reliable.
fallbackswitch now supports multiple sink pads, and on a timeout of the
active pad, it will automatically switch to the next lowest priority pad
that has data available.
fallbackswitch sink pads follow the `sink_%u` template and have
`priority` as a pad property.
Co-authored-by: Vivia Nikolaidou <vivia.nikolaidou@ltnglobal.com>
This let the application get an error message when ndisrc emits an EOS
triggered by 'connect-timeout' for instance.
Without this, a simple gst-launch-1.0 ndisrc pad-name="badname"
connect-timeout=1000 ! ndisrcdemux ! fakesink will block.
