add configure option --enable-libyami, default is off

Change-Id: I43a252d01e38d1b991eb2935b195e14bccd82376
OMXVideoDecoderBase: MapRawNV12, check dest buffer size before copy nv12 data
OMXVideoDecoderBase: improve MapRawNV12 to support odd frame size
update output port param for resolution change

paramPortDefinitionOutput.nBufferSize is used by client
to alloc output buffer (gst-omx for example).
chromium doesn't care of it, getDecodedBuffer uses
sizeof(VideoRenderBuffer) when bNativeBufferEnable is true.
even sizeof(VideoRenderBuffer) seems too big,
since only one pointer is set to pBuffer->pPlatformPrivate.

1. Output.nBufferSize inits to OUTPORT_BUFFER_SIZE
2. calculate Output.nBufferSize in HandleFormatChange
3. if decoder gets frame size during start,
   does HandleFormatChange in ProcessorInit

Change-Id: Ieb1c14be1a36fc853db4ae1ed360a7d65ce7cdc6
OMXVideoDecoderBase: call renderDone in processOutPortBuffers

it is incorrect to call renderDone() in PreFillBuffer.
    a) rendering hasn't been done yet
    b) two threads may come here twice:
        there are ComponentBase::Work->OMXVideoDecoderBase::getDecodedBuffer and ComponentBase::CBaseFillThisBuffer
        calling renderDone() twice will confuse codec, since codec usually recycle surface buffer upon this call.

clear pPlatformPrivate after renderDone(), since it has been returned back to codec.
it disclose the issue of flagNativeBuffer in ProcessorPreFillBuffer, fix it.

Change-Id: I48222fd769ff7cc5c5cf8591c89b51ffff4b0721
AVC dec: remove AccumulateBuffer

it fixed one issue that an incorrect frame data is sent from
omx to codec when codec temp-reject one buffer (which should be
retained in omx level)

it is unnecessary and problematic to AccumulateBuffer in OMXVideoDecoderAVC

Change-Id: I3f69e2038c1499308a9c934eac219d5d6b16d66f
add JPEG component
OMXVideoDecoderBase: change MapRawNV12 to CopyRawFrameData

other surface formats (422H for mjpeg) is supported besides NV12
it does real copy instead memory map
OMXVideoDecoderBase: fix wild pointer bug.

mDisplayXPtr is not initialized in OMXVideoDecoderBase constructor
so it is a wild pointer before initialized later.

Signed-off-by: Zhong Cong <congx.zhong@intel.com>
OMXVideodecoderBase: set jpeg output port format basing on input port format

libyami remove mimeType from VideoFormatInfo
libyami:  enable-yami set to yes as default

libyami to be the default parser/codec to omx implementation

Signed-off-by: Daniel Charles <daniel.charles@intel.com>
omx_vp8dec: Component to report Role as video_decoder.vp8

This is the correct role to report, vpx is legacy and should not
be used anymore

Signed-off-by: Daniel Charles <daniel.charles@intel.com>
omx_mjpegdec: fix linking problem with OMXVideoDecodeBase

when using sandbox, libraries are open on a preload sequence and
all symbols need definition.  Once sandbox is locked, loading
libraries is not allowed.

Signed-off-by: Daniel Charles <daniel.charles@intel.com>
1.add __USE_LIBYAMI__
2.add libyami_encoder for avc encoder
Merge branch 'changzhix-staging-rebase' into mystaging-rebase
omx_encoder: move config.h file include to cpp file

config.h file is included from a cpp file. Moving it from header
file

Signed-off-by: Daniel Charles <daniel.charles@intel.com>
OMXVideoDecoderBase: fix frame lost upon EOS

1. it's up to the omxil client (gst-omx for example) to repeately/actively
   retrieve all the decoded buffer after EOS reach input port
2. it's up to the codec lib (libyami for example) to set
   all the cached frame to be outputable
3. omx retains the input buffer (empty buffer with EOS) until there is
   not any output buffer available from decoder
jpegdec: add I420/IMC3 format support

for jpeg decoded video surface, when copying the raw frame data,
add I420/IMC3(driver internal implementation) to I420 format support.

replace uv_width/uv_height to uvWidth/uvHeight to conform the style
omx_comp: enable namespace YamiMediaCodec in videocodec

Signed-off-by: Tang Xin <xin.t.tang@intel.com>
When the resolution is changed to small, does not reset the va context.
So it's ok when vaimage's resolution is larger then video's resolution.