contrib: vpx: missing header
VPX: try to fix mountain lion patch
libvlccore: remove duplicate ldflags
opengl: Fix the ES 1 vs 2 version check

The version string for ES 1 is "OpenGL ES-CM 1.x" or
"OpenGL ES-CL 1.x". For ES 2 it is "OpenGL ES 2.0", while it
seems to be only "3.x" for ES 3.

Since the code is mostly built for either ES 1 or ES 2 (only
Apple support targeting both at the same time, from the same
built object code - but we only use ES 2 on iOS), simplify
this down to a compile time decision.

Signed-off-by: Martin Storsjö <martin@martin.st>
opengl: Make the ES1/ES2 video output work

This mostly consists of ifdeffing out parts selectively from
opengl.c based on whether shaders or the fixed pipeline are
absent.

Both the ES1 and ES2 outputs have been tested on Ubuntu on
a pandaboard. They seem to mostly work fine, but overlay
subpictures seem garbled.

Signed-off-by: Martin Storsjö <martin@martin.st>
opengl: Take w.num into account when calculating the buffer size

Signed-off-by: Martin Storsjö <martin@martin.st>
Don't leak -lmingw32 in LIBS
Don't automatically enable the gles video outputs

They still lack features such as window sizing and mouse events.

Signed-off-by: Martin Storsjö <martin@martin.st>
omxil: Split omx core management to a separate file

The point of the omx core management is to try to load and init the
OMX core once, even if there's multiple e.g. decoder instances. The
reason for this is that there are cases where the OMX core deinit
function will deinitialize the whole core on the first deinit call,
even if init has been called twice.

If this file is to be built as part of multiple separate shared
plugins, each of the plugins will initialize the OMX core separately,
which could cause issues with such OMX cores.

Since the second plugin that uses the OMX core, an OMX vout plugin,
isn't used automatically, and the only OMX implementation it currently
is tested to actually work with (the Broadcom OMX core on Raspberry
Pi) doesn't have issues with being uninitialized multiple times,
there's no need to jump through hoops to fix this theoretical issue.

If we really want to make sure the omx core is loaded and initialized
only once, the plugins need to be loaded with RTLD_GLOBAL and all
the variables in omxil_core.c need to be marked with
__attribute__ ((visibility ("default"))). But that's generally not
an option, and shouldn't be necessary in most cases.
omxil: Split event debug printing to a separate function
omxil: Split event queue handling to a separate struct
omxil: Add an omxil based video output module

This is kept under modules/codes/omxil due to sharing much code
with the omxil codec.
omxil: Try to load the broadcom OMX IL core and host library

The host library is intentionally not unloaded, since it starts
background threads when initialized, and the deinit function does
not stop the threads. Therefore, this library cannot be unloaded
once loaded and initialized.
omxil: Hardcode known roles for OMX broadcom components

This OMX core does not list any roles for the components.
omxil: Signal OMX version 1.1.2 when targeting raspberry pi

The broadcom OMX IL core requires this in order to respond to
requests.

In principle, this shouldn't probably break other OMX implementations,
unless they are picky about it in the same way, requiring version
1.1.1, but still keeping it behind ifdefs just in case.
omxil: Use the alternative OMX_TICKS ABI on the raspberry pi

This changes how some structs are laid out.

OMX on the raspberry pi passes whole OMX structs over to the
VideoCore processor, and the OMX implementation on that processor
uses this ABI.
omxil: Use larger input buffers on the raspberry pi

The default buffer size is not large enough for higher resolution
content.
omxil: Add a Broadcom/Raspberry Pi specific OMX header
omxil_vout: Add broadcom specific calls
omxil: Add a configure option for enabling raspberry pi specific omx code