The biggest changes are
- Many functions are not asynchronous anymore as it would be difficult
to run them correctly with our mix of synchronous C code and Rust
code.
- The pad context and its corresponding custom event are gone and
instead thread local storage and task local storage are used. This
makes it easier to correctly pass it through the different layers
of Rust and C code and back.
- Sink events have a different function for serialized and oob events,
src events are handled correctly by default now by simply forwarding
them.
- Task::prepare() has a separate variant that takes a preparation
function as this is a very common task.
- The task loop function can signal via its return value if it wants to
be called again or not.
ProxySink previously blocked on receiving the source pad
of ProxySrc in its ReadyToPaused transition, which meant
ProxySrc had to transition to Ready at the same time.
The usual use case is for the source and sink to reside in
two separate pipelines, and such an arrangement easily led
to deadlocks, as examplified by the new test case.
Instead we now maintain two more global hash maps holding
per-context sink pads and src pads weak references, and
forward events to those when needed.
As ProxySink may not have a source pad context to run
a future on when receiving FlushStart, gst::Element::call_async
is used instead, with a simple oneshot channel used to synchronize
flush start and flush stop handling.
Otherwise both would be closing the same socket, which a) breaks the
second user of the socket if any and b) could on the second close cause
a completely unrelated socket to be closed.
Windows part of the code is untested.
Otherwise in e.g. a pipeline like
ts-udpsrc ! ts-queue ! fakesink
the first turn would only get a packet and queue it up, then we would
wait due to throttling and only then we would forward the packet from
the queue (but not poll the socket again), wait again due to throttling
and only then poll and get the next packet.
See https://github.com/tokio-rs/tokio/issues/310
