-
Zebediah Figura authored
Aside from EOS logic, which is now handled entirely on the client side, wg_parser_stream_get_event() now only waits for data processing—that is, demuxing, decoding, and format conversion. While unblocking waits in wg_parser_stream_get_event() does allow that function to return immediately, a subsequent seek request in GStreamer will still have to wait for that data processing to complete and for the stream thread to return to the demuxer's main loop. In essence, wg_parser_begin_flush() is only moving costs around. In theory we could force the GStreamer pipeline to complete faster by actually flushing it. In practice this isn't really true. Individual elements do check whether they are flushing before processing, but even elements which take a relatively long time (i.e. multiple milliseconds) to process data don't periodically check whether they are flushing while doing so. Although there is arguably a benefit to skipping some elements by flushing the GStreamer pipeline, it does not seem worth the added code complexity in Wine. The real point of flushing in DirectShow or GStreamer is to unblock long or unbounded waits in sink elements (i.e. waits for PTS, or waits for running state while rendering preroll frames). None of these waits apply here. Waits for actual sample processing complete in bounded time, and should ideally take less than the sample DTS to complete (or we are already in trouble). Signed-off-by: Zebediah Figura <zfigura@codeweavers.com> Signed-off-by: Alexandre Julliard <julliard@winehq.org>
5144b276
Name |
Last commit
|
Last update |
---|---|---|
dlls | ||
documentation | ||
fonts | ||
include | ||
libs | ||
loader | ||
nls | ||
po | ||
programs | ||
server | ||
tools | ||
.editorconfig | ||
.mailmap | ||
ANNOUNCE | ||
AUTHORS | ||
COPYING.LIB | ||
LICENSE | ||
LICENSE.OLD | ||
MAINTAINERS | ||
README | ||
VERSION | ||
aclocal.m4 | ||
configure | ||
configure.ac |