Since Android 4.3 there is a hidden method that retrieve the audio hardware
latency: AudioSystem.getOutputLatency() (that should not be used according to
the android comments).

This latency should not be used when we use AudioTrack.getTimestamp since it
already take into account the hardware latency. So why adding a new method ?
Because AudioTrack.getTimestamp don't work with Bluetooth (it returns false).

This fix lip sync with Bluetooth audio.

It improves delay precision for old devices.

Move AudioTimestamp variables into a separate struct.
Move AudioTimestamp calculation into a separate function.
Call getTimestamp every 500ms, keep the previous result in cache.

Since it only reset PlaybackHeadPosition.
Move i_samples_written initialisation out of this function.

It allows to play more than 13h30min (@44.1kHz).
Add more comments for the buggy getPlaybackHeadPosition method.

refs samples/A-codecs/Creative/

refs samples/A-codecs/CreativeADPCM8bit/

Some muxer is trowing incorrect rate/scale and then duration.
As we're not computing pts from fully decoded samples, we need
a correct pts for avcodec input. Fix is possible since ADPCM uses
a fixed bits/sample and header.

Was going into infinite loop in that case.
refs #14389

This mostly reverts commit f0380ff0 and
fixes it for Win32, but also Linux

Repicked pcr might be on a track that lacks
of pcr field.

Avoids breaking with pcr on separate pid

refactorings... :/

AMR is declared as V0, uncompressed chunk.
Reading a max of 1024 samples in that case is too much.

also reverts dad98149

It is present in the .zip and .7zip since forever

It takes bandwidth and space that is not useful.

Don't abort DecodeVideo when there is no p_block. It allows to fetch more than
one output buffer consequently.

Close #14034

refs issues/no-sound-tv.mov