For asynchronous elements like a media source the paused state is rather
similar to the playing state. The most revelant difference is that
RequestSample commands are not immediately executed, but are scheduled
in an internal queue. As soon as playback is restarted, all pending
operations are submitted again (or they are discarded if playback is
stopped).
This patch implements such a queue, together with proper event emitting
when the media source is paused. Also, the characteristic
MFMEDIASOURCE_CAN_PAUSE is announced.
This patch is required for correct playback of some videos in Deep Rock
Galactic.
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
When starting a media source, the caller can specify a timestamp to seek
to by mean of a PROPVARIANT argument. If the PROPVARIANT is empty, then
no seek operation has to take place: playback has to either restart from
the beginning (if the media source was previously in stopped state) or
from where it was left (if the media source was in paused state).
Also, when a PROPVARIANT is empty it is a bug to use its content, because
there is no guarantee that it is initialized to a sensible value.
This patch fixes both bugs by gating the seek operation with the check
that the PROPVARIANT has the right type.
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Currently the media source emit a presentation timestamp relative to
when the playback was last restarted. I.e., the frame that sits two
seconds inside a media file will get timestamp 2 if playback was
started at the beginning of the file, but will get timestamp 1 if
playback was last restarted at second 1.
This does not match Windows behavior, where each frame always gets
the same timestamp independently from where playback was started.
Signed-off-by: Giovanni Mascellani <gmascellani@codeweavers.com>
Signed-off-by: Huw Davies <huw@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This reverts commit 1aa359a100.
appsrc suffers from a rather problematic race condition surrounding flushes [1].
Essentially, it's possible for a flushing seek to begin and end between
wg_parser_get_next_read_request and wg_parser_push_data. The race condition is
not easy to fix, and in light of it it's not clear if we want to use appsrc.
[1] https://www.winehq.org/pipermail/wine-devel/2021-September/196043.html
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51774
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
This necessitates an extra blit for the input data, but this is necessary for
both WoW64 support and an internal rework of the source path in wg_parser to use
GstAppSrc. Since source data is usually compressed and not a bottleneck, we
don't expect this to affect performance.
Signed-off-by: Derek Lesho <dlesho@codeweavers.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of having mixing together IMFMediaSource::Shutdown() and the
constructors' failure paths, creating confusion about what should be released
where, designate ::Shutdown/::Release to shutting down fully initialized objects
without checks, and keep the partially-created object cleanup code in the
constructor.
Signed-off-by: Derek Lesho <dlesho@codeweavers.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
In particular, unset the sink_connected value, and make sure that subsequent
wg_parser_get_read_request calls don't hang.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Zebediah Figura