configure: read_only_relocs is unnecessary on 64-bit OS X

Signed-off-by: Felix Paul Kühne <fkuehne@videolan.org>
macosx: fix mediainfo appearance on future OS X releases (close #12066)
unimotion: fix warning
macosx: contacting an app using SBApplication can fail, be a bit more conservative to prevent runtime exceptions
gestures: avoid undefined negative shift
gestures: cosmetic
mmal: Move video_output plugin into hw/mmal module

As the mmal modules will require some shared code in the future move them out
of the split directory structure into a hw/mmal subdirectory, like it
is handled with vdpau plugins already.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
mmal: Move codec plugin into hw/mmal module

The mmal codec plugin is built as a part of the mmal module now. This drops
the ability to en-/disable codec support independently from the vout, but in
fact currently there is no mmal implementation which wouldn't support both
modules, so it seems sane to build them together as this unclutters the
configure scripts a little.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
mmal/codec: Rework buffer handling

This patch reduces the number of required pictures in the picture pool as well
as the number of required buffer headers on the mmal component. If
MMAL_ENCODING_OPAQUE is used as data format the number of buffers which have
to be provided to the components ports are very critical and there is a
relation between the configured number of buffers at the port and the actual
number of buffers which are available at a port at any time.
The previous approach was rather conservative and allocated a lot of extra
buffers to ensure that things are smooth all the time. This has the drawback
of wasting memory though. Especially when adding another mmal element
(deinterlace filter) it caused a situation where we run out of resources. This
new approach reduces the required resources so that another mmal component can
be added to the chain.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
mmal/vout: Rework buffer handling

This patch reflects the buffer handling improvements done in the mmal codec
module into the the mmal video output module.
A nice side effect of the restructuring is that less magic values need to be
defined as the required values can be computed dynamically now.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
mmal/vout: Remove bad locking

This removes some bad locking. In fact this lock could cause a deadlock on
shutdown as the lock is held by the main thread when shutting down and this
function might be called as a result of shutting the ports down.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
mmal/vout: Fix memory leak

sys->pictures was allocated but not freed.

Signed-off-by: Julian Scheel <julian@jusst.de>
Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Update POTFILES
vout: fix memory leaks

In combination with the previous patch all crashes (double free()) are solved.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
OSS: remove volume/mute code (fixes #10408)
ios compilation script: add support for future Xcode releases
COntribs: fix gnutls build on OSX
h264: add an enum for SEI messages
h264: kill a warning in nal_decode by making src pointer const
input: waiting and flushing states should be mutually exclusive

A crash could occur in the following situation:
1) A video decoder is created and starts waiting for the first picture:
   b_waiting = true, b_first = true

2) The first picture is received but the decoder is still in waiting mode:
   b_waiting = true, b_first = false

3) A second picture is received, the decoder is now waiting in
DecoderWaitUnblock().

4) From the input thread, an EOF event is received, EsOutChangePosition is
called and sets the decoder in flushing mode.

5) The decoder thread wakes up and exits DecoderWaitUnblock because
b_flushing is true. However this triggers the assertion in
DecoderDecodeVideo since we have b_waiting && !b_first.

Fix #11892, #12041