There is no support for progress dialogs so far

Make some assumptions on channels, like 6 channels is 5.1 etc.

Ref #1897

Assume that 3 channels is 2.1 instead of 3 front channels,
also 6 is 5.1.

Ref #1897

This allows automagic enabling and disabling of the needed and useful aout and vout modules

Agreed by Pierre d'Herbemont, Sebastian Zwickert, Rémi Denis-Courmont, Jean-Baptiste Kempf and me

Regression from ac3f6195 as without this
there could be negative/zero max_duration_length if playlist didn't
change and it would cause instantenious refetch of that playlist.

Required to avoid visual glitches when running out of free surfaces
with avcodec and vaapi/dxva2 backends.

Fix #10868

FFmpeg doc/APIchanges is not trustworthy.

Fix #10744

The number of threads impacts the number of surfaces that should be
allocated by the HW acceleration backend. If not enough surfaces are
allocated, the VAAPI and DXVA modules returned the oldest surface
currently in used. This technique can cause many visual glitches with
some samples. The number of allocated surfaces now scales with the
number of threads used by avcodec.

Fix #9887
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>

(see also fccfbd2f)

This should perhaps be const... but libavcodec seems to require
non-const even when const ought to be enough :-(

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>

Close #10832

We don't do any actual call to gettext here, so the warning
is not really needed.

dequeueOutputBuffer should have an higher priority since releasing an
output buffer often allows MediaCodec to make progress