winegstreamer: Manage our own streaming thread.
This is a rather large and complex change. It comprises several parts:
(1) Instead of directly sending EOS, segment, and sample events to the
downstream DirectShow sink, first queue them in a local buffer (i.e.
"pin->event").
(2) Spawn a separate thread per source pin (i.e. "stream_thread") which consumes
said events and sends them downstream.
(3) When flushing or stopping, explicitly wait for this thread to pause or stop
(respectively).
There are a few reasons for this:
(1) It reduces the number of Unix -> PE callbacks we need to make, easing PE
conversion. This is not a great advantage *a priori*, and may not be worth a
similar dedicated "handler" thread for most modules, but winegstreamer is
different—we were already marshalling these calls onto another thread, and
now that marshalling can go away (almost).
(2) Because GStreamer can only do pad negotiation (and hence autoplugging) while
running (in contrast to DirectShow, which can do it while stopped), we
currently have to renegotiate every time the pipeline is started. Most
applications don't start the graph more than once, but even that requires
two negotiations, and startup time is demonstrably too high. It would be
nice to keep the graph in PAUSED state all of the time, but this is
difficult to do without more fine-grained control over the streaming thread.
[In particular, we cannot reliably wait for all samples to be delivered
except by stopping the GStreamer pipeline.]
Signed-off-by: 
Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: 
Alexandre Julliard <julliard@winehq.org>
Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Showing
This diff is collapsed.
Click to expand it.
Please
register
or
sign in
to comment