libstagefright: Extended media support via FFMPEG

 * Original work by Michael Chen - https://github.com/omxcodec
 * Kitkat port by Chih-Wei Huang / Android X86 project
 * Additional fixes by Arcee and Cyanogen
 * High resolution support by Cyanogen
 * Lollipop port and refactoring by Cyanogen

------

libstagefright: add null checking to addPlugin

libstagefright: fix error handling of dlsym()

According 'man dlsym', a NULL return from dlsym() doesn't indicate an error.
The correct way to test for an error is to call dlerror() to clear any old
error conditions, then call dlsym(), and then call dlerror() again to check
whether its return value is not NULL.

libstagefright: add more media mimetypes

This is the first step to add the ffmpeg plugins.

libstagefright: add ExtractorPlugin

The patch allows to load an ExtractorPlugin to extend the functions of
DataSource::sniff and MediaExtractor. A plugin has to implement a C
function getExtractorPlugin to fill the MediaExtractor::Plugin struct.

The filename of the plugin could be specified by the
media.stagefright.extractor-plugin property.

Change-Id: I995a37a4f1ab4bba6ca3c24c7001a27a1e3ccb90

FLACExtractor: Add more sample rates support

In FLACExtractor.cpp, it has function to check file's sample rate.
If the input sample rate is not in its list, it will return "unsupported
sample rate" issue. Modify code to make other sample rates (100,1k,42k,46k)
pass the check

Issue: AXIA-1441
Change-Id: I48f91119275560ec6d00feb0dedc70d10aa55262
Signed-off-by: Xiaobing Feng <xiaobing.feng@windriver.com>
Signed-off-by: Matt Gumbel <matthew.k.gumbel@intel.com>

libstagefright: add ffmpeg components

libstagefright: add more decoders

Add support for wma, wmv, ra, ape, dts decoders.

Change-Id: Iaf48a806aa0cef7d9bcb848383fc3d778c8bd248

libstagefright: allow to use the extended extractor in priority

If the meta contains the string "extended-extractor-use",
use the extended extractor first.

add support for rv20, rv30

add ffmpeg heuristic decoder

Change-Id: I5eed11b563ca7f15d44bacfb795d6f3da08ab883

add HEVC(H.265) decoder and cleanup

Squashed the following commits of branch cm_maguro-10.1 from
https://github.com/omxcodec/android_frameworks_av.git
by Michael Chen <omxcodec@gmail.com>

defb904 remove MEDIA_MIMETYPE_AUDIO_MP2
8036958 add fetchUriFromFd func to get file name
91bc7d5 fix videoCompressionFormatString and audioCodingTypeString funcs
f03069f reset FRAME_DROP_FREQ to 0
718b99a add HEVC(H.265) decoder
84f8bf6 cleanup
f026c93 cleanup
440614a add debug info

Change-Id: Ie75db0778f633357e2280aef6d47a0fa3beb823e

AwesomePlayer: use AwesomeLocalRenderer for OMX.ffmpeg.* components

stagefright: Remove duplicate types from QC media defs

Change-Id: I50ecafe79a2985d0868a1ac82464d6ca448aa2c5

Conflicts:
	media/libstagefright/ExtendedMediaDefs.cpp
	media/libstagefright/OMXCodec.cpp

libstagefright: Re-introduce a QCOM_HARDWARE ifdef after the FFMPEG commit

Fixes a build error on non QCOM hardware.

Change-Id: I4a4268b351d0d8bf748dd03ccea0fbab20ed4314

DataSource: Split off ffmpeg sniffer to a second pass, and only if necessary

ffmpeg's sniffer is intended as a grab-all-that-doesn't-work-elsewhere
extractor. Unfortunately, this causes two issues:

- As written, it requires ffmpeg to whitelist any extractors supported
by stagefright, or else it will blindly override them. This has codebase
sync issues, as shown by the VP9 and WAV accidental overrides
- It imposes an in-depth analysis of _all_ media, even that which we
want to be processed quickly by shipping stagefright plugins (hardware
or not). This is mostly noticeable in network streams and thumbnail
generation.

This patch moves FFmpegExtractor to an independent sniffer queue, and
it only invokes it when the regular MediaExtractor hits 1 of 3 conditions:

1 - The confidence in the identified container type is low
2 - No container is identified at all
3 - A video container was found by other extractors, but only 1 stream
(audio or video) was identified.

Change-Id: Ib96ff4f6bc06223fe0e819a57560d3c872a79ddd

stagefright: OMX.ffmpeg.* are software decoders, ensure they're treated as such

Wherever the component name for OMX.google soft decoders is used to identify
a software-based component, do the same for ffmpeg. Things like memory management
and window buffers care about this.

Change-Id: Ib83561936c7383e8726edb073cea9d78f7d1312f

libstagefright: Don't invoke FFMPEG for MP3

Change-Id: Ia30d25d1a994328827f14a286661cd2e1eaa1181
exynos4: libstragefright: add support for samsung colorformat/omx/mfc

Source:
http://git.insignal.co.kr/samsung/exynos/android/platform/frameworks/av/commit/?h=exynos-jb&id=1614612f7ca2a00473d202dbedcb135fadc608ad

Change-Id: Ib40b3cfa1480ecbb69831e7967a81f63719e2ff7

Conflicts:
	media/libstagefright/ACodec.cpp
libstagefright: back off exynos4 hacks

Change-Id: I953f502171bc98854b5d59165057c57b3c65cdaa
libstagefright: align YV12 for software codecs on exynos4

YV12 chroma stide should be aligned to 16 according to the
android framework. But, GSC & Mali couldn't accept a seperate
stride for U & V components. They just use Y_stride/2 as a
UV Stride.

Change-Id: Ibeeb3439ee10a4666420e5fa34ff0a6d6ea7c003
libstagefright: fix YV12 stride for software codecs on exynos4

Change-Id: I3612899d2bffa474eb6447788858911757a7f45d
omx: exynos4: bring inline with jellybean

Change-Id: Ic275fd30a721f8161dcc44c2706b86ab5ea213ba