Close #3745

Close #3351

This is required if one wants to link shared modules.
Signed-off-by: Rafaël Carré <funman@videolan.org>

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

This is now libvlc_track_description_list_release, as agreed at the VDD
technical discussion

This custom setting makes sure the codec actually fills the
OMX buffers with data, instead of opaque pointers to buffers
residing elsewhere.

This is needed in order to get sensible data output on
Nexus S, and most probably also on Galaxy S.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

OMX_SetConfig still lacks a good way to figure out the size of
the passed struct/variable, for now hardcoded to the size of the
only use case.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

The Samsung OMX components on e.g. Nexus S require major == 1
and minor == 0, otherwise they simply return errors on all
SetParameter/GetParameter calls.

Stagefright's OMX client always sets version 1.0.0, which thus
probably should be a safe choice for all android cases.

An alternative would be to store the version to set as a
variable in decoder_sys_t, and set that to 1.0.0 conditionally
only for Samsung OMX components, but that would make
OMX_INIT_COMMON more complex.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

Also rename confusing vlc_free()

We're in 2011 guys !

This adds a fake OMX core implementation, relying the calls
via IOMX to the media server, which contains the actual
OMX core.

Building with IOMX requires private Android headers from the
Android source tree, namely the frameworks/base and
system/core repositories. (Either froyo or gingerbread
should work for building.) This API is not public, has no
ABI guarantees and isn't supported.

Linking also requires libraries extracted from a
froyo/gingerbread device or emulator.

Since there are no ABI guarantees, linking to this API might
make the .so fail to load on some devices, so for proper use
it should be in a dynamically loaded module, separate from the
rest of the VLC core and modules.

Since this can lead to crashes on unsupported devices, it should
only be used in production on whitelisted device/firmware
combinations that are known to work.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>