bug 2171732 This is just to help TI to track down the OMX component issues. Ideally, we still need to have a fix for this issue, since we must take out battery if this occurs.
…he clock is reset. http://b/issue?id=2171037
…c frame instead of IDR. http://b/issue?id=2167163 J.D. & D.S.
This reverts commit a371da5. http://b/issue?id=2164330 J.D. & D.S.
* changes: RIO-7174: Encode AVC Mpeg4Bitrate atom. http://b/issue?id=2039880 The change authors the Mpeg4Bitrate atom. But will -- use avg bitrate as max bitrate; -- DecodeBufferDB is set to 0; There is followup work to address these issues. Since the Gallery app only looks for avg bitrate, this change alone is showing the bitrate info correctly.
http://b/issue?id=2039880 The change authors the Mpeg4Bitrate atom. But will -- use avg bitrate as max bitrate; -- DecodeBufferDB is set to 0; There is followup work to address these issues. Since the Gallery app only looks for avg bitrate, this change alone is showing the bitrate info correctly.
Change https://android-git.corp.google.com/g/#change,27815 modified a config which is NOT used now. This one is the real deal.
…g a 16-byte alignment.
…y processing in AMIO.
Also this change ensures VMIO gets the YUV format BEFORE PVMF_BUFFER_ALLOCATOR_KEY query. So depends on the YUV format, VMIO can decide whether to provide mem allocator or what kind of mem allocator, alloc from heap vs overlay etc.
…Output. This extra call results in a crash if Reset is called during Engine's track selection failure. Extra ResetData call from ThreadLogoff cleanups the Reset command from Command Queue in the MIO, and this ThreadLogoff was called from the callback of command complete of Reset command of Video MIO. When the call returns back to the Video MIO and tries to delete the Reset Command from the queue, it crashes since the command had already been deleted because of ResetData call from ThreadLogoff. There is no need for an extra ResetData call from ThreadLogoff, since ResetData will be called from Reset() and Reset() will always be called before ThreadLogoff.
…need to seek then playback start In PVMFMediaClock the clock observer will pass its driver latency to the clock and the clock will make clock adjustments on its own inside PVMFMediaClock class rather than having each module take care of its latency. Now on android, Audio MIO has a latency of 350 msecs, so when the clock starts, it starts with a value of "-350" msecs (PVMFMediaClock takes care of the latency of the device set by observer). In jitterbuffer node before clock start, estimated server clock is around 4000 msecs and client clock (PVMFMediaClock) is zero (A difference of 4 secs is needed to start the playback, this is the initial amount of buffering required). After clock starts Jitterbuffer again queries for the time, here estimated server clock is again around 4000 msecs but client clock is -350 msecs. Since the queried currenttime is a uint32 variable, the value for the client clock becomes very huge (due to overflow) and is greater than estimated server clock by a very big value. Jitterbuffer node finds the condition of estimated server clock being less than client clock and goes into Underflow condition and Engine goes into Auto-Pause state. Estimated server clock keeps increasing but will not be able to catch the client clock (since it is very big) and player will remain in Underflow condition for long time and hence we see the issue. Fix for the issue - Use PVTimeComparsionUtils class for comparing clock values. The class takes care of -ve values of clock and gives the correct comparison.
…" or "mp4" string. bug 2072271
…s too large for video-only recording
(Change in opencore.git)
…ata retrievers bug 2050320