This is racy and can cause the consumer of the messages to never be
woken up anymore:
1. Waker is stored because no message on the bus
2. Sync handler is called, waker is woken up
3. Bus is polled again and no message is on it (yet),
new waker is registered
4. Bus stores the message from 2. in its queue (after
the sync handler has returned BusSyncReply::Pass)
5. No new message ever appears on the bus because all
this happened for the very last message
Fixes https://gitlab.freedesktop.org/gstreamer/gstreamer-rs/issues/235
This allows to use MappedBuffer and similar types to be properly
debug-printed.
Also change VideoFrame/VideoFrameRef/RTPBuffer from a tuple struct to a
struct with proper field names to make the code easier to understand.
The future would resolve into the return value of the closure that is
called asynchronously on the thread pool, and allows asynchronous
awaiting for it to finish.
let res = element.call_async(|element| {
element.set_state(gst::State::Playing)
}).await;
assert_eq!(res, Ok(gst::StateChangeSuccess::Success))
Rework the API to statically prevent users adding extra features if the
builder has been created with builder_full_with_any_features(). It
doesn't make sense to add extra features if all are already included.
It does not borrow from anything else and can be safely stored away.
Only the VideoCodecState<InNegotiation> is actively borrowing from the
element to ensure that it is only modified during negotiation in a safe
way.
They can actually be shared with multiple threads at the same time
safely as all functions requiring an immutable reference are
thread-safe.
OTOH TypeFind can't be shared safely between different threads as not
all implementations of the TypeFind struct are thread-safe.
We need some classes derived from `BaseSink` to not enforce render being
implemented.
An example of this is AudioSink which only requires the user to
implement `write` but not `render`, so the default implementation
of render needs to be called.
It might be gone once we called into the parent class' implementation so
we need to keep a strong reference around here. Also we need to ensure
that we don't accidentally steal a floating reference from the caller
here: if the element is still floating it is apparently not part of this
bin and we can directly return FALSE.
This way we take ownership of any floating references passed in here, as
required by the GstBin API, instead of just borrowing the reference and
having someone else sink it or not.
