When draining (pp_block == NULL), queue a dummy input buffer with a EOS flag,
and wait for the output thread to process all output frames.

This patch also add extra check when processing output buffers. Indeed, in some
case, the last output buffer with a EOS flag can be invalid.

Drain when pp_block is NULL.

The packetizer set the *pp_block to NULL, therefore p_block was NULL too.

This fixes a regression from 7ada6eae

Closes #16128

Audio, video, and sub decoders were not drained. Indeed, pf_decode_* functions
were called with *pp_block == NULL instead of pp_block == NULL. There was no
way to distinguish a drain from an other call from the decoder loop.

There was also an issue with the packetizer. Indeed, a successful call to
pf_packetize leaded to a drain.

This fixes a deadlock when seeking paused. It happened when avcodec needed more
pictures than VLC. It was easily reproducible with h264 in a TS file.

In case of ENOMEN, the current avcodec worker thread will be stopped.

As advised by lu_zero.

Add a boolean to reset the cancel state to false

Add a boolean to reset the cancel state to false.

The file has been renamed by 4441e96 in latest libgpg-error

Can be used if the surface given to mediacodec has a punch hole. Configuring a
punch hole depends of the hardware, therefore, this option is only for
developers that use libvlc with a known hardware.

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

First sectors of DVD are filled with zeros.
Checking boot sector avoids seeking when probing "regular" media files.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The underlying TCP socket is mostly used for receiving. So in most
cases, there is enough space in send buffers for the final packets
(such as RST_STREAM and GOAWAY frames).

This fixes a race condition where the output thread got cancelled
before draining the queue. Now, it only gets cancelled if the send
buffer is congested (i.e. it calls poll(POLLOUT)). In normal cases,
the thread will exit explicitly after draining.

We can handle HTTP/1.0 server responses to HTTP/1.1 client requests.

According to 7.4.1.2.3, SPS extension must only follow
sps and can't be picture start then.

The HTTP module will redirect to MMS(H) when applicable, so handing
of the "http" scheem in the MMS module is no longer necessary.

Removing it saves a pointless connection attempt when HTTP fails for a
reason other than redirecting to MMS.

There is no support for TLS in the current MMS plug-in.