And use it to implement WMA decoder Process(Input|Output).
The test output is different because ffmpeg WMA decoder outputs data in
a different way as native. The data seems valid audio nonetheless, and
it shouldn't matter too much.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51931
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52391
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
GStreamer pads are automatically unlinked when destroyed.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
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>
So that we can decode WMA to something else than the default avdec_wmav2
F32LE / non-interleaved format.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51931
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52391
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Instead of the size of the data requested, which may be e.g. UINT_MAX.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52277
Signed-off-by: Zebediah Figura <zfigura@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>
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>
This effectively reverts 613446d018.
Duration and convert queries, in general, appear to be handled by the first
upstream element that knows how. If two different elements respond to each
query, we may treat the byte duration of the whole file as if it were the
duration of a single stream, or treat an undecoded byte duration as if it were a
decoded byte duration.
The aforementioned commit was written in order to ensure that we receive a valid
duration for test.mp3 in quartz_test.exe, and is obviated by the previous
patches which retry duration queries until successful (or EOS).
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=51126
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
The TestBot treats anything containing the string ": error: " as a compiler
error. It may be possible for the TestBot to be smarter, but it seems easier
just to tweak winegstreamer.
Signed-off-by: Zebediah Figura <z.figura12@gmail.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Rémi Bernon