This (compile-time switchable) option automatically starts & stops calls in
series to stress-test the setup/teardown codepaths. When startCPULoad() is
removed (https://webrtc-codereview.appspot.com/972008/) this showed no
hangs/crashes after completing 200 start/stop pairs.
Also fixed a tiny shutdown-order bug (onDestroy() calling super.onDestroy()
before performing self-shutdown) and changed default video frame resolution to
640x480 to more effectively stress the device (and be a more compelling demo).
BUG=1162
Review URL: https://webrtc-codereview.appspot.com/939032
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3238 4adac7df-926f-26a2-2b94-8c16560cd09d
Background:
As of now, MediaCodec API is the only public interface which enables us
to access low level HW resource in Android. ViEMediaCodecDecoder will be
used for further experiments/exploration.
TODO:
To fix known issues. (detaching thread from VM and frequent GC)
Review URL: https://webrtc-codereview.appspot.com/933033
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3233 4adac7df-926f-26a2-2b94-8c16560cd09d
- stopCPULoad is incorrect; since mIsBackgroudLoadRunning isn't declared
volatile, the empty while loop in the background thread isn't required to do a
memory read (as opposed to reading the value just once and caching it). The
result is that stopCPULoad() may never return as the .join() waits forever.
- startCPULoad isn't guaranteed to tax the CPU; the JVM is free to replace the
while loop in startCPULoad() with a thread pause since it can prove it'll
never exit the loop once entered (b/c of the previous item).
It's not clear what correct behavior here would be so I'm deleting the code
rather than trying to make it work. This was responsible for at least most if
not all of the hanginess of start/stop'ing multiple calls in series.
BUG=1162
Review URL: https://webrtc-codereview.appspot.com/972008
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3202 4adac7df-926f-26a2-2b94-8c16560cd09d
BUG=1120
TEST=trybot, local test on xoom and nexus
Message:
It turned out the last CL can only build neon code that
caused problem on Xoom.
Description:
In order to support audo-cpu-detection, I split files into two gypi files, one
contains non-neon code, antoher one ONLY contains neon specific code, so I can
apply different flags to them. Also created two build targets for each of them
We build for linux as before.
Tested on xoom and nexus S.
Review URL: https://webrtc-codereview.appspot.com/930024
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3141 4adac7df-926f-26a2-2b94-8c16560cd09d
