The code size saving in vlc_cleanup_run() is marginal and premature
optimization. In practice, vlc_cleanup_run() makes the source code
harder to follow/read, confuses static analyzers and generates false
positive clobber warnings (on some OSes due to long jumps).

It did exercise some of the cleanup code paths though.

Cancellation cannot occur here.

If the input state were initially "smaller or equal to" PAUSE_S, the
loop would just run forever and deadlock. So assume it is always larger
and remove the slack.

Also fix an invalid function pointer cast.

Close() already clears the array (while destroying it).

Cancellation is not possible there, so this was just a long jump.

See also 63ef5806.

remove audiotrack-audio-channels option.

And reset object if audioTrack_New fails in AudioTrack_Recreate.

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

Wait for the end of the pacing interval, then wait for the next song
(if it did not start in the mean time).

There are no cancellation points in this function, so there is no point
cleaning up after those.

Fixes ticket#14939

Because Demux() is not called during PAUSE the GET_PARAMETER keepalives are
sent by the TimeoutPrevention thread.  However this was not giving Live555
a chance to handle the responses through doEventLoop(), and so the responses
were queued up.  Because of a separate issue in handling pipelined
GET_PARAMETER responses in Live555 itself (now fixed, 2015-06-24), after two
GPs this would result in the loss of the PLAY response on resume, locking
everything up.

Even with the fix to Live555, queuing up all GP responses until the stream
is resumed is unpleasant and will eventually overflow Live555's response
buffer.

This fix calls the usual Live555 response handling mechanism for GPs sent
in the background thread during pause.  I have not added it to the normal
GP sends in Demux() because that calls doEventLoop() anyway, and to do so
would add a delay to normal processing.

TimeoutPrevention now requires access to p_demux itself, not just p_sys.

A mutex has been added to protect LIVE555 from simultaneous calls within
Demux() or Control() and the TimeoutPrevention() thread
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

simplifies