refs #14193

refs #14193

p_owner->b_paused can only be written by the owner, so the owner thread
does not need to lock to read it. (However, locking is necessary to
write it from the owner thread, or to read it from the decoder thread.)

This removes small hacks surrounding this corner case.

Do not rely on allocating a block for draining the decoder and output.

All audio decoders support the *pp_block == NULL case, and return NULL.
This enables audio decoders to drain cleanly.

DecoderPlayAudio() has no effects with a NULL block.

MainMenus p_intf can be already accessed before
applicationWillFinishLaunching was called.

This should fix quite some crashes reported by the users.

There is nothing special about exiting at this level. The decoder
should discard its buffers and return to reading the input FIFO at the
earliest (where it gets canceled). This is the same as flushing.

See also 0fde3bea.

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).