See also 0fde3bea.

This fixes an assertion failure.
Regression from 62140018.

This should fix some crashes as reported by the users.

Fixes #14186

a positive HRESULT means it succeeded.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

There is a race when starting video with subtitles at a given position (via
--start-time).

If all decoders are flushed early, the video decoder may not have created the
Vout via the decoder_NewPicture call. In that case, spu_new_buffer will be
blocking for 6 seconds. Indeed, spu_new_buffer can block for maximum 6 seconds
when it's waiting for a Vout.

To solve this race, abort spu_new_buffer if decoder is flushing.

How to reproduce the race condition:
./vlc --start-time 3600 <video_with_subtitles>
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Fixes #2100.

Override toggleVisible of BookmarkDialog to call update before using toggleVisible of QVLCFrame
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Fixes incorrect offset when playing http://streams.videolan.org/misc/test-files-ccc/vsfilter_general_TestCase.mkvSigned-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Check the teletext framing code in PES buffer for each of the received lines
and only copy those with correct framing code (p_block->p_buffer[3]) to the
p_sliced buffer that is later forwarded to ZVBI vbi_decode. Invalid lines
will not reach vbi_decode anymore.

When also packets with erroneous framing code are sent to vbi_decode (often
0x00 with some noise), in most cases those are decoded as packet 1/2,
causing the second text line on the teletext page to be overwritten with
spaces. So we need to avoid sending such packets with invalid framing code
to vbi_decode.

Close #14191
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Try to detect runtime what windows version it is running to see if
receive buffers should be increased or leave to OS handling.
Fixes #14200

With the current input clock and decoder buffering code, getting large
buffers is essential. So favor that over having short audio periods.
(Ideally the audio period should probably be an half or a third of the
PTS delay, rather than hard-coded to 40 ms, but that is a separate
issue).

commit 6c9bc13f

See also a6b259b7.

DecoderSignalWait() had no observable effects if has_data was false. It
could wake up the condition variable, but no thread would wait on that
event.

In some cases, the thread(s) consuming a FIFO needs to wake up in other
circumstances than the FIFO being non-empty. For that purpose, this new
set of functions is vastly more flexible than block_FifoWake().

There are ARM servers and or HD/UHD-capable STBs. The distinction no
longer makes sense.

es->p_dec is obviously non-NULL when the loop starts, and the loop
cannot change the value.

Calling input_DecoderStopWait() from the decoder thread makes no sense
as it signals a condition variable that only the decoder thread itself
would ever wait on.

More importantly, the call breaks assumptions made by the input thread.
For instance, input_DecoderDecode() assumes p_owner->b_waiting is only
changed by the decoder owner (i.e. input) thread.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The renderer may be updated in the DMO thread which uses COINIT_MULTITHREADED
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>