This noticeably improves stream startup time. The process of typefinding and
negotiation takes about 70 ms for a simple test file on one machine, and this
is currently done twice. This patch replaces the second instance with a simple
seek, which takes less than 10 ms.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is a fatal error condition for GStreamer, but should not cause errors for
DirectShow.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It does not matter whether we use PAUSED or PLAYING, but we should at least be
consistent.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of propagating GStreamer flush events to corresponding DirectShow pins.
This is mainly to avoid more callbacks from GStreamer and further separate the
Win32 and Unix code.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
It's not used right now, Syriac specific groups will be accomodated
as additional joining types.
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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>
A typical case would be between using a texture as render target and using it
as a shader resource.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This was deprecated in Wine 5.0, use the "shader_backend" setting instead.
Signed-off-by: Henri Verbeet <hverbeet@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This is the message session relies on succeeding.
Signed-off-by: Derek Lesho <dlesho@codeweavers.com>
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
GStreamer doesn't necessarily signal all error when setting the
PLAYING or PAUSED state. If Wine just waits on no-more-pads, it risks
a deadlock if an error is signaled after gst_element_get_state was
called.
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Zebediah Figura