Bug 882027. Route all calls to GetNextFrameStatus for determining the readyState through MediaDecoder::UpdateReadyStateForData on the main thread. r=cpearce

--HG--
extra : rebase_source : 9ea3260f294c633c24e15690fa4bb067af378088
Bug 880601. Emulate a form of keyframe skipping by allowing MediaOmxReader::DecodeVideoFrame to decode more than one video frame if video decoding is falling behind. r=cpearce
If we don't support this in any way, then we get into trouble when there is
plenty of compressed data buffered but for some reason video decoding falls
behind (maybe there was a short period where the video data wasn't available).
Audio playback continues normally, but MediaOmxReader keeps making one call
to ReadAudio and one to ReadVideo, and if each call to ReadAudio decodes at
least as much as the calls to ReadVideo, video decoding can never catch up
to the current audio playback position. So video never plays. And when the
video decoding point gets far enough away from the audio decoding point,
horrible things start to happen, such as video and audio reading completely
different parts of the media cache and interfering with the caching mechanism
(which assumes audio and video reads are close together).

This patch approximates keyframe skipping, and is basically just a way for
MediaOmxReader::DecodeVideoFrame to decode more than one frame at a time
if we need video decoding to catch up.

To prevent pathological situations, we cap both the maximum number of frames
decoded per DecodeVideoFrame and the amount of time we spend in the method
(excluding the time for the last frame).

--HG--
extra : rebase_source : cba95c537fe97df5b696581be8233b6e9cffb70b