François Laignel authored Dec 19, 2021 and Sebastian Dröge committed Dec 20, 2021

In `sink_chain` when the Segment is pending, attempting to lock
rec state could lead to a dead lock because the stream state is
already locked while the main stream state was not locked.

François Laignel authored Dec 19, 2021 and Sebastian Dröge committed Dec 20, 2021

Function `check_and_update_stream_start` checks whether other streams
reached EOS. The stream being checked might already have locked its
state. If it's about to check other streams too, this results in a
deadlock.

The problem was due to the `main_state` guard being dropped handling
event `StreamStart` checking whether the main stream is EOS:

```rust
    let main_is_eos = if let Some(main_state) = main_state {
        main_state.eos
    } else {
        false
    };
```

In the above code, `main_state` main state is comsumed and dropped
after evaluating `main_state.eos`.

This is also the case before handling event `Eos`.

This revealed another deadlock handling event `Eos` which is under
investigation.

Otherwise it will regularly fail because the runner already has the
directory available for some reason.

It should restart any pending streams instead of keeping everything
EOS'd

Part-of: <!622>

fallbacksrc: Actually calculate running times of segment start/stop if the PTS is outside the segment

Previously it was just using the segment start/stop without converting
it to the corresponding running time.

See https://github.com/hsivonen/encoding_rs/issues/75

A multipart upload should either be completed or aborted on error. In
the current state of things, a multipart upload would neither be
completed nor aborted, putting the onus on an external entity to take
care of finishing incomplete uploads or relying on a sane bucket
life cycle policy configured to abort incomplete multipart uploads.

An incomplete multipart upload still contributes to the storage costs as
long as it exists.

We introduce a property here to allow the user to select either aborting
or completing multipart uploads on error. Aborting the upload causes
whole of data to be discarded and the same upload ID is not usable for
uploading more parts to the same.

Completing an incomplete multipart upload can be useful in situations
like having a streamable MP4 where one might want to complete the upload
and have part of the data which was uploaded be preserved.

Part-of: <gstreamer/gst-plugins-rs!618>

uriplaylistbin plays a list of URIs sequentially, ensuring gapless transitions
and proper streams synchronization.

Mathieu Duponchelle authored Nov 24, 2021 and Sebastian Dröge committed Nov 24, 2021

The design of the element is based on the assumption that when
receiving a partial result, the following result will contain
at least as many items as there were stable items in the previous
result.

This patch adds a sanity check to make sure our "partial index"
isn't larger than the new received result, and errors out otherwise.

partial_index will eventually be reset to 0 once we receive a
new non-partial result.

Tomasz Andrzejak authored Nov 23, 2021 and Sebastian Dröge committed Nov 23, 2021

Fixes gstreamer/gst-plugins-rs#128

This property can be used to set metadata on the S3 storage object.

This plugin takes I420/YUV and appends an alpha plane to give YUVA/A420
to round the corners analogous to the border-radius in CSS. Other video
formats like NV12 not supported yet. Support for other planar formats
will follow.

Not all ways of specifying border-radius as in CSS are implemented at
the moment. Currently, we only support specifying it in pixels and it
gets applied uniformly to all corners.

Pass the object instance to the debug logs too to be able to distinguish
multiple instances.

See https://github.com/gtk-rs/gtk-rs-core/pull/384

Jan Alexander Steffens authored Nov 18, 2021 and Sebastian Dröge committed Nov 18, 2021

Only affects the claimed default in the properties, not the actual
default.

This uses nom 7 now.

Using the default-features implies `oldtime`, which adds a dependency on
the deprecated `time` 0.1 crate.

The vulnerability was handled as part of
gstreamer/gst-plugins-rs!602
and
gstreamer/gst-plugins-rs!603
but the tokio fork used in threadshare is based on an earlier
version which prevents cargo-deny from assuming that the vulnerability
is fixed.

See gstreamer/gst-plugins-rs!604

Fixed by gstreamer/gst-plugins-rs!602

A data race condition was discovered in tokio, which can lead
to memory corruption. This vulnerability affects our fork.

See:

- https://rustsec.org/advisories/RUSTSEC-2021-0124
- https://github.com/tokio-rs/tokio/issues/4225
- https://github.com/tokio-rs/tokio/pull/4226
- https://github.com/fengalin/tokio/pull/1

Fixes: gstreamer/gst-plugins-rs#174

Also add an asm feature to rav1e, which requires nasm to be in place.