Multiple concurrent buffers produced by the jitterbuffer will be
combined into a single buffer list which will be sent downstream.
Events or queries that interrupt the buffer flow will cause a split in
the output buffer list.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1618>
We can use `is_some_and(...)` instead of `map_or(false, ...)`.
Also in a few places the factory was retrieved multiple times, one time
with unwrapping and another time with handling the `None` case
correctly. Instead of unwrapping, move code to handle the `None` case.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1630>
We lost the environment variable checks during the addition of the
putobjectsink tests, which caused failures on MR branches.
It would be nicer to use some other mechanism to validate the tests can
run, so we don't count on only the environmnent, but for now this will
have to do.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1629>
They're not recommended by the spec to include in the RTP packets but it
is valid to include them. Pion is including them.
When parsing the size fields also make sure to only take that much of a
payload unit and to skip any trailing data (which should not exist in
the first place).
Pion is also currently storing multiple OBUs in a single payload unit,
which is not allowed by the spec but can be easily handled with this
code now.
Fixes https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/issues/560
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1612>
It would be possible that there is no cancellable yet when unlock() is
called, then a new future is executed and it wouldn't have any
information that it is not supposed to run at all.
To solve this remember if cancellation should happen and reset this
later.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1602>
It would be possible that there is no cancellable yet when unlock() is
called, then a new future is executed and it wouldn't have any
information that it is not supposed to run at all.
To solve this remember if unlock() was called and reset this in
unlock_stop().
Also implement actual unlocking in s3hlssink.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1602>
It would be possible that there is no cancellable yet when unlock() is
called, then a new future is executed and it wouldn't have any
information that it is not supposed to run at all.
To solve this remember if unlock() was called and reset this in
unlock_stop().
Also actually implement unlock() / unlock_stop() for the sink, and don't
cancel in stop() as unlock() / unlock_stop() would've been called before
that already.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1602>
It would be possible that there is no cancellable yet when unlock() is
called, then the setup task is started and it would simply run and being
waited on instead of not being run at all.
To solve this, remember if unlock() was called and reset this in
unlock_stop().
Also make sure to not keep the abort handle locked while waiting,
otherwise cancellation would never actually work.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1602>
It would be possible that there is no cancellable yet when unlock() is
called, then a new future is executed and it wouldn't have any
information that it is not supposed to run at all.
To solve this remember if unlock() was called and reset this in
unlock_stop().
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-rs/-/merge_requests/1602>
