We assume C99 nowadays.

The decoder pictures needs to be read back for rendering subtiles/OSD so
it's better to always use fast pictures for the decoders.

But as we don't have any module that provides slow pictures and are still
usable for DR...

When direct rendering was enabled, we used the display pool which can be
empty, leading to pictures being skipped.

Signed-off-by: Konstantin Pavlov <thresh@videolan.org>

It doesn't compile though, and is using a broken interface like crop

It is known to crash due to invalid buffer handling. On Linux, I get
memory accesses before the start of the audio buffer. It also crashes
on Windows. Until someone cares to fix it, and I think it really never
worked correctly, lets use the "ugly" resampler, which is not too ugly.

This should fix #3631, #4366, #4491 and possibly others.

Broken since d14e0b78

It's pretty much always -1.

It's been 7 years now...

Constify some function arguments.

After rewriting to use stream_* API gaps in segment sequence numbers
where detected. Solving this issue fixes live playback which was broken
since the rewrite to use the stream_* API.

Make the error message easier to read by splitting it up.

stream_filter/httplive.c: Append new segment any (HLS Live playback) when gap in sequence numbers is detected.

When a gap in segment sequence numbers is detected append the new one
anyway, since there is nothing that can be done to restore the missing
information. It will result in a playback hickup, but that cannot be
helped. Instead only complain loudly.

When reloading the HLS Playlist failes do not leak already allocated
hls_stream_t and segment_t structures. Instead cleanup.

Reloading HLS m3u8 file for live playback in a separate track. It used
to piggy back on the download track, which made it reload less often.
Since it would check the m3u8 file reload once after each download, which
generally takes longer then the suggested m3u8 reload algorithm.

This gets rid of one thread per RTP input. This will also ease would-be
support for RTCP.