First, clear an issue which was causing an assert to fire. Basically, once a decoder pump had entered the error state and was shutdown, it was not clearing its status, and when a substream attempt to recycle the pump, startup was failing an assert (no thread had been created, meaning that the system was not initialized, yet status indicated an error). This was a small one-liner in aah_decoder_pump.cpp. Second, try to become a little nuanced about how we handle errors in the decoder pump. A comment in the code pretty much says it all, but the summary is that we don't want to completely abort playback because a single chunk of ES failed to decode, but if nothing is decoding and we are making no progress at all, we probably need to put the MediaPlayer instance into the fatal Error state and signal the app level so that further action can be taken (automatic recovery attempts followed by bug reports and signalling the user if those fail). This is to address the fallout of http://b/issue?id=5498460, where something at the OMX decoder level becomes unhappy about not being able to obtain an output buffer which eventually unwinds to this assert which results in a dead mediaserver. After this change, the mediaserver will no longer crash, and may even recover (depending on whether or not the OMX unhappiness is transient or not), but the primary issue (unhappy OMX) is probably still around. It is quite difficult to reproduce, I will probably need to open a different bug to track that issue. Change-Id: I5b65b818378a5ae9c915e91b7db7129f0bda6837 Signed-off-by: John Grossman <johngro@google.com>
am 431c3e4c: Merge "Documentation for the VPN sample for ICS SDK. Staging server: http://fredchung.i:9999/resources/samples/ToyVpn/index.html" into ics-mr0
…
…
am 25bcbbb5: am 431c3e4c: Merge "Documentation for the VPN sample for ICS SDK. Staging server: http://fredchung.i:9999/resources/samples/ToyVpn/index.html" into ics-mr0
…
Description
No description provided
Languages
Java
77.3%
Kotlin
9.2%
PowerBuilder
6.6%
C++
5.5%
AIDL
1%