Protect write of send_target_bitrate.

This issue was catch by tsan bot.

BUG=3065
R=stefan@webrtc.org, andrew

Review URL: https://webrtc-codereview.appspot.com/10619004

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5790 4adac7df-926f-26a2-2b94-8c16560cd09d
Add API to allow deducting bitrate from incoming estimates before the capacity is distributed among outgoing video streams. For example, this can be used to reserve space for audio streams.

BUG=
R=stefan@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/10499004

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5791 4adac7df-926f-26a2-2b94-8c16560cd09d
Makes ScreenCapturerMac exclude the window specified in DesktopCapturer::SetExcludedWindow.
No behavior change for now since Chromium has not been updated to call SetExcludedWindow.

BUG=2789
R=sergeyu@chromium.org

Review URL: https://webrtc-codereview.appspot.com/10299004

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5792 4adac7df-926f-26a2-2b94-8c16560cd09d
Fix after auto update in r5787. APPRTCVideoView.h/m was removed incorrectly.

BUG=3121
R=fischman@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/10739004

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5793 4adac7df-926f-26a2-2b94-8c16560cd09d
Re-submit: rev5775

Modify bitrate controller to update bitrate based on process call and not
only whenever a RTCP receiver block is received.

Additionally:
 Add condition to only start rampup after a receiver block is received. This was same as old behaviour but now an explicit check is needed to verify process does not ramps up before the first block.

 Fix logic around capping max bitrate increase at 8% per second. Before it was only increasing once every 1 second and each increase would be as high as 8%. If receiver blocks had a different interval before it would lose an update or waste an update slot and not ramp up as much as a 8% (e.g. if RTCP received < 1 second).

 Did not touch decrease logic, however since it can be triggered more often it
 may decrease much faster and closer to the original written cap of once every
 300ms + rtt.

Note:
 rampup_tests.cc don't seem to be affected by this since there is no packet loss or REMB that go higher than expected cap.
 bitrate_controller_unittests.cc are don't really simulate a clock and the process thread, but trigger update by inserting an rtcp block.

BUG=3065
R=stefan@webrtc.org, mflodman@webrtc.org

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5794 4adac7df-926f-26a2-2b94-8c16560cd09d
talk/: enable _DEBUG in Debug for all posix

Chromium's build/common.gypi defines _DEBUG for Debug builds _except_ on
(OS=="mac" OS=="ios").  But libjingle uses _DEBUG on all platforms so define it on all posix (chromium covers non-posix separately and fine).

BUG=webrtc:3101
R=juberti@google.com

Review URL: https://webrtc-codereview.appspot.com/10699004

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5795 4adac7df-926f-26a2-2b94-8c16560cd09d
Exclude TwoStreamsSendAndFailUnsignalledRecvInOneToOne from TSAN.

Example failure:
http://build.chromium.org/p/client.webrtc/builders/Linux%20Tsan/builds/1458

TBR=wu@webrtc.org
BUG=2380

Review URL: https://webrtc-codereview.appspot.com/10759004

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5796 4adac7df-926f-26a2-2b94-8c16560cd09d
(Auto)update libjingle 63777286-> 63837929

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5797 4adac7df-926f-26a2-2b94-8c16560cd09d
Don't disable experimental AGC in audioproc.

R=aluebs@webrtc.org

Review URL: https://webrtc-codereview.appspot.com/10769004

git-svn-id: http://webrtc.googlecode.com/svn/trunk@5798 4adac7df-926f-26a2-2b94-8c16560cd09d
Add svn mime-type properties to loopback_test files so they can be served from:
https://webrtc.googlecode.com/svn/trunk/webrtc/tools/loopback_test/loopback_test.html


git-svn-id: http://webrtc.googlecode.com/svn/trunk@5799 4adac7df-926f-26a2-2b94-8c16560cd09d