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
Test:
-manual test with voe_cmd_test.
-manual test with RTPEncode & NetEqRTPPlay.
-manual test with simpleKenny.
-Bit-exact test of iSAC-swb and iSAC-wb with head revision of trunk. The bit-exactness is confirmed on all files generated by running webrtc/modules/audio_coding/codecs/isac/main/test/QA/runiSACLongtest.txt
Review URL: https://webrtc-codereview.appspot.com/937025
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3226 4adac7df-926f-26a2-2b94-8c16560cd09d
The following targets have been merged into audio_coding_unittests:
* cng_unittests
* g711_unittests
* g722_unittests
* isacfix_unittests
* pcm16b_unittests
Some of them were empty and were created with the assumption they were
needed in order to get code coverage (which was actually not needed).
The following test has been removed since it was empty:
* audio_conference_mixer_unittests
BUG=none
TEST=trybots passing (well, except for the unittests that are removed, they're failing until the try server configuration is updated)
Review URL: https://webrtc-codereview.appspot.com/971008
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3222 4adac7df-926f-26a2-2b94-8c16560cd09d
This was caused by not supplying a correct pointer to where fread should read. The files are now opened in binary mode (which I have under stood can cause problems between different OS if it is not done). I also check for EOF when I compare data from fread. Previously the checking for correct amount of bytes read failed when the end of the file had been reached.
BUG=
Review URL: https://webrtc-codereview.appspot.com/937032
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3212 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
- Pad packets (empty) were often NACKed even though they were received.
- Padding only frames (empty) were didn't properly update the decoding state,
and would therefore be NACKed even though they were received.
This is a recommit of r3183. Extensive testing suggest that this may have been caused by virtual machine flakiness.
TBR=mflodman@webrtc.org
BUG=1150
Review URL: https://webrtc-codereview.appspot.com/971011
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3200 4adac7df-926f-26a2-2b94-8c16560cd09d
For Visual Studio versions older than 2012, we are using a
separate reference output file for windows. (All other platforms
share the same generic reference file.) In VS 2012, the output
matches the generic reference, and not the platform-specific one.
Since, the ResourcePath() method cannot change behavior depending
on compiler version, this fix will short-cut ResourcePath() for
VS 2012 or newer (_MSC_VER >= 1700).
Also made NetEqDecodingTest.TestBitExactnes stop on the first diff.
Once there is a difference, the output is no longer bit-exact, and
the test should be declared a failure.
BUG=
TEST=neteq_unittests on VS2012, try bots
Review URL: https://webrtc-codereview.appspot.com/966028
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3199 4adac7df-926f-26a2-2b94-8c16560cd09d
The test computes metrics (average residual loss) for each mask type and size,
for a given set of loss models (random and bursty), and verifies various
behaviour of the codes (including relation/comparison to RS code).
Review URL: https://webrtc-codereview.appspot.com/748008
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3185 4adac7df-926f-26a2-2b94-8c16560cd09d
- Pad packets (empty) were often NACKed even though they were received.
- Padding only frames (empty) were didn't properly update the decoding state,
and would therefore be NACKed even though they were received.
TEST=trybots
BUG=1150
Review URL: https://webrtc-codereview.appspot.com/929031
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3183 4adac7df-926f-26a2-2b94-8c16560cd09d
- Pad packets (empty) were often NACKed even though they were received.
- Padding only frames (empty) didn't properly update the decoding state,
and would therefore be NACKed even though they were received.
TEST=trybots
BUG=1150
Review URL: https://webrtc-codereview.appspot.com/966026
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3181 4adac7df-926f-26a2-2b94-8c16560cd09d
During call setup Opus should always be signaled as a 48000 Hz stereo codec, not depending on what we plan to send, or how we plan to decode received packets.
The previous implementation had different payload types for mono and stereo, which breaks the proposed standard.
While working on this CL I ran in to the problem reported earlier, that we could get a crash related to deleting decoder memory. This should now be solved in Patch Set 3.
BUG=issue1013, issue1112
Review URL: https://webrtc-codereview.appspot.com/933022
git-svn-id: http://webrtc.googlecode.com/svn/trunk@3177 4adac7df-926f-26a2-2b94-8c16560cd09d
